Date: Wed, 13 Aug 1997 17:02:20 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: dg@root.com Cc: terry@lambert.org, julian@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: 2.2.2+ crash.. more info Message-ID: <199708140002.RAA15802@phaeton.artisoft.com> In-Reply-To: <199708132255.PAA18976@implode.root.com> from "David Greenman" at Aug 13, 97 03:55:32 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708140002.RAA15802>