[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1255257462.4095.79.camel@johannes.local>
Date: Sun, 11 Oct 2009 12:37:42 +0200
From: Johannes Berg <johannes@...solutions.net>
To: Michael Buesch <mb@...sch.de>
Cc: Dave Young <hidave.darkstar@...il.com>,
linux-kernel@...r.kernel.org, tglx@...utronix.de,
linux-wireless <linux-wireless@...r.kernel.org>,
"David S. Miller" <davem@...emloft.net>
Subject: Re: NOHZ: local_softirq_pending 08
On Sun, 2009-10-11 at 12:17 +0200, Michael Buesch wrote:
> Ehm, no. That's not exactly true.
> We call the non-_irqsafe functions, which by definition are designed to
> run in non-irq (soft or hard) context. At least that's how I understand the
> documentation, last time I read it.
So maybe the documentation is not entirely accurate. Such happens. From
this and previous threads tt's pretty obvious that these functions
cannot be called with softirqs enabled. And I've also stated before that
I do not believe that we should call them with softirqs enabled without
auditing the code for locking, which historically has been a weak point
of mac80211.
> Why don't you simply do local_bh_disable() in those functions, if they
> require bh disabled, instead of depending on the driver doing it?
>
> > FWIW, I believe the bug to be in b43 and wl12x1, and not as Michael
> > thinks in the stack.
>
> If mac80211 requires BHs disabled, it should do this.
I don't believe adding that into mac80211, even though it nests, is a
good idea for the case of many drivers where mac80211 and/or the driver
knows. It's pretty damn trivial to add two lines of code to the driver,
instead of penalising every other driver. The typical kernel style is
making things provide the required context, not a function take any
possible context.
johannes
Download attachment "signature.asc" of type "application/pgp-signature" (802 bytes)
Powered by blists - more mailing lists