Date: Tue, 2 Sep 2003 01:32:56 -0700
From: Mitchell Blank Jr <mitch@sfgoth.com>
To: Nick Piggin <piggin@cyberone.com.au>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] might_sleep() improvements
Message-ID: <20030902083256.GA52644@gaz.sfgoth.com>
References: <20030902075145.GA12817@sfgoth.com> <3F545175.1080505@cyberone.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3F545175.1080505@cyberone.com.au>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1310
Lines: 31

Nick Piggin wrote:
> >Andrew - I thought this might be appropriate for -mm kernels.
> >
> >This patch makes the following improvements to might_sleep():
> >
> >o Add a "might_sleep_if()" macro for when we might sleep only if some
> >  condition is met.  I think this is a bit better than the currently used
> >  "if (cond) might_sleep();" since it's clearer that the test won't be
> >  compiled in if spinlock sleep debugging is turned off.  (Obviously
> >  gcc is smart enough to omit simple conditions in that case)  It also
> >  looks cleaner, IMO.  Think of it as analogous to BUG()/BUG_ON().
> >
> 
> I think these should be pushed down to where the sleeping
> actually happens if possible.

No, you want to generate the warning as early as possible in case the
sleeping case happens very infrequently.  For instance:

	newskb = skb_unshare(skb, GFP_KERNEL);

might not even need to do any allocation (much less a sleep) in 99.9% of
cases, but it's still a bug if it's called in atomic context and we want
spinlock sleep debugging to catch that for us.

-Mitch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/