Re: [PATCH 4.19 07/38] vsock/virtio: stop workers during the .remove()

From: Stefano Garzarella
Date: Wed Oct 07 2020 - 03:13:32 EST


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