Received: by 10.192.165.148 with SMTP id m20csp1533027imm; Sat, 5 May 2018 14:46:21 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpZWk9cQHb6qCFum2LuMbLa9azis7dm7hKYc7Vg+UhTgyl3dRtoQQc2aLSvsc8IvUQL5odS X-Received: by 10.98.75.22 with SMTP id y22mr31734232pfa.29.1525556781184; Sat, 05 May 2018 14:46:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525556781; cv=none; d=google.com; s=arc-20160816; b=Def1IZYCnF/aiohMZ0B8BwMcuR4qUQTVNY3qEyAlSGxe2MnO00EH/kb2KXKunqfK9i kGueLeJKfS8loagNarH9Qsw+j/z5kzZHuyGxXsjCgesgYytgToqA+NDJ6kO11/3IinUb J+nWwoXVewQUe7w4MYEFIiwQQxciIVxbtibergiVA1FBWDl/m5Nm9UGfoFkfMsuOMw3i xqO5Qnm8/TwuqlCBTuMM2TLqJcbV7t8BGytzfHMwDWLHdKkLrw8zdhJG5+JwX2eJtwGi 1wFQXyiEHviywCCdB1pB2vi4TDF9PHaYCrTmS3B0AT2TP7K0h03K7VhinQKMqAk9QvCm 6wtQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:references :in-reply-to:subject:cc:date:to:from:arc-authentication-results; bh=aYWVTj6djBWlUL2UGXQBGm3CVhTdZ8ctgJWPrUbytKk=; b=Hi7NIHR6pQd4qNO0xf9oK5fQ0HMuTG8YRafkZ0SV/5pCKpCskzrT/IvuuVBjpu/+dy nf+W/tSjEF/2l2pOlAdHW8FoUXSzWfgdjJNIkVAOx6YDscyWeoqi4hkRt+Mky1DOw5hC RU13vuUAGEHB3nyDaWxirt34jy3CFq6pPXIAeNif6So3noO1q1/2xc1uUVCLv9MxMPXo DrFs/O3XGDvz/iyVo1SwxnsEQ39563Zz40G3aFQ9cFywG6IfxKS7DAXKHO7Yma8kxBgV 5gqtJ5R6ncAiSvh0jk3Y0+jol+77EpEw5ASHCnUwHMTGi5s4fq/SiANCgbzv+JTPYmSA DO1g== 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 m1-v6si15669320pgm.413.2018.05.05.14.46.05; Sat, 05 May 2018 14:46: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 S1751833AbeEEVpx (ORCPT + 99 others); Sat, 5 May 2018 17:45:53 -0400 Received: from mx2.suse.de ([195.135.220.15]:47011 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751238AbeEEVpw (ORCPT ); Sat, 5 May 2018 17:45:52 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id ED6A7AF5D; Sat, 5 May 2018 21:45:50 +0000 (UTC) From: NeilBrown To: Herbert Xu Date: Sun, 06 May 2018 07:45:43 +1000 Cc: Thomas Graf , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 3/8] rhashtable: use cmpxchg() to protect ->future_tbl. In-Reply-To: <20180505092725.rlwn77d3yhknspdw@gondor.apana.org.au> References: <152540595840.18473.11298241115621799037.stgit@noble> <152540605430.18473.11758878046224478232.stgit@noble> <20180505092725.rlwn77d3yhknspdw@gondor.apana.org.au> Message-ID: <874ljlepyw.fsf@notabene.neil.brown.name> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, May 05 2018, Herbert Xu wrote: > On Fri, May 04, 2018 at 01:54:14PM +1000, NeilBrown wrote: >> Rather than borrowing one of the bucket locks to >> protect ->future_tbl updates, use cmpxchg(). >> This gives more freedom to change how bucket locking >> is implemented. >>=20 >> Signed-off-by: NeilBrown > > This looks nice. > >> - spin_unlock_bh(old_tbl->locks); >> + rcu_assign_pointer(tmp, new_tbl); > > Do we need this barrier since cmpxchg is supposed to provide memory > barrier semantics? It's hard to find documentation even for what cmpxchg() is meant do, let alone what barriers is provides, but there does seem to be something hidden in Documentation/core-api/atomic_ops.rst which suggests full barrier semantics if the comparison succeeds. I'll replace the rcu_assign_pointer with a comment saying why it isn't needed. Thanks, NeilBrown > >> + if (cmpxchg(&old_tbl->future_tbl, NULL, tmp) !=3D NULL) >> + return -EEXIST; > > Thanks, > --=20 > Email: Herbert Xu > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEG8Yp69OQ2HB7X0l6Oeye3VZigbkFAlruJgcACgkQOeye3VZi gbmISg/+NHCEEUQlrCp/hbVMYz7ERruLcVe1s6QgnrywsLmbljF/BFKkDR0LU+Bs OtKc14Jjztz3EJ9rWkUVDBFVDz5XSJN5Xv5V4E2uacTc3YEMELu0NvbLhpfVqUTD FtJut6XPO88jkrfdq35ilWgxP7A9vPw/lgPZbzGgT8lE2cHaRJ6Ll5Tfx0l4jv1A w+rSTcnrItRpdZrANEy9w5U4GRj+afkfavMlUSMfvLVWm3c7gfK9I4vx0eLZdBwk 7ZsylSBfiPT9X7+YVjR28RL7unMC8/KbqyNTJWcqICHrj82wI00nGx3WDSSgwklp 0pWAs7mBckvekvosop5es+GCpJuW9vrJOtLHNLsnlA5GbCV8xTFcMTDhBQdJP/j2 Urfvt5qYQCYMw2XjZ9zdXPnYh0oLptfzvdRQXrVUQz+Ef4BabRDPPjoZb6jvdnOV 7d68ynttF053wDcAFC5Yyg+RFt1ED2YWbhbW3x0PfD4em8LL+qkzG/jwD7Qnqv+z dMZ5K30GvZmT6gPsrwhBhElqWV8qUtCH+SJXqvGwxiCIDF3+Q3SLR7rHSLL7o0NP smBCrItfZ1+Pp7LNPgXrK5DViB0oYnwkVIUalwGucoQyRRIMMCJbIfaXy3zMG9lc hjF0ANhb0mZvSHZHBhQV2ivqI7bF8k87mCH8CjRKWdVzfzsmi4Y= =QD+2 -----END PGP SIGNATURE----- --=-=-=--