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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20201007071317.cf7wpip3yxicv362@steredhat>
Date:   Wed, 7 Oct 2020 09:13:17 +0200
From:   Stefano Garzarella <sgarzare@...hat.com>
To:     Pavel Machek <pavel@...x.de>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Stefan Hajnoczi <stefanha@...hat.com>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        "David S. Miller" <davem@...emloft.net>,
        Sasha Levin <sashal@...nel.org>
Subject: Re: [PATCH 4.19 07/38] vsock/virtio: stop workers during the
 .remove()

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