[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b94e7ecf-8b83-47c0-bf69-d4a98da1fd0d@paulmck-laptop>
Date: Wed, 26 Mar 2025 14:37:52 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Boqun Feng <boqun.feng@...il.com>
Cc: Waiman Long <llong@...hat.com>, Eric Dumazet <edumazet@...gle.com>,
Peter Zijlstra <peterz@...radead.org>,
Breno Leitao <leitao@...ian.org>, Ingo Molnar <mingo@...hat.com>,
Will Deacon <will@...nel.org>, aeh@...a.com,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
jhs@...atatu.com, kernel-team@...a.com,
Erik Lundgren <elundgren@...a.com>
Subject: Re: [PATCH] lockdep: Speed up lockdep_unregister_key() with
expedited RCU synchronization
On Wed, Mar 26, 2025 at 11:42:37AM -0700, Boqun Feng wrote:
> On Wed, Mar 26, 2025 at 10:10:28AM -0700, Paul E. McKenney wrote:
> > On Wed, Mar 26, 2025 at 01:02:12PM -0400, Waiman Long wrote:
> [...]
> > > > > > Thinking about it more, doing it in a lockless way is probably a good
> > > > > > idea.
> > > > > >
> > > > > If we are using hazard pointer for synchronization, should we also take off
> > > > > "_rcu" from the list iteration/insertion/deletion macros to avoid the
> > > > > confusion that RCU is being used?
> > > > >
> > > > We can, but we probably want to introduce a new set of API with suffix
> > > > "_lockless" or something because they will still need a lockless fashion
> > > > similar to RCU list iteration/insertion/deletion.
> > >
> > > The lockless part is just the iteration of the list. Insertion and deletion
> > > is protected by lockdep_lock().
> > >
> > > The current hlist_*_rcu() macros are doing the right things for lockless use
> > > case too. We can either document that RCU is not being used or have some
> > > _lockless helpers that just call the _rcu equivalent.
> >
> > We used to have _lockless helper, but we got rid of them. Not necessarily
> > meaning that we should not add them back in, but... ;-)
> >
>
> I will probably go with using *_rcu() first with some comments, if this
> "hazard pointers for hash table" is a good idea in other places, we can
> add *_hazptr() or pick a better name then.
Works for me!
Thanx, Paul
Powered by blists - more mailing lists