All of lore.kernel.org
 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 ` [PATCH 2/2] [PATCH] sched: Add smp_rmb() in task rq locking cycles 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 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.