Skip site navigation (1)Skip section navigation (2)
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>