Re: [syzbot] [kvm?] possible deadlock in kvm_arch_pm_notifier

[Sean Christopherson <seanjc@google.com>]

On Mon, Jan 06, 2025, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    0bc21e701a6f MAINTAINERS: Remove Olof from SoC maintainers
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=163abd0f980000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=86dd15278dbfe19f
> dashboard link: https://syzkaller.appspot.com/bug?extid=352e553a86e0d75f5120
> compiler:       gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
> userspace arch: i386
> 
> Unfortunately, I don't have any reproducer for this issue yet.
> 
> Downloadable assets:
> disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/7feb34a89c2a/non_bootable_disk-0bc21e70.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/7552d06d3231/vmlinux-0bc21e70.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/0d1494ecdf2f/bzImage-0bc21e70.xz
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+352e553a86e0d75f5120@syzkaller.appspotmail.com
> 
> ======================================================
> WARNING: possible circular locking dependency detected
> 6.13.0-rc5-syzkaller-00012-g0bc21e701a6f #0 Not tainted
> ------------------------------------------------------
> syz.8.2149/14842 is trying to acquire lock:
> ffffc90006bccb58 (&kvm->lock){+.+.}-{4:4}, at: kvm_arch_suspend_notifier arch/x86/kvm/x86.c:6919 [inline]
> ffffc90006bccb58 (&kvm->lock){+.+.}-{4:4}, at: kvm_arch_pm_notifier+0xf5/0x2b0 arch/x86/kvm/x86.c:6941
> 
> but task is already holding lock:
> ffffffff8dcbeb10 ((pm_chain_head).rwsem){++++}-{4:4}, at: blocking_notifier_call_chain_robust kernel/notifier.c:344 [inline]
> ffffffff8dcbeb10 ((pm_chain_head).rwsem){++++}-{4:4}, at: blocking_notifier_call_chain_robust+0xa9/0x170 kernel/notifier.c:333
> 
> which lock already depends on the new lock.

Huh.  I was going to say that this is essentially the same underlying problem
that led to commit 44d174596260 ("KVM: Use dedicated mutex to protect
kvm_usage_count to avoid deadlock"), where taking kvm_lock in notifier callbacks
is prone to deadlocks that are all but impossible to hit in practice.

But this is the per-VM lock, kvm->lock, not the global lock.  I don't see any
reason to take kvm->lock in kvm_arch_suspend_notifier().  vcpu->arch.pv_time.active
and vcpu->arch.pvclock_set_guest_stopped_request are protected by vcpu->mutex,
not kvm->lock, i.e. accessing those fields is racy no matter what.