Date: Wed, 29 May 2002 21:09:01 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Peter Wemm <peter@wemm.org> Cc: Richard Wenninger <richard@richardw.net>, <current@FreeBSD.ORG> Subject: Re: UMA lock Message-ID: <20020529204116.T24797-100000@gamplex.bde.org> In-Reply-To: <20020529040704.A8A96380A@overcee.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020529204116.T24797-100000>