Am Freitag, den 16.08.2019, 23:18 +0100 schrieb Jonathan Bell: > On Thu, Aug 15, 2019 at 3:52 PM Oliver Neukum <oneukum@xxxxxxxx> wrote: > > That is an accident waiting to happen. Please make a patch using > > a bounce buffer allocated with knalloc() in > > drivers/media/usb/uvc/uvc_ctrl.c:uvc_ctrl_populate_cache() and friends. > > A patch to uvcvideo will not fix the underlying bug with the host > controller hardware. Absolutely correct. > There are hundreds of device drivers of varying > vintages that potentially react badly to having a rogue host > controller DMA engine writing more bytes than were reported by the > controller's interrupt status register. Then these drivers are likely to be buggy. Not guaranteed to, it is possible to write a driver which is correct and still would react badly to that, but it is difficult. > So my original two questions still need answering: > 1) Does the symptom seen with v4l2-ctl exist on other platforms using > dwc2 (which implies that this is not a bug specific to Raspberry Pi) > 2) How do we harden upstream dwc2 against a broken controller DMA? Unknown and very hard to find out, because you are almost always in a situation where you have a full cache line, which is larger than 4 bytes. You must flush all cache lines your buffer is part of. You must not touch them until DMA is complete. That is easiest to achieve if you just kmalloc() each buffer separately. Using two parts of a buffer for subsequent DMA is within the rules, but not worth the trouble. Using a bounce buffer in the dwc2 driver is likely not worth the trouble, as you wouldn't get away with a single buffer and dynamic allocation would suck (it would have to be atomic). Regards Oliver
