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@xxxxxxxxxxxxxxxxxxxxxxxxx > > ====================================================== > 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.
