Date: Wed, 14 May 2003 07:00:14 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: grog@FreeBSD.org Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/geom geom_disk.c Message-ID: <20030514.070014.76083395.imp@bsdimp.com> In-Reply-To: <20030514124835.GE4390@wantadilla.lemis.com> References: <20030514081041.GD4390@wantadilla.lemis.com> <30440.1052912279@critter.freebsd.dk> <20030514124835.GE4390@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20030514124835.GE4390@wantadilla.lemis.com>
"Greg 'groggy' Lehey" <grog@FreeBSD.org> writes:
: On Wednesday, 14 May 2003 at 13:37:59 +0200, Poul-Henning Kamp wrote:
: > In message <20030514081041.GD4390@wantadilla.lemis.com>, "Greg 'groggy' Lehey"
: > writes:
: >
: >> malloc() of "16" with the following non-sleepablelocks held:
: >> exclusive sleep mutex g_xup r = 0 (0xc8612ca8) locked @ /src/FreeBSD/5-CURRENT-ZAPHOD/src/sys/geom/geom_io.c:363
: >
: > This is a problem, you cannot sleep in the primary I/O path (ie: strategy()
: > and done()), if you sleep in the I/O path, you stop all I/O processing
: > and if the system needs to page something out to make the ram available
: > to you, you have a deadlock.
:
: I wasn't sleeping. This happened elsewhere as the result of a drive
: going away. I had expected that the panic stack trace would point me
: at it, but it didn't. I'll investigate further when I've fixed the
: current panic.
Malloc might sleep, and the above warning is that it might sleep. You
can't hold mutexes and call malloc. That's what that message is
saying. Phk's explaination of what sleeping means is also correct,
even if you aren't actually sleeping.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030514.070014.76083395.imp>