2010/10/18 Luis R. Rodriguez <mcgrof@xxxxxxxxx>: > 2010/10/18 Björn Smedman <bjorn.smedman@xxxxxxxxxxx>: >> 2010/10/15 Björn Smedman <bjorn.smedman@xxxxxxxxxxx> >>> >>> 2010/10/15 Ben Greear <greearb@xxxxxxxxxxxxxxx>: >>> > I tried the patch below, and it didn't seem to help. Might even >>> > have hurt..as it died on divide-by-zero error: >>> >>> Hmm, looks like the ani code got a zero listen time from the hw... >>> That just might mean that the DMA actually hits one of these >>> descriptors. :) >> >> Am I the only one worried about this? Leaving a DMA descriptor >> pointing at memory which has been passed on to somebody else... To me >> that's like pointing a loaded gun at someone (and it seems this >> particular gun can go off a little haphazardly). >> >> Luis, given how hard it seems to be to get that locking and skb >> shoveling right, are you sure you want to keep pointing that DMA >> engine on innocent people's data? > > This is why this issue is of high priority to me. I no longer get the > poison nor does Ben, the RX poison issue is resolved as far as I can > tell, I just need to split up the patches into easily reviewable > chunks and get them upstream. The locking issue you found looks like it could cause those overwritten poisons (as well as some weird problems I've seen in AP mode with lots of monitor interfaces). It's really great to see that problem go. All I'm saying is that this stuff is difficult and the next time we get it wrong we should try to avoid overwriting arbitrary kernel memory with our RXed frames (or TXing something sensitive). Will the DMA engine stop when it sees a zero ds_data? In that case I suggest we never keep an address there that we do not want to RX to or TX from. Also, is there some way to verify that we are not corrupting memory with the DMA? I mean the poison check is great but if I understand correctly it cannot detect if we overwrite active memory (i.e. before it is freed and marked with the poison). /Björn -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
