Date: Mon, 19 May 2003 14:00:34 -0700 (PDT) From: Mark Gooderum <mark@verniernetworks.com> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/51352: panic: malloc(M_WAITOK) in interrupt context Message-ID: <200305192100.h4JL0Yji083950@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/51352; it has been noted by GNATS. From: Mark Gooderum <mark@verniernetworks.com> To: Mark Gooderum <mark@verniernetworks.com> Cc: freebsd-gnats-submit@FreeBSD.org, dada@sbox.tugraz.at, Archie Cobbs <archie@packetdesign.com> Subject: Re: kern/51352: panic: malloc(M_WAITOK) in interrupt context Date: Mon, 19 May 2003 14:00:05 -0700 Sorry - probably a false alarm on my part - confusing splnet() with intr_nesting_level. -- Mark > I've managed to trigger this running a kernel with DIAGNOSTIC and > INVARIANTS - the core is always the traceback below. This is running > 4.7. > > The offending MALLOC() is in dup_sockaddr() - which takes a flag for > "canblock". The dup_sockaddr() call is from sorecieve() which > _always_ calls dup_sockaddr() at splnet() with the canwait flag > usually set to true (always in this particular code path down from > recvfrom() as far as I can tell). Something here is a bug - if the > MALLOC() blocks the socket code can get back to where it is so the > splnet() to protect that socket is in fact not protecting the socket > so I can see bad JuJu happening but I haven't discerned the full > nature of this juju. > > But I don't understand enough of the socket code yet to say whether I > can safely say don't wait always (as it looks like the code doesn't > particulary seem to check or care if the dup fails). >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200305192100.h4JL0Yji083950>