Re: [syzbot] [kvm?] INFO: task hung in kvm_swap_active_memslots (2)

[Sean Christopherson <seanjc@google.com>]

On Mon, Nov 17, 2025, Sean Christopherson wrote:
> On Mon, Nov 17, 2025, Alexander Potapenko wrote:
> > On Mon, Nov 17, 2025 at 11:44 AM syzbot
> > <syzbot+5c566b850d6ab6f0427a@syzkaller.appspotmail.com> wrote:

...

> > > Showing all locks held in the system:
> > > 1 lock held by khungtaskd/31:
> > >  #0: ffffffff8e3c42e0 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline]
> > >  #0: ffffffff8e3c42e0 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:867 [inline]
> > >  #0: ffffffff8e3c42e0 (rcu_read_lock){....}-{1:3}, at: debug_show_all_locks+0x36/0x1c0 kernel/locking/lockdep.c:6775
> > > 2 locks held by getty/8058:
> > >  #0: ffff88803440d0a0 (&tty->ldisc_sem){++++}-{0:0}, at: tty_ldisc_ref_wait+0x24/0x80 drivers/tty/tty_ldisc.c:243
> > >  #1: ffffc9000e0cd2f0 (&ldata->atomic_read_lock){+.+.}-{4:4}, at: n_tty_read+0x41b/0x14f0 drivers/tty/n_tty.c:2222
> > > 2 locks held by syz.2.1185/11790:
> > >  #0: ffff888032d640a8 (&kvm->slots_lock){+.+.}-{4:4}, at: class_mutex_constructor include/linux/mutex.h:228 [inline]
> > >  #0: ffff888032d640a8 (&kvm->slots_lock){+.+.}-{4:4}, at: kvm_alloc_apic_access_page+0x27/0x140 arch/x86/kvm/lapic.c:2782
> > >  #1: ffff888032d64138 (&kvm->slots_arch_lock){+.+.}-{4:4}, at: kvm_set_memslot+0x34/0x1380 virt/kvm/kvm_main.c:1915
> > 
> > It's worth noting that in addition to upstream this bug has been
> > reported by syzkaller on several other kernel branches.
> > In each report, the task was shown to be holding the same pair of
> > locks: &kvm->slots_arch_lock and &kvm->slots_lock.
> 
> Ya, though that's not terribly interesting because kvm_swap_active_memslots()
> holds those locks, and the issue is specifically that kvm_swap_active_memslots()
> is waiting on kvm->mn_active_invalidate_count to go to zero.
> 
> Paolo even called out this possibility in commit 52ac8b358b0c ("KVM: Block memslot
> updates across range_start() and range_end()"):
> 
>  : Losing the rwsem fairness does theoretically allow MMU notifiers to
>  : block install_new_memslots forever.  Note that mm/mmu_notifier.c's own
>  : retry scheme in mmu_interval_read_begin also uses wait/wake_up
>  : and is likewise not fair.
> 
> In every reproducer, the "VMM" process is either getting thrashed by reclaim, or
> the process itself is generating a constant stream of mmu_notifier invalidations.
> 
> I don't see an easy, or even decent, solution for this.

The new reproducer reminded me: I do have _an_ idea for solving this problem, but
it's pretty awful.  Rather than block memslot updates, KVM "just" needs to track
which events are relevant.  If we could guarantee at most one VM is affected by
an invalidation, then we could shove a flag into the event itself, e.g. to avoid
any memory allocations.  Ugly, but easy.

Unfortunately, a process that is running multiple VMs will fall apart :-/  The
only way I can think of to track events would be to do so in the VM, and that in
turn requires a memory allocation (and it's still ugly as we'd have to track
kernel pointers, ugh).