From: "Paul E. McKenney" <paulmck@linux.ibm.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: NeilBrown <neilb@suse.com>, Thomas Graf <tgraf@suug.ch>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/4] rhashtable: use bit_spin_locks to protect hash bucket.
Date: Tue, 26 Mar 2019 08:36:46 -0700 [thread overview]
Message-ID: <20190326153646.GL4102@linux.ibm.com> (raw)
In-Reply-To: <20190326050320.gwk3tgtqwl5csivt@gondor.apana.org.au>
On Tue, Mar 26, 2019 at 01:03:20PM +0800, 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.
Not seeing the code, I have no opinion on the safety in this case,
but I did want to mention that rcu_assign_pointer() has been upgraded
to a release store, so that it orders all prior accesses from the
viewpoint of some other thread that just picked up the stored pointer
via rcu_dereference().
But you are quite right, rcu_assign_pointer() used to just do an
smp_wmb(). It is now new and improved! ;-)
Thanx, Paul
next prev parent reply other threads:[~2019-03-26 15:36 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 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 [this message]
2019-03-27 3:45 ` Herbert Xu
2019-03-26 22:35 ` NeilBrown
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 2/4] rhashtable: allow rht_bucket_var to return NULL NeilBrown
2019-03-25 5:05 ` [PATCH 1/4] rhashtable: use cmpxchg() in nested_table_alloc() NeilBrown
2019-03-25 5:05 ` [PATCH 4/4] rhashtable: add lockdep tracking to bucket bit-spin-locks 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=20190326153646.GL4102@linux.ibm.com \
--to=paulmck@linux.ibm.com \
--cc=herbert@gondor.apana.org.au \
--cc=linux-kernel@vger.kernel.org \
--cc=neilb@suse.com \
--cc=netdev@vger.kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.