From: Jiri Slaby <jirislaby@gmail.com>
To: Bob Copeland <me@bobcopeland.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, 08 Mar 2009 10:28:23 +0100 [thread overview]
Message-ID: <49B38FB7.3000002@gmail.com> (raw)
In-Reply-To: <20090308030928.GB14966@hash.localnet>
On 8.3.2009 04:09, Bob Copeland wrote:
> At this point, I guess the best way forward is to have a special debug
> patch for when we pass an skb up the stack, when it gets allocated, and
> what is in the descriptors.
Yes, I have been thinking about some (ring buffer) array which would
store address-desc_status pairs (even few megs in a vmalloc area) and
pointer (not modulo-ed counter) to this array (index would be modulo-ed,
indeed). From poison output we know the address, so we can then instruct
ath5k to dump the buffer and see what happens :), what was in the status
when we freed the skb.
Maybe some additional info may be needed, as you suggest.
> Jiri, I really think we should implement that better check for the
> self linked descriptor using the rxdp register.
As I stated a while ago, definitely!
> 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.
> 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 ;).
next prev parent reply other threads:[~2009-03-08 9:28 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 [this message]
2009-03-08 16:10 ` Bob Copeland
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=49B38FB7.3000002@gmail.com \
--to=jirislaby@gmail.com \
--cc=ath5k-devel@venema.h4ckr.net \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=lrodriguez@atheros.com \
--cc=me@bobcopeland.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).