linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


  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).