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.
From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
[ Upstream commit 1ff95eb2bebda50c4c5406caaf201e0fcb24cc8f ]
RISCV_ALTERNATIVE_EARLY will issue sbi_ecall() very early in the boot
process, before the first memory mapping is setup so we can't have any
instrumentation happening here.
In addition, when the kernel is relocatable, we must also not issue any
relocation this early since they would have been patched virtually only.
So, instead of disabling instrumentation for the whole kernel/sbi.c file
and compiling it with -fno-pie, simply move __sbi_ecall() and
__sbi_base_ecall() into their own file where this is fixed.
Reported-by: Conor Dooley <conor.dooley@xxxxxxxxxxxxx>
Closes:https://lore.kernel.org/linux-riscv/20240813-pony-truck-3e7a83e9759e@spud/
Reported-by
<https://lore.kernel.org/linux-riscv/20240813-pony-truck-3e7a83e9759e@spud/Reported-by>:syzbot+cfbcb82adf6d7279fd35@xxxxxxxxxxxxxxxxxxxxxxxxx
<mailto:syzbot%2Bcfbcb82adf6d7279fd35@xxxxxxxxxxxxxxxxxxxxxxxxx>
Closes:https://lore.kernel.org/linux-riscv/00000000000065062c061fcec37b@xxxxxxxxxx/
<https://lore.kernel.org/linux-riscv/00000000000065062c061fcec37b@xxxxxxxxxx/>
Fixes: 1745cfafebdf ("riscv: don't use global static vars to store
alternative data")
Signed-off-by: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
Link:https://lore.kernel.org/r/20240829165048.49756-1-alexghiti@xxxxxxxxxxxx
<https://lore.kernel.org/r/20240829165048.49756-1-alexghiti@xxxxxxxxxxxx>
Signed-off-by: Palmer Dabbelt <palmer@xxxxxxxxxxxx>
Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>
---
arch/riscv/include/asm/sbi.h | 20 ++++++++++-
arch/riscv/kernel/Makefile | 6 +++-
arch/riscv/kernel/sbi.c | 63 -----------------------------------
arch/riscv/kernel/sbi_ecall.c | 48 ++++++++++++++++++++++++++
4 files changed, 72 insertions(+), 65 deletions(-)
create mode 100644 arch/riscv/kernel/sbi_ecall.c
I'll pay attention to that from now on.
Thanks,
Alex
thanks,
greg k-h
_______________________________________________
linux-riscv mailing list
linux-riscv@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-riscv
