Date: Mon, 19 Jun 2006 09:29:25 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: "Christian S.J. Peron" <csjp@FreeBSD.org> Cc: Peter Jeremy <peterjeremy@optushome.com.au>, Kris Kennaway <kris@FreeBSD.org>, current@freebsd.org, dunstan@FreeBSD.org Subject: Re: NULL pointer dereference panic Message-ID: <20060619092805.F8526@fledge.watson.org> In-Reply-To: <44960E61.5000808@FreeBSD.org> References: <20060618192011.GF715@turion.vk2pj.dyndns.org> <44960E61.5000808@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 18 Jun 2006, Christian S.J. Peron wrote: > 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. Wojciech Koszek has been doing some work to debug a related pty/pts/devfs problem, and mentioned to me a day or so ago that he may have identified a workaround (and maybe a fix)? If this panic is a result of the same or a related problem, his work may be relevant. I've CC'd him. Robert N M Watson Computer Laboratory University of Cambridge > > > 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 > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060619092805.F8526>