linux-kernel - Re: iwlagn is getting very shaky

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] [day] [month] [year] [list]

Message-ID: <1323958053.3337.48.camel@jlt3.sipsolutions.net>
Date:	Thu, 15 Dec 2011 15:07:33 +0100
From:	Johannes Berg <johannes@...solutions.net>
To:	Emmanuel Grumbach <egrumbach@...il.com>
Cc:	Norbert Preining <preining@...ic.at>,
	"Guy, Wey-Yi" <wey-yi.w.guy@...el.com>,
	Pekka Enberg <penberg@...helsinki.fi>,
	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Dave Jones <davej@...hat.com>,
	David Rientjes <rientjes@...gle.com>
Subject: Re: iwlagn is getting very shaky

So I finally looked at this ...

On Sun, 2011-12-11 at 21:56 +0200, Emmanuel Grumbach wrote:
> >> Could something be hogging the workqueues?

> > So I tried to understand what is going on with the workqueue and ended
> > up to see that if we are lucky, we can need the workqueue for the BA
> > handshake (could be AddBA / DelBA handling, or driver callback) while
> > we are scanning. Which basically means that we will need to wait until
> > the scan is over to handle these frames / callbacks. I got these
> > measurements while stopping the BA session:
> >
> > * scanning working for roughly 3 seconds (pardon me not being precise,
> > but with this order of magnitude I don't care much about the single
> > millisecond..)

Oh. I see, while scanning we won't process the work queue.

> > * when scanning is over, the while loop in ieee80211_iface_work
> > consumes 73 mgmt for about 34ms.
> > ( how come we have so many beacons during those 3 seconds..., or maybe
> > all the BCAST probe request ?, my network is quite busy...)
> > * then the finally my stop_tx_ba_cb was served which took 10ms (time
> > takes by the driver).
> > * another series of beacons (10ms).
> 
> What about flushing the workqueue before we scan ?
> This is not a bullet proof solution of course, we will still encounter
> bad races, but at least  we would flush what we can before the
> workqueue becomes unable for 4 seconds (!).

Yeah, that seems like a good thing. Actually I had an idea about this
before -- drain & stop the workqueue for any functions in mac80211/cfg.c
so that mac80211 essentially becomes single-threaded.

> We can also delay the scan if we are in the middle of {add,del}BA
> handshake, which is the only flow I can think about that needs
> responsiveness. The other frame exchanges are MLME ones and involve
> the wpa_supplicant (unless we are using the late WEXT). Hopefully the
> wpa_supplicant won't request to scan in the middle of association or
> so. There might be other features (mesh or whatever), that may be
> hidden from the wpa_supplicant and require good responsiveness from
> the wq too.

Hm, yeah, that would be an idea too, but I'm not sure it's easy to do
right now.

johannes

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