[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20190529.212852.1077585415381753122.davem@davemloft.net>
Date: Wed, 29 May 2019 21:28:52 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: sgarzare@...hat.com
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
virtualization@...ts.linux-foundation.org, kvm@...r.kernel.org,
stefanha@...hat.com, mst@...hat.com
Subject: Re: [PATCH 1/4] vsock/virtio: fix locking around 'the_virtio_vsock'
From: Stefano Garzarella <sgarzare@...hat.com>
Date: Tue, 28 May 2019 12:56:20 +0200
> @@ -68,7 +68,13 @@ struct virtio_vsock {
>
> static struct virtio_vsock *virtio_vsock_get(void)
> {
> - return the_virtio_vsock;
> + struct virtio_vsock *vsock;
> +
> + mutex_lock(&the_virtio_vsock_mutex);
> + vsock = the_virtio_vsock;
> + mutex_unlock(&the_virtio_vsock_mutex);
> +
> + return vsock;
This doesn't do anything as far as I can tell.
No matter what, you will either get the value before it's changed or
after it's changed.
Since you should never publish the pointer by assigning it until the
object is fully initialized, this can never be a problem even without
the mutex being there.
Even if you sampled the the_virtio_sock value right before it's being
set to NULL by the remove function, that still can happen with the
mutex held too.
This function is also terribly named btw, it implies that a reference
count is being taken. But that's not what this function does, it
just returns the pointer value as-is.
Powered by blists - more mailing lists