Date: Wed, 10 Jun 2015 15:53:37 +0200 From: Mateusz Guzik <mjguzik@gmail.com> To: Ivan Klymenko <fidaj@ukr.net> Cc: Mateusz Guzik <mjg@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@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: <20150610135337.GC23380@dft-labs.eu> In-Reply-To: <20150610163326.20ab3e0c@nonamehost.local> References: <201506101048.t5AAmD1O029382@svn.freebsd.org> <20150610163326.20ab3e0c@nonamehost.local>
next in thread | previous in thread | raw e-mail | index | archive | help
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> написав: > > > Author: mjg > > Date: Wed Jun 10 10:48:12 2015 > > New Revision: 284215 > > URL: https://svnweb.freebsd.org/changeset/base/284215 > > > > Log: > > Implement lockless resource limits. > > > > Use the same scheme implemented to manage credentials. > > > > Code needing to look at process's credentials (as opposed to > > thred's) is provided with *_proc variants of relevant functions. > > > > Places which possibly had to take the proc lock anyway still use > > the proc pointer to access limits. > > > > > > I have panic. > I not sure that it refers to a specific commit. > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x80 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff809cfbfa > stack pointer = 0x28:0xfffffe01aa4906c0 > frame pointer = 0x28:0xfffffe01aa4906e0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 4091 (npviewer.bin) > trap number = 12 > panic: page fault > cpuid = 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% > > 221 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=<value optimized out>) at pcpu.h:221 > #1 0xffffffff809d3a7d in kern_reboot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:447 > #2 0xffffffff809d3fb8 in vpanic (fmt=<value optimized out>, > ap=<value optimized out>) at /usr/src/sys/kern/kern_shutdown.c:744 > #3 0xffffffff809d3de3 in panic (fmt=0x0) > at /usr/src/sys/kern/kern_shutdown.c:675 > #4 0xffffffff80e73b35 in trap_fatal (frame=<value optimized out>, > eva=<value optimized out>) at /usr/src/sys/amd64/amd64/trap.c:853 > #5 0xffffffff80e73e6e in trap_pfault (frame=0xfffffe01aa490610, > usermode=<value optimized out>) at /usr/src/sys/amd64/amd64/trap.c:676 > #6 0xffffffff80e734d4 in trap (frame=0xfffffe01aa490610) > 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=0xfffff8010185e4c0, which=8) > at /usr/src/sys/kern/kern_resource.c:1209 > #9 0xffffffff8097c942 in fdalloc (td=0xfffff8010185e4c0, > minfd=<value optimized out>, result=0xfffffe01aa4907dc) > at /usr/src/sys/kern/kern_descrip.c:790 > #10 0xffffffff8097cf95 in finstall (td=0xfffff8010185e4c0, > fp=0xfffff80139e89870, fd=0xfffffe01aa4907dc, flags=1, fcaps=0x0) > at /usr/src/sys/kern/kern_descrip.c:1768 > #11 0xffffffff80a99844 in kern_openat (td=0xfffff8010185e4c0, fd=-100, > path=0xfffff80016832400 "/compat/linux/proc/stat", pathseg=UIO_SYSSPACE, > flags=<value optimized out>, mode=<value optimized out>) > at /usr/src/sys/kern/vfs_syscalls.c:1158 > #12 0xffffffff8229fe93 in linux_common_open (td=0xfffff8010185e4c0, dirfd=8, > path=0xfffff80016832400 "/compat/linux/proc/stat", > l_flags=<value optimized out>, mode=51) > at /usr/src/sys/modules/linux/../../compat/linux/linux_file.c:134 > #13 0xffffffff822a0068 in linux_open (td=<value optimized out>, > args=<value optimized out>) > at /usr/src/sys/modules/linux/../../compat/linux/linux_file.c:211 > #14 0xffffffff80f7408b in ia32_syscall (frame=0xfffffe01aa490ac0) > 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) > 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)); newtd->td_proc = p; - newtd->td_ucred = crhold(td->td_ucred); + thread_cow_get(newtd, td); /* create the emuldata */ linux_proc_init(td, newtd, args->flags); Still, it seems a bug that linux_clone_thread replicates so much of create_thread. -- Mateusz Guzik <mjguzik gmail.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150610135337.GC23380>