On Tue, Jul 02, 2024 at 04:56:53PM -0700, Paul E. McKenney wrote: > > Paul, isn't this the RCU flavour you created to deal with > > !rcu_is_watching()? The flavour that never should have been created in > > favour of just cleaning up the mess instead of making more. > > My guess is that you are instead thinking of RCU Tasks Rude, which can > be eliminated once all architectures get their entry/exit/deep-idle > functions either inlined or marked noinstr. Would it make sense to disable it for those architectures that have already done this work? > > > I will > > > ultimately use it anyway to avoid uprobe taking unnecessary refcount > > > and to protect uprobe->consumers iteration and uc->handler() calls, > > > which could be sleepable, so would need rcu_read_lock_trace(). > > > > I don't think you need trace-rcu for that. SRCU would do nicely I think. > > From a functional viewpoint, agreed. > > However, in the past, the memory-barrier and array-indexing overhead > of SRCU has made it a no-go for lightweight probes into fastpath code. > And these cases were what motivated RCU Tasks Trace (as opposed to RCU > Tasks Rude). I'm thinking we're growing too many RCU flavours again :/ I suppose I'll have to go read up on rcu/tasks.* and see what's what. > The other rule for RCU Tasks Trace is that although readers are permitted > to block, this blocking can be for no longer than a major page fault. > If you need longer-term blocking, then you should instead use SRCU. I think this would render it unsuitable for uprobes. The whole point of having a sleepable handler is to be able to take faults.
