From owner-freebsd-current@FreeBSD.ORG Mon Jun 19 02:39:29 2006 Return-Path: X-Original-To: current@freebsd.org 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 1DDAF16A47C for ; Mon, 19 Jun 2006 02:39:29 +0000 (UTC) (envelope-from csjp@FreeBSD.org) Received: from ems01.seccuris.com (ems01.seccuris.com [204.112.0.35]) by mx1.FreeBSD.org (Postfix) with SMTP id 1796043D45 for ; Mon, 19 Jun 2006 02:39:27 +0000 (GMT) (envelope-from csjp@FreeBSD.org) Received: (qmail 26712 invoked by uid 86); 19 Jun 2006 03:12:52 -0000 Received: from unknown (HELO ?127.0.0.1?) (204.112.0.37) by ems01.seccuris.com with SMTP; 19 Jun 2006 03:12:52 -0000 Message-ID: <44960E61.5000808@FreeBSD.org> Date: Sun, 18 Jun 2006 21:39:29 -0500 From: "Christian S.J. Peron" User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: Peter Jeremy References: <20060618192011.GF715@turion.vk2pj.dyndns.org> In-Reply-To: <20060618192011.GF715@turion.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kris Kennaway , current@freebsd.org Subject: Re: NULL pointer dereference panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 02:39:29 -0000 I've seen this panic a few times before. You can trip using the Peter Holm PTY stress test on SMP systems fairly quickly. This same panic is also the reason I have not committed my Giant removal work from fcntl(2). Now that I've seen this, it's pretty clear that my Giant fcntl(2) work is not directly the cause, but it probably changes the timing enough to make this race easier to hit. So, I think we are seeing this panic occur more frequently because there has been quite a bit of Giant removal/locking work, and it is changing the timing enough to expose other race conditions. Based on some analysis I've been doing, it is my opinion that this race is the result of the problems associated with TTY/devfs interactions. But I have not had the time to get to the bottom of it. Peter Jeremy wrote: > I got the following panic is a fresh -current. Unfortunately, it didn't > do a crash dump - I'm not sure why. Has anyone else seen this? > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x2c > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc052cf96 > stack pointer = 0x28:0xd6690970 > frame pointer = 0x28:0xd6690990 > 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 = 97180 (script) > trap number = 12 > panic: page fault > KDB: stack backtrace: > kdb_backtrace(c07008a8,c076ac80,c06eb1ad,d6690844,100,...) at kdb_backtrace+0x2e > panic(c06eb1ad,c0702b35,d6690930,1,1,...) at panic+0xb7 > trap_fatal(d6690930,2c,c071dc0f,2fd,c2b6f6c0,...) at trap_fatal+0x30e > trap_pfault(d6690930,0,2c,c054f7e1,2c,...) at trap_pfault+0x1ba > trap(8,28,28,c0709faa,1a3,...) at trap+0x461 > calltrap() at calltrap+0x5 > --- trap 0xc, eip = 0xc052cf96, esp = 0xd6690970, ebp = 0xd6690990 --- > _mtx_lock_flags(24,0,c0709faa,1a3,0,...) at _mtx_lock_flags+0x46 > vfs_ref(0,d66909f8,0,d66909dc,c06d4f68,...) at vfs_ref+0x32 > vop_stdgetwritemount(d66909f8,c076ea74,d66909f0,d6690a2c,d6690a14,...) at vop_stdgetwritemount+0x1d > VOP_GETWRITEMOUNT_APV(c073df20,d66909f8,c07b4988,c06fe125,d6690a0c,...) at VOP_GETWRITEMOUNT_APV+0xa8 > vn_start_write(c4251000,d6690a2c,1,2,c0701fa5,...) at vn_start_write+0x37 > vn_close(c4251000,3,c2f37780,c2b6f6c0,6b5,...) at vn_close+0x65 > vn_closefile(c370c750,c2b6f6c0,d6690af0,c0512cce,c370c750,...) at vn_closefile+0xe9 > devfs_close_f(c370c750,c2b6f6c0,c06fca41,876,c370c750,...) at devfs_close_f+0x19 > fdrop_locked(c370c750,c2b6f6c0,c06fca41,861) at fdrop_locked+0xbe > fdrop(c370c750,c2b6f6c0,d6690b38,c0567d6f,c076ea74,0,c07046e5,6b5,c07b4a6c,d6690b68,0,c07b4a68,d6690b64,c0566bba,0,c394872c,246,c0744d24,c394872c,661,c06fca41,d6690b8c,c052d0f2,c394872c,1,c06ff4e5,13 > > closef(c370c750,c2b6f6c0,c06fca41,661,c07b4a68,...) at closef+0x427 > fdfree(c2b6f6c0,0,c06fd2c3,106,d6690c50,...) at fdfree+0x5c6 > exit1(c2b6f6c0,0,d6690d30,c06bf073,c2b6f6c0,...) at exit1+0x57b > sys_exit(c2b6f6c0,d6690d04,4,c2b6f6c0,c33f0000,...) at sys_exit+0x1d > syscall(3b,3b,3b,1,0,...) at syscall+0x2e3 > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x281012fb, esp = 0xbfbfe1ec, ebp = 0xbfbfe1f8 --- > > -- Christian S.J. Peron csjp@FreeBSD.ORG FreeBSD Committer FreeBSD Security Team