Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1495552
| From | bdegraaf@codeaurora.org |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC] arm64: Enforce observed order for spinlock and data |
| Date | 2016-10-04 20:30 +0200 |
| Message-ID | <soCDv-6kw-7@gated-at.bofh.it> (permalink) |
| References | (2 earlier) <snvb3-2vI-5@gated-at.bofh.it> <snx3c-3OD-17@gated-at.bofh.it> <soh61-z2-31@gated-at.bofh.it> <souZj-1my-9@gated-at.bofh.it> <soCat-5Vn-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 2016-10-04 13:53, bdegraaf@codeaurora.org wrote: > On 2016-10-04 06:12, Mark Rutland wrote: >> On Mon, Oct 03, 2016 at 03:20:57PM -0400, bdegraaf@codeaurora.org >> wrote: >>> On 2016-10-01 14:11, Mark Rutland wrote: >>> >Hi Brent, >>> > >>> >Evidently my questions weren't sufficiently clear; even with your >>> >answers it's not clear to me what precise issue you're attempting to >>> >solve. I've tried to be more specific this time. >>> > >>> >At a high-level, can you clarify whether you're attempting to solve is: >>> > >>> >(a) a functional correctness issue (e.g. data corruption) >>> >(b) a performance issue >>> > >>> >And whether this was seen in practice, or found through code >>> >inspection? >> >>> Thinking about this, as the reader/writer code has no known "abuse" >>> case, I'll remove it from the patchset, then provide a v2 patchset >>> with a detailed explanation for the lockref problem using the commits >>> you provided as an example, as well as performance consideration. >> >> If there's a functional problem, let's consider that in isolation >> first. >> Once we understand that, then we can consider doing what is optimal. >> >> As should be obvious from the above, I'm confused because this patch >> conflates functional details with performance optimisations which (to >> me) sound architecturally dubious. >> >> I completely agree with Peter that if the problem lies with lockref, >> it >> should be solved in the lockref code. >> >> Thanks, >> Mark. > > After looking at this, the problem is not with the lockref code per se: > it is > a problem with arch_spin_value_unlocked(). In the out-of-order case, > arch_spin_value_unlocked() can return TRUE for a spinlock that is in > fact > locked but the lock is not observable yet via an ordinary load. Other > than > ensuring order on the locking side (as the prior patch did), there is a > way > to make arch_spin_value_unlock's TRUE return value deterministic, but > it > requires that it does a write-back to the lock to ensure we didn't > observe > the unlocked value while another agent was in process of writing back a > locked value. > > Brent Scratch that--things get complicated as the lock itself gets "cloned," which could happen during the out-of-order window. I'll post back later after I've analyzed it fully.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[RFC] arm64: Enforce observed order for spinlock and data Brent DeGraaf <bdegraaf@codeaurora.org> - 2016-09-30 19:50 +0200
Re: [RFC] arm64: Enforce observed order for spinlock and data Robin Murphy <robin.murphy@arm.com> - 2016-09-30 20:50 +0200
Re: [RFC] arm64: Enforce observed order for spinlock and data bdegraaf@codeaurora.org - 2016-10-01 17:50 +0200
Re: [RFC] arm64: Enforce observed order for spinlock and data Peter Zijlstra <peterz@infradead.org> - 2016-09-30 21:00 +0200
Re: [RFC] arm64: Enforce observed order for spinlock and data Peter Zijlstra <peterz@infradead.org> - 2016-09-30 21:10 +0200
Re: [RFC] arm64: Enforce observed order for spinlock and data bdegraaf@codeaurora.org - 2016-10-01 18:10 +0200
Re: [RFC] arm64: Enforce observed order for spinlock and data Mark Rutland <mark.rutland@arm.com> - 2016-09-30 21:40 +0200
Re: [RFC] arm64: Enforce observed order for spinlock and data bdegraaf@codeaurora.org - 2016-10-01 18:20 +0200
Re: [RFC] arm64: Enforce observed order for spinlock and data Mark Rutland <mark.rutland@arm.com> - 2016-10-01 20:20 +0200
Re: [RFC] arm64: Enforce observed order for spinlock and data bdegraaf@codeaurora.org - 2016-10-03 21:30 +0200
Re: [RFC] arm64: Enforce observed order for spinlock and data Peter Zijlstra <peterz@infradead.org> - 2016-10-04 09:00 +0200
Re: [RFC] arm64: Enforce observed order for spinlock and data Mark Rutland <mark.rutland@arm.com> - 2016-10-04 12:20 +0200
Re: [RFC] arm64: Enforce observed order for spinlock and data bdegraaf@codeaurora.org - 2016-10-04 20:00 +0200
Re: [RFC] arm64: Enforce observed order for spinlock and data bdegraaf@codeaurora.org - 2016-10-04 20:30 +0200
Re: [RFC] arm64: Enforce observed order for spinlock and data Mark Rutland <mark.rutland@arm.com> - 2016-10-04 21:20 +0200
Re: [RFC] arm64: Enforce observed order for spinlock and data bdegraaf@codeaurora.org - 2016-10-05 17:00 +0200
Re: [RFC] arm64: Enforce observed order for spinlock and data bdegraaf@codeaurora.org - 2016-10-05 17:20 +0200
Re: [RFC] arm64: Enforce observed order for spinlock and data Peter Zijlstra <peterz@infradead.org> - 2016-10-05 17:20 +0200
Re: [RFC] arm64: Enforce observed order for spinlock and data bdegraaf@codeaurora.org - 2016-10-05 17:40 +0200
Re: [RFC] arm64: Enforce observed order for spinlock and data bdegraaf@codeaurora.org - 2016-10-12 22:10 +0200
csiph-web