[PATCH] RISC-V: KVM: Fix TOCTOU race in SBI system suspend handler
Jiakai Xu
xujiakai2025 at iscas.ac.cn
Thu May 21 20:18:13 PDT 2026
Hi, drew!
Thanks for your review!
> > I'm not a big fan of this approach and I see sashiko found it has gaps[1].
I read sashiko's feedback and I think it makes sense.
> > I'd rather we introduce a mutex to kvm_arch to serialize cross-vcpu
>
> Eh, not sure why I said 'introduce' here. We can just use kvm->lock.
I looked into that, but it may be not suitable. Here's why:
Documentation/virt/kvm/locking.rst explicitly states: kvm->lock is taken
outside vcpu->mutex. The susp handler runs inside kvm_arch_vcpu_ioctl_run(),
which is called from kvm_vcpu_ioctl() where vcpu->mutex is already held.
Taking kvm->lock inside the susp handler would produce: vcpu->mutex → kvm->lock.
So may be we should introduce a mutex to kvm_arch to serialize cross-vcpu
mp-state operations.
What do you think?
> > mp-state operations. So it'd be taken in SUSP, HART_START, and also SRST
>
> And, even though SRST doesn't really need it - why not... Consistency has
> its merits.
>
> > (anywhere that reads or modifies another vcpu's mp-state). Operations that
> > only modify the calling vcpu's own state would still only use the per-vcpu
> > mp_state_lock.
> >
> > [1] https://sashiko.dev/#/patchset/20260521142030.1560861-1-xujiakai2025%40iscas.ac.cn
I agree with you.
Regards,
Jiakai
More information about the linux-riscv
mailing list