lots of malloc(M_WAITOK)'s in interrupt context from camisr

[Poul-Henning Kamp]

In message <20030426013438.W38897 at 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 at 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.