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
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
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
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
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
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
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
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
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 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.
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.
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.
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.
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
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
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
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
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
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
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
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
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:
> 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 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
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
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
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
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: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
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
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
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
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
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
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
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
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
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
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
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
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
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
46 matches
Mail list logo
