| Message ID | 20220420102022.3310970-1-p.yadav@ti.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 8868c03f3ca584abec7bb53d6c3f7c5ab6b60949 |
| Headers | show |
| Series | [v2] spi: spi-mem: check if data buffers are on stack | expand |
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?
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.
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
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
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; }