lockdep warning with 2d65a9f48fcdf7866aab6457bc707ca233e0c791

lockdep warning with 2d65a9f48fcdf7866aab6457bc707ca233e0c791

[Aneesh Kumar K.V]

=============================================
[ 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

Re: lockdep warning with 2d65a9f48fcdf7866aab6457bc707ca233e0c791

[Paolo Bonzini]

On 10/15/2014 07:28 PM, Aneesh Kumar K.V wrote:
> 
> =============================================
> [ 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]

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

Re: lockdep warning with 2d65a9f48fcdf7866aab6457bc707ca233e0c791

[Paul Mackerras]

On Wed, Oct 15, 2014 at 10:58:45PM +0530, Aneesh Kumar K.V wrote:
> 
> =============================================
> [ 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]

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.