Re: nfs + msdosfs = crashes & panics

[Jeffrey Hsu <hsu@xxxxxxxxxxx>]

Chris Pressey wrote:

> Fatal trap 12: page fault while in kernel mode
> fault virtual address	= 0x34
> fault code		= supervisor read, page not present
> instruction pointer	= 0x8:0xc01c0009
> stack pointer	        = 0x10:0xc927486c
> frame pointer	        = 0x10:0xc92748b8
> 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		= 456 (nfsd)
> current thread          = pri 10 
> interrupt mask		= none
> panic: from debugger

> #0  0xc017937e in dumpsys ()
> (kgdb) bt
> #0  0xc017937e in dumpsys ()
> #1  0xc0179173 in boot ()
> #2  0xc01795a4 in poweroff_wait ()
> #3  0xc0129989 in db_panic ()
> #4  0xc0129927 in db_command ()
> #5  0xc01299f3 in db_command_loop ()
> #6  0xc012bfb1 in db_trap ()
> #7  0xc02aea66 in kdb_trap ()
> #8  0xc02bfe8e in trap_fatal ()
> #9  0xc02bf90f in trap ()
> #10 0xc01c0009 in msdosfs_write ()
> #11 0xc0209488 in nfsrv_write ()
> #12 0xc021da8a in nfssvc_nfsd ()
> #13 0xc021d385 in nfssvc ()
> #14 0xc02c01d6 in syscall2 ()
> #15 0xc02afa6a in Xint0x80_syscall ()

You're probably indirecting though a non-existent proc-related structure.
The protocol threads don't have a proc structure associated with
them.  Before, there were a bunch of places which incorrectly used
curproc to check things like credentials.   All the places
are going to core dump now.  I've fixed a bunch of places which
incorrectly used curthread, but there are still some left.