On Thu, Oct 13, 2016 at 04:00:47PM -0400, bdegr...@codeaurora.org wrote:
> On 2016-10-13 07:02, Will Deacon wrote:
> >Brent,
> >
> >On Wed, Oct 12, 2016 at 04:01:06PM -0400, bdegr...@codeaurora.org wrote:
> >
> >Everything from this point down needs clarification.
> >
> >>All arm64 lockref accesses
On 2016-10-13 07:02, Will Deacon wrote:
Brent,
On Wed, Oct 12, 2016 at 04:01:06PM -0400, bdegr...@codeaurora.org
wrote:
Everything from this point down needs clarification.
All arm64 lockref accesses that occur without taking the spinlock must
behave like true atomics, ensuring successive o
Brent,
On Wed, Oct 12, 2016 at 04:01:06PM -0400, bdegr...@codeaurora.org wrote:
> I am still working through some additional analyses for mixed accesses,
> but I thought I'd send along some sample commit text for the fix as it
> currently stands. Please feel free to comment if you see something t
On 2016-10-05 11:30, bdegr...@codeaurora.org wrote:
On 2016-10-05 11:10, Peter Zijlstra wrote:
On Wed, Oct 05, 2016 at 10:55:57AM -0400, bdegr...@codeaurora.org
wrote:
On 2016-10-04 15:12, Mark Rutland wrote:
>Hi Brent,
>
>Could you *please* clarify if you are trying to solve:
>
>(a) a correctn
On 2016-10-05 11:10, Peter Zijlstra wrote:
On Wed, Oct 05, 2016 at 10:55:57AM -0400, bdegr...@codeaurora.org
wrote:
On 2016-10-04 15:12, Mark Rutland wrote:
>Hi Brent,
>
>Could you *please* clarify if you are trying to solve:
>
>(a) a correctness issue (e.g. data corruption) seen in practice.
>(
On Wed, Oct 05, 2016 at 10:55:57AM -0400, bdegr...@codeaurora.org wrote:
> On 2016-10-04 15:12, Mark Rutland wrote:
> >Hi Brent,
> >
> >Could you *please* clarify if you are trying to solve:
> >
> >(a) a correctness issue (e.g. data corruption) seen in practice.
> >(b) a correctness issue (e.g. dat
On 2016-10-05 10:55, bdegr...@codeaurora.org wrote:
On 2016-10-04 15:12, Mark Rutland wrote:
Hi Brent,
Could you *please* clarify if you are trying to solve:
(a) a correctness issue (e.g. data corruption) seen in practice.
(b) a correctness issue (e.g. data corruption) found by inspection.
(c)
On 2016-10-04 15:12, Mark Rutland wrote:
Hi Brent,
Could you *please* clarify if you are trying to solve:
(a) a correctness issue (e.g. data corruption) seen in practice.
(b) a correctness issue (e.g. data corruption) found by inspection.
(c) A performance issue, seen in practice.
(d) A perform
Hi Brent,
Could you *please* clarify if you are trying to solve:
(a) a correctness issue (e.g. data corruption) seen in practice.
(b) a correctness issue (e.g. data corruption) found by inspection.
(c) A performance issue, seen in practice.
(d) A performance issue, found by inspection.
Any one o
On 2016-10-04 13:53, bdegr...@codeaurora.org wrote:
On 2016-10-04 06:12, Mark Rutland wrote:
On Mon, Oct 03, 2016 at 03:20:57PM -0400, bdegr...@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
On 2016-10-04 06:12, Mark Rutland wrote:
On Mon, Oct 03, 2016 at 03:20:57PM -0400, bdegr...@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 attem
On Mon, Oct 03, 2016 at 03:20:57PM -0400, bdegr...@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
On Mon, Oct 03, 2016 at 03:20:57PM -0400, bdegr...@codeaurora.org wrote:
> 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
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 attemptin
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 i
On 2016-09-30 15:32, Mark Rutland wrote:
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
On 2016-09-30 15:05, Peter Zijlstra wrote:
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 store
On 2016-09-30 14:43, Robin Murphy wrote:
+* so LSE needs an explicit barrier here as well. Without this, the
+* changed contents of the area protected by the spinlock could be
+* observed prior to the lock.
What is that last sentence supposed to mean? If the lock is fre
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 t
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 t
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 t
Hi Brent,
On 30/09/16 18:40, 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
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 loc
23 matches
Mail list logo
