Re: [PATCH] RISC-V: KVM: Fix TOCTOU race in SBI system suspend handler

Andrew Jones <[email protected]>
Newsgroups org.infradead.lists.kvm-riscv,org.infradead.lists.linux-riscv,org.kernel.vger.kvm,org.kernel.vger.linux-kernel
Message-ID <y2nfuwydbx4wxk3optxr5bex2pubo5whqvk2bzsl7os2kdkwaq@yk36oa4kozfh>
On Fri, May 22, 2026 at 03:18:13AM +0000, Jiakai Xu wrote:
> 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?

Good catch. I should have trusted my initial instincts to introduce a new
mutex :-)

Thanks,
drew

-- 
kvm-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kvm-riscv
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.