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

[Stefano Garzarella]

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