From owner-svn-src-head@FreeBSD.ORG Wed Jun 10 13:53:44 2015 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BBCC7CE9; Wed, 10 Jun 2015 13:53:44 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48B711BEB; Wed, 10 Jun 2015 13:53:44 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by wiga1 with SMTP id a1so49301789wig.0; Wed, 10 Jun 2015 06:53:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=/AL510lTEptpL1N7bEPF8Plq2TyFBEmclSd4flA3sQQ=; b=xLLhfWlKMYIhW8p7pDIz9ggVFIP2VyBVDl9rzh5XkYMuLp6aCkq4A3Q7EWI1snHTNe QuuKkCyCTlUJmzVfqS/eEfwEwiErxflSyXOd6PGkrh1nu3Hi4iSsL7sadntJpeJ7Mkv5 6Ka0Z4O2rusVOpFFo67xa6wTxYiWL8wJG0A5HA9qz1rbHh1c2+lPYNHVc4PqWEAuxwn5 UgzC8Ymd4PCaSXeekdjG8Th06N63zWDGlRW0SqCYwHbjLMfxRvRwrjDxsEQ7Hbmbju8g 6gdUD7dRQJm/MfxC3yo094e9/ek7J+ZEO5cZ86kS50PjbZcdSbNgFje20uGAos6GyWsz qSjg== X-Received: by 10.180.14.193 with SMTP id r1mr19149232wic.47.1433944422735; Wed, 10 Jun 2015 06:53:42 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id w11sm14699919wjr.48.2015.06.10.06.53.39 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 10 Jun 2015 06:53:40 -0700 (PDT) Date: Wed, 10 Jun 2015 15:53:37 +0200 From: Mateusz Guzik To: Ivan Klymenko Cc: Mateusz Guzik , 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> References: <201506101048.t5AAmD1O029382@svn.freebsd.org> <20150610163326.20ab3e0c@nonamehost.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20150610163326.20ab3e0c@nonamehost.local> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 13:53:45 -0000 On Wed, Jun 10, 2015 at 04:33:26PM +0300, Ivan Klymenko wrote: > Wed, 10 Jun 2015 10:48:13 +0000 (UTC) > Mateusz Guzik написав: > > > 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=) 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=, > ap=) 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=, > eva=) at /usr/src/sys/amd64/amd64/trap.c:853 > #5 0xffffffff80e73e6e in trap_pfault (frame=0xfffffe01aa490610, > usermode=) 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=, 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=, mode=) > 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=, mode=51) > at /usr/src/sys/modules/linux/../../compat/linux/linux_file.c:134 > #13 0xffffffff822a0068 in linux_open (td=, > args=) > 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