Re: FAILED: patch "[PATCH] tracing: Free buffers when a used dynamic event is removed" failed to apply to 4.19-stable tree

[Greg KH <gregkh@linuxfoundation.org>]

On Sun, Dec 04, 2022 at 11:14:51AM -0500, Steven Rostedt wrote:
> On Sun, 4 Dec 2022 09:21:23 +0100
> Greg KH <gregkh@linuxfoundation.org> wrote:
> 
> > > > 5448d44c3855 ("tracing: Add unified dynamic event framework")  
> > > 
> > > And this is mentioned below.
> > > 
> > > [..]
> > >   
> > > > If any dynamic event that is being removed was enabled, then make sure the
> > > > buffers they were enabled in are now cleared.
> > > > 
> > > > Link: https://lkml.kernel.org/r/20221123171434.545706e3@gandalf.local.home
> > > > Link: https://lore.kernel.org/all/20221110020319.1259291-1-zhengyejian1@huawei.com/
> > > > 
> > > > Cc: stable@vger.kernel.org
> > > > Cc: Andrew Morton <akpm@linux-foundation.org>
> > > > Depends-on: e18eb8783ec49 ("tracing: Add tracing_reset_all_online_cpus_unlocked() function")  
> > >   
> > > > Depends-on: 5448d44c38557 ("tracing: Add unified dynamic event framework")  
> > > 
> > > ^^^  
> > 
> > Did you just make up a new field?  We have a documented way to show
> > dependancies for stable patches, please let's not create a new one :(
> 
> Ug, I've seen this tag used before: 
> 
>  example:  e3f0c638f428fd66b5871154b62706772045f91a
> 
> And just assumed that was the method. I guess I should have looked deeper.
> 
> > 
> > > > Depends-on: 6212dd29683ee ("tracing/kprobes: Use dyn_event framework for kprobe events")
> > > > Depends-on: 065e63f951432 ("tracing: Only have rmmod clear buffers that its events were active in")
> > > > Depends-on: 575380da8b469 ("tracing: Only clear trace buffer on module unload if event was traced")
> > > > Fixes: 77b44d1b7c283 ("tracing/kprobes: Rename Kprobe-tracer to kprobe-event")  
> > 
> > Adding the "unified framework" seems like way too much for a stable
> > patch, are you sure all of these are required and should be applied to
> > 4.19.y?
> > 
> 
> It's that balance between rewriting it to the bare minimum, which is not as
> intrusive, but tested much less and may be even more buggy, to backporting
> a larger change that has been verified by real world use cases.
> 
> Or we just do not backport it. The bug will still exist, but you really
> have to work hard to hit it. And because it's only controlled by privileged
> users, maybe it's OK to just ignore it. I think I've seen only one report
> of this issue in the last 10 years.
> 
> Thoughts?

Sasha backported this to 5.4 and newer without needing the full new
feature to be added, so I think we are now ok.

thanks,

greg k-h