Return-path: Received: from fg-out-1718.google.com ([72.14.220.156]:37150 "EHLO fg-out-1718.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751346AbZCHJ2a (ORCPT ); Sun, 8 Mar 2009 05:28:30 -0400 Message-ID: <49B38FB7.3000002@gmail.com> (sfid-20090308_102847_182049_F28BE078) Date: Sun, 08 Mar 2009 10:28:23 +0100 From: Jiri Slaby MIME-Version: 1.0 To: Bob Copeland CC: Sitsofe Wheeler , Nick Kossifidis , Frederic Weisbecker , linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org, ath5k-devel@venema.h4ckr.net, "Luis R. Rodriguez" Subject: Re: [TIP] BUG kmalloc-4096: Poison overwritten (ath5k_rx_skb_alloc) References: <40f31dec0902231508l512af5b7w68cfcc0bdf3cfa87@mail.gmail.com> <20090224135817.GB6019@hash.localnet> <49A46AD4.3060007@gmail.com> <20090225140139.GA18694@silver.sucs.org> <20090226135938.GA12182@hash.localnet> <20090226170338.GA1745@silver.sucs.org> <20090303041222.GA1238@hash.localnet> <20090303200352.GA8343@silver.sucs.org> <20090304120759.GA6519@hash.localnet> <20090306094249.GA10236@silver.sucs.org> <20090308030928.GB14966@hash.localnet> In-Reply-To: <20090308030928.GB14966@hash.localnet> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: linux-wireless-owner@vger.kernel.org List-ID: 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 ;).