[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