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

Martin Sperl kernel at martin.sperl.org
Fri May 8 13:02:44 PDT 2015


Hi!

It seems as if there is a potential race inside spi_finalize_current_message
in this section of drivers/spi/spi.c

void spi_finalize_current_message(struct spi_master *master)
{
        struct spi_message *mesg;
        unsigned long flags;
        int ret;

        spin_lock_irqsave(&master->queue_lock, flags);
        mesg = master->cur_msg;
        master->cur_msg = NULL;

        queue_kthread_work(&master->kworker, &master->pump_messages);
        spin_unlock_irqrestore(&master->queue_lock, flags);

        spi_unmap_msg(master, mesg);
...

The kernel thread gets scheduled before spi_unmap_msg is getting called
this is obviously not an issue when master->dummy_rx and master->dummy_tx
are NULL, but if a driver sets SPI_MASTER_MUST_RX or SPI_MASTER_MUST_TX,
then master->dummy_rx and master->dummy_tx may get freed inside the
pump thread _before_ the memory is unmapped inside finalize.

This can result in:
[   83.774518] page:db7ba030 count:0 mapcount:0 mapping:  (null) index:0x0
[   83.783143] flags: 0x200(arch_1)
[   83.791861] page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag set
[   83.803147] bad because of flags:
[   83.808397] flags: 0x200(arch_1)
...
[   83.813703] [<c012a2d4>] (__kmalloc_track_caller) from [<c01050d8>] (krealloc+0x60/0xb8)
[   83.813734] [<c01050d8>] (krealloc) from [<c03cce08>] (__spi_pump_messages+0x70c/0x79c)
[   83.813764] [<c03cce08>] (__spi_pump_messages) from [<c03cd0b4>] (__spi_sync+0x21c/0x22c)
[   83.813789] [<c03cd0b4>] (__spi_sync) from [<c03cd100>] (spi_sync+0x1c/0x20)
[   83.813871] [<c03cd100>] (spi_sync) from [<bf0341c4>] (fbtft_write_spi+0x90/0x108 [fbtft])

Surprisingly Noralf saw this only in a downstream 4.0 kernel but I have not
experienced such a situation in 4.1-rc2 (and after being able to reproduce
on downstream 4.0 I still have not been able to trigger such a situation in
4.1-rc2).

Based on the findings by Noralf, the following solves the issue:

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 57a1950..1e662a0 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1089,6 +1089,8 @@ void spi_finalize_current_message(struct spi_master *master)
 	unsigned long flags;
 	int ret;
 
+	spi_unmap_msg(master, master->cur_msg);
+
 	spin_lock_irqsave(&master->queue_lock, flags);
 	mesg = master->cur_msg;
 	master->cur_msg = NULL;
@@ -1096,8 +1098,6 @@ void spi_finalize_current_message(struct spi_master *master)
 	queue_kthread_work(&master->kworker, &master->pump_messages);
 	spin_unlock_irqrestore(&master->queue_lock, flags);
 
-	spi_unmap_msg(master, mesg);
-
 	if (master->cur_msg_prepared && master->unprepare_message) {
 		ret = master->unprepare_message(master, mesg);
 		if (ret) {


Note that I am not sure about the locking, so I left unmap outside the
lock for now.

Not knowing the semantics of prepare_message it may be possible that move
may also need to get applied to the master->unprepare_message() call.


Martin


More information about the linux-rpi-kernel mailing list