Re: NULL pointer dereference panic

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_at_FreeBSD.ORG
FreeBSD Committer
FreeBSD Security Team