linux-kernel - Re: [PATCH 2/3] workqueues: implement flush

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080701125018.GA99@tv-sign.ru>
Date:	Tue, 1 Jul 2008 16:50:18 +0400
From:	Oleg Nesterov <oleg@...sign.ru>
To:	Jarek Poplawski <jarkao2@...il.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Jarek Poplawski <jarkao2@...pl>,
	Max Krasnyansky <maxk@...lcomm.com>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] workqueues: implement flush_work()

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/