linux-kernel - Re: [PATCH 6.6] membarrier: riscv: Add full memory barrier in switch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2024091056-bogus-whoops-4bde@gregkh>
Date: Tue, 10 Sep 2024 15:25:25 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Alexandre Ghiti <alex@...ti.fr>
Cc: WangYuli <wangyuli@...ontech.com>, stable@...r.kernel.org,
	sashal@...nel.org, parri.andrea@...il.com,
	mathieu.desnoyers@...icios.com, palmer@...osinc.com,
	linux-kernel@...r.kernel.org, paul.walmsley@...ive.com,
	palmer@...belt.com, aou@...s.berkeley.edu, nathan@...nel.org,
	ndesaulniers@...gle.com, trix@...hat.com,
	linux-riscv@...ts.infradead.org, llvm@...ts.linux.dev,
	paulmck@...nel.org, mingo@...hat.com, peterz@...radead.org,
	juri.lelli@...hat.com, vincent.guittot@...aro.org,
	dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com,
	mgorman@...e.de, bristot@...hat.com, vschneid@...hat.com,
	brauner@...nel.org, arnd@...db.de
Subject: Re: [PATCH 6.6] membarrier: riscv: Add full memory barrier in
 switch_mm()

On Tue, Sep 10, 2024 at 02:35:06PM +0200, Alexandre Ghiti wrote:
> 
> On 10/09/2024 13:58, Greg KH wrote:
> > On Tue, Sep 10, 2024 at 01:31:04PM +0200, Alexandre Ghiti wrote:
> > > Hi Greg,
> > > 
> > > On 10/09/2024 09:32, Greg KH wrote:
> > > > On Mon, Sep 09, 2024 at 10:57:01AM +0800, WangYuli wrote:
> > > > > From: Andrea Parri <parri.andrea@...il.com>
> > > > > 
> > > > > [ Upstream commit d6cfd1770f20392d7009ae1fdb04733794514fa9 ]
> > > > > 
> > > > > The membarrier system call requires a full memory barrier after storing
> > > > > to rq->curr, before going back to user-space.  The barrier is only
> > > > > needed when switching between processes: the barrier is implied by
> > > > > mmdrop() when switching from kernel to userspace, and it's not needed
> > > > > when switching from userspace to kernel.
> > > > > 
> > > > > Rely on the feature/mechanism ARCH_HAS_MEMBARRIER_CALLBACKS and on the
> > > > > primitive membarrier_arch_switch_mm(), already adopted by the PowerPC
> > > > > architecture, to insert the required barrier.
> > > > > 
> > > > > Fixes: fab957c11efe2f ("RISC-V: Atomic and Locking Code")
> > > > > Signed-off-by: Andrea Parri <parri.andrea@...il.com>
> > > > > Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
> > > > > Link: https://lore.kernel.org/r/20240131144936.29190-2-parri.andrea@gmail.com
> > > > > Signed-off-by: Palmer Dabbelt <palmer@...osinc.com>
> > > > > Signed-off-by: WangYuli <wangyuli@...ontech.com>
> > > > > ---
> > > > >    MAINTAINERS                         |  2 +-
> > > > >    arch/riscv/Kconfig                  |  1 +
> > > > >    arch/riscv/include/asm/membarrier.h | 31 +++++++++++++++++++++++++++++
> > > > >    arch/riscv/mm/context.c             |  2 ++
> > > > >    kernel/sched/core.c                 |  5 +++--
> > > > >    5 files changed, 38 insertions(+), 3 deletions(-)
> > > > >    create mode 100644 arch/riscv/include/asm/membarrier.h
> > > > Now queued up, thanks.
> > > 
> > > The original patch was merged in 6.9 and the Fixes tag points to a commit
> > > introduced in v4.15. So IIUC, this patch should have been backported
> > > "automatically" to the releases < 6.9 right? As stated in the documentation
> > > (process/stable-kernel-rules.html):
> > > 
> > > "Note, such tagging is unnecessary if the stable team can derive the
> > > appropriate versions from Fixes: tags."
> > > 
> > > Or did we miss something?
> > Yes, you didn't tag cc: stable at all in this commit, which is why we
> > did not see it.  The documentation says that :)
> 
> 
> Ok, some patches seem to make it to stable without the cc: stable tag (like
> the one below for example), so I thought it was not necessary.

Yes, they do, because many maintainers and developers don't follow the
normal rules, so we sweep the tree when we have a chance and do a "best
effort" backport at times.

But again, it is NOT guaranteed that this will happen, and even if it
does, you will NOT get emails saying the attempt-at-backporting fails,
if it fails, as obviously the developers involved weren't explicitly
asking for it to be backported.

So in short, just properly tag things for stable, and all will be fine.

thanks,

greg k-h