Re: riscv: signal: protect regs->status RMW from concurrent preemption

[Andy Chiu <tchiu@tenstorrent.com>]

Hi Aurelien,

On Fri, Sep 25, 2026 at 06:33:50AM +0200, Aurelien Jarno wrote:
> Hi Guobin,
> 
> On 2026-08-07 11:00, Guobin Zhang wrote:
> > __fstate_clean() performs a non-atomic read-modify-write (RMW) on
> > task_pt_regs(current)->status to clear the FS bits. This RMW is
> > unprotected - it runs with preemption enabled and IRQs on during
> > signal delivery (setup_rt_frame -> fstate_save) and sigreturn
> > (restore_fp_state -> fstate_restore).
> > 
> > If a reschedule IPI or timer interrupt triggers preemption between
> > the load and store of this RMW, __switch_to_vector() calls
> > riscv_v_vstate_set_restore() which modifies the VS bits of the
> > same regs->status. When the preempted task resumes, it stores back
> > the stale value captured before preemption, overwriting the VS
> > update and restoring VS=DIRTY while TIF_RISCV_V_DEFER_RESTORE
> > remains set - a combination that should never occur and leads to
> > vector state corruption.
> > 
> > The race window:
> > 
> >   __fstate_clean (signal path)      set_restore (schedule path)
> >   -----------------------------     -----------------------------
> >   ld  a0, regs->status  // VS=DIRTY, FS=DIRTY
> >                                      <- preempted (reschedule IPI)
> >                                      regs->status VS = INITIAL
> >                                      set TIF_RISCV_V_DEFER_RESTORE
> >                                      <- resumed
> >   andi a0, ~FS
> >   ori  a0, FS_CLEAN     // stale a0 still has VS=DIRTY
> >   sd   a0, regs->status // overwrites VS=INITIAL with VS=DIRTY
> >   -> result: VS=DIRTY + DEFER -> ANOMALY
> > 
> > Fix by adding preempt_disable/enable around the RMW in
> > __fstate_clean() and fstate_off(). riscv_v_vstate_set_restore()
> > has the identical hazard: it is called from __restore_v_state()
> > (sigreturn path) with preemption enabled, and it can race the same
> > way against the scheduler's own call to riscv_v_vstate_set_restore()
> > for the same task in __switch_to_vector(). Wrap that call site with
> > preempt_disable/enable as well.
> > 
> > Add WARN_ON_ONCE(preemptible()) to riscv_v_vstate_restore()
> > to catch any future unprotected callers at development time.
> > 
> > Signed-off-by: Guobin Zhang <guobin.zhang@intel.com>
> > ---
> > Race: regs->status is shared between the FPU (SR_FS) and vector
> > (SR_VS) state machines. Three call sites do a non-atomic RMW on it
> > while preemptible: __fstate_clean()/fstate_off() in switch_to.h, and
> > riscv_v_vstate_set_restore() as called from signal.c's
> > __restore_v_state() (sigreturn path).
> > 
> > Cause: if the task is preempted between the load and the store, the
> > scheduler's own switch_to() writes the other half of the same
> > register word when switching this task back in. The task then
> > resumes and stores its stale value, clobbering that write.
> > 
> > Fix: wrap each RMW with preempt_disable()/preempt_enable(). This is
> > sufficient because the conflicting writer only runs via an actual
> > context switch of this task, which preempt_disable() prevents.
> > local_irq_disable() is not needed: no IRQ handler touches
> > regs->status, so masking IRQs would add latency without closing any
> > extra race.
> > 
> > Reproduced on Spacemit K1 hardware; not reproducible under QEMU/TCG
> > (see commit message for the full race-window trace).
> > ---
> >  arch/riscv/include/asm/switch_to.h | 4 ++++
> >  arch/riscv/include/asm/vector.h    | 2 ++
> >  arch/riscv/kernel/signal.c         | 2 ++
> >  3 files changed, 8 insertions(+)
> 
> Han Gao pointed me to this patch as a possible fix to the issue I 
> encountered on the SpacemiT K1 [1]. So far, my first tests show
> that it either fixes the issue or at the bare minimum hides it.
> 
> As you also mention that you reproduced the issue on the Spacemit K1 
> hardware, can you please tell me if the bug appeared with similar 
> symptoms?
> 

I have a reproducer on this bug and can reliablely catch it on K3. The
code runs in a loop that does the following things:

1. dirtify FS by executing a fp instruction
2. configure vstate as e8 m1
3. load bytes into v5
4. trigger a signal handler by executing ebreak
5. vector save using the loaded v5

The signal handler verifies if it comes from the ebreak, otherwise it is
the vstate corruption. Run multiple threads per core to increase the
context switch rate.

This should hit the problem pretty soon, as corrupting lmul to m8 would
cause the vector save from v5 trap immediately. With the fix the problem
no longer occurs.

Cheers,
Andy