From: sashiko-bot@kernel.org
To: "Puranjay Mohan" <puranjay@kernel.org>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH RFC] perf/x86/amd/lbr: Don't freeze the LBR on PMI for user-only filters
Date: Thu, 05 Nov 2026 17:23:01 +0000 [thread overview]
Message-ID: <sashiko-outbox-199604@kernel.org> (raw)
In-Reply-To: <20261105170340.165507-1-puranjay@kernel.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] perf/x86/amd/lbr: freeze format exposed and accepted without feature check
- [Medium] perf/x86/amd/lbr: wrong freeze state in amd_pmu_lbr_enable_all() for multi-event LBR
--
commit 4ee339b2b2fdce2f2f85b09e93b75d05b24049b1
Author: Puranjay Mohan <puranjay@kernel.org>
perf/x86/amd/lbr: Don't freeze the LBR on PMI for user-only filters
This commit skips setting DEBUGCTLMSR_FREEZE_LBRS_ON_PMI on PMI when kernel
branches are suppressed in LBR_SELECT, while adding a freeze format attribute
(config2:0) to allow user space to explicitly request freezing the LBR.
> diff --git a/arch/x86/events/amd/core.c b/arch/x86/events/amd/core.c
> index 49b6b8fce5664..d63649c756a58 100644
> --- a/arch/x86/events/amd/core.c
> +++ b/arch/x86/events/amd/core.c
> @@ -1404,8 +1404,22 @@ static struct attribute_group group_events_amd_brs = {
>
> #endif /* CONFIG_PERF_EVENTS_AMD_BRS */
>
> +PMU_FORMAT_ATTR(freeze, "config2:0");
> +
> +static struct attribute *amd_pmu_lbr_format_attrs[] = {
> + &format_attr_freeze.attr,
> + NULL,
> +};
> +
> +static struct attribute_group group_format_amd_lbr = {
> + .name = "format",
> + .attrs = amd_pmu_lbr_format_attrs,
> + .is_visible = amd_branches_is_visible,
> +};
> +
> static const struct attribute_group *amd_attr_update[] = {
> &group_caps_amd_branches,
> + &group_format_amd_lbr,
> #ifdef CONFIG_PERF_EVENTS_AMD_BRS
> &group_events_amd_brs,
> #endif
> diff --git a/arch/x86/events/amd/lbr.c b/arch/x86/events/amd/lbr.c
> index a55646fcb8465..f45e2c53566af 100644
> --- a/arch/x86/events/amd/lbr.c
> +++ b/arch/x86/events/amd/lbr.c
> @@ -10,6 +10,12 @@
> /* LBR Branch Select valid bits */
> #define LBR_SELECT_MASK 0x1ff
>
> +/* attr.config2: freeze the LBR on PMI */
> +#define LBR_CFG2_FREEZE BIT_ULL(0)
> +
> +/* Software only, masked out before writing LBR_SELECT */
> +#define LBR_FREEZE BIT_ULL(63)
> +
> /*
> * LBR Branch Select filter bits which when set, ensures that the
> * corresponding type of branches are not recorded
> @@ -307,6 +313,9 @@ static int amd_pmu_lbr_setup_filter(struct perf_event *event)
> /* Filter bits operate in suppress mode */
> reg->config = mask ^ LBR_SELECT_MASK;
>
> + if (event->attr.config2 & LBR_CFG2_FREEZE)
> + reg->config |= LBR_FREEZE;
> +
> return 0;
> }
[Severity: Medium]
Should group_format_amd_lbr and amd_pmu_lbr_setup_filter() check for
X86_FEATURE_AMD_LBR_PMC_FREEZE?
In arch/x86/events/amd/core.c, group_format_amd_lbr uses
amd_branches_is_visible():
static umode_t
amd_branches_is_visible(struct kobject *kobj, struct attribute *attr, int i)
{
return x86_pmu.lbr_nr ? attr->mode : 0;
}
Because x86_pmu.lbr_nr is non-zero both on Zen 3 BRS systems (where
amd_brs_detect() sets x86_pmu.lbr_nr = 16) and on LBRv2 systems or VMs that do
not advertise X86_FEATURE_AMD_LBR_PMC_FREEZE, the sysfs format attribute
/sys/bus/event_source/devices/cpu/format/freeze is exposed on systems that
cannot freeze the LBR on PMI.
In addition, when a user opens an event with LBR_CFG2_FREEZE set in
event->attr.config2 on those systems, amd_pmu_lbr_setup_filter() accepts it
and sets LBR_FREEZE in reg->config, while amd_pmu_lbr_enable_all() silently
ignores it because the MSR_IA32_DEBUGCTLMSR update is guarded by
cpu_feature_enabled(X86_FEATURE_AMD_LBR_PMC_FREEZE).
Should the visibility callback and amd_pmu_lbr_setup_filter() verify
cpu_feature_enabled(X86_FEATURE_AMD_LBR_PMC_FREEZE) and return -EOPNOTSUPP if
freeze is requested when unsupported?
> @@ -392,20 +401,26 @@ void amd_pmu_lbr_sched_task(struct perf_event_pmu_context *pmu_ctx,
> void amd_pmu_lbr_enable_all(void)
> {
> struct cpu_hw_events *cpuc = this_cpu_ptr(&cpu_hw_events);
> - u64 lbr_select, dbg_ctl, dbg_extn_cfg;
> + u64 lbr_cfg = 0, lbr_select = 0, dbg_ctl, dbg_extn_cfg;
>
> if (!cpuc->lbr_users || !x86_pmu.lbr_nr)
> return;
>
> /* Set hardware branch filter */
> if (cpuc->lbr_select) {
> - lbr_select = cpuc->lbr_sel->config & LBR_SELECT_MASK;
> + lbr_cfg = cpuc->lbr_sel->config;
> + lbr_select = lbr_cfg & LBR_SELECT_MASK;
> wrmsrq(MSR_AMD64_LBR_SELECT, lbr_select);
> }
>
> if (cpu_feature_enabled(X86_FEATURE_AMD_LBR_PMC_FREEZE)) {
> rdmsrq(MSR_IA32_DEBUGCTLMSR, dbg_ctl);
> - wrmsrq(MSR_IA32_DEBUGCTLMSR, dbg_ctl | DEBUGCTLMSR_FREEZE_LBRS_ON_PMI);
> + /* Skip the freeze if kernel branches are suppressed, unless asked */
> + if ((lbr_select & LBR_KERNEL) && !(lbr_cfg & LBR_FREEZE))
> + dbg_ctl &= ~DEBUGCTLMSR_FREEZE_LBRS_ON_PMI;
> + else
> + dbg_ctl |= DEBUGCTLMSR_FREEZE_LBRS_ON_PMI;
> + wrmsrq(MSR_IA32_DEBUGCTLMSR, dbg_ctl);
> }
[Severity: Medium]
Can this re-enable DEBUGCTLMSR_FREEZE_LBRS_ON_PMI for an active user-only LBR
event when multiple branch-stack events are scheduled on the same CPU?
In arch/x86/events/amd/lbr.c, amd_pmu_lbr_add() sets cpuc->lbr_select = 1 and
increments cpuc->lbr_users, but amd_pmu_lbr_del() unconditionally clears
cpuc->lbr_select to 0 whenever any branch-stack event is removed:
void amd_pmu_lbr_del(struct perf_event *event)
{
struct cpu_hw_events *cpuc = this_cpu_ptr(&cpu_hw_events);
if (!x86_pmu.lbr_nr)
return;
if (has_branch_stack(event))
cpuc->lbr_select = 0;
cpuc->lbr_users--;
...
}
If two user-only branch-stack events are active on a CPU (cpuc->lbr_users == 2)
and one of them is removed via amd_pmu_lbr_del(), cpuc->lbr_users remains 1
while cpuc->lbr_select becomes 0.
When amd_pmu_v2_enable_all() then calls amd_pmu_lbr_enable_all(), the
if (cpuc->lbr_select) block is skipped, leaving lbr_cfg and lbr_select as 0.
As a result, (lbr_select & LBR_KERNEL) evaluates to false and
amd_pmu_lbr_enable_all() sets DEBUGCTLMSR_FREEZE_LBRS_ON_PMI in
MSR_IA32_DEBUGCTLMSR even though the remaining active event suppresses kernel
branches and did not request a freeze.
Additionally, if a user-only event with freeze=0 is added alongside an event
that requires freezing (either recording kernel branches or with freeze=1),
amd_pmu_lbr_add() overwrites cpuc->lbr_sel->config with the new event's config,
causing amd_pmu_lbr_enable_all() to clear DEBUGCTLMSR_FREEZE_LBRS_ON_PMI for
both events.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261105170340.165507-1-puranjay@kernel.org?part=1
next prev parent reply other threads:[~2026-11-05 17:23 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-23 12:41 [PATCH] perf/x86/amd/lbr: Freeze LBR on PMI only when kernel branches are recorded Puranjay Mohan
2026-10-23 13:01 ` sashiko-bot
2026-10-23 15:18 ` Puranjay Mohan
2026-10-26 15:35 ` Sandipan Das
2026-10-29 20:12 ` Andrii Nakryiko
2026-11-02 10:08 ` Sandipan Das
2026-11-03 19:09 ` Andrii Nakryiko
2026-11-05 6:17 ` Sandipan Das
2026-11-05 16:58 ` Andrii Nakryiko
2026-11-05 17:03 ` [PATCH RFC] perf/x86/amd/lbr: Don't freeze the LBR on PMI for user-only filters Puranjay Mohan
2026-11-05 17:23 ` sashiko-bot [this message]
2026-11-06 1:07 ` Andrii Nakryiko
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=sashiko-outbox-199604@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=puranjay@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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