mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Nícolas F. R. A. Prado" <nfraprado@collabora.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Mark Brown <broonie@kernel.org>,
	linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 1/1] spi: Remove unneded check for orig_nents
Date: Thu, 16 May 2024 12:25:19 -0400	[thread overview]
Message-ID: <2fccdd9a-5b97-4dc6-a6b1-ce2d9e0819bd@notapiano> (raw)
In-Reply-To: <ZkYJTxmlM5oWOzFL@smile.fi.intel.com>

On Thu, May 16, 2024 at 04:25:35PM +0300, Andy Shevchenko wrote:
> On Thu, May 16, 2024 at 01:18:04PM +0300, Andy Shevchenko wrote:
> > On Wed, May 15, 2024 at 05:09:33PM -0400, 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@linux.intel.com>
> > > 
> > > 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.
> > 
> > Thanks for the report and preliminary analysis!
> > I'll look at it hopefully sooner than later.
> > 
> > But at least what I think now is that my change revealed a problem somewhere
> > else, because that's how DMA mapping / streaming APIs designed, it's extremely
> > rare to check orig_nents field.
> 
> Can you test the below patch?
> 
> diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
> index b2efd4964f7c..51811f04e463 100644
> --- a/drivers/spi/spi.c
> +++ b/drivers/spi/spi.c
> @@ -1243,6 +1243,7 @@ static int __spi_map_msg(struct spi_controller *ctlr, struct spi_message *msg)
>  	else
>  		rx_dev = ctlr->dev.parent;
>  
> +	ret = -ENOMSG;
>  	list_for_each_entry(xfer, &msg->transfers, transfer_list) {
>  		/* The sync is done before each transfer. */
>  		unsigned long attrs = DMA_ATTR_SKIP_CPU_SYNC;
> @@ -1272,6 +1273,9 @@ static int __spi_map_msg(struct spi_controller *ctlr, struct spi_message *msg)
>  			}
>  		}
>  	}
> +	/* No transfer has been mapped, bail out with success */
> +	if (ret)
> +		return 0;
>  
>  	ctlr->cur_rx_dma_dev = rx_dev;
>  	ctlr->cur_tx_dma_dev = tx_dev;

Hi Andy,

thank you for the patch. Unfortunately it didn't completely solve the issue. Now
the stack trace is slightly different and points at the next line:

	dma_sync_sgtable_for_device(rx_dev, &xfer->rx_sg, DMA_FROM_DEVICE);

So now we're hitting the case where only the tx buffer was DMA mapped, but the
rx is still uninitialized, though the cur_msg_mapped flag is set to true, since
it is shared between them. The original code checked for the initialization of
each scatterlist individually, which is why it worked.

Thanks,
Nícolas

  reply	other threads:[~2024-05-16 16:25 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-07 20:10 Andy Shevchenko
2024-05-08 12:08 ` Mark Brown
2024-05-16 11:28   ` [PATCH] spi: Remove unneeded " Markus Elfring
2024-05-15 21:09 ` [PATCH v1 1/1] spi: Remove unneded " Nícolas F. R. A. Prado
2024-05-16 10:18   ` Andy Shevchenko
2024-05-16 13:25     ` Andy Shevchenko
2024-05-16 16:25       ` Nícolas F. R. A. Prado [this message]
2024-05-16 17:46         ` Andy Shevchenko
2024-05-16 21:11           ` Nícolas F. R. A. Prado
2024-05-17 15:40             ` Andy Shevchenko
2024-05-22 10:03   ` Neil Armstrong
2024-05-22 11:33     ` Andy Shevchenko
2024-05-22 11:53       ` Neil Armstrong
2024-05-22 13:18         ` Neil Armstrong
2024-05-22 14:24           ` Andy Shevchenko
2024-05-22 15:12             ` Nícolas F. R. A. Prado
2024-05-22 15:24               ` Andy Shevchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2fccdd9a-5b97-4dc6-a6b1-ce2d9e0819bd@notapiano \
    --to=nfraprado@collabora.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=broonie@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®