From owner-freebsd-current Mon Mar 10 10: 0:10 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C464037B404 for ; Mon, 10 Mar 2003 10:00:06 -0800 (PST) Received: from mail.speakeasy.net (mail13.speakeasy.net [216.254.0.213]) by mx1.FreeBSD.org (Postfix) with ESMTP id D927B43F85 for ; Mon, 10 Mar 2003 10:00:01 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 31209 invoked from network); 10 Mar 2003 18:00:04 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail13.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 10 Mar 2003 18:00:04 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.6/8.12.6) with ESMTP id h2AHuOhT065526; Mon, 10 Mar 2003 12:56:25 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20030308213535.GE56020@rot13.obsecurity.org> Date: Mon, 10 Mar 2003 13:00:15 -0500 (EST) From: John Baldwin To: Kris Kennaway Subject: Re: NULL pointer problem in pid selection ? Cc: alfred@FreeBSD.org, current@FreeBSD.ORG, Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 08-Mar-2003 Kris Kennaway wrote: > On Sat, Mar 08, 2003 at 11:46:34AM +0100, Poul-Henning Kamp wrote: >> >> Just got this crash on -current, and I belive I have seen similar >> before. addr2line(1) reports the faulting address to be >> ../../../kern/kern_fork.c:395 >> which is in the inner loop of pid collision avoidance. > > I've been running this patch from Alfred for the past month or so on > bento, which has fixed a similar panic I was seeing regularly. Using just a shared lock instead of an xlock should be ok there. You aren't modifying the process tree, just looking at it. OTOH, the proc lock is supposed to protect p_grp and p_session, so they shouldn't be NULL. :( > Kris > > Index: kern/kern_fork.c > =================================================================== > RCS file: /home/ncvs/src/sys/kern/kern_fork.c,v > retrieving revision 1.186 > diff -u -r1.186 kern_fork.c > --- kern/kern_fork.c 27 Feb 2003 02:05:17 -0000 1.186 > +++ kern/kern_fork.c 4 Mar 2003 00:28:09 -0000 > @@ -325,6 +325,7 @@ > * exceed the limit. The variable nprocs is the current number of > * processes, maxproc is the limit. > */ > + sx_xlock(&proctree_lock); > sx_xlock(&allproc_lock); > uid = td->td_ucred->cr_ruid; > if ((nprocs >= maxproc - 10 && uid != 0) || nprocs >= maxproc) { > @@ -432,6 +433,7 @@ > LIST_INSERT_HEAD(&allproc, p2, p_list); > LIST_INSERT_HEAD(PIDHASH(p2->p_pid), p2, p_hash); > sx_xunlock(&allproc_lock); > + sx_xunlock(&proctree_lock); > > /* > * Malloc things while we don't hold any locks. > @@ -757,6 +759,7 @@ > return (0); > fail: > sx_xunlock(&allproc_lock); > + sx_xunlock(&proctree_lock); > uma_zfree(proc_zone, newproc); > if (p1->p_flag & P_THREADED) { > PROC_LOCK(p1); > > >> >> Poul-Henning >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 0; lapic.id = 00000000 >> fault virtual address = 0x14 >> fault code = supervisor read, page not present >> instruction pointer = 0x8:0xc01c3eec >> stack pointer = 0x10:0xe74e3c74 >> frame pointer = 0x10:0xe74e3cbc >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, def32 1, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 99777 (sh) >> trap number = 12 >> panic: page fault >> cpuid = 0; lapic.id = 00000000 >> Stack backtrace: >> backtrace(c032ff8e,0,c03394ce,e74e3b68,1) at 0xc01d86a7 = backtrace+0x17 >> panic(c03394ce,c0342131,cfe5496c,1,1) at 0xc01d87ba = panic+0x10a >> trap_fatal(e74e3c34,14,c03422ba,2e3,cfe4fa50) at 0xc02fa672 = trap_fatal+0x322 >> trap_pfault(e74e3c34,0,14,c035a038,14) at 0xc02fa322 = trap_pfault+0x1c2 >> trap(18,10,10,cf19c3f8,cf76b9ec) at 0xc02f9e9d = trap+0x3cd >> calltrap() at 0xc02e2cd8 = calltrap+0x5 >> --- trap 0xc, eip = 0xc01c3eec, esp = 0xe74e3c74, ebp = 0xe74e3cbc --- >> fork1(cfe4fa50,14,0,e74e3cd4,cfe54858) at 0xc01c3eec = fork1+0x3fc >> fork(cfe4fa50,e74e3d10,c03422ba,404,0) at 0xc01c3852 = fork+0x52 >> syscall(2f,2f,2f,0,80ff000) at 0xc02fa98e = syscall+0x26e >> Xint0x80_syscall() at 0xc02e2d2d = Xint0x80_syscall+0x1d >> --- syscall (2), eip = 0x807ba9f, esp = 0xbfbff6bc, ebp = 0xbfbff6e8 --- >> boot() called on cpu#0 >> >> -- >> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 >> phk@FreeBSD.ORG | TCP/IP since RFC 956 >> FreeBSD committer | BSD since 4.3-tahoe >> Never attribute to malice what can adequately be explained by incompetence. >> >> To Unsubscribe: send mail to majordomo@FreeBSD.org >> with "unsubscribe freebsd-current" in the body of the message -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message