On Saturday 28 March 2009 00:49:12 Francesco Gringoli wrote: > On Mar 27, 2009, at 10:51 PM, Michael Buesch wrote: > > > This patch adds poisoning and sanity checking to the RX DMA buffers. > > This is used for protection against buggy hardware/firmware that > > raises > > RX interrupts without doing an actual DMA transfer. > > > > This mechanism protects against rare "bad packets" (due to > > uninitialized skb data) > > and rare kernel crashes due to uninitialized RX headers. > > > > > > Francesco, please stresstest this. > Hi Michael, > > thank you for the patch, I will test it ASAP. Before testing, however, > I would like to have a feedback about sanity checking directly the > rxhdr. Two reasons: 1) also with the patch I sent you yesterday, I > continued to observe kernel freezing with FCSFAIL set 2) I fear that > when dma_rx is triggered with such dma events, also the content of > rxhdr can be broken. In particular if the rxhdr->len reports an > incredible long frame, dma_rx could begin recycling too many skbs. I > was reported (by Bo) that when this happens, kernel would likely freeze.
This should be fixed by this patch as well. > I did several tests with the open firmware and I found that the > maximum framelength that can be observed within firmware space is > 0x1005 (with plcp). SPR_RXE_FRAMELEN _NEVER_ reports a value greater > than this (independently of FCSFAIL, I sampled its value in several > parts of the ucode). This does not surprise me as this should be the > maximum length possible, at least for OFDM frames (length is encoded > inside plcp in a twelve bits field that takes to 0xfff plus 6 bytes > from the plcp gives 0x1005). Given this hypothesis, however, we should > never observe any frame longer than 0x1005 in dma_rx as the rxhdr->len > field is always written by ucode before push_frame_into_fifo by > copying the value of SPR_RXE_FRAMELEN. Observing a greater value means > that what we think to be a frame sent the ucode, is nothing more than > random memory. So we could poison the rxhdr and verify in dma_rx that > it is still poisoned, in that case we could simply exit. How do you > think? We already did that, but slightly incorrectly. Should be fixed by the patch and the other one I just sent. -- Greetings, Michael. _______________________________________________ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
