On Thu, 2015-03-19 at 10:38 +0100, Pavel Machek wrote:

On Thu 2015-03-19 10:14:21, Oliver Neukum wrote:

quoted

On Mon, 2015-03-16 at 22:37 +0100, Jiri Kosina wrote:

quoted

quoted

Are you sure CONFIG_DMA_API_DEBUG wouldn't warn here?

As far as I can tell, it will not warn. The problem is not in the
mapping itself. That is usually legitimate. The problem arises
because the buffer doesn't have a cacheline of its own. Thus the
memory corruption happens after the IO operation has started.

Nasty. Would WARN_ON(buffer & CACHELINE_SIZE-1) do at least part of

No. It is perfectly legitimate to put your buffer at an offset
or to combine buffers provided you don't use them at the same
time.

the trick? Alternatively, could we call ksize() on the object, and
fail if it is not big enough?

What object? We have a pointer to a memory location.

Alternatively, we could create "allocate_for_usb" function, and only
take pointers allocated by that function in usb functions. That would
also teach people the problem exists...

No, this problem is not limited to USB.

	Regards
		Oliver