[PATCH 3/5] MTD: blktrans: fix a race vs kthread_stop.

Maxim Levitsky maximlevitsky at gmail.com
Sun Oct 24 21:44:54 EDT 2010


On Mon, 2010-10-25 at 01:31 +0100, David Woodhouse wrote:
> On Fri, 2010-10-15 at 17:20 +0200, Maxim Levitsky wrote:
> > There is small race window that could make kthread_stop hang forever.
> > I found that while hacking the IR subsystem.
> > 
> > Signed-off-by: Maxim Levitsky <maximlevisky at gmail.com>
> > ---
> >  drivers/mtd/mtd_blkdevs.c |    4 ++++
> >  1 files changed, 4 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/mtd/mtd_blkdevs.c b/drivers/mtd/mtd_blkdevs.c
> > index 040c2d9..a919587 100644
> > --- a/drivers/mtd/mtd_blkdevs.c
> > +++ b/drivers/mtd/mtd_blkdevs.c
> > @@ -133,6 +133,10 @@ static int mtd_blktrans_thread(void *arg)
> >  
> >  		if (!req && !(req = blk_fetch_request(rq))) {
> >  			set_current_state(TASK_INTERRUPTIBLE);
> > +
> > +			if (kthread_should_stop())
> > +				set_current_state(TASK_RUNNING);
> > +
> >  			spin_unlock_irq(rq->queue_lock);
> >  			schedule();
> >  			spin_lock_irq(rq->queue_lock);
> 
> 
> Shouldn't we add a break in there too, so it immediately breaks out of
> the loop (with the lock held)?
It doesn't matter here, as schedule() won't make task sleep, so the
thread will break at next iteration.


Best regards
	Maxim Levitsky




More information about the linux-mtd mailing list