[PATCH v2] spi: spi-mem: check if data buffers are on stack

[PATCH v2] spi: spi-mem: check if data buffers are on stack

[Pratyush Yadav]

The buffers passed in the data phase must be DMA-able. Programmers often
don't realise this requirement and pass in buffers that reside on the
stack. This can be hard to spot when reviewing code. Reject ops if their
data buffer is on the stack to avoid this.

Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Acked-by: Mark Brown <broonie@kernel.org>
---

Changes in v2:
- Include task_stack.h. It might not get included indirectly on some
  platforms and can cause build failures.
- Add a WARN_ON_ONCE() for debuggability.
- Add Mark's Ack.

 drivers/spi/spi-mem.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
index 7d7091aa0c22..e8de4f5017cd 100644
--- a/drivers/spi/spi-mem.c
+++ b/drivers/spi/spi-mem.c
@@ -10,6 +10,7 @@
 #include <linux/pm_runtime.h>
 #include <linux/spi/spi.h>
 #include <linux/spi/spi-mem.h>
+#include <linux/sched/task_stack.h>

 #include "internals.h"

@@ -211,6 +212,15 @@ static int spi_mem_check_op(const struct spi_mem_op *op)
 	    !spi_mem_buswidth_is_valid(op->data.buswidth))
 		return -EINVAL;

+	/* Buffers must be DMA-able. */
+	if (WARN_ON_ONCE(op->data.dir == SPI_MEM_DATA_IN &&
+			 object_is_on_stack(op->data.buf.in)))
+		return -EINVAL;
+
+	if (WARN_ON_ONCE(op->data.dir == SPI_MEM_DATA_OUT &&
+			 object_is_on_stack(op->data.buf.out)))
+		return -EINVAL;
+
 	return 0;
 }

--
2.34.1

Re: [PATCH v2] spi: spi-mem: check if data buffers are on stack

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 808 bytes --]

On Wed, Apr 20, 2022 at 03:50:22PM +0530, Pratyush Yadav wrote:
> The buffers passed in the data phase must be DMA-able. Programmers often
> don't realise this requirement and pass in buffers that reside on the
> stack. This can be hard to spot when reviewing code. Reject ops if their
> data buffer is on the stack to avoid this.
> 
> Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
> Acked-by: Mark Brown <broonie@kernel.org>
> ---
> 
> Changes in v2:
> - Include task_stack.h. It might not get included indirectly on some
>   platforms and can cause build failures.
> - Add a WARN_ON_ONCE() for debuggability.
> - Add Mark's Ack.

Since this is now an isolated patch does that mean whatever meant that I
acked rather than applying this patch has gone in and I can now apply it
directly?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v2] spi: spi-mem: check if data buffers are on stack

[Pratyush Yadav]

On 20/04/22 02:04PM, Mark Brown wrote:
> On Wed, Apr 20, 2022 at 03:50:22PM +0530, Pratyush Yadav wrote:
> > The buffers passed in the data phase must be DMA-able. Programmers often
> > don't realise this requirement and pass in buffers that reside on the
> > stack. This can be hard to spot when reviewing code. Reject ops if their
> > data buffer is on the stack to avoid this.
> > 
> > Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
> > Acked-by: Mark Brown <broonie@kernel.org>
> > ---
> > 
> > Changes in v2:
> > - Include task_stack.h. It might not get included indirectly on some
> >   platforms and can cause build failures.
> > - Add a WARN_ON_ONCE() for debuggability.
> > - Add Mark's Ack.
> 
> Since this is now an isolated patch does that mean whatever meant that I
> acked rather than applying this patch has gone in and I can now apply it
> directly?

Yes, you should be able to apply it directly. Miquel's spi-mem-ecc 
branch is now in 5.18-rc1 and later. Though this patch never conflicted 
with that branch to begin with. The spi-mem-ecc branch does not touch 
spi_mem_check_op() as far as I can see.

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.

Re: [PATCH v2] spi: spi-mem: check if data buffers are on stack

[Miquel Raynal]

Hey,

p.yadav@ti.com wrote on Thu, 21 Apr 2022 12:40:56 +0530:

> On 20/04/22 02:04PM, Mark Brown wrote:
> > On Wed, Apr 20, 2022 at 03:50:22PM +0530, Pratyush Yadav wrote:  
> > > The buffers passed in the data phase must be DMA-able. Programmers often
> > > don't realise this requirement and pass in buffers that reside on the
> > > stack. This can be hard to spot when reviewing code. Reject ops if their
> > > data buffer is on the stack to avoid this.
> > > 
> > > Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
> > > Acked-by: Mark Brown <broonie@kernel.org>
> > > ---
> > > 
> > > Changes in v2:
> > > - Include task_stack.h. It might not get included indirectly on some
> > >   platforms and can cause build failures.
> > > - Add a WARN_ON_ONCE() for debuggability.
> > > - Add Mark's Ack.  
> > 
> > Since this is now an isolated patch does that mean whatever meant that I
> > acked rather than applying this patch has gone in and I can now apply it
> > directly?  
> 
> Yes, you should be able to apply it directly. Miquel's spi-mem-ecc 
> branch is now in 5.18-rc1 and later. Though this patch never conflicted 
> with that branch to begin with. The spi-mem-ecc branch does not touch 
> spi_mem_check_op() as far as I can see.

It did during a few version AFAIR, but not the final ones anymore.

But it's upstream now, so please feel free to apply.

Thanks,
Miquèl

Re: [PATCH v2] spi: spi-mem: check if data buffers are on stack

[Mark Brown]

On Wed, 20 Apr 2022 15:50:22 +0530, Pratyush Yadav wrote:
> The buffers passed in the data phase must be DMA-able. Programmers often
> don't realise this requirement and pass in buffers that reside on the
> stack. This can be hard to spot when reviewing code. Reject ops if their
> data buffer is on the stack to avoid this.
> 
> 

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[1/1] spi: spi-mem: check if data buffers are on stack
      commit: 8868c03f3ca584abec7bb53d6c3f7c5ab6b60949

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark