Re: memory clobber in rx path, maybe related to ath9k.

["Luis R. Rodriguez" <mcgrof@gmail.com>]

On Thu, Oct 14, 2010 at 12:15 PM, Ben Greear <greearb@candelatech.com> wrote:
> On 10/13/2010 01:03 PM, Luis R. Rodriguez wrote:
>>
>> 2010/10/13 Björn Smedman<bjorn.smedman@venatech.se>:
>>>
>>> Hi Ben,
>>>
>>> First of all keep up the good work. :)
>>>
>>> On Wed, Oct 13, 2010 at 6:39 PM, Ben Greear<greearb@candelatech.com>
>>>  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...

Easier to read at least, thanks.

  Luis