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
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 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
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 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
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 2016-09-20 07:00, Robin Murphy wrote:
On 19/09/16 19:25, bdegr...@codeaurora.org wrote:
On 2016-09-19 14:01, Robin Murphy wrote:
On 19/09/16 18:36, Brent DeGraaf wrote:
According to section 6.3.8 of the ARM Programmer's Guide,
non-temporal
loads and stores do not verify that address depende
On 2016-09-19 14:28, Laura Abbott wrote:
On 09/19/2016 10:36 AM, Brent DeGraaf wrote:
According to section 6.3.8 of the ARM Programmer's Guide, non-temporal
loads and stores do not verify that address dependency is met between
a
load of an address to a register and a subsequent non-temporal lo
On 2016-09-19 14:01, Robin Murphy wrote:
On 19/09/16 18:36, Brent DeGraaf wrote:
According to section 6.3.8 of the ARM Programmer's Guide, non-temporal
loads and stores do not verify that address dependency is met between
a
load of an address to a register and a subsequent non-temporal load or
On 2016-08-22 14:56, Mark Rutland wrote:
Hi Brent,
Thanks for the thorough reply. Comments inline below.
On Mon, Aug 22, 2016 at 01:32:47PM -0400, bdegr...@codeaurora.org
wrote:
On 2016-08-22 07:37, Mark Rutland wrote:
>* What problem does this patch address?
Initially, I set out to fix a co
On 2016-08-22 07:37, Mark Rutland wrote:
Hi,
On Fri, Aug 19, 2016 at 04:02:08PM -0400, Brent DeGraaf wrote:
Introduce explicit control-flow logic immediately prior to virtual
counter register read in all cases so that the mrs read will
always be accessed after all vdso data elements are read an
Sorry, this is my first go at proper email etiquette. I think I've got
it now.
--
"Can you explain the problem that you're fixing here, please?"
---
On 2016-08-11 11:54, Will Deacon wrote:
On Thu, Aug 11, 2016 at 11:37:44AM -0400, Christopher Covington wrote:
From: Brent DeGraaf
Prior gettimeofday code register read code is not architecturally
correct as there is no control flow gating logic enforced
immediately prior to the required isb.
18 matches
Mail list logo
