Date: Wed, 03 Apr 2002 21:51:49 -0800 From: Peter Wemm <peter@wemm.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: David Greenman <dg@root.com>, Will Froning <wfroning@angui.sh>, hackers@FreeBSD.ORG Subject: Re: Fatal trap 12: page fault while in kernel mode Message-ID: <20020404055149.CE6263811@overcee.wemm.org> In-Reply-To: <3CABE569.D0560F0C@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote:
> David Greenman wrote:
> > >#16 0xc0152220 in tsleep ()
> > >#17 0xc016abfe in m_clalloc_wait ()
> > >#18 0xc01c8b14 in nfs_realign ()
> > >#19 0xc01c9653 in nfsrv_rcv ()
> > >#20 0xc01701d0 in sowakeup ()
> > >#21 0xc01abd7c in udp_input ()
> > >#22 0xc01a1bfb in ip_input ()
> > >#23 0xc01a1c5b in ipintr ()
> >
> > This is basically telling you that there is a bug in the NFS code that i
s
> > incorrectly trying to do a "wait" type of allocation in an interrupt contex
t,
> > which is not valid. You can't sleep when there is no process context.
>
> Amusing.
>
> Then the fix is probably to take the proc pointer of the
> proc whose socket is being used to do the call, which is
> the third argument to nfssvc_addsock(), and put it into
> the structure pointed to by "struct nfssvc_sock *" as the
> argument to the upcall.
>
> Then, in the upcall code in nfsrv_rcv(), pass the proc
> pointer down as the process context.
>
> I think, actually, that multiple sleeps by the same process
> are also disallowed (;^)), so probably...
>
>
> You will need to modify nfs_realign() to take a waitflag,
> as propagated from nfsrv_rcv()... and then pass it through
> on the MCLGET and the MGET, to make sure that if the alloc
> fails, that it's OK.
>
> This does point out a problem in MCLGET() (the macro that
> wraps m_clalloc_wait()) wanting a process context.
>
> Probably, the best thing would be to pass a proc p in, and
> if it's NULL, just imply no wait semantics.
>
> What an ugly mess...
Terry, if you spent half of the time reading the code as speculating and
writing about your wild speculation, you'd know that we already have a
"waitflag" for nfsrv_rcv() to track safeness to wait or not. The bug is that
nfs_realign doesn't take the 'waitflag' argument and has two 'can wait'
mbuf allocation calls.
The fix is trivial and hardly ugly. But then again, anybody who actually
bothered to read the code before posting would know that.
Cheers,
-Peter
--
Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020404055149.CE6263811>