[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2026010856-ethics-lethargic-b9e9@gregkh>
Date: Thu, 8 Jan 2026 15:02:33 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Leon Hwang <leon.hwang@...ux.dev>
Cc: stable@...r.kernel.org, Andrii Nakryiko <andrii@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...nel.org>, Namhyung Kim <namhyung@...nel.org>,
Ian Rogers <irogers@...gle.com>,
Adrian Hunter <adrian.hunter@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
"H . Peter Anvin" <hpa@...or.com>, linux-perf-users@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 6.6.y 0/4] perf/x86/amd: add LBR capture support outside
of hardware events
On Thu, Jan 08, 2026 at 09:53:46PM +0800, Leon Hwang wrote:
>
>
> On 2026/1/8 19:11, Greg KH wrote:
> > On Fri, Jan 02, 2026 at 05:03:16PM +0800, Leon Hwang wrote:
> >> Hi all,
> >>
> >> This backport wires up AMD perfmon v2 so BPF and other software clients
> >> can snapshot LBR stacks on demand, similar to the Intel support
> >> upstream. The series keeps the LBR-freeze path branchless, adds the
> >> perf_snapshot_branch_stack callback for AMD, and drops the
> >> sampling-only restriction now that snapshots can be taken from software
> >> contexts.
> >>
> >> Leon Hwang (4):
> >> perf/x86/amd: Ensure amd_pmu_core_disable_all() is always inlined
> >> perf/x86/amd: Avoid taking branches before disabling LBR
> >> perf/x86/amd: Support capturing LBR from software events
> >> perf/x86/amd: Don't reject non-sampling events with configured LBR
> >
> >
> > Why is this for a stable kernel? Isn't it a new feature? If you need
> > this feature, why not use a newer kernel tree?
> >
>
> This series enables LBR snapshot support on AMD CPUs.
>
> You are right that this is not a bug fix but a feature enablement.
> If backporting this to the stable tree is not appropriate, that is
> totally fine. In that case, I will carry these changes in our in-house
> stable kernel instead.
Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
For what types of patches are acceptable for stable kernels.
And really, you should be moving off of 6.6.y now anyway :)
thanks,
greg k-h
Powered by blists - more mailing lists