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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 30 Nov 2011 11:10:28 +0100
From:	Michal Hocko <mhocko@...e.cz>
To:	Stanislaw Gruszka <sgruszka@...hat.com>
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 Tue 29-11-11 12:39:07, Stanislaw Gruszka wrote:
> Hi Michal
> 
> 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?

> 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.

> If so I'll try to reproduce it locally, otherwise I'll review related
> code to find reason of that problem.
> 
> Thanks
> Stanislaw 

Thanks

-- 
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9    
Czech Republic
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ