Re: [PATCH v1 1/1] spi: Remove unneded check for orig_nents

From: Andy Shevchenko
Date: Wed May 22 2024 - 11:24:22 EST


On Wed, May 22, 2024 at 11:12:43AM -0400, Nícolas F. R. A. Prado wrote:
> On Wed, May 22, 2024 at 05:24:40PM +0300, Andy Shevchenko wrote:
> > On Wed, May 22, 2024 at 03:18:18PM +0200, Neil Armstrong wrote:
> > > On 22/05/2024 13:53, Neil Armstrong wrote:
> > > > On 22/05/2024 13:33, Andy Shevchenko wrote:
> > > > > On Wed, May 22, 2024 at 12:03:33PM +0200, Neil Armstrong wrote:
> > > > > > On 15/05/2024 23:09, Nícolas F. R. A. Prado wrote:
> > > > > > > On Tue, May 07, 2024 at 11:10:27PM +0300, Andy Shevchenko wrote:
> > > > > > > > Both dma_unmap_sgtable() and sg_free_table() in spi_unmap_buf_attrs()
> > > > > > > > have checks for orig_nents against 0. No need to duplicate this.
> > > > > > > > All the same applies to other DMA mapping API calls.
> > > > > > > >
> > > > > > > > Also note, there is no other user in the kernel that does this kind of
> > > > > > > > checks.
> > > > > > > >
> > > > > > > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > this commit caused a regression which I reported here:
> > > > > > >
> > > > > > > https://lore.kernel.org/all/d3679496-2e4e-4a7c-97ed-f193bd53af1d@notapiano
> > > > > > >
> > > > > > > along with some thoughts on the cause and a possible solution, though I'm not
> > > > > > > familiar with this code base at all and would really appreciate any feedback you
> > > > > > > may have.
> > > > > >
> > > > > > I also see the same regression on the SM8550 and SM8650 platforms,
> > > > > > please CC linux-arm-msm@xxxxxxxxxxxxxxx and me for a potential fix to test on those platforms.
> > > > >
> > > > > There is still no answer from IOMMU patch author. Do you have the same trace
> > > > > due to IOMMU calls? Anyway, I guess it would be nice to see it.
> [..]
> > > > >
> > > > > Meanwhile, I have three changes I posted in the replies to the initial report,
> > > > > can you combine them all and test? This will be a plan B (? or A, depending on
> > > > > the culprit).
> > > > >
> > > >
> > > > I'll try to apply them and test.
> > >
> > > I stacked the 3 changes, and it works:
> > > Tested-by: Neil Armstrong <neil.armstrong@xxxxxxxxxx> # on SM8650-QRD
> >
> > Thank you!
> >
> > I will try to develop and submit a fix against IOMMU which I believe is the
> > correct place to address this. So, this one will be plan B in case the IOMMU
> > folks will refuse the other one.
>
> Hi,
>
> that change did not work for me. Stack trace follows at the end.
>
> But adding the following on top did fix it:
>
> diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
> index 0851c5e1fd1f..5d3972d9d1da 100644
> --- a/drivers/spi/spi.c
> +++ b/drivers/spi/spi.c
> @@ -1253,8 +1253,13 @@ static int __spi_map_msg(struct spi_controller *ctlr, struct spi_message *msg)
> /* The sync is done before each transfer. */
> unsigned long attrs = DMA_ATTR_SKIP_CPU_SYNC;
>
> - if (!ctlr->can_dma(ctlr, msg->spi, xfer))
> + if (!ctlr->can_dma(ctlr, msg->spi, xfer)) {
> + memset(&xfer->tx_sg, 0, sizeof(xfer->tx_sg));
> + xfer->tx_sg.sgl = &dummy_sg;
> + memset(&xfer->rx_sg, 0, sizeof(xfer->rx_sg));
> + xfer->rx_sg.sgl = &dummy_sg;
> continue;
> + }
>
> if (xfer->tx_buf != NULL) {
> ret = spi_map_buf_attrs(ctlr, tx_dev, &xfer->tx_sg,
>
>
> The thing is that even with all the previous changes applied, if one of the
> transfers inside the message doesn't support DMA, the null pointer would still
> be passed to the DMA API.

Ah, indeed, the conditionals also can be translated to

can_dma = can_dma();

if (can_dma && _buf)
...
else
...

but...


> Alternatively, I think a better way to achieve the same is (I have verified this
> also works):

I agree that this one is much better approach. I will clean it up and send
as a quick fix. IOMMU will still be on the table as I think it's wrong to
dereference SG when nents = 0.

> I'll let you decide what is the best fix for the issue (what has been posted so
> far in this thread or another fix in IOMMU). If you go with this, feel free to
> add my
>
> Tested-by: Nícolas F. R. A. Prado <nfraprado@xxxxxxxxxxxxx>

Thank you!

--
With Best Regards,
Andy Shevchenko