Re: FAILED: patch "[PATCH] tracepoint: Use rcu get state and cond sync for static call" failed to apply to 5.10-stable tree

[Mathieu Desnoyers <mathieu.desnoyers@efficios.com>]

----- On Aug 19, 2021, at 8:42 PM, rostedt rostedt@goodmis.org wrote:

> On Thu, 19 Aug 2021 17:09:33 -0400
> Steven Rostedt <rostedt@goodmis.org> wrote:
> 
>> Mathieu, seems that the "slow down 10x" patch was able to be backported
>> to 5.10, where as this patch was not. Reason being is that
>> start_poll_synchronize_rcu() was added in 5.13.
> 
> I can get this to work if I backport the following RCU patches:
> 
> 29d2bb94a8a126ce80ffbb433b648b32fdea524e
> srcu: Provide internal interface to start a Tree SRCU grace period
> 
> 5358c9fa54b09b5d3d7811b033aa0838c1bbaaf2
> srcu: Provide polling interfaces for Tree SRCU grace periods
> 
> 1a893c711a600ab57526619b56e6f6b7be00956e
> srcu: Provide internal interface to start a Tiny SRCU grace period
> 
> 8b5bd67cf6422b63ee100d76d8de8960ca2df7f0
> srcu: Provide polling interfaces for Tiny SRCU grace periods
> 
> The first three can be cherry-picked without issue. The last one has a
> small conflict, of:
> 
> include/linux/srcutiny.h.rej:
> --- include/linux/srcutiny.h
> +++ include/linux/srcutiny.h
> @@ -16,6 +16,7 @@
> struct srcu_struct {
>        short srcu_lock_nesting[2];     /* srcu_read_lock() nesting depth. */
>        unsigned short srcu_idx;        /* Current reader array element in bit 0x2. */
> +       unsigned short srcu_idx_max;    /* Furthest future srcu_idx request. */
>        u8 srcu_gp_running;             /* GP workqueue running? */
>        u8 srcu_gp_waiting;             /* GP waiting for readers? */
>        struct swait_queue_head srcu_wq;
> 
> 
> Which I just added that line, and everything worked.
> 
> Paul, do you have any issues with these four patches getting backported?
> 
> Greg, Are you OK with them too?
> 
> Once those are backported, this patch can be backported as well, and
> everything should work. This patch really needs to stay with:
> 
> 231264d6927f6740af36855a622d0e240be9d94c
> tracepoint: Fix static call function vs data state mismatch
> 
> Otherwise I would say to revert it if this one can't be backported with
> it.

In my opinion backporting those patches to stable is important, because the tracepoint
fix which causes the slowdown is really fixing a correctness issue: it ensures that the
kernel does not crash in specific race scenarios.

Indeed the slowdown associated with that patch is quite big on typical use-cases of
tracepoint registration/unregistration, so the second fixing the speed regression is
also important, and that last fix requires the SRCU backports.

Thanks,

Mathieu


-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com