On Tue, 28 May 2002, Peter Wemm wrote:
> Richard Wenninger wrote:
> > /usr/src/sys/vm/uma_core.c:1324: could sleep with "UMA lock" locked from
> > /usr/src/sys/vm/uma-core.c:1157
> >
> > Should I be concerned?
>
> Excessively concerned: no. But these are all *real* problems that must
> be fixed.
>
> Specifically, they are holding locks while calling a function that *might*
> tsleep() if memory is low at the time. If it does tsleep, it will panic or
> otherwise lead to a deadlock or corruption.
>
> The fact that they've gone largely unnoticed until now means that it is not
> an urgent problem (which is why it is a warning), but if you run really low
> of memory you will find out just how serious it is.
I had checks for calling malloc() with M_WAITOK at a nonzero ipl and found
too many problems to notice, so I usually kept the checks turned off. (I
still have the checks, but they are no-ops in -current). Most of the
problems seem to involve booting and networking code. The socket locking
changes in -current seem to have addressed a few of these.
> The bug is that things are calling things like malloc with M_WAITOK when
> waiting is explicitly not allowed. There are other functions that can
> tsleep as well that we have not added checks for yet, so this is likely
> just the tip of the iceberg. :-(
In -current, msleep() could easily check whether it is called with a lock
except the expected one (Giant or mtx). Similar ipl-based checks are
impossible because it is almost mandatory to sleep it a nonzero ipl to
prevent races:
s = splfoo();
while ((foo_p->state & FOO_READY) == 0)
tsleep(...);
// code that depends on foo being ready
splx(s);
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
