All of lore.kernel.org
 help / color / mirror / Atom feed
From: peterz@infradead.org (Peter Zijlstra)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC] arm64: Enforce observed order for spinlock and data
Date: Fri, 30 Sep 2016 20:52:31 +0200	[thread overview]
Message-ID: <20160930185231.GA3142@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <1475257257-23072-1-git-send-email-bdegraaf@codeaurora.org>

On Fri, Sep 30, 2016 at 01:40:57PM -0400, Brent DeGraaf wrote:
> Prior spinlock code solely used load-acquire and store-release
> semantics to ensure ordering of the spinlock lock and the area it
> protects. However, store-release semantics and ordinary stores do
> not protect against accesses to the protected area being observed
> prior to the access that locks the lock itself.
> 
> While the load-acquire and store-release ordering is sufficient
> when the spinlock routines themselves are strictly used, other
> kernel code that references the lock values directly (e.g. lockrefs)
> could observe changes to the area protected by the spinlock prior
> to observance of the lock itself being in a locked state, despite
> the fact that the spinlock logic itself is correct.
> 
> Barriers were added to all the locking routines wherever necessary
> to ensure that outside observers which read the lock values directly
> will not observe changes to the protected data before the lock itself
> is observed.

I cannot see this going in. You're making spinlocks far more expensive
in the common case that doesn't need this.

Please enumerate the special cases (there's more than just lockref?) and
fix those.

WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: Brent DeGraaf <bdegraaf@codeaurora.org>
Cc: Ingo Molnar <mingo@redhat.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Christopher Covington <cov@codeaurora.org>,
	Timur Tabi <timur@codeaurora.org>,
	Nathan Lynch <nathan_lynch@mentor.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC] arm64: Enforce observed order for spinlock and data
Date: Fri, 30 Sep 2016 20:52:31 +0200	[thread overview]
Message-ID: <20160930185231.GA3142@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <1475257257-23072-1-git-send-email-bdegraaf@codeaurora.org>

On Fri, Sep 30, 2016 at 01:40:57PM -0400, Brent DeGraaf wrote:
> Prior spinlock code solely used load-acquire and store-release
> semantics to ensure ordering of the spinlock lock and the area it
> protects. However, store-release semantics and ordinary stores do
> not protect against accesses to the protected area being observed
> prior to the access that locks the lock itself.
> 
> While the load-acquire and store-release ordering is sufficient
> when the spinlock routines themselves are strictly used, other
> kernel code that references the lock values directly (e.g. lockrefs)
> could observe changes to the area protected by the spinlock prior
> to observance of the lock itself being in a locked state, despite
> the fact that the spinlock logic itself is correct.
> 
> Barriers were added to all the locking routines wherever necessary
> to ensure that outside observers which read the lock values directly
> will not observe changes to the protected data before the lock itself
> is observed.

I cannot see this going in. You're making spinlocks far more expensive
in the common case that doesn't need this.

Please enumerate the special cases (there's more than just lockref?) and
fix those.

  parent reply	other threads:[~2016-09-30 18:52 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-30 17:40 [RFC] arm64: Enforce observed order for spinlock and data Brent DeGraaf
2016-09-30 17:40 ` Brent DeGraaf
2016-09-30 18:43 ` Robin Murphy
2016-09-30 18:43   ` Robin Murphy
2016-10-01 15:45   ` bdegraaf at codeaurora.org
2016-10-01 15:45     ` bdegraaf
2016-09-30 18:52 ` Peter Zijlstra [this message]
2016-09-30 18:52   ` Peter Zijlstra
2016-09-30 19:05 ` Peter Zijlstra
2016-09-30 19:05   ` Peter Zijlstra
2016-10-01 15:59   ` bdegraaf at codeaurora.org
2016-10-01 15:59     ` bdegraaf
2016-09-30 19:32 ` Mark Rutland
2016-09-30 19:32   ` Mark Rutland
2016-10-01 16:11   ` bdegraaf at codeaurora.org
2016-10-01 16:11     ` bdegraaf
2016-10-01 18:11     ` Mark Rutland
2016-10-01 18:11       ` Mark Rutland
2016-10-03 19:20       ` bdegraaf at codeaurora.org
2016-10-03 19:20         ` bdegraaf
2016-10-04  6:50         ` Peter Zijlstra
2016-10-04  6:50           ` Peter Zijlstra
2016-10-04 10:12         ` Mark Rutland
2016-10-04 10:12           ` Mark Rutland
2016-10-04 17:53           ` bdegraaf at codeaurora.org
2016-10-04 17:53             ` bdegraaf
2016-10-04 18:28             ` bdegraaf at codeaurora.org
2016-10-04 18:28               ` bdegraaf
2016-10-04 19:12             ` Mark Rutland
2016-10-04 19:12               ` Mark Rutland
2016-10-05 14:55               ` bdegraaf at codeaurora.org
2016-10-05 14:55                 ` bdegraaf
2016-10-05 15:10                 ` Peter Zijlstra
2016-10-05 15:10                   ` Peter Zijlstra
2016-10-05 15:30                   ` bdegraaf at codeaurora.org
2016-10-05 15:30                     ` bdegraaf
2016-10-12 20:01                     ` bdegraaf at codeaurora.org
2016-10-12 20:01                       ` bdegraaf
2016-10-13 11:02                       ` Will Deacon
2016-10-13 11:02                         ` Will Deacon
2016-10-13 20:00                         ` bdegraaf at codeaurora.org
2016-10-13 20:00                           ` bdegraaf
2016-10-14  0:24                           ` Mark Rutland
2016-10-14  0:24                             ` Mark Rutland
2016-10-05 15:11                 ` bdegraaf at codeaurora.org
2016-10-05 15:11                   ` bdegraaf

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=20160930185231.GA3142@twins.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=linux-arm-kernel@lists.infradead.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.