Skip site navigation (1)Skip section navigation (2)
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>