From owner-freebsd-bugs@FreeBSD.ORG Mon May 19 14:00:35 2003 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4900F37B401 for ; Mon, 19 May 2003 14:00:35 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E473743F85 for ; Mon, 19 May 2003 14:00:34 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h4JL0YUp083951 for ; Mon, 19 May 2003 14:00:34 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h4JL0Yji083950; Mon, 19 May 2003 14:00:34 -0700 (PDT) Date: Mon, 19 May 2003 14:00:34 -0700 (PDT) Message-Id: <200305192100.h4JL0Yji083950@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Mark Gooderum Subject: Re: kern/51352: panic: malloc(M_WAITOK) in interrupt context X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Mark Gooderum List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2003 21:00:35 -0000 The following reply was made to PR kern/51352; it has been noted by GNATS. From: Mark Gooderum To: Mark Gooderum Cc: freebsd-gnats-submit@FreeBSD.org, dada@sbox.tugraz.at, Archie Cobbs 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). >