linux-kernel - Re: [3.2-rc3] 100% CPU usage while in del_timer_sync from iwl3945_rs_free

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]

Message-ID: <20111130142316.GA2466@redhat.com>
Date:	Wed, 30 Nov 2011 15:23:16 +0100
From:	Stanislaw Gruszka <sgruszka@...hat.com>
To:	Michal Hocko <mhocko@...e.cz>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	"John W. Linville" <linville@...driver.com>,
	linux-wireless@...r.kernel.org
Subject: Re: [3.2-rc3] 100% CPU usage while in del_timer_sync from
 iwl3945_rs_free_sta

On Wed, Nov 30, 2011 at 11:10:28AM +0100, Michal Hocko wrote:
> On Tue 29-11-11 12:39:07, Stanislaw Gruszka wrote:
> > On Tue, Nov 29, 2011 at 11:07:27AM +0100, Michal Hocko wrote:
> > > [I am not sure whether this is ieee80211 or iwl3945 issue so put both
> > > maintainers into loop]
> > The only changed we had in iwlegacy between 3.1 and 3.2-rc, was only 
> > adjustment to mac80211 changes. However I think this is iwlegacy issue,
> > just for some reason bug did not trigger before.
> 
> I have double checked 3.1 and cannot reproduce it.
> Anyway, I have put:
> 
> diff --git a/drivers/net/wireless/iwlegacy/iwl-3945-rs.c b/drivers/net/wireless/iwlegacy/iwl-3945-rs.c
> index 8faeaf2..9221ed4 100644
> --- a/drivers/net/wireless/iwlegacy/iwl-3945-rs.c
> +++ b/drivers/net/wireless/iwlegacy/iwl-3945-rs.c
> @@ -432,6 +432,7 @@ static void iwl3945_rs_free_sta(void *iwl_priv, struct ieee80211_sta *sta,
>  	 * to use iwl_priv to print out debugging) since it may not be fully
>  	 * initialized at this point.
>  	 */
> +	printk("XXX: deleting time: %x\n", rs_sta->rate_scale_flush.base);
>  	del_timer_sync(&rs_sta->rate_scale_flush);
>  }
>  
> And the timer base is really NULL when the issue happens. So, somebody
> probably removed the timer already?

I think we call rs_ops->free_sta without rs_ops->alloc_sta, otherwise
I don't know how it could be NULL in iwl3945_rs_free_sta (excluding memory
corruption or bug in timer internals).

I suspect this could be a regression introduced by commit:

commit 07ba55d7f1d0da174c9bc545c713b44cee760197
Author: Arik Nemtsov <arik@...ery.com>
Date:   Wed Sep 28 14:12:53 2011 +0300

    nl80211/mac80211: allow adding TDLS peers as stations

I'm attaching patch with revert of relevant hunk, because full revert
would be hard currently. Does it workaround problem for you?

> > Is this problem 100% reproducible for you ? 
> 
> Yes, it seems to be sufficient to suspend to RAM while associated and
> turn off the AP before waking up the machine.
> I wasn't able to reproduce just by turning of the AP while associated
> without suspend.

I'm not able to recreate, but I'm not using your config as my system
user-space has problem to startup with it :-(

Stanislaw

View attachment "mac80211_use_sta_info_destroy_addr.patch" of type "text/plain" (556 bytes)