[ath9k-devel] [PATCH] mac80211: debugfs var for the default aggregation timeout.

Johannes Berg <[email protected]>
Newsgroups org.ath9k.lists.ath9k-devel,org.kernel.vger.linux-wireless
Message-ID <[email protected]>
On Fri, 2016-04-08 at 21:27 -0400, Avery Pennarun wrote:

> > Just to be clear, this crash is only from *reading* the agg_status
> > files.??I don't know if the crashiness reduces when disabling the
> > aggregation timeouts, since that's a separate bug (in which the
> > queue gets stuck and the 'pending' column of this file just keeps
> > increasing).

Oh, right, I was confusing the two. The reading one is even stranger
though, in a way. I have no explanation for it (yet). We could suspect
memory corruption, but why would it specifically hit issues here? Not
very plausible.

> Updated .ko file that definitely has debug symbols this time:
> http://apenwarr.ca/tmp/mac80211-agg-status-crash-debugsyms.ko
> 

Ok, that confirms what I did manually in my previous email - that it
crashed on this:

141			p += scnprintf(p, sizeof(buf) + buf - p, "\t%#.2x",
142					tid_tx ? tid_tx->dialog_token : 0);

(and by hand I'd already checked that it crashed dereferencing the
tid_tx->dialog_token, since tid_tx was the value 0x5b35da40.

If any people more familiar with ARM are reading this - does the value
0x5b35da40 ring a bell? Is that a userspace area? Or an area where the
stack would be? All other points around here seem to look like
0xac0c3c58, or maybe 0x838c6958, but not 0x5b35...., how could we end
up with that?

johannes
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.