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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 4 Dec 2022 09:21:23 +0100
Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx
> > > Link: https://lore.kernel.org/all/20221110020319.1259291-1-zhengyejian1@xxxxxxxxxx/
> > > 
> > > Cc: stable@xxxxxxxxxxxxxxx
> > > Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
> > > 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?

-- Steve



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux