From owner-freebsd-current Wed May 29 4: 5:56 2002 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 01C2537B40A for ; Wed, 29 May 2002 04:05:53 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id VAA17707; Wed, 29 May 2002 21:05:40 +1000 Date: Wed, 29 May 2002 21:09:01 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Peter Wemm Cc: Richard Wenninger , Subject: Re: UMA lock In-Reply-To: <20020529040704.A8A96380A@overcee.wemm.org> Message-ID: <20020529204116.T24797-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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