On Thu, May 8, 2014 at 9:22 AM, David Laight <[email protected]> wrote: > From: Mathias Nyman >> From: Dan Williams <[email protected]> >> >> Save someone else the debug cycles of figuring out why a driver's >> transfer request is failing or causing undefined system behavior. >> Buffers submitted for dma must come from GFP allocated / DMA-able >> memory. >> >> Return -EAGAIN matching the return value for dma_mapping_error() cases. > > Won't that just cause the request to be resubmitted a few clock > cycles later? > Surely you either need to error the request, or panic.
No, panic() is too drastic for this. > In any case is this the right place for this sort of test? Yes. The system is already compromised because the driver is broken. The expectation is that this is a clue bat for a driver developer to fix their code before it goes upstream. I found this while debugging an interaction with a new driver that was causing the xhci controller to lock up. Had this warning been there I likely never would have received the xhci bug report. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
