| Message ID | 1345775624-9696-1-git-send-email-marex@denx.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Marek, On Thu, Aug 23 2012, Marek Vasut wrote: > The init_completion() call does reinit not only the variable carrying > the flag that the completion finished, but also initialized the > waitqueue associated with the completion. On the contrary, the > INIT_WAITQUEUE() call only reinits the flag. > > In case there was anything still stuck in the waitqueue, subsequent call > to init_completion() would be able to create possible race condition. This > patch uses the proper function and moves init_completion() into .probe() call > of the driver, to be issued only once. > > Note that such scenario is impossible, since two threads can never enter the > mxs_spi_txrx_dma(), since whole this section is protected by mutex in SPI core. > This by no means allows this issue to exit though. > > Signed-off-by: Marek Vasut <marex@denx.de> Thanks for writing that up -- I appreciate seeing the explanation of the problems this could have caused. - Chris.
Dear Chris Ball, > Hi Marek, > > On Thu, Aug 23 2012, Marek Vasut wrote: > > The init_completion() call does reinit not only the variable carrying > > the flag that the completion finished, but also initialized the > > waitqueue associated with the completion. On the contrary, the > > INIT_WAITQUEUE() call only reinits the flag. Darn, it's INIT_COMPLETION() of course. > > In case there was anything still stuck in the waitqueue, subsequent call > > to init_completion() would be able to create possible race condition. > > This patch uses the proper function and moves init_completion() into > > .probe() call of the driver, to be issued only once. > > > > Note that such scenario is impossible, since two threads can never enter > > the mxs_spi_txrx_dma(), since whole this section is protected by mutex > > in SPI core. This by no means allows this issue to exit though. > > > > Signed-off-by: Marek Vasut <marex@denx.de> > > Thanks for writing that up -- I appreciate seeing the explanation of the > problems this could have caused. You're very welcome, I was really lazy, sorry about that and thanks for pushing me ;-) I hope someone might eventually even find this explanation useful. > - Chris. Best regards, Marek Vasut
diff --git a/drivers/spi/spi-mxs.c b/drivers/spi/spi-mxs.c index 331f600..c965cc6 100644 --- a/drivers/spi/spi-mxs.c +++ b/drivers/spi/spi-mxs.c @@ -230,7 +230,7 @@ static int mxs_spi_txrx_dma(struct mxs_spi *spi, int cs, return -EINVAL; } - init_completion(&spi->c); + INIT_COMPLETION(spi->c); if (*first) pio |= BM_SSP_CTRL0_LOCK_CS; @@ -560,6 +560,8 @@ static int __devinit mxs_spi_probe(struct platform_device *pdev) ssp->devid = devid; ssp->dma_channel = dma_channel; + init_completion(&spi->c); + ret = devm_request_irq(&pdev->dev, irq_err, mxs_ssp_irq_handler, 0, DRIVER_NAME, ssp); if (ret)
The init_completion() call does reinit not only the variable carrying the flag that the completion finished, but also initialized the waitqueue associated with the completion. On the contrary, the INIT_WAITQUEUE() call only reinits the flag. In case there was anything still stuck in the waitqueue, subsequent call to init_completion() would be able to create possible race condition. This patch uses the proper function and moves init_completion() into .probe() call of the driver, to be issued only once. Note that such scenario is impossible, since two threads can never enter the mxs_spi_txrx_dma(), since whole this section is protected by mutex in SPI core. This by no means allows this issue to exit though. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Chris Ball <cjb@laptop.org> Cc: Shawn Guo <shawn.guo@linaro.org> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: Fabio Estevam <fabio.estevam@freescale.com> --- drivers/spi/spi-mxs.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) V2: Update the patch description and snap a whip over myself for being lazy to write one in the first place!