Return-path: Received: from mail.candelatech.com ([208.74.158.172]:40260 "EHLO ns3.lanforge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755713Ab0JNTPP (ORCPT ); Thu, 14 Oct 2010 15:15:15 -0400 Message-ID: <4CB756B8.4000308@candelatech.com> Date: Thu, 14 Oct 2010 12:15:04 -0700 From: Ben Greear MIME-Version: 1.0 To: "Luis R. Rodriguez" CC: =?UTF-8?B?QmrDtnJuIFNtZWRtYW4=?= , Vasanthakumar Thiagarajan , Johannes Berg , "linux-wireless@vger.kernel.org" Subject: Re: memory clobber in rx path, maybe related to ath9k. References: <4CAE1DFB.303@candelatech.com> <1286479642.20974.32.camel@jlt3.sipsolutions.net> <4CB378CD.1080800@candelatech.com> <4CB3D598.7050904@candelatech.com> <4CB4AA89.1070009@candelatech.com> <20101013053141.GA15798@vasanth-laptop> <4CB5E0A8.5020502@candelatech.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Sender: linux-wireless-owner@vger.kernel.org List-ID: On 10/13/2010 01:03 PM, Luis R. Rodriguez wrote: > 2010/10/13 Björn Smedman: >> Hi Ben, >> >> First of all keep up the good work. :) >> >> On Wed, Oct 13, 2010 at 6:39 PM, Ben Greear wrote: >> [snip] >>> Either way, it seems safer to null out the bf_ampdu field after >>> the memory is consumed..it could prevent some tricky bugs later. >> >> I think this is a good idea. But it probably wont be enough to null >> out bf_mpdu. You also need to look at bf_buf_addr (which if I >> understand correctly is the physical address the DMA engine will >> actually write RXed frames to) and bf_dmacontext (which seems in most >> cases to hold an identical address and may in fact be where the DMA >> engine will really write the frame). > > See the TODO list for ath9k: > > * Remove this redundancy crap: bf->bf_buf_addr = bf->bf_dmacontext; > > http://wireless.kernel.org/en/users/Drivers/ath9k/todo I just posted a patch that attempts this. It doesn't fix the memory clobber issue, but maybe the code is a bit cleaner/safer at least... Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com