Re: [RFC PATCH 0/3] fprobe, rcu/tasks, rhashtable: Switch fprobe and BPF kprobe-multi to Tasks-Rude RCU

[Andrii Nakryiko]

On Mon, Sep 28, 2026 at 5:04 PM Paul E. McKenney <paulmck@xxxxxxxxxx> wrote:
>
> On Tue, Sep 29, 2026 at 08:28:28AM +0900, Masami Hiramatsu wrote:
> > On Mon, 28 Sep 2026 09:25:02 -0700
> > "Paul E. McKenney" <paulmck@xxxxxxxxxx> wrote:
> >
> > > On Mon, Sep 28, 2026 at 11:29:13PM +0900, Masami Hiramatsu (Google) wrote:
> > > > Hi,
> > > >
> > > > Here is an RFC patch series which removes standard RCU read lock
> > > > (guard(rcu) and rcu_read_lock()) from fprobe callback paths
> > > > by switching fprobe and BPF multi-kprobe to Tasks-Rude RCU.
> > > >
> > > > Motivation & Problem
> > > > ====================
> > > >
> > > > Currently, fprobe entry and exit callbacks (fprobe_fgraph_entry,
> > > > fprobe_return, and fprobe_ftrace_entry) execute in the tracing hot
> > > > path where preemption is disabled.
> > > >
> > > > However, fprobe was forced to wrap hash lookups with guard(rcu)() and
> > > > rcu_read_lock() because:
> > > >
> > > > - rhashtable defers bucket table deallocation using standard RCU
> > > > - unregister_fprobe() and BPF waited for a standard RCU grace period
> > > >
> > > > Taking standard RCU read locks in the tracing fast path introduces
> > > > several drawbacks:
> > > >
> > > > 1. Unnecessary Runtime Overhead:
> > > >    Every probe hit manipulates current->rcu_read_lock_nesting with
> > > >    memory barriers, and rcu_read_unlock() adds conditional branches
> > > >    to check for special quiescent processing.
> > > >    On debug kernels with CONFIG_PROVE_RCU=y or CONFIG_LOCKDEP=y,
> > > >    this additionally acquires and releases lockdep maps on every hit,
> > > >    introducing severe lockdep hashing overhead and tracer recursion risks.
> > > >
> > > > 2. Fragile Dependency on rcu_is_watching():
> > > >    Standard RCU treats idle CPUs (and user-space on nohz_full CPUs) as
> > > >    Extended Quiescent States (EQS). If a function is traced while
> > > >    rcu_is_watching() is false, standard RCU is blind to the read-side
> > > >    critical section. In such contexts, synchronize_rcu() does not wait
> > > >    for the reader (risking Use-After-Free), and lockdep emits an
> > > >    "RCU-illegal: rcu_read_lock() used while not watching!" warning.
> > > >    To avoid this, ftrace callbacks normally require FTRACE_OPS_FL_RCU,
> > > >    adding extra trampoline check overhead.
> > > >
> > > > 3. Asymmetric Synchronization with fprobe_return():
> > > >    fprobe_return() executes under preempt_disable_notrace() without
> > > >    holding rcu_read_lock(). Prior to this series, unregister_fprobe()
> > > >    only waited on synchronize_rcu(), which does NOT wait for pure
> > > >    preempt-disabled sections, leaving a potential Use-After-Free window
> > > >    during probe unregistration.
> > > >
> > > > I've tried to fix the last UAF with simply introducing guard(rcu)()[1]
> > > > but Sashiko found the 2nd problem [2]. So I decided to implement this
> > > > series.
> > >
> > > Unless I am missing something subtle, Sashiko needs to be taught a
> > > little bit more about RCU.  Preemption-disabled regions of code really
> > > are valid RCU readers.  If you have a reproducer showing that this is
> > > not the case in some situation, that would be a bug in RCU.
> >
> > Thanks for the clarification!
> > So I think we can replace rcu_read_lock() with rcu_read_lock_sched_notrace()?
> > (also, maybe we need to add rcu_is_watching() check)
>
> That would work, and yes, you are quite right that if !rcu_is_watching(),
> RCU is studiously ignoring you completely, no matter what your preemption
> state is.
>
> > Current code may involves lockdep in fprobe, that is not good.
>
> Agreed, that could be problematic in any number of contexts.  ;-)
>
> > BTW, if we want to trace some code in extended quiescent state, do we
> > still need this Tasks-Rude RCU?
>
> Well, you need something other than vanilla RCU, anyway.  And Tasks Rude
> RCU is one candidate, though it is also a candidate that might annoy
> people wishing to minimize IPIs.
>

Would RCU Tasks Trace be a better candidate given uprobes and
sleepable BPF depends on it? Would it work here?

>                                                         Thanx, Paul
>
> > Thank you,
> >
> > >
> > > Adding Roman Gushchin and Chris Mason on CC for their thoughts.
> > >
> > >                                                     Thanx, Paul
> > >
> > > > [1] https://lore.kernel.org/all/179055575009.241711.6358052647499787191.stgit@devnote2/
> > > > [2] https://lore.kernel.org/all/20260928005114.9C9FC1F000FF@xxxxxxxxxxxxxxx/
> > > >
> > > >
> > > > Solution: Tasks-Rude RCU
> > > > ========================
> > > >
> > > > Because fprobe callbacks already run strictly within preempt-disabled
> > > > contexts, we can transition fprobe and its deferred table reclamation
> > > > to Tasks-Rude RCU:
> > > >
> > > > - Tasks-Rude RCU detects grace periods via schedule_on_each_cpu(),
> > > >   forcing a schedule on every online CPU. This guarantees that all
> > > >   preempt-disabled sections that began prior to the grace period have
> > > >   completed before memory is reclaimed.
> > > > - Unlike standard RCU, Tasks-Rude RCU does not rely on dyntick-idle /
> > > >   EQS tracking. It does NOT require rcu_is_watching() to be true and
> > > >   does not trigger lockdep warnings in pre-RCU/idle execution paths.
> > > > - Within fprobe, guard(rcu)() is replaced with guard(rcu_sched_notrace)(),
> > > >   reducing the lookup lock to pure, non-tracing preempt counter
> > > >   increments without lockdep or RCU state manipulation.
> > > >
> > > > Feedback and suggestions from RCU, BPF, and tracing maintainers are welcome!
> > > >
> > > > Thank you,
> > > >
> > > > ---
> > > > base-commit: 5bfa9f1a9dcb6ecb607adbc1c0226605c972935b
> > > >
> > > > Masami Hiramatsu (Google) (3):
> > > >       rcu/tasks: Export call_rcu_tasks_rude()
> > > >       rhashtable: Add use_tasks_rude parameter to defer bucket table free
> > > >       fprobe: Switch fprobe and BPF kprobe-multi to Tasks-Rude RCU
> > > >
> > > >
> > > >  include/linux/rcupdate.h         |    6 +++
> > > >  include/linux/rhashtable-types.h |    2 +
> > > >  kernel/bpf/syscall.c             |    2 +
> > > >  kernel/rcu/tasks.h               |    8 ++---
> > > >  kernel/trace/fprobe.c            |   66 +++++++++++++++++++++-----------------
> > > >  lib/rhashtable.c                 |    5 ++-
> > > >  6 files changed, 54 insertions(+), 35 deletions(-)
> > > >
> > > > --
> > > > Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>
> >
> >
> > --
> > Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>