[PATCH V2] mxs/spi: Fix misuse of init_completion

[PATCH V2] mxs/spi: Fix misuse of init_completion

[Marek Vasut]

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!

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)
-- 
1.7.10.4

[PATCH V2] mxs/spi: Fix misuse of init_completion

[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.
>
> 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.
-- 
Chris Ball   <cjb@laptop.org>   <http://printf.net/>
One Laptop Per Child

[PATCH V2] mxs/spi: Fix misuse of init_completion

[Marek Vasut]

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