All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.