Re: [RFC 0/3] Revert SRCU from tracepoint infrastructure

From: Paul E. McKenney
Date: Fri Feb 07 2020 - 16:24:52 EST


On Fri, Feb 07, 2020 at 03:56:53PM -0500, Joel Fernandes (Google) wrote:
> Hi,
> These patches remove SRCU usage from tracepoints. The reason for proposing the
> reverts is because the whole point of SRCU was to avoid having to call
> rcu_irq_enter_irqson(). However this was added back in 865e63b04e9b2 ("tracing:
> Add back in rcu_irq_enter/exit_irqson() for rcuidle tracepoints") because perf
> was breaking..
>
> Further it occurs to me that, by using SRCU for tracepoints, we forgot that RCU
> is not really watching the tracepoint callbacks. This means that anyone doing
> preempt_disable() in their tracepoint callback, and expecting RCU to listen to
> them is in for a big surprise. When RCU is not watching, it does not care about
> preempt-disable sections on CPUs as you can see in the forced-quiescent state loop.
>
> Since SRCU is not providing any benefit because of 865e63b04e9b2 anyway, let us
> revert SRCU tracepoint code to maintain the sanity of potential
> tracepoint callback registerers.

For whatever it is worth, SRCU is the exception to the "RCU needs to
be watching" rule. You can have SRCU readers on idle CPUs, offline
CPUs, CPUs executing in userspace, whatever.

Thanx, Paul

> Joel Fernandes (Google) (3):
> Revert "tracepoint: Use __idx instead of idx in DO_TRACE macro to make
> it unique"
> Revert "tracing: Add back in rcu_irq_enter/exit_irqson() for rcuidle
> tracepoints"
> Revert "tracepoint: Make rcuidle tracepoint callers use SRCU"
>
> include/linux/tracepoint.h | 40 ++++++--------------------------------
> kernel/tracepoint.c | 10 +---------
> 2 files changed, 7 insertions(+), 43 deletions(-)
>
> --
> 2.25.0.341.g760bfbb309-goog
>