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: <20201006193432.GA8771@duo.ucw.cz>
Date:   Tue, 6 Oct 2020 21:34:32 +0200
From:   Pavel Machek <pavel@...x.de>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Stefan Hajnoczi <stefanha@...hat.com>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        Stefano Garzarella <sgarzare@...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()

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...

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Download attachment "signature.asc" of type "application/pgp-signature" (196 bytes)