[PW_SID:958645] KVM: lockdep improvements#360
Conversation
Despite the fact that several lockdep-related checks are skipped when
calling trylock* versions of the locking primitives, for example
mutex_trylock, each time the mutex is acquired, a held_lock is still
placed onto the lockdep stack by __lock_acquire() which is called
regardless of whether the trylock* or regular locking API was used.
This means that if the caller successfully acquires more than
MAX_LOCK_DEPTH locks of the same class, even when using mutex_trylock,
lockdep will still complain that the maximum depth of the held lock stack
has been reached and disable itself.
For example, the following error currently occurs in the ARM version
of KVM, once the code tries to lock all vCPUs of a VM configured with more
than MAX_LOCK_DEPTH vCPUs, a situation that can easily happen on modern
systems, where having more than 48 CPUs is common, and it's also common to
run VMs that have vCPU counts approaching that number:
[ 328.171264] BUG: MAX_LOCK_DEPTH too low!
[ 328.175227] turning off the locking correctness validator.
[ 328.180726] Please attach the output of /proc/lock_stat to the bug report
[ 328.187531] depth: 48 max: 48!
[ 328.190678] 48 locks held by qemu-kvm/11664:
[ 328.194957] #0: ffff800086de5ba0 (&kvm->lock){+.+.}-{3:3}, at: kvm_ioctl_create_device+0x174/0x5b0
[ 328.204048] #1: ffff0800e78800b8 (&vcpu->mutex){+.+.}-{3:3}, at: lock_all_vcpus+0x16c/0x2a0
[ 328.212521] #2: ffff07ffeee51e98 (&vcpu->mutex){+.+.}-{3:3}, at: lock_all_vcpus+0x16c/0x2a0
[ 328.220991] #3: ffff0800dc7d80b8 (&vcpu->mutex){+.+.}-{3:3}, at: lock_all_vcpus+0x16c/0x2a0
[ 328.229463] #4: ffff07ffe0c980b8 (&vcpu->mutex){+.+.}-{3:3}, at: lock_all_vcpus+0x16c/0x2a0
[ 328.237934] #5: ffff0800a3883c78 (&vcpu->mutex){+.+.}-{3:3}, at: lock_all_vcpus+0x16c/0x2a0
[ 328.246405] #6: ffff07fffbe480b8 (&vcpu->mutex){+.+.}-{3:3}, at: lock_all_vcpus+0x16c/0x2a0
Luckily, in all instances that require locking all vCPUs, the
'kvm->lock' is taken a priori, and that fact makes it possible to use
the little known feature of lockdep, called a 'nest_lock', to avoid this
warning and subsequent lockdep self-disablement.
The action of 'nested lock' being provided to lockdep's lock_acquire(),
causes the lockdep to detect that the top of the held lock stack contains
a lock of the same class and then increment its reference counter instead
of pushing a new held_lock item onto that stack.
See __lock_acquire for more information.
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
Use mutex_trylock_nest_lock instead of mutex_trylock when locking all vCPUs
of a VM, to avoid triggering a lockdep warning, if the VM is configured to
have more than MAX_LOCK_DEPTH vCPUs.
This fixes the following false lockdep warning:
[ 328.171264] BUG: MAX_LOCK_DEPTH too low!
[ 328.175227] turning off the locking correctness validator.
[ 328.180726] Please attach the output of /proc/lock_stat to the bug report
[ 328.187531] depth: 48 max: 48!
[ 328.190678] 48 locks held by qemu-kvm/11664:
[ 328.194957] #0: ffff800086de5ba0 (&kvm->lock){+.+.}-{3:3}, at: kvm_ioctl_create_device+0x174/0x5b0
[ 328.204048] #1: ffff0800e78800b8 (&vcpu->mutex){+.+.}-{3:3}, at: lock_all_vcpus+0x16c/0x2a0
[ 328.212521] #2: ffff07ffeee51e98 (&vcpu->mutex){+.+.}-{3:3}, at: lock_all_vcpus+0x16c/0x2a0
[ 328.220991] #3: ffff0800dc7d80b8 (&vcpu->mutex){+.+.}-{3:3}, at: lock_all_vcpus+0x16c/0x2a0
[ 328.229463] #4: ffff07ffe0c980b8 (&vcpu->mutex){+.+.}-{3:3}, at: lock_all_vcpus+0x16c/0x2a0
[ 328.237934] #5: ffff0800a3883c78 (&vcpu->mutex){+.+.}-{3:3}, at: lock_all_vcpus+0x16c/0x2a0
[ 328.246405] #6: ffff07fffbe480b8 (&vcpu->mutex){+.+.}-{3:3}, at: lock_all_vcpus+0x16c/0x2a0
Since the locking of all vCPUs is a primitive that can be useful in other
architectures that are supported by KVM, also move the code to kvm_main.c
Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
Use the kvm_trylock_all_vcpus()/unlock_all_vcpus() instead of riscv's own implementation, to avoid triggering a lockdep warning, if the VM is configured to have more than MAX_LOCK_DEPTH vCPUs. Compile tested only. Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
KVM's SEV intra-host migration code needs to lock all vCPUs of the source and the target VM, before it proceeds with the migration. The number of vCPUs that belong to each VM is not bounded by anything except a self-imposed KVM limit of CONFIG_KVM_MAX_NR_VCPUS vCPUs which is significantly larger than the depth of lockdep's lock stack. Luckily, the locks in both of the cases mentioned above, are held under the 'kvm->lock' of each VM, which means that we can use the little known lockdep feature called a "nest_lock" to support this use case in a cleaner way, compared to the way it's currently done. Implement and expose 'mutex_lock_killable_nest_lock' for this purpose. Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
Implement kvm_lock_all_vcpus() and use it instead of
sev own sev_{lock|unlock}_vcpus_for_migration().
Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
|
Patch 1: "[v4,1/5] locking/mutex: implement mutex_trylock_nested" |
|
Patch 1: "[v4,1/5] locking/mutex: implement mutex_trylock_nested" |
|
Patch 1: "[v4,1/5] locking/mutex: implement mutex_trylock_nested" |
|
Patch 1: "[v4,1/5] locking/mutex: implement mutex_trylock_nested" |
|
Patch 1: "[v4,1/5] locking/mutex: implement mutex_trylock_nested" |
|
Patch 1: "[v4,1/5] locking/mutex: implement mutex_trylock_nested" |
|
Patch 1: "[v4,1/5] locking/mutex: implement mutex_trylock_nested" |
|
Patch 1: "[v4,1/5] locking/mutex: implement mutex_trylock_nested" |
|
Patch 1: "[v4,1/5] locking/mutex: implement mutex_trylock_nested" |
|
Patch 1: "[v4,1/5] locking/mutex: implement mutex_trylock_nested" |
|
Patch 1: "[v4,1/5] locking/mutex: implement mutex_trylock_nested" |
|
Patch 1: "[v4,1/5] locking/mutex: implement mutex_trylock_nested" |
|
Patch 2: "[v4,2/5] arm64: KVM: use mutex_trylock_nest_lock when locking all vCPUs" |
|
Patch 2: "[v4,2/5] arm64: KVM: use mutex_trylock_nest_lock when locking all vCPUs" |
|
Patch 2: "[v4,2/5] arm64: KVM: use mutex_trylock_nest_lock when locking all vCPUs" |
|
Patch 2: "[v4,2/5] arm64: KVM: use mutex_trylock_nest_lock when locking all vCPUs" |
|
Patch 2: "[v4,2/5] arm64: KVM: use mutex_trylock_nest_lock when locking all vCPUs" |
|
Patch 2: "[v4,2/5] arm64: KVM: use mutex_trylock_nest_lock when locking all vCPUs" |
|
Patch 2: "[v4,2/5] arm64: KVM: use mutex_trylock_nest_lock when locking all vCPUs" |
|
Patch 2: "[v4,2/5] arm64: KVM: use mutex_trylock_nest_lock when locking all vCPUs" |
|
Patch 2: "[v4,2/5] arm64: KVM: use mutex_trylock_nest_lock when locking all vCPUs" |
|
Patch 2: "[v4,2/5] arm64: KVM: use mutex_trylock_nest_lock when locking all vCPUs" |
|
Patch 2: "[v4,2/5] arm64: KVM: use mutex_trylock_nest_lock when locking all vCPUs" |
|
Patch 2: "[v4,2/5] arm64: KVM: use mutex_trylock_nest_lock when locking all vCPUs" |
|
Patch 3: "[v4,3/5] RISC-V: KVM: switch to kvm_trylock/unlock_all_vcpus" |
|
Patch 3: "[v4,3/5] RISC-V: KVM: switch to kvm_trylock/unlock_all_vcpus" |
|
Patch 3: "[v4,3/5] RISC-V: KVM: switch to kvm_trylock/unlock_all_vcpus" |
|
Patch 4: "[v4,4/5] locking/mutex: implement mutex_lock_killable_nest_lock" |
|
Patch 4: "[v4,4/5] locking/mutex: implement mutex_lock_killable_nest_lock" |
|
Patch 4: "[v4,4/5] locking/mutex: implement mutex_lock_killable_nest_lock" |
|
Patch 4: "[v4,4/5] locking/mutex: implement mutex_lock_killable_nest_lock" |
|
Patch 4: "[v4,4/5] locking/mutex: implement mutex_lock_killable_nest_lock" |
|
Patch 4: "[v4,4/5] locking/mutex: implement mutex_lock_killable_nest_lock" |
|
Patch 4: "[v4,4/5] locking/mutex: implement mutex_lock_killable_nest_lock" |
|
Patch 4: "[v4,4/5] locking/mutex: implement mutex_lock_killable_nest_lock" |
|
Patch 4: "[v4,4/5] locking/mutex: implement mutex_lock_killable_nest_lock" |
|
Patch 4: "[v4,4/5] locking/mutex: implement mutex_lock_killable_nest_lock" |
|
Patch 4: "[v4,4/5] locking/mutex: implement mutex_lock_killable_nest_lock" |
|
Patch 4: "[v4,4/5] locking/mutex: implement mutex_lock_killable_nest_lock" |
|
Patch 5: "[v4,5/5] x86: KVM: SEV: implement kvm_lock_all_vcpus and use it" |
|
Patch 5: "[v4,5/5] x86: KVM: SEV: implement kvm_lock_all_vcpus and use it" |
|
Patch 5: "[v4,5/5] x86: KVM: SEV: implement kvm_lock_all_vcpus and use it" |
|
Patch 5: "[v4,5/5] x86: KVM: SEV: implement kvm_lock_all_vcpus and use it" |
|
Patch 5: "[v4,5/5] x86: KVM: SEV: implement kvm_lock_all_vcpus and use it" |
|
Patch 5: "[v4,5/5] x86: KVM: SEV: implement kvm_lock_all_vcpus and use it" |
|
Patch 5: "[v4,5/5] x86: KVM: SEV: implement kvm_lock_all_vcpus and use it" |
|
Patch 5: "[v4,5/5] x86: KVM: SEV: implement kvm_lock_all_vcpus and use it" |
|
Patch 5: "[v4,5/5] x86: KVM: SEV: implement kvm_lock_all_vcpus and use it" |
|
Patch 5: "[v4,5/5] x86: KVM: SEV: implement kvm_lock_all_vcpus and use it" |
|
Patch 5: "[v4,5/5] x86: KVM: SEV: implement kvm_lock_all_vcpus and use it" |
|
Patch 5: "[v4,5/5] x86: KVM: SEV: implement kvm_lock_all_vcpus and use it" |
4d9ad71 to
625be03
Compare
PR for series 958645 applied to workflow__riscv__fixes
Name: KVM: lockdep improvements
URL: https://patchwork.kernel.org/project/linux-riscv/list/?series=958645
Version: 4