[lkml]   [2016]   [Oct]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] arm64: Enforce observed order for spinlock and data
On 2016-10-04 13:53, wrote:
> On 2016-10-04 06:12, Mark Rutland wrote:
>> On Mon, Oct 03, 2016 at 03:20:57PM -0400,
>> 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,"
could happen during the out-of-order window. I'll post back later after
analyzed it fully.

 \ /
  Last update: 2016-10-04 20:28    [W:0.127 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site