From: NeilBrown <neilb@suse.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
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.
Date: Wed, 27 Mar 2019 09:35:18 +1100 [thread overview]
Message-ID: <874l7p463d.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <20190326050320.gwk3tgtqwl5csivt@gondor.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 1105 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2019-03-27 1:05 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-25 5:05 [PATCH 0/4] Convert rhashtable to use bitlocks NeilBrown
2019-03-25 5:05 ` [PATCH 4/4] rhashtable: add lockdep tracking to bucket bit-spin-locks NeilBrown
2019-03-25 5:05 ` [PATCH 2/4] rhashtable: allow rht_bucket_var to return NULL NeilBrown
2019-03-25 5:05 ` [PATCH 3/4] rhashtable: use bit_spin_locks to protect hash bucket NeilBrown
2019-03-26 5:03 ` Herbert Xu
2019-03-26 15:36 ` Paul E. McKenney
2019-03-27 3:45 ` Herbert Xu
2019-03-26 22:35 ` NeilBrown [this message]
2019-03-27 3:45 ` Herbert Xu
2019-03-27 15:04 ` Paul E. McKenney
2019-03-26 5:27 ` Herbert Xu
2019-03-26 22:40 ` NeilBrown
2019-03-25 5:05 ` [PATCH 1/4] rhashtable: use cmpxchg() in nested_table_alloc() NeilBrown
-- strict thread matches above, loose matches on Subject: below --
2019-04-01 23:07 [PATCH 0/4 v2] Convert rhashtable to use bitlocks NeilBrown
2019-04-01 23:07 ` [PATCH 3/4] rhashtable: use bit_spin_locks to protect hash bucket NeilBrown
2019-04-02 10:11 ` David Laight
2019-04-02 21:10 ` NeilBrown
2019-04-03 9:26 ` David Laight
2019-04-04 0:13 ` NeilBrown
2019-04-08 2:34 ` Herbert Xu
2019-04-10 19:34 ` Guenter Roeck
2019-04-11 0:48 ` NeilBrown
2019-04-11 2:15 ` David Miller
2019-04-11 6:13 ` NeilBrown
2019-04-11 6:40 ` NeilBrown
2019-04-11 12:44 ` Guenter Roeck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874l7p463d.fsf@notabene.neil.brown.name \
--to=neilb@suse.com \
--cc=herbert@gondor.apana.org.au \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=paulmck@linux.ibm.com \
--cc=tgraf@suug.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).