Re: [PATCH AUTOSEL 6.18-6.1] perf/x86/intel: Fallback to sw branch type decoding if no hw decoding

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] perf/x86/intel: X86_BR_TYPE_SAVE forced in intel_pmu_setup_hw_lbr_filter()
--

commit c34c39f861fe5e2bf440b3a3e6e92d35016fb9be
Author: Dapeng Mi <dapeng1.mi@linux.intel.com>

perf/x86/intel: Fallback to sw branch type decoding if no hw decoding

This commit updates intel_pmu_lbr_filter() to check the x86_lbr_type static
branch instead of X86_FEATURE_ARCH_LBR, falling back to software branch-type
decoding when hardware branch-type decoding is unavailable on arch-LBR CPUs.

Link: https://patch.msgid.link/20260616044654.3468742-4-dapeng1.mi@linux.intel.com

> diff --git a/arch/x86/events/intel/lbr.c b/arch/x86/events/intel/lbr.c
> index 7aa59966e7c3e..896aeaac9e6a4 100644
> --- a/arch/x86/events/intel/lbr.c
> +++ b/arch/x86/events/intel/lbr.c
> @@ -1230,7 +1230,7 @@ intel_pmu_lbr_filter(struct cpu_hw_events *cpuc)
>  		 * Doesn't support OTHER_BRANCH decoding for now.
>  		 * OTHER_BRANCH branch type still rely on software decoding.
>  		 */
> -		if (static_cpu_has(X86_FEATURE_ARCH_LBR) &&
> +		if (static_branch_likely(&x86_lbr_type) &&
>  		    type <= ARCH_LBR_BR_TYPE_KNOWN_MAX) {
>  			to_plm = kernel_ip(to) ? X86_BR_KERNEL : X86_BR_USER;
>  			type = arch_lbr_br_type_map[type] | to_plm;

[Severity: Medium]
Should intel_pmu_setup_hw_lbr_filter() also be updated to check
static_branch_likely(&x86_lbr_type) before forcing X86_BR_TYPE_SAVE?

Currently, intel_pmu_setup_hw_lbr_filter() checks X86_FEATURE_ARCH_LBR and
unconditionally enables X86_BR_TYPE_SAVE under the assumption that hardware
provides branch types without software disassembly:

arch/x86/events/intel/lbr.c:intel_pmu_setup_hw_lbr_filter() {
	...
	if (static_cpu_has(X86_FEATURE_ARCH_LBR)) {
		reg->config = mask;

		/*
		 * The Arch LBR HW can retrieve the common branch types
		 * from the LBR_INFO. It doesn't require the high overhead
		 * SW disassemble.
		 * Enable the branch type by default for the Arch LBR.
		 */
		reg->reg |= X86_BR_TYPE_SAVE;
		return 0;
	}
	...
}

When an event is opened with PERF_SAMPLE_BRANCH_USER |
PERF_SAMPLE_BRANCH_KERNEL | PERF_SAMPLE_BRANCH_ANY (without
PERF_SAMPLE_BRANCH_TYPE_SAVE) on an arch-LBR CPU where x86_lbr_type is
disabled, forcing X86_BR_TYPE_SAVE into cpuc->br_sel causes
intel_pmu_lbr_filter() to bypass its fast-path return:

arch/x86/events/intel/lbr.c:intel_pmu_lbr_filter() {
	/* if sampling all branches, then nothing to filter */
	if (((br_sel & X86_BR_ALL) == X86_BR_ALL) &&
	    ((br_sel & X86_BR_TYPE_SAVE) != X86_BR_TYPE_SAVE))
		return;

With this change in intel_pmu_lbr_filter(), every LBR entry then falls back
to software disassembly via branch_type() in NMI context, and any entry where
branch_type() returns X86_BR_NONE (such as when copy_from_user_nmi() fails on
an unmapped user page) gets discarded even though the user asked to sample
all branches without branch-type saving:

		/* if type does not correspond, then discard */
		if (type == X86_BR_NONE || (br_sel & type) != type) {
			cpuc->lbr_entries[i].from = 0;
			compress = true;
		}

Would it make sense to gate X86_BR_TYPE_SAVE in
intel_pmu_setup_hw_lbr_filter() on static_branch_likely(&x86_lbr_type) as
well?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261019135441.1420968-463-sashal@kernel.org?part=1