Re: [PATCH 2/3] workqueues: implement flush_work()

[Oleg Nesterov]

On 06/30, Jarek Poplawski wrote:
>
> On Sun, Jun 29, 2008 at 06:49:26PM +0400, Oleg Nesterov wrote:
> ...
> > --- 26-rc2/kernel/workqueue.c~WQ_2_FLUSH_WORK	2008-06-12 21:28:13.000000000 +0400
> > +++ 26-rc2/kernel/workqueue.c	2008-06-29 18:20:33.000000000 +0400
> > @@ -399,6 +399,52 @@ void flush_workqueue(struct workqueue_st
> >  }
> >  EXPORT_SYMBOL_GPL(flush_workqueue);
> >
> > +/**
> > + * flush_work - block until a work_struct's callback has terminated
> > + * @work: the work which is to be flushed
> > + *
> > + * It is expected that, prior to calling flush_work(), the caller has
> > + * arranged for the work to not be requeued, otherwise it doesn't make
> > + * sense to use this function.
> > + */
>
> I missed this before, and probably it's not required, but "Returns..."
> could be added here.

Agreed, I'll update the comment later, together with other changes
in workqueue.c

> > +	spin_lock_irq(&cwq->lock);
> > +	if (!list_empty(&work->entry)) {
> > +		/*
> > +		 * See the comment near try_to_grab_pending()->smp_rmb().
> > +		 * If it was re-queued under us we are not going to wait.
> > +		 */
> > +		smp_rmb();
> > +		if (unlikely(cwq != get_wq_data(work)))
> > +			goto out;
> > +		prev = &work->entry;
> > +	} else {
>
> Probably it doesn't matter too much, but one little doubt: don't we
> need (for consistency) smp_rmb() for this branch as well? It seems
> this cwq could be read out of order here too.
>
> > +		if (cwq->current_work != work)
> > +			goto out;

Yes, cwq can be "stale", but this doesn't matter and we can't have
the false positive here.

cwq->current_work is always changed under cwq->lock, and we hold this
lock. If we see "cwq->current_work == work" we can safely insert the
barrier and wait. Even if this work was already re-queued on another
CPU or another workqueue_struct.

Note also that rmb() can't really help here.

> Otherwise, all looks correct to me as before.

Thanks!

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/