Date: Wed, 22 Jan 2003 13:54:24 -0800 From: Alfred Perlstein <bright@mu.org> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: arch@FreeBSD.ORG Subject: Re: M_ flags summary. Message-ID: <20030122215424.GV42333@elvis.mu.org> In-Reply-To: <15919.4208.394911.712558@grasshopper.cs.duke.edu> References: <20030122023246.GP42333@elvis.mu.org> <20030121224148.A75236@unixdaemons.com> <20030121.222025.101592442.imp@bsdimp.com> <20030122100253.A76397@unixdaemons.com> <0aef01c2c23d$0f1ae690$52557f42@errno.com> <20030122155457.A77036@unixdaemons.com> <15919.4208.394911.712558@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
* Andrew Gallatin <gallatin@cs.duke.edu> [030122 13:43] wrote:
>
> The taste "problem" here is that it always used to be safe to sleep
> in a process context. That's not true anymore. Now its safe to
> sleep in a process context if you're not holding any mutexes. So
> there are pleny of sleepable allocation bugs lurking.
>
> If we want to catch sleepable allocation bugs right up front, I
> suggest we put this:
>
> if (!(flags & M_NOWAIT)) {
> WITNESS_SLEEP(1, NULL);
> }
>
> at the top of malloc, and at the top of all entry points to the mbuf
> allocator. Eg, before the system has a chance to pull the allocation
> off of some cache which will succeed 99.5% of the time, except when
> the system is under memory pressure.
>
> Sorry for dragging this in another direction..
This is actually a very good idea. It's too bad that one needs witness
to catch this though. Can you add it, or shall i do it tonight?
--
-Alfred Perlstein [alfred@freebsd.org]
'Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.'
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030122215424.GV42333>