On Mon, Jun 01, 2026, David Woodhouse wrote:
> On Fri, 2026-01-02 at 14:24 +0000, Fred Griffoul wrote:
> >
> > @@ -55,6 +70,27 @@ void gfn_to_pfn_cache_invalidate_start(struct kvm *kvm,
> > unsigned long start,
> > read_unlock_irq(&gpc->lock);
> > }
> > spin_unlock(&kvm->gpc_lock);
> > +
> > + if (evict_vcpus) {
> > + /*
> > + * KVM needs to ensure the vCPU is fully out of guest context
> > + * before allowing the invalidation to continue.
> > + */
> > + unsigned int req = KVM_REQ_OUTSIDE_GUEST_MODE;
> > + bool called;
> > +
> > + /*
> > + * If the OOM reaper is active, then all vCPUs should have
> > + * been stopped already, so perform the request without
> > + * KVM_REQUEST_WAIT and be sad if any needed to be IPI'd.
> > + */
>
> I am unconvinced of the veracity of that claim. We get here via
> __oom_reap_task_mm() which has explicit comments about 'might start
> racing with the dying task'.
>
> I think it's actually fine to use KVM_REQUEST_WAIT in theory...
Actually, it has to be "fine", because KVM already does KVM_REQUEST_WAIT for
literally every releavnt OOM kill thanks to the kvm_flush_remote_tlbs() in
kvm_mmu_notifier_invalidate_range_start() -> kvm_handle_hva_range(). So I would
say don't worry about KVM_REQUEST_WAIT here; if we need to fix anything for the
OOM case, then we need a more generic fix.
