Re: dwc2 / Raspberry Pi - hardware bug for small transfers results in memory corruption

[Oliver Neukum <oneukum@suse.com>]

Am Freitag, den 16.08.2019, 23:18 +0100 schrieb Jonathan Bell:
> On Thu, Aug 15, 2019 at 3:52 PM Oliver Neukum <oneukum@suse.com> 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