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;
From:   NeilBrown <neilb@suse.com>
To:     Herbert Xu <herbert@gondor.apana.org.au>
Date:   Wed, 27 Mar 2019 09:35:18 +1100
Cc:     Thomas Graf <tgraf@suug.ch>, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org,
        "Paul E. McKenney" <paulmck@linux.ibm.com>
Subject: Re: [PATCH 3/4] rhashtable: use bit_spin_locks to protect hash bucket.
In-Reply-To: <20190326050320.gwk3tgtqwl5csivt@gondor.apana.org.au>
References: <155349021177.1111.15681654355431465791.stgit@noble.brown> <155349033961.1111.18247269615646768227.stgit@noble.brown> <20190326050320.gwk3tgtqwl5csivt@gondor.apana.org.au>
Message-ID: <874l7p463d.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

--=-=-=
Content-Type: text/plain

On Tue, Mar 26 2019, Herbert Xu wrote:

> On Mon, Mar 25, 2019 at 04:05:39PM +1100, NeilBrown wrote:
>>
>> + * Sometimes we unlock a bucket by writing a new pointer there.  In that
>> + * case we don't need to unlock, but we do need to reset state such as
>> + * local_bh. For that we have rht_unlocked().  This doesn't include
>> + * the memory barrier that bit_spin_unlock() provides, but rcu_assign_pointer()
>> + * will have provided that.
>
> Hmm, are you sure that's enough? IIRC rcu_assign_pointer only
> provides a write barrier compared to the more complete (but one-way)
> barrier that a spin-lock provides.
>

The bit_spin_unlock(), which I am avoiding as unnecessary, would have
provided release semantics.
i.e. any write by this CPU that happened before the releasing write
will be visible to other CPUs before (or when) they see the result of
the releasing write.
This is (as I understand it) exactly that rcu_assign_pointer() promises
- even before acquire semantics were added as Paul just reported.

So yes, I am sure (surer now that I've walked through it carefully).

Thanks,
NeilBrown

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEG8Yp69OQ2HB7X0l6Oeye3VZigbkFAlyaqSYACgkQOeye3VZi
gblG1BAAugBQSAHkt7j0YxxaNGdLzZFDd1c7CFpL3USh8KEqNJlSZidq0g+746mk
YlEW67d9PUu0ey4A1dalzjD3vD/ti4MCy1GqWS5LF+JV1GoYOpFesq6aHi28yBsf
JeFHBBk8EBiKZ3LspXL9sjd/KodwbujTEtQKw0Ax1FJWizCMiF8g80G+Ly3RjUn3
8QF3WHCgdjNfPcHXmMkLnRVXEnKRUSgutvPTj9rPSdhUme3ZLcQFee3ff+HbKD9r
BSun9EA8nEW+9wfFscXu+F0we5l+cmATr8sK9y4OEyiu+HCdj3JgG3lOiAaDeW3+
ZOuoX8C3AUsDpBMQB3Xx0nppDnl7cI3WW7JmLnIAAIyk8fKrJBYaXNQX0xlxGipu
c2HDn738xwBMGd1ECfQECXDEANUjGdmSXR/sZISx3rPjIgyyYRllgvV3LvcdhZk4
f9cB8LEkmW3Vo1+M4J1CT8Iwb6LFVJrqxbc8HlzIEyBMUEqIJiKwR+plTUeeXPUd
NfF83LluCow4a12uFWyn86jqydlxeHKe1qqPFPZGexHDWvnHJNsmGxGWU75I0Knq
w6xikBUm9tcQauQVRXmF85Fv6AnbLapyAiYSEuG+oKvr5xvwd+1/hQaGRcZ5Oj1k
j3FgQ+tECDpaMcFh6FAHO1XLq4TD3EbOmX1eT201gIJdjzeQeS4=
=u/o4
-----END PGP SIGNATURE-----
--=-=-=--