Re: [RFC PATCH] perf/x86/intel: downgrade alloc_bts_buffer() WARN() to pr_err()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Replacing `WARN_ONCE(1, ...)` with `pr_err_once(1, ...)` without removing the condition argument causes a build failure.
--

commit e234f9d8f1cd00344467d9d8095e6f5f291f3900
Author: Sergey Senozhatsky <senozhatsky@chromium.org>

perf/x86/intel: downgrade alloc_bts_buffer() WARN() to pr_err()

This commit downgrades the BTS buffer allocation failure warning from
WARN_ONCE to pr_err_once to prevent triggering fleet monitoring alarms
under memory pressure.

> diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c
> index 91a093d8cf2e7..02ec21ebb7af2 100644
> --- a/arch/x86/events/intel/ds.c
> +++ b/arch/x86/events/intel/ds.c
> @@ -918,7 +918,7 @@ static int alloc_bts_buffer(int cpu)
>  
>  	buffer = dsalloc_pages(BTS_BUFFER_SIZE, GFP_KERNEL | __GFP_NOWARN, cpu);
>  	if (unlikely(!buffer)) {
> -		WARN_ONCE(1, "%s: BTS buffer allocation failure\n", __func__);
> +		pr_err_once(1, "%s: BTS buffer allocation failure\n", __func__);

[Severity: Low]
Does this cause a build failure? Unlike WARN_ONCE which takes a condition
as its first argument, pr_err_once expects the format string as its first
argument. Leaving the integer 1 here will attempt to concatenate the KERN_ERR
macro string literal with an integer during expansion, which usually results
in a compile-time syntax error.

>  		return -ENOMEM;
>  	}
>  	hwev->ds_bts_vaddr = buffer;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260827065529.3835720-1-senozhatsky@chromium.org?part=1