Date: Wed, 10 Jun 2015 18:24:01 +0300 From: Ivan Klymenko <fidaj@ukr.net> To: Mateusz Guzik <mjguzik@gmail.com> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Mateusz Guzik <mjg@FreeBSD.org> Subject: Re: svn commit: r284215 - in head/sys: amd64/linux32 compat/linux compat/svr4 dev/drm2/i915 fs/fdescfs i386/ibcs2 i386/linux kern ofed/drivers/infiniband/core ofed/drivers/infiniband/hw/mthca sys vm Message-ID: <20150610182401.685fb7b6@nonamehost.local> In-Reply-To: <20150610135337.GC23380@dft-labs.eu> References: <201506101048.t5AAmD1O029382@svn.freebsd.org> <20150610163326.20ab3e0c@nonamehost.local> <20150610135337.GC23380@dft-labs.eu>
next in thread | previous in thread | raw e-mail | index | archive | help
Wed, 10 Jun 2015 15:53:37 +0200 Mateusz Guzik <mjguzik@gmail.com> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0= =B2: > On Wed, Jun 10, 2015 at 04:33:26PM +0300, Ivan Klymenko wrote: > > Wed, 10 Jun 2015 10:48:13 +0000 (UTC) > > Mateusz Guzik <mjg@FreeBSD.org> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0= =B2: > >=20 > > > Author: mjg > > > Date: Wed Jun 10 10:48:12 2015 > > > New Revision: 284215 > > > URL: https://svnweb.freebsd.org/changeset/base/284215 > > >=20 > > > Log: > > > Implement lockless resource limits. > > > =20 > > > Use the same scheme implemented to manage credentials. > > > =20 > > > Code needing to look at process's credentials (as opposed to > > > thred's) is provided with *_proc variants of relevant functions. > > > =20 > > > Places which possibly had to take the proc lock anyway still use > > > the proc pointer to access limits. > > >=20 > > >=20 > >=20 > > I have panic. > > I not sure that it refers to a specific commit. > >=20 > > Fatal trap 12: page fault while in kernel mode > > cpuid =3D 0; apic id =3D 00 > > fault virtual address =3D 0x80 > > fault code =3D supervisor read data, page not present > > instruction pointer =3D 0x20:0xffffffff809cfbfa > > stack pointer =3D 0x28:0xfffffe01aa4906c0 > > frame pointer =3D 0x28:0xfffffe01aa4906e0 > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > > current process =3D 4091 (npviewer.bin) > > trap number =3D 12 > > panic: page fault > > cpuid =3D 0 > > KDB: stack backtrace: > > #0 0xffffffff80a17c27 at kdb_backtrace+0x67 > > #1 0xffffffff809d3f79 at vpanic+0x189 > > #2 0xffffffff809d3de3 at panic+0x43 > > #3 0xffffffff80e73b35 at trap_fatal+0x355 > > #4 0xffffffff80e73e6e at trap_pfault+0x31e > > #5 0xffffffff80e734d4 at trap+0x464 > > #6 0xffffffff80e57422 at calltrap+0x8 > > #7 0xffffffff8097c942 at fdalloc+0x32 > > #8 0xffffffff8097cf95 at finstall+0x95 > > #9 0xffffffff80a99844 at kern_openat+0x3c4 > > #10 0xffffffff8229fe93 at linux_common_open+0xc3 > > #11 0xffffffff822a0068 at linux_open+0x58 > > #12 0xffffffff80f7408b at ia32_syscall+0x41b > > #13 0xffffffff80e57a05 at Xint0x80_syscall+0x95 > > Uptime: 29m1s > > Dumping 854 out of 6047 > > MB:..2%..12%..21%..32%..42%..51%..62%..72%..81%..92% > >=20 > > 221 pcpu.h: No such file or directory. > > in pcpu.h > > (kgdb) #0 doadump (textdump=3D<value optimized out>) at pcpu.h:221 > > #1 0xffffffff809d3a7d in kern_reboot (howto=3D260) > > at /usr/src/sys/kern/kern_shutdown.c:447 > > #2 0xffffffff809d3fb8 in vpanic (fmt=3D<value optimized out>,=20 > > ap=3D<value optimized out>) > > at /usr/src/sys/kern/kern_shutdown.c:744 #3 0xffffffff809d3de3 in > > panic (fmt=3D0x0) at /usr/src/sys/kern/kern_shutdown.c:675 > > #4 0xffffffff80e73b35 in trap_fatal (frame=3D<value optimized out>,=20 > > eva=3D<value optimized out>) > > at /usr/src/sys/amd64/amd64/trap.c:853 #5 0xffffffff80e73e6e in > > trap_pfault (frame=3D0xfffffe01aa490610, usermode=3D<value optimized > > out>) at /usr/src/sys/amd64/amd64/trap.c:676 #6 0xffffffff80e734d4 > > out>in trap (frame=3D0xfffffe01aa490610) > > at /usr/src/sys/amd64/amd64/trap.c:426 > > #7 0xffffffff80e57422 in calltrap () > > at /usr/src/sys/amd64/amd64/exception.S:235 > > #8 0xffffffff809cfbfa in lim_cur (td=3D0xfffff8010185e4c0, which=3D8) > > at /usr/src/sys/kern/kern_resource.c:1209 > > #9 0xffffffff8097c942 in fdalloc (td=3D0xfffff8010185e4c0,=20 > > minfd=3D<value optimized out>, result=3D0xfffffe01aa4907dc) > > at /usr/src/sys/kern/kern_descrip.c:790 > > #10 0xffffffff8097cf95 in finstall (td=3D0xfffff8010185e4c0,=20 > > fp=3D0xfffff80139e89870, fd=3D0xfffffe01aa4907dc, flags=3D1, > > fcaps=3D0x0) at /usr/src/sys/kern/kern_descrip.c:1768 > > #11 0xffffffff80a99844 in kern_openat (td=3D0xfffff8010185e4c0, > > fd=3D-100, path=3D0xfffff80016832400 "/compat/linux/proc/stat", > > pathseg=3DUIO_SYSSPACE, flags=3D<value optimized out>, mode=3D<value > > optimized out>) at /usr/src/sys/kern/vfs_syscalls.c:1158 > > #12 0xffffffff8229fe93 in linux_common_open (td=3D0xfffff8010185e4c0, > > dirfd=3D8, path=3D0xfffff80016832400 "/compat/linux/proc/stat",=20 > > l_flags=3D<value optimized out>, mode=3D51) > > at /usr/src/sys/modules/linux/../../compat/linux/linux_file.c:134 > > #13 0xffffffff822a0068 in linux_open (td=3D<value optimized out>,=20 > > args=3D<value optimized out>) > > at /usr/src/sys/modules/linux/../../compat/linux/linux_file.c:211 > > #14 0xffffffff80f7408b in ia32_syscall (frame=3D0xfffffe01aa490ac0) > > at subr_syscall.c:133 > > #15 0xffffffff80e57a05 in Xint0x80_syscall () at ia32_exception.S:73 > > #16 0x00000000ffffe452 in ?? () > > Previous frame inner to this frame (corrupt stack?) > > Current language: auto; currently minimal > > (kgdb)=20 > >=20 >=20 > The following should fix it: > diff --git a/sys/compat/linux/linux_fork.c > b/sys/compat/linux/linux_fork.c index 0fd47fd..394c26f 100644 > --- a/sys/compat/linux/linux_fork.c > +++ b/sys/compat/linux/linux_fork.c > @@ -298,7 +298,7 @@ linux_clone_thread(struct thread *td, struct > linux_clone_args *args) __rangeof(struct thread, td_startcopy, > td_endcopy));=20 > newtd->td_proc =3D p; > - newtd->td_ucred =3D crhold(td->td_ucred); > + thread_cow_get(newtd, td); > =20 > /* create the emuldata */ > linux_proc_init(td, newtd, args->flags); >=20 > Still, it seems a bug that linux_clone_thread replicates so much of > create_thread. >=20 Seems it helps to solve this problem. Panic more not reproduced. Thank you.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150610182401.685fb7b6>