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 | <rqpv3mrcsxxdlaedbckb26bf5vfkj3xgd6m26me24nf4tbcqtb@jh62r2df3ur7> |
On Fri, May 22, 2026 at 07:50:43AM -0500, Andrew Jones wrote: > 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 :-) > But... before we get too carried away. Unless I'm missing something, this race really looks too theoretical to justify any change at all. Do you have a test case in mind that could force it? Thanks, drew -- kvm-riscv mailing list [email protected] http://lists.infradead.org/mailman/listinfo/kvm-riscv