linux-kernel - Re: BUG: scheduling while atomic 2.6.39-rc7 (iwl3945_irq

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 1 Jun 2011 16:43:14 +0200
From:	Stanislaw Gruszka <sgruszka@...hat.com>
To:	James Hogan <james@...anarts.com>
Cc:	"John W. Linville" <linville@...driver.com>,
	linux-wireless@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: BUG: scheduling while atomic 2.6.39-rc7 (iwl3945_irq_tasklet)

On Tue, May 17, 2011 at 09:41:42AM +0100, James Hogan wrote:
> On 16 May 2011 18:25, John W. Linville <linville@...driver.com> wrote:
> > On Fri, May 13, 2011 at 09:34:49PM +0100, James Hogan wrote:
> >> On 2.6.39-rc7 I've seen a panic due to "BUG: scheduling while atomic"
> >> with the backtrace below (not much detail as it was written in a text
> >> message while it was displayed on the screen!). All worked fine in
> >> 2.6.38.
> >>
> >> This was soon after resuming from suspend (enough time to unlock the
> >> screen, but not much else). I think it was the same bug I saw in rc2 but
> >> didn't have time to track down. I can probably get it to happen again if
> >> more detail is needed. It doesn't happen every suspend (I think it had
> >> survived a couple of suspend/resume cycles at this point).
> >>
> >> I could bisect if necessary, but hopefully the backtrace will be enough
> >> to see what's going on?
> >
> > A bisect might be very helpful -- time is short for 2.6.39 already.
> 
> Hmm, it won't reproduce. I'll have to try and bisect this evening, as
> it was in my home network that it hit the BUG before.

We use mutex in atomic contex when changing channel. I'm not sure if
this is the particular problem you have. If you found a way to
reproduce, you may try this patch:

diff --git a/drivers/net/wireless/iwlegacy/iwl-core.c b/drivers/net/wireless/iwlegacy/iwl-core.c
index 42df832..01244b2 100644
--- a/drivers/net/wireless/iwlegacy/iwl-core.c
+++ b/drivers/net/wireless/iwlegacy/iwl-core.c
@@ -861,9 +861,7 @@ void iwl_legacy_chswitch_done(struct iwl_priv *priv, bool is_success)
 
 	if (priv->switch_rxon.switch_in_progress) {
 		ieee80211_chswitch_done(ctx->vif, is_success);
-		mutex_lock(&priv->mutex);
 		priv->switch_rxon.switch_in_progress = false;
-		mutex_unlock(&priv->mutex);
 	}
 }
 EXPORT_SYMBOL(iwl_legacy_chswitch_done);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/