Messages in this thread | | | Date | Mon, 10 Nov 2008 09:58:37 +0000 | From | Ben Dooks <> | Subject | Re: [patch 6/7] SDHCI: Check DMA for overruns at end of transfer |
| |
On Mon, Nov 03, 2008 at 11:28:40PM -0200, Henrique de Moraes Holschuh wrote: > On Mon, 03 Nov 2008, Ben Dooks wrote: > > On Mon, Nov 03, 2008 at 07:12:00PM -0200, Henrique de Moraes Holschuh wrote: > > > Maybe I didn't understand it right, but if the DMA controller could overrun > > > a buffer, don't you ALSO need to add defensive padding (i.e. increase the > > > buffer) to make sure nothing important gets overrun? > > > > This is only generated by problems elsewhere in the driver, such as > > getting the timeout clock wrong. It is here just as a precaution and > > as an aide to debugging, it should not trigger in normal circumstances. > > Then why is it just a WARN_ON, since you had a rogue DMA operation > overwriting unknown kernel memory? Seems like an outright BUG_ON to me.
It is a problem, but it doesn't kill the entire system. We could print it at a higher level. The WARN_ON()/BUG_ON() where not appropriate, as we do not need a whole stack backtrace, and I belive the mmc block thread somehow seems to manage to keep running even with an OOPS.
> > There is a seperate problem where the DMA buffer is passed from the stack > > which is, IIRC, a complete no-no under Linux. > > Can't say much on that. I just found it strange that something as damaging > as an overrun was only getting a WARN_ON and no defensive measure. If it is > not going to happen normally, it might not require a defensive buffer, but > once it happens, it looks like one must reboot ASAP from what you said...
-- Ben (ben@fluff.org, http://www.fluff.org/)
'a smiley only costs 4 bytes'
| |