mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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.

  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