public inbox for linux-perf-users@vger.kernel.org
 help / color / mirror / Atom feed
From: Leon Hwang <leon.hwang@linux.dev>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: stable@vger.kernel.org, Andrii Nakryiko <andrii@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org, "H . Peter Anvin" <hpa@zytor.com>,
	linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 6.6.y 0/4] perf/x86/amd: add LBR capture support outside of hardware events
Date: Thu, 8 Jan 2026 22:10:43 +0800	[thread overview]
Message-ID: <72c81c74-669b-4d1e-94fe-08ef2732cab2@linux.dev> (raw)
In-Reply-To: <2026010856-ethics-lethargic-b9e9@gregkh>



On 2026/1/8 22:02, Greg KH wrote:
> 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

Thanks for the pointer and the guidance. I’ll review the stable kernel
rules more carefully and adjust accordingly.

Appreciate the advice. :)

Thanks,
Leon


      reply	other threads:[~2026-01-08 14:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-02  9:03 [PATCH 6.6.y 0/4] perf/x86/amd: add LBR capture support outside of hardware events Leon Hwang
2026-01-02  9:03 ` [PATCH 6.6.y 1/4] perf/x86/amd: Ensure amd_pmu_core_disable_all() is always inlined Leon Hwang
2026-01-02  9:03 ` [PATCH 6.6.y 2/4] perf/x86/amd: Avoid taking branches before disabling LBR Leon Hwang
2026-01-02  9:03 ` [PATCH 6.6.y 3/4] perf/x86/amd: Support capturing LBR from software events Leon Hwang
2026-01-02  9:03 ` [PATCH 6.6.y 4/4] perf/x86/amd: Don't reject non-sampling events with configured LBR Leon Hwang
2026-01-08 11:11 ` [PATCH 6.6.y 0/4] perf/x86/amd: add LBR capture support outside of hardware events Greg KH
2026-01-08 13:53   ` Leon Hwang
2026-01-08 14:02     ` Greg KH
2026-01-08 14:10       ` Leon Hwang [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=72c81c74-669b-4d1e-94fe-08ef2732cab2@linux.dev \
    --to=leon.hwang@linux.dev \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=andrii@kernel.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hpa@zytor.com \
    --cc=irogers@google.com \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=stable@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox