From: Bob Copeland <me@bobcopeland.com>
To: Jiri Slaby <jirislaby@gmail.com>
Cc: Sitsofe Wheeler <sitsofe@yahoo.com>,
Nick Kossifidis <mickflemm@gmail.com>,
Frederic Weisbecker <fweisbec@gmail.com>,
linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org,
ath5k-devel@venema.h4ckr.net,
"Luis R. Rodriguez" <lrodriguez@atheros.com>
Subject: Re: [TIP] BUG kmalloc-4096: Poison overwritten (ath5k_rx_skb_alloc)
Date: Sun, 8 Mar 2009 12:10:51 -0400 [thread overview]
Message-ID: <20090308161051.GA17812@hash.localnet> (raw)
In-Reply-To: <49B38FB7.3000002@gmail.com>
On Sun, Mar 08, 2009 at 10:28:23AM +0100, Jiri Slaby wrote:
>> bf_last is no longer a
>> valid marker for the self-linked descriptor at the end of the loop since
>> we re-add the just-processed descriptor every time through the loop
>> (or am I missing something?)...
>
> Why? bf_last is snapshotted before the loop. And when we see this bf
> while processing, we stop. In the next round we check if bf->next is
> done. If yes, we move on.
I think it works for the first one but doesn't take into account
subsequent self-linked descriptors. E.g. if we start with buffers:
A->B->C
bf_last is 'C'. The hardware sees descriptors:
A'->B'->C'(->C')
After one round, the hardware sees:
B'->C'->A'(->A')
Suppose the hardware does A',B',C' before we process any buffer. So after
we process A, the hardware moves on to A'. It finishes a packet, re-reads
the link and starts overwriting A' again, but for some reason is really
slow to complete this second packet.
Now, the tasklet burns through B and C. On C we do the check if bf->next
(i.e. A) is done, and it is because the hardware wrote one packet to it[1].
However, it's still in the process of writing another frame over A' again.
We skip C, send A to __ieee80211_rx, the skb is freed, but the hardware
is still writing stuff to it.
In the trace Sitsofe posted, I didn't see any tasklets processing more
than a couple of packets, though.
[1] Note, the status is cleared when we hand the buffer to hardware, but
not by the hardware itself when it rewrites the same buffer. That could
explain why status is "martian" for overwritten frames.
>> If you want I'll cook up a patch for that too.
>
> If you like, feel free to kick it off. Remember to remove bf->flags
> completely, so that we save another bunch of memory ;).
Ok, I probably won't get to it until this evening so if you prefer to
do it, go ahead - otherwise I'll tackle it then.
--
Bob Copeland %% www.bobcopeland.com
next prev parent reply other threads:[~2009-03-08 16:11 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-22 11:18 [TIP] BUG kmalloc-4096: Poison overwritten (ath5k_rx_skb_alloc) Sitsofe Wheeler
2009-02-22 12:01 ` Jiri Slaby
2009-02-22 12:20 ` Sitsofe Wheeler
2009-02-22 12:47 ` Jiri Slaby
2009-02-22 14:47 ` Frederic Weisbecker
2009-02-22 17:02 ` Sitsofe Wheeler
2009-02-22 17:10 ` Frederic Weisbecker
2009-02-22 19:27 ` Jiri Slaby
2009-02-22 19:42 ` Frederic Weisbecker
2009-02-22 20:18 ` Sitsofe Wheeler
2009-02-22 20:27 ` Jiri Slaby
2009-02-22 20:30 ` Frederic Weisbecker
2009-02-22 21:56 ` Jiri Slaby
2009-02-22 22:21 ` Sitsofe Wheeler
2009-02-22 23:20 ` Jiri Slaby
2009-02-23 15:35 ` Bob Copeland
2009-02-23 16:03 ` Nick Kossifidis
2009-02-23 16:15 ` Nick Kossifidis
2009-02-23 16:21 ` Bob Copeland
2009-02-23 16:27 ` Nick Kossifidis
2009-02-23 16:30 ` Bob Copeland
2009-02-23 16:41 ` Nick Kossifidis
2009-02-23 16:44 ` Bob Copeland
2009-02-23 16:16 ` pat-lkml
2009-02-23 16:20 ` Nick Kossifidis
2009-02-23 22:22 ` Jiri Slaby
2009-02-23 22:43 ` Jiri Slaby
2009-02-23 23:08 ` Nick Kossifidis
2009-02-24 13:58 ` Bob Copeland
2009-02-24 21:47 ` Jiri Slaby
2009-02-25 14:01 ` Sitsofe Wheeler
2009-02-26 1:06 ` Bob Copeland
2009-02-26 20:53 ` Jiri Slaby
2009-02-26 21:05 ` Bob Copeland
2009-02-26 13:59 ` Bob Copeland
2009-02-26 17:03 ` Sitsofe Wheeler
2009-03-02 17:34 ` [ath5k-devel] " Bob Copeland
2009-03-03 4:12 ` Bob Copeland
2009-03-03 20:03 ` Sitsofe Wheeler
2009-03-04 12:07 ` Bob Copeland
2009-03-06 9:42 ` Sitsofe Wheeler
2009-03-07 4:47 ` Bob Copeland
2009-03-07 8:04 ` Sitsofe Wheeler
2009-03-07 13:34 ` Bob Copeland
2009-03-08 3:09 ` Bob Copeland
2009-03-08 9:28 ` Jiri Slaby
2009-03-08 16:10 ` Bob Copeland [this message]
2009-03-10 0:43 ` Bob Copeland
2009-03-10 8:19 ` Sitsofe Wheeler
2009-03-12 6:10 ` Sitsofe Wheeler
2009-03-13 9:52 ` Sitsofe Wheeler
2009-03-13 12:28 ` Bob Copeland
2009-03-20 13:14 ` Bob Copeland
2009-03-29 14:24 ` Sitsofe Wheeler
2009-03-29 15:14 ` Bob Copeland
2009-03-31 8:30 ` Sitsofe Wheeler
2009-05-13 21:44 ` Sitsofe Wheeler
2009-05-15 4:09 ` Bob Copeland
2009-05-18 10:05 ` Sitsofe Wheeler
2009-05-22 9:39 ` Sitsofe Wheeler
2009-05-22 12:06 ` Bob Copeland
2009-05-26 21:10 ` Sitsofe Wheeler
2009-06-28 20:23 ` Sitsofe Wheeler
2009-07-14 2:24 ` Bob Copeland
2009-02-26 1:11 ` Bob Copeland
2009-02-22 20:17 ` Bob Copeland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090308161051.GA17812@hash.localnet \
--to=me@bobcopeland.com \
--cc=ath5k-devel@venema.h4ckr.net \
--cc=fweisbec@gmail.com \
--cc=jirislaby@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=lrodriguez@atheros.com \
--cc=mickflemm@gmail.com \
--cc=sitsofe@yahoo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).