[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    Re: 2.2.2+ crash.. more info
From:       Terry Lambert <terry () lambert ! org>
Date:       1997-08-14 0:02:20
[Download RAW message or body]

> >>    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.

[prev in list] [next in list] [prev in thread] [next in thread]