riscv: mm: Unconditionally sfence.vma for spurious fault

Svvptc does not guarantee that it's safe to just return here. Since we
have already cleared our bit, if, theoretically, the bounded timeframe
for the accessed page to become valid still hasn't happened after sret,
we could fault again and actually crash.

Hopefully, these spurious faults should be rare enough that this is an
acceptable slowdown.

Cc: stable@vger.kernel.org
Fixes: 503638e0babf ("riscv: Stop emitting preventive sfence.vma for new vmalloc mappings")
Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn>
Link: https://patch.msgid.link/20260303-handle-kfence-protect-spurious-fault-v2-5-f80d8354d79d@iscas.ac.cn
Signed-off-by: Paul Walmsley <pjw@kernel.org>

diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S
index ebf6918b4e9b66f2d36b11aec4459171cbfa87f3..c6988983cdf7d70315b7a900f11b9765d3e85a02 100644 (file)
--- a/arch/riscv/kernel/entry.S
+++ b/arch/riscv/kernel/entry.S
@@ -75,8 +75,11 @@
        /* Atomically reset the current cpu bit in new_valid_map_cpus */
        amoxor.d        a0, a1, (a0)
 
-       /* Only emit a sfence.vma if the uarch caches invalid entries */
-       ALTERNATIVE("sfence.vma", "nop", 0, RISCV_ISA_EXT_SVVPTC, 1)
+       /*
+        * A sfence.vma is required here. Even if we had Svvptc, there's no
+        * guarantee that after returning we wouldn't just fault again.
+        */
+       sfence.vma
 
        REG_L   a0, TASK_TI_A0(tp)
        REG_L   a1, TASK_TI_A1(tp)