On Thu, Aug 11, 2016 at 11:26:47AM -0700, Paul E. McKenney wrote:
> If my upcoming testing of the two changes together pans out, I will
> give you a Tested-by -- I am guessing that you don't want to wait
> until the next merge window for these changes.
I was planning to stuff them in tip/locking/u
On Fri, Aug 12, 2016 at 08:25:43PM +0200, Peter Zijlstra wrote:
> On Thu, Aug 11, 2016 at 11:26:47AM -0700, Paul E. McKenney wrote:
> > If my upcoming testing of the two changes together pans out, I will
> > give you a Tested-by -- I am guessing that you don't want to wait
> > until the next merge
> Initial testing says that the change below must precede the change
> to the definition of lockless_dereference(), so the two should go
> together.
Indeed.
> If my upcoming testing of the two changes together pans out, I will
> give you a Tested-by -- I am guessing that you don't want to wait
>
On Thu, Aug 11, 2016 at 11:50:21AM +0200, Johannes Berg wrote:
> From: Johannes Berg
>
> This reverts commit fa7d81bb3c269a2ee38b6e4d569d9eb8be1a78ad.
>
> As Peter explained:
> [...] lockless_dereference() is _stronger_ than READ_ONCE(), not weaker.
>
> [...]
>
> Also, clue is in the nam
From: Johannes Berg
This reverts commit fa7d81bb3c269a2ee38b6e4d569d9eb8be1a78ad.
As Peter explained:
[...] lockless_dereference() is _stronger_ than READ_ONCE(), not weaker.
[...]
Also, clue is in the name: 'dereference', you don't actually dereference
the pointer here, only load it.
On Wed, Jun 22, 2016 at 08:46:12AM +0100, Chris Wilson wrote:
> We are only documenting that the read is outside of the lock, and do not
> require strict ordering on the operation. In this case the more relaxed
> lockless_dereference() will suffice.
No, no, no... This is 'broken'. lockless_derefer
On Thu, Aug 11, 2016 at 12:38:59PM +0200, Daniel Vetter wrote:
> On Thu, Aug 11, 2016 at 11:50:21AM +0200, Johannes Berg wrote:
> > From: Johannes Berg
> >
> > This reverts commit fa7d81bb3c269a2ee38b6e4d569d9eb8be1a78ad.
> >
> > As Peter explained:
> > [...] lockless_dereference() is _stronge
On Thu, Aug 11, 2016 at 11:44:08AM +0200, Peter Zijlstra wrote:
> On Wed, Jun 22, 2016 at 08:46:12AM +0100, Chris Wilson wrote:
> > We are only documenting that the read is outside of the lock, and do not
> > require strict ordering on the operation. In this case the more relaxed
> > lockless_deref
On Wed, Jun 22, 2016 at 08:46:12AM +0100, Chris Wilson wrote:
> We are only documenting that the read is outside of the lock, and do not
> require strict ordering on the operation. In this case the more relaxed
> lockless_dereference() will suffice.
>
> Signed-off-by: Chris Wilson
> Cc: Daniel Ve
We are only documenting that the read is outside of the lock, and do not
require strict ordering on the operation. In this case the more relaxed
lockless_dereference() will suffice.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Julia Lawall
Cc: Chris Wilson
Cc: Emil Velikov
---
drivers/g
10 matches
Mail list logo
