netdev - RE: iwlwifi worse than ever in current git.

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: <0BA3FCBA62E2DC44AF3030971E174FB3079B13@HASMSX103.ger.corp.intel.com>
Date:	Fri, 20 Jan 2012 06:50:36 +0000
From:	"Grumbach, Emmanuel" <emmanuel.grumbach@...el.com>
To:	Dave Jones <davej@...hat.com>
CC:	Emmanuel Grumbach <egrumbach@...il.com>,
	Dan Williams <dcbw@...hat.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"Guy, Wey-Yi W" <wey-yi.w.guy@...el.com>,
	Linux Wireless <linux-wireless@...r.kernel.org>
Subject: RE: iwlwifi worse than ever in current git.

> 
> On Thu, Jan 19, 2012 at 08:38:35PM +0000, Grumbach, Emmanuel wrote:
>  > >
>  > > >
>  > > > On Thu, Jan 19, 2012 at 08:47:28AM +0200, Emmanuel Grumbach wrote:
>  > > >  > Ok, I finally had a change to take a closer look at this. Please run
>  > > >  > with debug=0xC0000000.
>  > > >  >
>  > > >  > This will be noisy, but I guess we have no choice...
>  > > >  > I will be travelling next week, so...
>  > > >
>  > > > Ah. Got it. I had to do a large download (a kernel tarball was enough)
> to
>  > > > trigger it.
>  > > > Log is at http://davej.fedorapeople.org/iwl-debug.txt
>  > > >
>  > > > The download began at around 13:17 in the log.
>  > > > It hung shortly afterwards.
>  > > >
>  > > > 	Dave
>  > >
>  > > Thanks for that one. Really helpful. I need to send you a patch to get a
>  > > little more data. I don't know when I will be able to do it though.
>  >
>  > Can you please retry with the patch attached ?
> 
> Hung again.
> 
> http://davej.fedorapeople.org/iwl-debug2.txt
> 
> 	Dave

Thanks. From what I see, a management frame is sent from an AC queue and when we get the Tx response for this frame, we get sta_id = AP, tid = 0 (and the bug is probably here). So we modify the counters for sta_id = AP, and tid = 0, and this messes up everything.
I guess I need to see why I don't see this issue, and see how to give a hint to the Tx response path that counters shouldn't be modified.

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html