All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Mi, Dapeng" <dapeng1.mi@linux.intel.com>
To: sashiko-reviews@lists.linux.dev
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH 6/8] perf/x86/intel: Validate return value of intel_pmu_init_hybrid()
Date: Fri, 5 Jun 2026 11:29:58 +0800	[thread overview]
Message-ID: <633befb1-d3ed-4cc3-b515-449fbc98a44b@linux.intel.com> (raw)
In-Reply-To: <20260605013609.38A451F00893@smtp.kernel.org>


On 6/5/2026 9:36 AM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Low] Unnecessary error handling and dead cleanup code for early boot memory allocation failure.
> --
>
> commit e6fc94eb7f63fa466e8e1aeaed9a0d18231a88dc
> Author: Dapeng Mi <dapeng1.mi@linux.intel.com>
>
> perf/x86/intel: Validate return value of intel_pmu_init_hybrid()
>
> This commit validates the return value of intel_pmu_init_hybrid() to prevent
> attempts to access the uninitialized x86_pmu.hybrid_pmu[] array due to
> allocation failure. It adds error paths that destroy the task_ctx_cache when
> an error occurs.
>
>> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
>> index ea3ab3050a3b1..efd9caa3502c5 100644
>> --- a/arch/x86/events/intel/core.c
>> +++ b/arch/x86/events/intel/core.c
>> @@ -8539,7 +8540,9 @@ __init int intel_pmu_init(void)
>>  		 *
>>  		 * Initialize the common PerfMon capabilities here.
>>  		 */
>> -		intel_pmu_init_hybrid(hybrid_big_small);
>> +		ret = intel_pmu_init_hybrid(hybrid_big_small);
>> +		if (ret < 0)
>> +			goto err;
> [Severity: Low]
> Is this error handling necessary for an early boot function?
>
> Since intel_pmu_init() in arch/x86/events/intel/core.c is marked with __init,
> it executes only during early boot. At this stage, if a physical memory
> allocation fails, the system typically cannot boot anyway. Handling memory
> allocation failures and returning -ENOMEM here is likely dead code.

Even it's in early boot, it's better not to trigger an invalid memory
access error which could cause misleading.


>
> [ ... ]
>
>> @@ -8885,6 +8900,10 @@ __init int intel_pmu_init(void)
>>  	intel_aux_output_init();
>>  
>>  	return 0;
>> +
>> +err:
>> +	kmem_cache_destroy(x86_get_pmu(smp_processor_id())->task_ctx_cache);
> [Severity: Low]
> Will this cleanup code in intel_pmu_init() actually free anything?
>
> If the allocation fails during intel_pmu_init_hybrid() and we jump to the err
> label, task_ctx_cache has not been allocated yet. It is only allocated later
> in the function via intel_pmu_lbr_init() or intel_pmu_arch_lbr_init().
>
> This guarantees task_ctx_cache is NULL when this error path is taken, meaning
> this call to kmem_cache_destroy() acts as a no-op.

No, intel_pmu_arch_lbr_init() which is called before
intel_pmu_init_hybrid() could create the LBR needed slab cache
"task_ctx_cache". If intel_pmu_init_hybrid() returns error, the created
slab cache needs to be destroyed.

Thanks.

>
>> +	return ret;
>>  }
>>

  reply	other threads:[~2026-06-05  3:30 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-05  1:11 [PATCH 0/8] perf/x86: Miscellaneous PMU bug fixes Dapeng Mi
2026-06-05  1:11 ` [PATCH 1/8] perf/x86/intel: Remove anythread_deprecated bit from perf_capabilities Dapeng Mi
2026-06-05 17:04   ` Falcon, Thomas
2026-06-08  1:37     ` Mi, Dapeng
2026-06-05  1:11 ` [PATCH 2/8] perf/x86: Introduce is_x86_pmu() helper Dapeng Mi
2026-06-05 17:08   ` Falcon, Thomas
2026-06-05  1:11 ` [PATCH 3/8] perf/x86: Update cap_user_rdpmc base on rdpmc user disable state Dapeng Mi
2026-06-05 17:15   ` Falcon, Thomas
2026-06-05  1:11 ` [PATCH 4/8] perf/x86/intel: Fix redundant branch type check in intel_pmu_lbr_filter() Dapeng Mi
2026-06-05 18:28   ` Falcon, Thomas
2026-06-08  1:56     ` Mi, Dapeng
2026-06-08  6:15       ` Mi, Dapeng
2026-06-05  1:11 ` [PATCH 5/8] perf/x86/intel: Fix kernel address leakages in LBR stack Dapeng Mi
2026-06-05  1:33   ` sashiko-bot
2026-06-05  3:20     ` Mi, Dapeng
2026-06-05  1:11 ` [PATCH 6/8] perf/x86/intel: Validate return value of intel_pmu_init_hybrid() Dapeng Mi
2026-06-05  1:36   ` sashiko-bot
2026-06-05  3:29     ` Mi, Dapeng [this message]
2026-06-05 16:17   ` Chen, Zide
2026-06-08  2:48     ` Mi, Dapeng
2026-06-05 18:47   ` Falcon, Thomas
2026-06-05  1:11 ` [PATCH 7/8] perf/x86/intel: Drop fixed-counter PEBS constraints for baseline PEBS Dapeng Mi
2026-06-05 20:32   ` Chen, Zide
2026-06-08  2:46     ` Mi, Dapeng
2026-06-08 15:46       ` Chen, Zide
2026-06-09  0:36         ` Mi, Dapeng
2026-06-05  1:11 ` [PATCH 8/8] perf/core: Fix kernel register info leak via hardware skid Dapeng Mi
2026-06-05  1:38   ` sashiko-bot
2026-06-05  3:42     ` Mi, Dapeng
2026-06-05 19:08   ` Falcon, Thomas
2026-06-08  2:47     ` Mi, Dapeng

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=633befb1-d3ed-4cc3-b515-449fbc98a44b@linux.intel.com \
    --to=dapeng1.mi@linux.intel.com \
    --cc=linux-perf-users@vger.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 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.