Re: SPI regression with today's build

[kernel@xxxxxxxxxxxxxxxx]

> On 08.05.2019, at 21:11, kernel@xxxxxxxxxxxxxxxx wrote:
> 
> As per (intended) api finalize_current_message should be called before
> finalize current message, as all sorts of reordering may occur and data
> may get moved arround.
> 
> For example you could even transform a spi_write_then_read into a single
> spi_transfer using a buffer and then copy the data back to the original
> place, whioch would not be supported as is.
> 
> In the end it may even make sense to make the dma-mapping also a
> spi resource transformation at the right place and move spi_res_release
> before the finalize current message.
> 
> But obviously that is a bigger change to core we may not be able to
> get into the current release window.

Something like this (compiles but untested) could solve the issue:

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 5e75944ad5d1..002acfee7785 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1183,8 +1183,6 @@ static int spi_transfer_one_message(struct spi_controller *ctlr,

        spi_finalize_current_message(ctlr);

-       spi_res_release(ctlr, msg);
-
        return ret;
 }

@@ -1448,6 +1446,8 @@ void spi_finalize_current_message(struct spi_controller *ctlr)
                }
        }

+       spi_res_release(ctlr, mesg);
+
        spin_lock_irqsave(&ctlr->queue_lock, flags);
        ctlr->cur_msg = NULL;
        ctlr->cur_msg_prepared = false;


It also fixes a memory leak (spi_res objects) when:
* bus_drivers call spi_finalize_current_message on its own
* prepare_message fails
* spi_map_msg fails

Then those resource transformations are not reverted and
memory is not freed.

@Nicolas: maybe you can confirm that this fixes your issue.

@Marc: you need to decide on if this is acceptable, but as
it is fixing actual memory leaks there may be a good argument
to apply it. But then as it is at the core longer testing would
be welcome...

Martin