On Tue, Oct 06, 2020 at 09:34:32PM +0200, Pavel Machek wrote:
Hi!
[ Upstream commit 17dd1367389cfe7f150790c83247b68e0c19d106 ]
Before to call vdev->config->reset(vdev) we need to be sure that no one is accessing the device, for this reason, we add new variables in the struct virtio_vsock to stop the workers during the .remove().
This patch also add few comments before vdev->config->reset(vdev) and vdev->config->del_vqs(vdev).
@@ -621,12 +645,18 @@ static int virtio_vsock_probe(struct virtio_device *vdev) INIT_WORK(&vsock->send_pkt_work, virtio_transport_send_pkt_work); INIT_WORK(&vsock->loopback_work, virtio_transport_loopback_work);
- mutex_lock(&vsock->tx_lock);
- vsock->tx_run = true;
- mutex_unlock(&vsock->tx_lock);
- mutex_lock(&vsock->rx_lock); virtio_vsock_rx_fill(vsock);
- vsock->rx_run = true; mutex_unlock(&vsock->rx_lock);
mutex_lock(&vsock->event_lock); virtio_vsock_event_fill(vsock);
- vsock->event_run = true; mutex_unlock(&vsock->event_lock);
This looks like some kind of voodoo code. Locks are just being allocated few lines above, so there are no other threads accessing *vsock. That means we don't need to take the locks... right?
At least taking the tx_lock is unneccessary, but probably the others, too...
Before commit 0deab087b16a ("vsock/virtio: use RCU to avoid use-after-free on the_virtio_vsock") we assigned 'the_virtio_vsock pointer' before this section, so this should be the reason of these locks.
Now that we moved the assignment at the end of the probe(), we can clean a bit, especially the tx_lock.
I'll take a look.
Thanks, Stefano