Displaying 8 results from an estimated 8 matches for "rcu_derefer".
2016 Jan 26
4
[v3,11/41] mips: reuse asm-generic/barrier.h
...p_read_barrier_depends()" does NOTHING wrt the second write.
>
> Just to clarify: on alpha it adds a memory barrier, but that memory
> barrier is useless.
No trailing data-dependent read, so agreed, no smp_read_barrier_depends()
needed. That said, I believe that we should encourage rcu_dereference*()
or lockless_dereference() instead of READ_ONCE() for documentation
reasons, though.
> On non-alpha, it is a no-op, and obviously does nothing simply because
> it generates no code.
>
> So if anybody believes that the "smp_read_barrier_depends()" does
> something, t...
2016 Jan 26
4
[v3,11/41] mips: reuse asm-generic/barrier.h
...p_read_barrier_depends()" does NOTHING wrt the second write.
>
> Just to clarify: on alpha it adds a memory barrier, but that memory
> barrier is useless.
No trailing data-dependent read, so agreed, no smp_read_barrier_depends()
needed. That said, I believe that we should encourage rcu_dereference*()
or lockless_dereference() instead of READ_ONCE() for documentation
reasons, though.
> On non-alpha, it is a no-op, and obviously does nothing simply because
> it generates no code.
>
> So if anybody believes that the "smp_read_barrier_depends()" does
> something, t...
2016 Jan 26
3
[v3,11/41] mips: reuse asm-generic/barrier.h
...S. Stop perpetuating it. I already removed a
>> number of bogus cases of it, and I removed the incorrect documentation
>> that had this crap.
>
> If I understand your objection correctly, you want the above pattern
> expressed either like this:
>
> struct foo *x = rcu_dereference(*ptr);
> x->bar = 5;
>
> Or like this:
>
> struct foo *x = lockless_dereference(*ptr);
> x->bar = 5;
>
> Or am I missing your point?
You are entirely missing the point.
You might as well just write it as
struct foo x = READ_ONCE(*ptr)...
2016 Jan 26
3
[v3,11/41] mips: reuse asm-generic/barrier.h
...S. Stop perpetuating it. I already removed a
>> number of bogus cases of it, and I removed the incorrect documentation
>> that had this crap.
>
> If I understand your objection correctly, you want the above pattern
> expressed either like this:
>
> struct foo *x = rcu_dereference(*ptr);
> x->bar = 5;
>
> Or like this:
>
> struct foo *x = lockless_dereference(*ptr);
> x->bar = 5;
>
> Or am I missing your point?
You are entirely missing the point.
You might as well just write it as
struct foo x = READ_ONCE(*ptr)...
2016 Jan 27
0
[v3,11/41] mips: reuse asm-generic/barrier.h
...does NOTHING wrt the second write.
> >
> > Just to clarify: on alpha it adds a memory barrier, but that memory
> > barrier is useless.
>
> No trailing data-dependent read, so agreed, no smp_read_barrier_depends()
> needed. That said, I believe that we should encourage rcu_dereference*()
> or lockless_dereference() instead of READ_ONCE() for documentation
> reasons, though.
>
> > On non-alpha, it is a no-op, and obviously does nothing simply because
> > it generates no code.
> >
> > So if anybody believes that the "smp_read_barrier_dep...
2016 Jan 26
0
[v3,11/41] mips: reuse asm-generic/barrier.h
On Tue, Jan 26, 2016 at 2:15 PM, Linus Torvalds
<torvalds at linux-foundation.org> wrote:
>
> You might as well just write it as
>
> struct foo x = READ_ONCE(*ptr);
> x->bar = 5;
>
> because that "smp_read_barrier_depends()" does NOTHING wrt the second write.
Just to clarify: on alpha it adds a memory barrier, but that memory
barrier is useless.
On
2016 Jan 27
1
[v3,11/41] mips: reuse asm-generic/barrier.h
On Tue, Jan 26, 2016 at 02:33:40PM -0800, Linus Torvalds wrote:
> If it turns out that some architecture does actually need a barrier
> between a read and a dependent write, then that will mean that
>
> (a) we'll have to make up a _new_ barrier, because
> "smp_read_barrier_depends()" is not that barrier. We'll presumably
> then have to make that new barrier
2016 Jan 27
1
[v3,11/41] mips: reuse asm-generic/barrier.h
On Tue, Jan 26, 2016 at 02:33:40PM -0800, Linus Torvalds wrote:
> If it turns out that some architecture does actually need a barrier
> between a read and a dependent write, then that will mean that
>
> (a) we'll have to make up a _new_ barrier, because
> "smp_read_barrier_depends()" is not that barrier. We'll presumably
> then have to make that new barrier