spi: race in spi_finalize_current_message starting queue_kthread_work before the message is unmapped

[Mark Brown]

On Mon, May 11, 2015 at 09:27:35PM +0200, Martin Sperl wrote:
> > On 11.05.2015, at 20:00, Mark Brown <broonie at kernel.org> wrote:

> > No, it's supposed to be usable for PIO too - it can keep logic simpler.

> but only slightly - it is a simple
>   (xfer->tx_buf) ? xfer->tx_buf[i] : 0
> so I do not see a huge difference.

People can make the logic more complex than that.

> > Indeed, just having a page that gets reused would be better.  I'm hoping
> > that someone who needs this will get around to optimizing it at some
> > point.

> I could possibly look into that, but it goes against the point you
> made above about PIO.
> Either we allocate the memory completely and make it work for PIO.
> Or we only create a scatter/gather list of the same page and leave
> tx_buf == NULL.

We can tell if it's a DMA transfer - if it's a DMA transfer then using
anything except the SG list is a bit dodgy anyway since you're not
really supposed to have the CPU look at anything that's mapped for the
device (though it's generally fine if the device never actually DMAs).

> So unless we have a separate flag to say we only need it for DMA,
> then we have to keep the the current logic with allocation or we break
> other drivers.

We essentially have that; anything looking at a DMA mapped transfer had
better cope.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-rpi-kernel/attachments/20150512/ab78d667/attachment.sig>