Re: [PATCH 2/2] membarrier: riscv: Provide core serializing command

[Palmer Dabbelt]

On Wed, 29 Nov 2023 14:43:34 PST (-0800), parri.andrea@xxxxxxxxx wrote:
> > > So I should probably stick to 93917ad50972, which apparently selected
> > > CONFIG_MEMBARRIER on RISC-V, for the Fixes: tag in question.
> >
> > I think it goes further than that, because you can explicitly
> > CONFIG_MEMBARRIER=y, see init/Kconfig:
> >
> > config MEMBARRIER
> >         bool "Enable membarrier() system call" if EXPERT
> >         default y
> >         help
> >           Enable the membarrier() system call that allows issuing memory
> >           barriers across all running threads, which can be used to distribute
> >           the cost of user-space memory barriers asymmetrically by transforming
> >           pairs of memory barriers into pairs consisting of membarrier() and a
> >           compiler barrier.
> >
> >           If unsure, say Y.
> >
> > Before 1464d00b27b2, riscv just happened to set it to =n in the defconfig.
> >
> > I suspect the initial port of riscv merged after v4.14 was already broken.
>
> I see.  Oh well, guess I'll have to leave this up to the maintainers then
> (I believe I've never managed to build riscv that far), Palmer?

I see

$ git grep "config MEMBARRIER" fab957c11efe2f405e08b9f0d080524bc2631428
fab957c11efe2f405e08b9f0d080524bc2631428:init/Kconfig:config MEMBARRIER

so IMO this is just one of those forever bugs.  So I'd lean towards

   Fixes: fab957c11efe ("RISC-V: Atomic and Locking Code")

(or anything in that original patch set).  It's not that big of a 
backport, so I think it's safe enough?

> > > I'll look into adding the membarrier feature you mention (as a final/
> > > follow-up patch), unless you or someone else want to take care of it.
> >
> > I'll be happy to review it :)
>
> Sweet!  :-)
>
>   Andrea