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)
        // code that depends on foo being ready


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to