The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Peter Hurley <peter@hurleysoftware.com>
To: Tejun Heo <tj@kernel.org>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>,
	linux-kernel@vger.kernel.org,
	Peter Hurley <peter@hurleysoftware.com>
Subject: [PATCH] workqueue: Guarantee work function memory ordering
Date: Sat, 22 Feb 2014 07:11:51 -0500	[thread overview]
Message-ID: <1393071111-5128-1-git-send-email-peter@hurleysoftware.com> (raw)

Users of the workqueue api may assume the workqueue provides a
memory ordering guarantee for re-queued work items; ie., that
if a work item is not queue-able then the previously queued
work instance is not running and so any memory operations
which occur before queuing the work will be visible to the work
function.

For example, code of the form:
    add new data to work on
    queue work
assumes that this latest data is acted upon, either by the
newly queued instance (if it could be queued) or by the not-yet-
running instance (if a new instance could not be queued).

Provide this implicit memory ordering guarantee; prevent
speculative loads in the work function from occurring before
the current work instance is marked not pending (and thus has
started). This, in turn, guarantees that stores occurring before
schedule_work/queue_work are visible to either the not-yet-running
work instance (if new work could not be queued) or that new work
is queued (and thus ensuring the new data is acted upon).

Note that preventing early stores is unnecessary because no
conclusion can be reached about the state of the work function
from outside the work function by ordering early stores after
clearing PENDING (other than testing PENDING).

Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
---
 kernel/workqueue.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 82ef9f3..a4b241d 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -2201,6 +2201,16 @@ __acquires(&pool->lock)
 
 	spin_unlock_irq(&pool->lock);
 
+	/*
+	 * Paired with the implied mb of test_and_set_bit(PENDING).
+	 * Guarantees speculative loads which occur in the work item
+	 * function do not complete before PENDING is cleared in
+	 * set_work_pool_and_clear_pending() above. In turn, this
+	 * ensures that stores are either visible to the not-yet-
+	 * running work instance or a new instance is queueable.
+	 */
+	smp_rmb();
+
 	lock_map_acquire_read(&pwq->wq->lockdep_map);
 	lock_map_acquire(&lockdep_map);
 	trace_workqueue_execute_start(work);
-- 
1.8.1.2


             reply	other threads:[~2014-02-22 12:12 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-22 12:11 Peter Hurley [this message]
2014-02-22 14:40 ` [PATCH] workqueue: Guarantee work function memory ordering Tejun Heo
2014-02-22 15:05   ` Peter Hurley
2014-02-22 15:41     ` Tejun Heo

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=1393071111-5128-1-git-send-email-peter@hurleysoftware.com \
    --to=peter@hurleysoftware.com \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tj@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox