From mboxrd@z Thu Jan 1 00:00:00 1970 From: dlustig@nvidia.com (Daniel Lustig) Date: Tue, 27 Feb 2018 14:20:37 -0800 Subject: [PATCH] riscv/barrier: Define __smp_{store_release,load_acquire} In-Reply-To: References: Message-ID: To: linux-riscv@lists.infradead.org List-Id: linux-riscv.lists.infradead.org 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 >> --- >> ?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