Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp290197ybi; Wed, 29 May 2019 21:31:21 -0700 (PDT) X-Google-Smtp-Source: APXvYqwSlB+Puc6hUnIcrSFzs1da2lH48wswcOt8W6KSNL2rJHI9l/6pOv4eDONMW0lnO8JUBifr X-Received: by 2002:a17:90a:ff15:: with SMTP id ce21mr1671054pjb.77.1559190681549; Wed, 29 May 2019 21:31:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559190681; cv=none; d=google.com; s=arc-20160816; b=AFBSUEGpKOlj1VJ2zcUot5d1qV9zuFNglyty6NV0wiKaJkbzjlAgp9Kpg9louTNu+3 KiFNV97JCpPrnh7CDx60K22AC/IX3s0YVORal+VFbV7ejaBmMIMK6PE7tTICDcpIVdI+ 3On+81AwHnmhU81DpdDicWsDoydUqkW8M7Oz8UlcIphfCIdFfGss4t4FuJ+6i6wSeCtk zrTwKhoT/W9hEuTBIF099p6n8EdjoG16sSqYZqQyroebqTy9mZEOQcOxa0jDGipVL2D0 8RkI91vshpk747xUG8WGf6rY9F8HLcHWUUZSbnnu9ZySH85D1KmuiA62tizSO4EE6Fe2 ej4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:from:subject:cc:to:message-id:date; bh=ajrS9w8DcyIihi2431eB1d1gPGTHWDOpwql0GFu6I80=; b=u1Pp9Dh0137mfoSSN5smlBVD94JvPCyKkUGPmPoKQMLRCC3Ieou/pXF0+ZuKIj5Vcl xTqRnaCgQE55EXeGz37lCQPHD+vm+4BFECgYCNFmm6cU0Tl3vp5RLtak/o5J8Vjq1YAJ HbmNvmvPHvpNgDWiYc44+1pLWkcCJJ/Pq6mMF8GJAbLfB3RAvTTfye4rKME2qt76TrnQ z1xM/LzSk/vBmflp3mWdg/3tCMZsydGVFNyUFhNveQg/w8uumPU+jVAK+qxBRgPQEYo0 7zTp2bNfInScpEcmXOMVQAcLhoIMuPZgWPrnZe+TmhWuCduq3gzLdLEeFSVqcXLJ/cBQ 4VAg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l1si2241699pgi.278.2019.05.29.21.31.05; Wed, 29 May 2019 21:31:21 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388180AbfE3E3A (ORCPT + 99 others); Thu, 30 May 2019 00:29:00 -0400 Received: from shards.monkeyblade.net ([23.128.96.9]:46664 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730048AbfE3E24 (ORCPT ); Thu, 30 May 2019 00:28:56 -0400 Received: from localhost (unknown [IPv6:2601:601:9f80:35cd::3d5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id 6F6C0136E07E5; Wed, 29 May 2019 21:28:55 -0700 (PDT) Date: Wed, 29 May 2019 21:28:52 -0700 (PDT) Message-Id: <20190529.212852.1077585415381753122.davem@davemloft.net> To: sgarzare@redhat.com Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, kvm@vger.kernel.org, stefanha@redhat.com, mst@redhat.com Subject: Re: [PATCH 1/4] vsock/virtio: fix locking around 'the_virtio_vsock' From: David Miller In-Reply-To: <20190528105623.27983-2-sgarzare@redhat.com> References: <20190528105623.27983-1-sgarzare@redhat.com> <20190528105623.27983-2-sgarzare@redhat.com> X-Mailer: Mew version 6.8 on Emacs 26.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Wed, 29 May 2019 21:28:55 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Stefano Garzarella 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.