From owner-freebsd-current@FreeBSD.ORG  Fri Apr 25 09:06:17 2003
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 3CD5137B401; Fri, 25 Apr 2003 09:06:17 -0700 (PDT)
Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 11C3A43FBD; Fri, 25 Apr 2003 09:06:16 -0700 (PDT)
	(envelope-from phk@phk.freebsd.dk)
Received: from critter.freebsd.dk (localhost [127.0.0.1])
	by critter.freebsd.dk (8.12.9/8.12.9) with ESMTP id h3PG6Cwd009418;
	Fri, 25 Apr 2003 18:06:12 +0200 (CEST)
	(envelope-from phk@phk.freebsd.dk)
To: Bruce Evans <bde@zeta.org.au>
From: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
In-Reply-To: Your message of "Sat, 26 Apr 2003 01:48:54 +1000."
             <20030426013438.W38897@gamplex.bde.org> 
Date: Fri, 25 Apr 2003 18:06:12 +0200
Message-ID: <9417.1051286772@critter.freebsd.dk>
cc: gibbs@freebsd.org
cc: current@freebsd.org
Subject: Re: lots of malloc(M_WAITOK)'s in interrupt context from camisr 
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Apr 2003 16:06:17 -0000

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.