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.
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
