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

[sashiko-bot@kernel.org]

> 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