From: Oleg Nesterov <oleg@redhat.com>
To: David Howells <dhowells@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Jiri Pirko <jpirko@redhat.com>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC,PATCH] workqueues: turn queue_work() into the "barrier" for work->func()
Date: Wed, 12 Nov 2008 12:58:04 +0100 [thread overview]
Message-ID: <20081112115804.GA3444@redhat.com> (raw)
In-Reply-To: <9266.1226443581@redhat.com>
On 11/11, David Howells wrote:
>
> Oleg Nesterov <oleg@redhat.com> wrote:
>
> > I think the caller of queue_work() has all rights to expect that
> > the next invocation of work_func() must see "VAR == 1", but this
> > is not true if the work is already pending.
>
> As you said, queue_work() does test_and_set_bit() which implies smp_mb()
> either side of the function, so you're half way there, and run_workqueue()
> calls spin_unlock_irq() just before calling work_clear_pending()... So might
> it make sense to move the work_clear_pending() into locked section? Or would
> that require an smp_mb__before_clear_bit()?
This can't really help, afaics. We still need mb() between clear_bit(_PENDING)
and LOAD(VAR). Because unlock() is the "one way" barrier, LOAD(VAR) can leak
into the critical section, and it can be re-ordered with clear_bit() inside
the critical section.
Oleg.
prev parent reply other threads:[~2008-11-12 10:58 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-11 20:33 [RFC,PATCH] workqueues: turn queue_work() into the "barrier" for work->func() Oleg Nesterov
2008-11-11 22:46 ` David Howells
2008-11-12 11:58 ` Oleg Nesterov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081112115804.GA3444@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=dhowells@redhat.com \
--cc=dmitry.torokhov@gmail.com \
--cc=jpirko@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.