From owner-freebsd-hackers Wed Aug 13 17:07:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA08801 for hackers-outgoing; Wed, 13 Aug 1997 17:07:39 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id RAA08792; Wed, 13 Aug 1997 17:07:28 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA15802; Wed, 13 Aug 1997 17:02:20 -0700 From: Terry Lambert Message-Id: <199708140002.RAA15802@phaeton.artisoft.com> Subject: Re: 2.2.2+ crash.. more info To: dg@root.com Date: Wed, 13 Aug 1997 17:02:20 -0700 (MST) Cc: terry@lambert.org, julian@FreeBSD.ORG, hackers@FreeBSD.ORG In-Reply-To: <199708132255.PAA18976@implode.root.com> from "David Greenman" at Aug 13, 97 03:55:32 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >> Quite likely. It's fairly easy to have a bug where a resource is exhausted > >> (usually memory) in a subroutine called from an interrupt routine, resulting > >> in a tsleep() if the call to malloc isn't M_NOWAIT. > > > >Is there any way we could talk you into adding an #ifdef DIAGNOSTIC > >to malloc to catch this case? > > To catch which case? malloc() doesn't know a whole lot about the state of > the system; it especially doesn't have knowledge about how interrupts work > and whether or not it is okay sleep. I don't know if we have a way of > knowing this even if we did want to add such machine-dependant checks to > malloc(). In any case, the checks would be best added to tsleep(), not to > malloc(). OK, tsleep() then. The idea is to get a panic and a traceback to proactively detect misbehaving drivers. That means that even if it's not going to sleep, it should test whether an ISR is active vis-a-vis the nonexistance of M_NOWAIT. On second thought, it's a bad idea to put it in tsleep() instead of malloc(); the driver calling a malloc() which could tsleep() is in error, in any case. Putting the test in tsleep() would only mask the error in the case the malloc *might* sleep, but didn't. You really want to catch erroneous use of API's (like this) with DIAGNOSTIC -- regardless of runtime cost involved. Anyway, it was just a thought -- after Mike Smith talked about spending a year tracking one down, it seems a small penalty, even if the ISR dispatcher has to set a flag on entry and exit to make it possible to catch. Since it's only DIAGNOSTIC, I'm not concerned about the expense. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.