On 10/09/2024 15:25, Greg KH wrote:
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@xxxxxxxxx>
[ 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@xxxxxxxxx>
Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx>
Link: https://lore.kernel.org/r/20240131144936.29190-2-parri.andrea@xxxxxxxxx
Signed-off-by: Palmer Dabbelt <palmer@xxxxxxxxxxxx>
Signed-off-by: WangYuli <wangyuli@xxxxxxxxxxxxx>
---
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.
Great, thank you, I'll make sure we tag the fixes to backport properly!
Thanks again,
Alex
thanks,
greg k-h
