Re: [PATCH] tracing: fprobe: fix suspicious rcu usage in fprobe_entry
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: 2025-09-03 09:43:42
Also in:
linux-crypto, lkml
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: 2025-09-03 09:43:42
Also in:
linux-crypto, lkml
On Mon, Sep 01, 2025 at 08:00:15AM -0700, Paul E. McKenney wrote:
If this is happening often enough, it would be easy for me to create an rcu_dereference_all_check() that allows all forms of vanilla RCU readers (but not, for example, SRCU readers), but with only two use cases, it is not clear to me that this is an overall win.
Hi Paul: Please create such a helper. Because the alternative is for me to do something like this in rhashtable: #define rht_dereference_rcu(p, ht) \ rcu_dereference_check(p, lockdep_rht_mutex_is_held(ht) || \ rcu_read_lock_any_held()) This really makes no sense because rcu_read_lock_any_held is an internal RCU implementation detail and has nothing to do with rhashtable. rhashtable is just a middle-man like RCU. The actual context (be it vanilla, bh or sched RCU) used is entirely up to the user. Actually what puzzles me is why can't we just get rid of the bh and sched variants of rcu_dereference? After all, there is only one synchronize_rcu/call_rcu and it supports all three variants. Cheers, -- Email: Herbert Xu [off-list ref] Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt