From: "Michael S. Tsirkin"
Date: Wed, 24 Jan 2018 23:46:19 +0200
> On Wed, Jan 24, 2018 at 04:38:30PM -0500, David Miller wrote:
>> From: Jason Wang
>> Date: Tue, 23 Jan 2018 17:27:25 +0800
>>
>> > We used to call mutex_lock() in vhost_dev_lock_vqs() which tries to
>> > hold mutexes of all virt
On Wed, Jan 24, 2018 at 04:38:30PM -0500, David Miller wrote:
> From: Jason Wang
> Date: Tue, 23 Jan 2018 17:27:25 +0800
>
> > We used to call mutex_lock() in vhost_dev_lock_vqs() which tries to
> > hold mutexes of all virtqueues. This may confuse lockdep to report a
> > possible deadlock because
From: Jason Wang
Date: Tue, 23 Jan 2018 17:27:25 +0800
> We used to call mutex_lock() in vhost_dev_lock_vqs() which tries to
> hold mutexes of all virtqueues. This may confuse lockdep to report a
> possible deadlock because of trying to hold locks belong to same
> class. Switch to use mutex_lock_
On Tue, Jan 23, 2018 at 05:27:25PM +0800, Jason Wang wrote:
> We used to call mutex_lock() in vhost_dev_lock_vqs() which tries to
> hold mutexes of all virtqueues. This may confuse lockdep to report a
> possible deadlock because of trying to hold locks belong to same
> class. Switch to use mutex_lo
We used to call mutex_lock() in vhost_dev_lock_vqs() which tries to
hold mutexes of all virtqueues. This may confuse lockdep to report a
possible deadlock because of trying to hold locks belong to same
class. Switch to use mutex_lock_nested() to avoid false positive.
Fixes: 6b1e6cc7855b0 ("vhost:
