[PATCH] perf/x86/intel/ds: don't WARN when the BTS buffer can't be allocated

[PATCH] perf/x86/intel/ds: don't WARN when the BTS buffer can't be allocated

[Yuehong Wu]

alloc_bts_buffer() asks for the buffer with __GFP_NOWARN and then WARNs
if the allocation failed anyway.  The failure is already handled: the
caller disables BTS for the event and releases what was set up, and
perf_event_open() returns -ENOMEM.

The WARN_ONCE() came with commit 4485154138f6 ("perf/x86/intel: Avoid
spamming kernel log for BTS buffer failure"), which added __GFP_NOWARN to
stop the log spam of the failing per-CPU allocation but kept one warning
as a hint.  That hint is fatal under panic_on_warn: on a machine with
BTS, the 64 KiB buffer allocation can fail on a memory-constrained
system and a plain perf_event_open() then panics the kernel.  Since the
allocation explicitly asked not to warn and the error path is fine, drop
the WARN_ONCE().

Reproduced on 7.3.0-next-20261027 by making the page allocator fail the
order-4 BTS buffer allocation (fail_page_alloc: min-order=4,
ignore-gfp-wait=0).  Without this change the first perf_event_open() of
a hardware event hits the warning and, with panic_on_warn=1, panics.
With this change the same allocation failure is silent: BTS is disabled
and a following branches/period=1 event returns -EOPNOTSUPP, while the
kernel keeps running.  The buffer is allocated per possible CPU,
independently of any specific BTS event, so the failure path is
exercised without BTS tracing.

Fixes: 4485154138f6 ("perf/x86/intel: Avoid spamming kernel log for BTS buffer failure")
Signed-off-by: Yuehong Wu <wuyuehong@cmss.chinamobile.com>
---
 arch/x86/events/intel/ds.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c
index 8444670..27e4115 100644
--- a/arch/x86/events/intel/ds.c
+++ b/arch/x86/events/intel/ds.c
@@ -939,10 +939,8 @@ static int alloc_bts_buffer(int cpu)
 		return 0;
 
 	buffer = dsalloc_pages(BTS_BUFFER_SIZE, GFP_KERNEL | __GFP_NOWARN, cpu);
-	if (unlikely(!buffer)) {
-		WARN_ONCE(1, "%s: BTS buffer allocation failure\n", __func__);
+	if (unlikely(!buffer))
 		return -ENOMEM;
-	}
 	hwev->ds_bts_vaddr = buffer;
 	/* Update the fixmap */
 	cea = &get_cpu_entry_area(cpu)->cpu_debug_buffers.bts_buffer;
-- 
2.43.0

Re: [PATCH] perf/x86/intel/ds: don't WARN when the BTS buffer can't be allocated

[sashiko-bot]

> alloc_bts_buffer() asks for the buffer with __GFP_NOWARN and then WARNs
> if the allocation failed anyway.  The failure is already handled: the
> caller disables BTS for the event and releases what was set up, and
> perf_event_open() returns -ENOMEM.
> 
> The WARN_ONCE() came with commit 4485154138f6 ("perf/x86/intel: Avoid
> spamming kernel log for BTS buffer failure"), which added __GFP_NOWARN to
> stop the log spam of the failing per-CPU allocation but kept one warning
> as a hint.  That hint is fatal under panic_on_warn: on a machine with
> BTS, the 64 KiB buffer allocation can fail on a memory-constrained
> system and a plain perf_event_open() then panics the kernel.  Since the
> allocation explicitly asked not to warn and the error path is fine, drop
> the WARN_ONCE().
> 
> Reproduced on 7.3.0-next-20261027 by making the page allocator fail the
> order-4 BTS buffer allocation (fail_page_alloc: min-order=4,
> ignore-gfp-wait=0).  Without this change the first perf_event_open() of
> a hardware event hits the warning and, with panic_on_warn=1, panics.
> With this change the same allocation failure is silent: BTS is disabled
> and a following branches/period=1 event returns -EOPNOTSUPP, while the
> kernel keeps running.  The buffer is allocated per possible CPU,
> independently of any specific BTS event, so the failure path is
> exercised without BTS tracing.
> 
> Fixes: 4485154138f6 ("perf/x86/intel: Avoid spamming kernel log for BTS buffer failure")
> Signed-off-by: Yuehong Wu <wuyuehong@cmss.chinamobile.com>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261105-perf-ds-bts-warn-1-yuehongwu@cmss.chinamobile.com?part=1