Date: Fri, 25 Apr 2003 18:06:12 +0200 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Bruce Evans <bde@zeta.org.au> Cc: current@freebsd.org Subject: Re: lots of malloc(M_WAITOK)'s in interrupt context from camisr Message-ID: <9417.1051286772@critter.freebsd.dk> In-Reply-To: Your message of "Sat, 26 Apr 2003 01:48:54 %2B1000." <20030426013438.W38897@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20030426013438.W38897@gamplex.bde.org>, Bruce Evans writes:
>+ if (flags & M_WAITOK)
>+ if (curthread->td_ithd != NULL ||
>+ curthread->td_intr_nesting_level != 0)
>+ Debugger("malloc(M_WAITOK) in interrupt context");
>[...]
>The mallocs are actually in sysctl support code and other subsystems that
>camisr wanders off into, so the fix isn't just to use M_NOWAIT.
I would tend to think that while sleeping in interrupt threads
should be avoided, it should only be avoided "at reasonable cost",
not "at any cost".
For example, CAM creates new devices from its interrupt context and
ends up calling make_dev().
While I probably could implement make_dev() in a M_NOWAIT fashion, it
is certainly not worth it considering how often/seldom it is used
and the general havoc and delay we usually encounter at the hardware
level when it is called.
Of course, changing CAM to create devices in some other context than
interrupt would solve this particular instance, but I belive we already
have other similar corner cases.
So maybe we need a malloc flag more, to indicate that "Yeah, I know
I really shouldn't sleep here, but the alternative is worse".
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9417.1051286772>