vhost_vsock_handle_tx_kick() already holds the mutex during its call to vhost_get_vq_desc(). All we have to do here is take the same lock during virtqueue clean-up and we mitigate the reported issues.
Also WARN() as a precautionary measure. The purpose of this is to capture possible future race conditions which may pop up over time.
Cc: stable@vger.kernel.org Signed-off-by: Lee Jones lee.jones@linaro.org --- drivers/vhost/vhost.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c index 59edb5a1ffe28..bbaff6a5e21b8 100644 --- a/drivers/vhost/vhost.c +++ b/drivers/vhost/vhost.c @@ -693,6 +693,7 @@ void vhost_dev_cleanup(struct vhost_dev *dev) int i;
for (i = 0; i < dev->nvqs; ++i) { + mutex_lock(&dev->vqs[i]->mutex); if (dev->vqs[i]->error_ctx) eventfd_ctx_put(dev->vqs[i]->error_ctx); if (dev->vqs[i]->kick) @@ -700,6 +701,7 @@ void vhost_dev_cleanup(struct vhost_dev *dev) if (dev->vqs[i]->call_ctx.ctx) eventfd_ctx_put(dev->vqs[i]->call_ctx.ctx); vhost_vq_reset(dev, dev->vqs[i]); + mutex_unlock(&dev->vqs[i]->mutex); } vhost_dev_free_iovecs(dev); if (dev->log_ctx)
On Mon, Mar 14, 2022 at 08:43:02AM +0000, Lee Jones wrote:
vhost_vsock_handle_tx_kick() already holds the mutex during its call to vhost_get_vq_desc(). All we have to do here is take the same lock during virtqueue clean-up and we mitigate the reported issues.
Also WARN() as a precautionary measure. The purpose of this is to capture possible future race conditions which may pop up over time.
These two sentances do not match your actual patch :(
Cc: stable@vger.kernel.org Signed-off-by: Lee Jones lee.jones@linaro.org
What commit caused this problem? Can you add a Fixes: line as well for this?
thanks,
greg k-h
On Mon, Mar 14, 2022 at 08:43:02AM +0000, Lee Jones wrote:
vhost_vsock_handle_tx_kick() already holds the mutex during its call to vhost_get_vq_desc(). All we have to do here is take the same lock during virtqueue clean-up and we mitigate the reported issues.
Also WARN() as a precautionary measure. The purpose of this is to capture possible future race conditions which may pop up over time.
Cc: stable@vger.kernel.org Signed-off-by: Lee Jones lee.jones@linaro.org
Pls refer to my previous responses to this patch. I'd like to see an argument for why this will make future bugs less and not more likely.
drivers/vhost/vhost.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c index 59edb5a1ffe28..bbaff6a5e21b8 100644 --- a/drivers/vhost/vhost.c +++ b/drivers/vhost/vhost.c @@ -693,6 +693,7 @@ void vhost_dev_cleanup(struct vhost_dev *dev) int i; for (i = 0; i < dev->nvqs; ++i) {
mutex_lock(&dev->vqs[i]->mutex);@@ -700,6 +701,7 @@ void vhost_dev_cleanup(struct vhost_dev *dev) if (dev->vqs[i]->call_ctx.ctx) eventfd_ctx_put(dev->vqs[i]->call_ctx.ctx); vhost_vq_reset(dev, dev->vqs[i]);
mutex_unlock(&dev->vqs[i]->mutex);-- 2.35.1.723.g4982287a31-goog
On Mon, 14 Mar 2022, Michael S. Tsirkin wrote:
On Mon, Mar 14, 2022 at 08:43:02AM +0000, Lee Jones wrote:
vhost_vsock_handle_tx_kick() already holds the mutex during its call to vhost_get_vq_desc(). All we have to do here is take the same lock during virtqueue clean-up and we mitigate the reported issues.
Also WARN() as a precautionary measure. The purpose of this is to capture possible future race conditions which may pop up over time.
Cc: stable@vger.kernel.org Signed-off-by: Lee Jones lee.jones@linaro.org
Pls refer to my previous responses to this patch. I'd like to see an argument for why this will make future bugs less and not more likely.
If you think the previous 'check owner' patch fixes all of the concurrency issues, then this patch can be dropped.
linux-stable-mirror@lists.linaro.org
-
Greg KH -
Lee Jones -
Michael S. Tsirkin