From: Peter Zijlstra <peterz@infradead.org>
To: Manfred Spraul <manfred@colorfullife.com>
Cc: Oleg Nesterov <oleg@redhat.com>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Kirill Tkhai <ktkhai@parallels.com>,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
Josh Poimboeuf <jpoimboe@redhat.com>
Subject: Re: [PATCH 2/2] [PATCH] sched: Add smp_rmb() in task rq locking cycles
Date: Wed, 18 Feb 2015 23:43:17 +0100 [thread overview]
Message-ID: <20150218224317.GC5029@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <54E4E479.4050003@colorfullife.com>
On Wed, Feb 18, 2015 at 08:14:01PM +0100, Manfred Spraul wrote:
> >spinlock_t local, global;
> >bool force_global;
> >bool my_lock(bool try_local)
> >{
> > if (try_local) {
> > spin_lock(&local);
> > if (!spin_is_locked(&global)) {
> > if (!force_global) {
> > return true;
> > }
> > }
> > spin_unlock(&local);
> >
> >
> > spin_lock(&global);
> > spin_unlock_wait(&local);
> > return false;
> > }
> >
> > void my_unlock(bool drop_local)
> > {
> > if (drop_local)
> > spin_unlock(&local);
> > else
> > spin_unlock(&global);
> > }
> >}
> >Another question is do we need a barrier AFTER spin_unlock_wait(). I do not
> >know what ipc/sem.c actually needs, but in general (I think) this does need
> >mb(). Otherwise my_lock / my_unlock itself does not have the proper acq/rel
> >semantics. For example, my_lock(false) can miss the changes which were done
> >under my_lock(true).
> How could that happen?
> I thought that
> thread A:
> protected_var = 1234;
> spin_unlock(&lock_a)
>
> thread B:
> spin_lock(&lock_b)
> if (protected_var)
> is safe. i.e, there is no need that acquire and releases is done on the same pointer.
Well, just those four statements can of course be executed like:
CPU0 CPU1
spin_lock(&b)
if (prot_var)
prot_var = 1;
spin_unlock(&a);
And you would see the old var. Lock a and b are completely independent
here.
Now of course the local/global thing in sysvsem is more complex.
As to what Oleg meant:
X := 0
CPU0 CPU1
spin_lock(&global);
spin_lock(&local);
X = 1;
spin_unlock(&local);
spin_unlock_wait(&local);
assert(X == 1); /* BOOM */
that assert can trigger, because spin_unlock_wait() are reads, the read
of X can be lifted over and above, before the assignment of X on CPU1.
Again, the sysvsem code is slightly more complex, but I think Oleg is
right, there is no guarantee you'll observe the full critical section of
sem->lock if sem_lock() takes the slow path and does sem_wait_array(),
because of the above.
next prev parent reply other threads:[~2015-02-18 22:43 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20150217104516.12144.85911.stgit@tkhai>
2015-02-17 10:47 ` Kirill Tkhai
2015-02-17 12:12 ` Peter Zijlstra
2015-02-17 12:36 ` Kirill Tkhai
2015-02-17 12:45 ` Peter Zijlstra
2015-02-17 13:05 ` Peter Zijlstra
2015-02-17 16:05 ` Paul E. McKenney
2015-02-17 18:01 ` Paul E. McKenney
2015-02-17 18:23 ` Peter Zijlstra
2015-02-17 21:45 ` Paul E. McKenney
2015-02-18 13:41 ` Peter Zijlstra
2015-02-17 18:36 ` Peter Zijlstra
2015-02-17 21:52 ` Paul E. McKenney
2015-02-18 13:47 ` Peter Zijlstra
2015-02-18 18:43 ` Paul E. McKenney
2015-02-18 15:53 ` Oleg Nesterov
2015-02-18 16:11 ` Peter Zijlstra
2015-02-18 16:32 ` Oleg Nesterov
2015-02-18 19:23 ` Paul E. McKenney
2015-02-18 15:59 ` Oleg Nesterov
2015-02-18 19:14 ` Manfred Spraul
2015-02-18 22:43 ` Peter Zijlstra [this message]
2015-02-19 14:19 ` Oleg Nesterov
2015-02-20 18:28 ` Manfred Spraul
2015-02-20 18:45 ` Peter Zijlstra
2015-02-20 20:23 ` Oleg Nesterov
2015-02-21 12:54 ` Peter Zijlstra
2015-04-25 19:56 ` Paul E. McKenney
2015-04-26 10:52 ` Paul E. McKenney
2015-04-28 14:33 ` Peter Zijlstra
2015-04-28 15:53 ` Chris Metcalf
2015-04-28 16:24 ` Peter Zijlstra
2015-04-28 16:44 ` [PATCH] spinlock: clarify doc for raw_spin_unlock_wait() Chris Metcalf
2015-04-29 17:34 ` Manfred Spraul
2015-04-28 17:33 ` [PATCH 1/2] tile: modify arch_spin_unlock_wait() semantics Chris Metcalf
2015-04-28 17:33 ` [PATCH 2/2] tile: use READ_ONCE() in arch_spin_is_locked() Chris Metcalf
2015-04-28 16:40 ` [PATCH 2/2] [PATCH] sched: Add smp_rmb() in task rq locking cycles Peter Zijlstra
2015-04-28 16:58 ` Chris Metcalf
2015-04-28 17:43 ` Peter Zijlstra
2015-04-28 18:00 ` Chris Metcalf
2015-04-28 18:24 ` Peter Zijlstra
2015-04-28 18:38 ` Chris Metcalf
2015-04-28 14:32 ` Peter Zijlstra
2015-04-28 20:33 ` Paul E. McKenney
2015-02-21 3:26 ` Paul E. McKenney
2015-02-23 18:29 ` Paul E. McKenney
2015-02-18 17:05 ` [tip:sched/core] sched: Clarify ordering between task_rq_lock() and move_queued_task() tip-bot for Peter Zijlstra
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=20150218224317.GC5029@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=jpoimboe@redhat.com \
--cc=ktkhai@parallels.com \
--cc=linux-kernel@vger.kernel.org \
--cc=manfred@colorfullife.com \
--cc=mingo@redhat.com \
--cc=oleg@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
/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
Powered by JetHome