[PATCH] riscv/barrier: Define __smp_{store_release,load_acquire}

[PATCH] riscv/barrier: Define __smp_{store_release,load_acquire}

[Andrea Parri]

Introduce __smp_{store_release,load_acquire}, and rely on the generic
definitions for smp_{store_release,load_acquire}. This avoids the use
of full ("rw,rw") fences on SMP.

Signed-off-by: Andrea Parri <parri.andrea@gmail.com>
---
 arch/riscv/include/asm/barrier.h | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/riscv/include/asm/barrier.h b/arch/riscv/include/asm/barrier.h
index 5510366d169ae..d4628e4b3a5ea 100644
--- a/arch/riscv/include/asm/barrier.h
+++ b/arch/riscv/include/asm/barrier.h
@@ -38,6 +38,21 @@
 #define __smp_rmb()	RISCV_FENCE(r,r)
 #define __smp_wmb()	RISCV_FENCE(w,w)
 
+#define __smp_store_release(p, v)					\
+do {									\
+	compiletime_assert_atomic_type(*p);				\
+	RISCV_FENCE(rw,w);						\
+	WRITE_ONCE(*p, v);						\
+} while (0)
+
+#define __smp_load_acquire(p)						\
+({									\
+	typeof(*p) ___p1 = READ_ONCE(*p);				\
+	compiletime_assert_atomic_type(*p);				\
+	RISCV_FENCE(r,rw);						\
+	___p1;								\
+})
+
 /*
  * This is a very specific barrier: it's currently only used in two places in
  * the kernel, both in the scheduler.  See include/linux/spinlock.h for the two
-- 
2.7.4

[PATCH] riscv/barrier: Define __smp_{store_release,load_acquire}

[Palmer Dabbelt]

On Mon, 26 Feb 2018 18:24:11 PST (-0800), parri.andrea at gmail.com wrote:
> Introduce __smp_{store_release,load_acquire}, and rely on the generic
> definitions for smp_{store_release,load_acquire}. This avoids the use
> of full ("rw,rw") fences on SMP.
>
> Signed-off-by: Andrea Parri <parri.andrea@gmail.com>
> ---
>  arch/riscv/include/asm/barrier.h | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
>
> diff --git a/arch/riscv/include/asm/barrier.h b/arch/riscv/include/asm/barrier.h
> index 5510366d169ae..d4628e4b3a5ea 100644
> --- a/arch/riscv/include/asm/barrier.h
> +++ b/arch/riscv/include/asm/barrier.h
> @@ -38,6 +38,21 @@
>  #define __smp_rmb()	RISCV_FENCE(r,r)
>  #define __smp_wmb()	RISCV_FENCE(w,w)
>
> +#define __smp_store_release(p, v)					\
> +do {									\
> +	compiletime_assert_atomic_type(*p);				\
> +	RISCV_FENCE(rw,w);						\
> +	WRITE_ONCE(*p, v);						\
> +} while (0)
> +
> +#define __smp_load_acquire(p)						\
> +({									\
> +	typeof(*p) ___p1 = READ_ONCE(*p);				\
> +	compiletime_assert_atomic_type(*p);				\
> +	RISCV_FENCE(r,rw);						\
> +	___p1;								\
> +})
> +
>  /*
>   * This is a very specific barrier: it's currently only used in two places in
>   * the kernel, both in the scheduler.  See include/linux/spinlock.h for the two

I'm adding Daniel just in case I misunderstood what's going on here, but these 
look good to me.  As this is a non-trivial memory model change I'm going to let 
it bake in linux-next for a bit just so it gets some visibility.

Thanks!

[PATCH] riscv/barrier: Define __smp_{store_release,load_acquire}

[Daniel Lustig]

On 2/27/2018 10:21 AM, Palmer Dabbelt wrote:
> On Mon, 26 Feb 2018 18:24:11 PST (-0800), parri.andrea at gmail.com wrote:
>> Introduce __smp_{store_release,load_acquire}, and rely on the generic
>> definitions for smp_{store_release,load_acquire}. This avoids the use
>> of full ("rw,rw") fences on SMP.
>>
>> Signed-off-by: Andrea Parri <parri.andrea@gmail.com>
>> ---
>> ?arch/riscv/include/asm/barrier.h | 15 +++++++++++++++
>> ?1 file changed, 15 insertions(+)
>>
>> diff --git a/arch/riscv/include/asm/barrier.h b/arch/riscv/include/asm/barrier.h
>> index 5510366d169ae..d4628e4b3a5ea 100644
>> --- a/arch/riscv/include/asm/barrier.h
>> +++ b/arch/riscv/include/asm/barrier.h
>> @@ -38,6 +38,21 @@
>> ?#define __smp_rmb()??? RISCV_FENCE(r,r)
>> ?#define __smp_wmb()??? RISCV_FENCE(w,w)
>>
>> +#define __smp_store_release(p, v)??????????????????? \
>> +do {??????????????????????????????????? \
>> +??? compiletime_assert_atomic_type(*p);??????????????? \
>> +??? RISCV_FENCE(rw,w);??????????????????????? \
>> +??? WRITE_ONCE(*p, v);??????????????????????? \
>> +} while (0)
>> +
>> +#define __smp_load_acquire(p)??????????????????????? \
>> +({??????????????????????????????????? \
>> +??? typeof(*p) ___p1 = READ_ONCE(*p);??????????????? \
>> +??? compiletime_assert_atomic_type(*p);??????????????? \
>> +??? RISCV_FENCE(r,rw);??????????????????????? \
>> +??? ___p1;??????????????????????????????? \
>> +})
>> +
>> ?/*
>> ? * This is a very specific barrier: it's currently only used in two places in
>> ? * the kernel, both in the scheduler.? See include/linux/spinlock.h for the two
> 
> I'm adding Daniel just in case I misunderstood what's going on here,
> but these look good to me.  As this is a non-trivial memory model
> change I'm going to let it bake in linux-next for a bit just so it
> gets some visibility.

Looks good to me too.  In particular, it also covers the
Write->release(p)->acquire(p)->Write ordering that we were debating
in the broader LKMM thread, which is good.

Dan

> 
> Thanks

[PATCH] riscv/barrier: Define __smp_{store_release,load_acquire}

[Andrea Parri]

On Tue, Feb 27, 2018 at 02:20:37PM -0800, Daniel Lustig wrote:
> On 2/27/2018 10:21 AM, Palmer Dabbelt wrote:
> > On Mon, 26 Feb 2018 18:24:11 PST (-0800), parri.andrea at gmail.com wrote:
> >> Introduce __smp_{store_release,load_acquire}, and rely on the generic
> >> definitions for smp_{store_release,load_acquire}. This avoids the use
> >> of full ("rw,rw") fences on SMP.
> >>
> >> Signed-off-by: Andrea Parri <parri.andrea@gmail.com>
> >> ---
> >> ?arch/riscv/include/asm/barrier.h | 15 +++++++++++++++
> >> ?1 file changed, 15 insertions(+)
> >>
> >> diff --git a/arch/riscv/include/asm/barrier.h b/arch/riscv/include/asm/barrier.h
> >> index 5510366d169ae..d4628e4b3a5ea 100644
> >> --- a/arch/riscv/include/asm/barrier.h
> >> +++ b/arch/riscv/include/asm/barrier.h
> >> @@ -38,6 +38,21 @@
> >> ?#define __smp_rmb()??? RISCV_FENCE(r,r)
> >> ?#define __smp_wmb()??? RISCV_FENCE(w,w)
> >>
> >> +#define __smp_store_release(p, v)??????????????????? \
> >> +do {??????????????????????????????????? \
> >> +??? compiletime_assert_atomic_type(*p);??????????????? \
> >> +??? RISCV_FENCE(rw,w);??????????????????????? \
> >> +??? WRITE_ONCE(*p, v);??????????????????????? \
> >> +} while (0)
> >> +
> >> +#define __smp_load_acquire(p)??????????????????????? \
> >> +({??????????????????????????????????? \
> >> +??? typeof(*p) ___p1 = READ_ONCE(*p);??????????????? \
> >> +??? compiletime_assert_atomic_type(*p);??????????????? \
> >> +??? RISCV_FENCE(r,rw);??????????????????????? \
> >> +??? ___p1;??????????????????????????????? \
> >> +})
> >> +
> >> ?/*
> >> ? * This is a very specific barrier: it's currently only used in two places in
> >> ? * the kernel, both in the scheduler.? See include/linux/spinlock.h for the two
> > 
> > I'm adding Daniel just in case I misunderstood what's going on here,
> > but these look good to me.  As this is a non-trivial memory model
> > change I'm going to let it bake in linux-next for a bit just so it
> > gets some visibility.
> 
> Looks good to me too.  In particular, it also covers the
> Write->release(p)->acquire(p)->Write ordering that we were debating
> in the broader LKMM thread, which is good.

Yeah, I think that other changes would be required to completely cover
the issues debated in that thread: I plan to prepare and to post a new
series/RFC to address those (unless someone precedes me of course ;-).

  Andrea


> 
> Dan
> 
> > 
> > Thanks