lockdep warning with 2d65a9f48fcdf7866aab6457bc707ca233e0c791

=============================================
[ INFO: possible recursive locking detected ]
3.17.0+ #31 Not tainted
---------------------------------------------
qemu-system-ppc/9112 is trying to acquire lock:
(&(&vcpu->arch.tbacct_lock)->rlock){......}, at: [<d000000011591f84>] .vcore_stolen_time+0x44/0xb0 [kvm_hv]

but task is already holding lock:
(&(&vcpu->arch.tbacct_lock)->rlock){......}, at: [<d000000011592524>] .kvmppc_remove_runnable.part.2+0x34/0xd0 [kvm_hv]

other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0
       ----

lock(&(&vcpu->arch.tbacct_lock)->rlock);
lock(&(&vcpu->arch.tbacct_lock)->rlock);

*** DEADLOCK ***

May be due to missing lock nesting notation

3 locks held by qemu-system-ppc/9112:

 #0:  (&vcpu->mutex){+.+.+.}, at: [<c00000000008687c>] .vcpu_load+0x2c/0xf0
 #1:  (&(&vcore->lock)->rlock){+.+...}, at: [<d000000011594790>] .kvmppc_vcpu_run_hv+0x770/0x1720 [kvm_hv]
 #2:  (&(&vcpu->arch.tbacct_lock)->rlock){......}, at: [<d000000011592524>] .kvmppc_remove_runnable.part.2+0x34/0xd0 [kvm_hv]

stack backtrace:
CPU: 56 PID: 9112 Comm: qemu-system-ppc Not tainted 3.17.0+ #31
Call Trace:
[c000000fe488f330] [c0000000000167dc] .show_stack+0x7c/0x1f0 (unreliable)
[c000000fe488f400] [c0000000008ea148] .dump_stack+0x9c/0xd8
[c000000fe488f480] [c000000000110c6c] .__lock_acquire+0x151c/0x1ef0
[c000000fe488f600] [c000000000111fb0] .lock_acquire+0xd0/0x1b0
[c000000fe488f6d0] [c0000000008ddedc] ._raw_spin_lock_irq+0x5c/0x80
[c000000fe488f760] [d000000011591f84] .vcore_stolen_time+0x44/0xb0 [kvm_hv]
[c000000fe488f7f0] [d00000001159253c] .kvmppc_remove_runnable.part.2+0x4c/0xd0 [kvm_hv]
[c000000fe488f890] [d0000000115950c0] .kvmppc_vcpu_run_hv+0x10a0/0x1720 [kvm_hv]
[c000000fe488f9f0] [c000000000091d1c] .kvmppc_vcpu_run+0x2c/0x40
[c000000fe488fa60] [c00000000008efd4] .kvm_arch_vcpu_ioctl_run+0x54/0x170
[c000000fe488faf0] [c000000000086f78] .kvm_vcpu_ioctl+0x5c8/0x780
[c000000fe488fcb0] [c000000000264b54] .do_vfs_ioctl+0x474/0x770
[c000000fe488fd90] [c000000000264ea8] .SyS_ioctl+0x58/0xb0
[c000000fe488fe30] [c000000000009264] syscall_exit+0x0/0x98

This must come from here:

        while (vcpu->arch.state = KVMPPC_VCPU_RUNNABLE &&
               (vc->vcore_state = VCORE_RUNNING ||
                vc->vcore_state = VCORE_EXITING)) {
                spin_unlock(&vc->lock);
                kvmppc_wait_for_exec(vcpu, TASK_UNINTERRUPTIBLE);
                spin_lock(&vc->lock);
        }

        if (vcpu->arch.state = KVMPPC_VCPU_RUNNABLE) {
                kvmppc_remove_runnable(vc, vcpu);
                vcpu->stat.signal_exits++;
                kvm_run->exit_reason = KVM_EXIT_INTR;
                vcpu->arch.ret = -EINTR;
        }

if vc->vcore_state is VCORE_SLEEPING (I think it cannot be VCORE_STARTING)?

Paolo

This is actually harmless, because the lock taken in vcore_stolen_time() is always a different lock from the one taken in kvmppc_remove_runnable(). In vcore_stolen_time() we take the lock of the runner vcpu if we are not the runner vcpu (if we are the runner, we don't take any lock there). Nor is there any lock ordering problem, because we always take the runner's lock last.

This is all a bit subtle, probably a bit too subtle. I have been meaning to rework it but haven't had the time yet.

Paul.