From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Peter Hurley <peter@hurleysoftware.com>,
James Bottomley <James.Bottomley@HansenPartnership.com>,
Tejun Heo <tj@kernel.org>,
laijs@cn.fujitsu.com, linux-kernel@vger.kernel.org,
linux1394-devel@lists.sourceforge.net,
Chris Boot <bootc@bootc.net>,
linux-scsi@vger.kernel.org, target-devel@vger.kernel.org
Subject: memory-barriers.txt again (was Re: [PATCH 4/9] firewire: don't use PREPARE_DELAYED_WORK)
Date: Sun, 23 Feb 2014 02:23:03 +0100 [thread overview]
Message-ID: <20140223022303.3240093c@stein> (raw)
In-Reply-To: <5308F48C.8080609@hurleysoftware.com>
Hi Paul,
in patch "Documentation/memory-barriers.txt: Downgrade UNLOCK+BLOCK" (sic),
you wrote:
+ Memory operations issued before the LOCK may be completed after the
+ LOCK operation has completed. An smp_mb__before_spinlock(), combined
+ with a following LOCK, orders prior loads against subsequent stores
+ and stores and prior stores against subsequent stores. Note that
Is there a "and stores" too many? Or was one "stores" mistyped and meant
to be something else? Or what else is meant?
@@ -1677,13 +1681,57 @@ LOCK, and an access following the UNLOCK to happen before the UNLOCK, and the
two accesses can themselves then cross:
*A = a;
- LOCK
- UNLOCK
+ LOCK M
+ UNLOCK M
*B = b;
may occur as:
- LOCK, STORE *B, STORE *A, UNLOCK
+ LOCK M, STORE *B, STORE *A, UNLOCK M
+
+This same reordering can of course occur if the LOCK and UNLOCK are
+to the same lock variable, but only from the perspective of another
+CPU not holding that lock.
The example says "LOCK M" and "UNLOCK M" (since the patch). I read
this as LOCK and UNLOCK to the same variable, M. Why does the
following sentence then say that "this same reordering can... occur
if the LOCK and UNLOCK are to the same lock variable"? This sentence
would make sense if the example had been about LOCK M, UNLOCK N.
+In short, an UNLOCK followed by a LOCK may -not- be assumed to be a full
+memory barrier because it is possible for a preceding UNLOCK to pass a
+later LOCK from the viewpoint of the CPU, but not from the viewpoint
+of the compiler. Note that deadlocks cannot be introduced by this
+interchange because if such a deadlock threatened, the UNLOCK would
+simply complete.
So rather than deadlock, "the UNLOCK would simply complete". But
/why/ does it complete? It is left unclear (to me at least), why
it would do so. IOW, what mechanism will make it always proceed
to the UNLOCK? Without knowing that, it is left entirely unclear
(to me) why the deadlock wouldn't happen.
--
Stefan Richter
-=====-====- --=- =-===
http://arcgraph.de/sr/
next prev parent reply other threads:[~2014-02-23 1:29 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-20 20:44 [PATCHSET wq/for-3.15] workqueue: remove PREPARE_[DELAYED_]WORK() Tejun Heo
2014-02-20 20:44 ` [PATCH 1/9] wireless/rt2x00: don't use PREPARE_WORK in rt2800usb.c Tejun Heo
2014-03-07 15:26 ` Tejun Heo
2014-02-20 20:44 ` [PATCH 2/9] ps3-vuart: don't use PREPARE_WORK Tejun Heo
2014-02-20 20:44 ` Tejun Heo
2014-02-21 23:19 ` Geoff Levand
2014-02-21 23:19 ` Geoff Levand
2014-02-20 20:44 ` [PATCH 3/9] floppy: don't use PREPARE_[DELAYED_]WORK Tejun Heo
2014-02-21 9:37 ` Jiri Kosina
2014-02-20 20:44 ` [PATCH 4/9] firewire: don't use PREPARE_DELAYED_WORK Tejun Heo
2014-02-20 20:44 ` Tejun Heo
2014-02-21 1:44 ` Peter Hurley
2014-02-21 1:59 ` Tejun Heo
2014-02-21 2:07 ` Peter Hurley
2014-02-21 2:07 ` Peter Hurley
2014-02-21 2:13 ` Tejun Heo
2014-02-21 5:13 ` Peter Hurley
2014-02-21 10:03 ` Tejun Heo
2014-02-21 12:51 ` Peter Hurley
2014-02-21 12:51 ` Peter Hurley
2014-02-21 13:06 ` Tejun Heo
2014-02-21 16:53 ` Peter Hurley
2014-02-21 16:57 ` Tejun Heo
2014-02-21 23:01 ` Peter Hurley
2014-02-21 23:18 ` Tejun Heo
2014-02-21 23:46 ` Peter Hurley
2014-02-22 14:38 ` Tejun Heo
2014-02-22 14:38 ` Tejun Heo
2014-02-22 14:48 ` Peter Hurley
2014-02-22 18:43 ` James Bottomley
2014-02-22 18:48 ` Peter Hurley
2014-02-22 18:48 ` Peter Hurley
2014-02-22 18:52 ` James Bottomley
2014-02-22 19:03 ` Peter Hurley
2014-02-22 19:03 ` Peter Hurley
2014-02-23 1:23 ` Stefan Richter [this message]
2014-02-23 16:37 ` memory-barriers.txt again (was Re: [PATCH 4/9] firewire: don't use PREPARE_DELAYED_WORK) Paul E. McKenney
2014-02-23 16:37 ` Paul E. McKenney
2014-02-23 20:35 ` Peter Hurley
2014-02-23 23:50 ` Paul E. McKenney
2014-02-24 0:09 ` Peter Hurley
2014-02-24 16:26 ` Paul E. McKenney
2014-02-24 16:26 ` Paul E. McKenney
2014-02-24 0:32 ` Stefan Richter
2014-02-24 16:27 ` Paul E. McKenney
2014-02-23 20:05 ` [PATCH 4/9] firewire: don't use PREPARE_DELAYED_WORK James Bottomley
2014-02-23 22:32 ` Peter Hurley
2014-02-21 20:45 ` Stefan Richter
2014-02-21 20:45 ` Stefan Richter
2014-03-05 21:34 ` Stefan Richter
2014-03-07 15:18 ` Tejun Heo
2014-03-07 15:26 ` [PATCH UPDATED " Tejun Heo
2014-03-07 15:26 ` Tejun Heo
2014-02-20 20:44 ` [PATCH 5/9] usb: " Tejun Heo
2014-02-20 20:59 ` Greg Kroah-Hartman
2014-02-21 15:06 ` Alan Stern
2014-02-21 15:07 ` Tejun Heo
2014-02-22 14:59 ` [PATCH v2 " Tejun Heo
2014-02-22 15:14 ` Alan Stern
2014-02-22 15:20 ` Peter Hurley
2014-02-22 15:37 ` Tejun Heo
2014-02-22 23:03 ` Alan Stern
2014-02-23 4:29 ` Tejun Heo
2014-02-20 20:44 ` [PATCH 6/9] nvme: don't use PREPARE_WORK Tejun Heo
2014-02-20 20:44 ` Tejun Heo
2014-03-07 15:26 ` Tejun Heo
2014-03-07 15:26 ` Tejun Heo
2014-02-20 20:44 ` [PATCH 7/9] afs: " Tejun Heo
2014-03-07 15:27 ` Tejun Heo
2014-02-20 20:44 ` [PATCH 8/9] staging/fwserial: " Tejun Heo
2014-02-21 15:13 ` Peter Hurley
2014-02-20 20:44 ` [PATCH 9/9] workqueue: remove PREPARE_[DELAYED_]WORK() Tejun Heo
2014-03-07 15:27 ` Tejun Heo
2014-02-20 22:00 ` [PATCH 7/9] afs: don't use PREPARE_WORK David Howells
2014-02-20 22:46 ` 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=20140223022303.3240093c@stein \
--to=stefanr@s5r6.in-berlin.de \
--cc=James.Bottomley@HansenPartnership.com \
--cc=bootc@bootc.net \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux1394-devel@lists.sourceforge.net \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peter@hurleysoftware.com \
--cc=target-devel@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 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.