* [PATCH] perf/x86: Don't WARN when the ext_regs_buf allocation fails
@ 2026-10-13 8:13 vineash
2026-10-13 8:23 ` sashiko-bot
0 siblings, 1 reply; 2+ messages in thread
From: vineash @ 2026-10-13 8:13 UTC (permalink / raw)
To: peterz, mingo, acme, namhyung
Cc: dapeng1.mi, kan.liang, mark.rutland, alexander.shishkin, jolsa,
irogers, adrian.hunter, james.clark, x86, linux-perf-users,
linux-kernel
reserve_ext_regs_buffers() wraps the per-CPU ext_regs_buf allocation in
WARN_ON_ONCE(). The allocator already prints a warning with a stack dump
when a GFP_KERNEL allocation fails, so the WARN only repeats it, which
Documentation/process/coding-style.rst asks not to do. The failure is
also handled: the buffers are freed again, the event is still created,
and events that ask for SIMD or extended register sampling are rejected
with -ENOMEM in x86_pmu_hw_config() and event_simd_regs_validate().
syzkaller hit this with fault injection on next-20261002. The trigger
is a plain hardware cycles event opened while no other x86 PMU event
exists, with the allocation failed:
!per_cpu(ext_regs_buf, cpu)
WARNING: arch/x86/events/core.c:441 at reserve_ext_regs_buffers arch/x86/events/core.c:441 [inline]
WARNING: arch/x86/events/core.c:441 at x86_reserve_hardware+0x6ff/0x880 arch/x86/events/core.c:458
Call Trace:
__x86_pmu_event_init arch/x86/events/core.c:825 [inline]
x86_pmu_event_init+0x109/0xc50 arch/x86/events/core.c:3003
perf_try_init_event+0x140/0xbc0 kernel/events/core.c:13261
perf_init_event kernel/events/core.c:13365 [inline]
perf_event_alloc+0x2145/0x5680 kernel/events/core.c:13640
__do_sys_perf_event_open+0x669/0x2d40 kernel/events/core.c:14185
do_syscall_64+0x12c/0x7b0 arch/x86/entry/syscall_64.c:84
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Drop the WARN_ON_ONCE(). This matches reserve_ds_buffers() and
reserve_lbr_buffers(), which also handle allocation failure without a
warning.
Fixes: b84c96283684 ("perf/x86: Enable XMM register sampling for non-PEBS events")
Assisted-by: Claude:claude-opus-5-5 syzkaller
Signed-off-by: vineash <vineash30640@gmail.com>
---
Notes (not for the commit log):
Found with syzkaller in a QEMU/KVM guest with "-cpu host" (Intel Xeon Gold
5118 host).
Tested on next-20261002 (x86_64, syzbot's upstream-apparmor-kasan config,
gcc 12) with a small C reproducer: write failslab/ignore-gfp-wait=N, then
open a user-only cycles event with /proc/thread-self/fail-nth set to 1..64.
The third injected failure lands on the ext_regs_buf kzalloc_node().
before: 3/3 runs hit the WARNING above, at fail-nth=3
after: 3/3 runs without any WARNING; with failslab/verbose=2 the forced
failure is shown at reserve_ext_regs_buffers()
(arch/x86/events/core.c:439), and perf_event_open() returns a
valid fd, as before
The WARN came up in the Sashiko review of v9 of the series. Dapeng
preferred to keep the WARN_ON_ONCE() over propagating the error, since
that would need a lot of fallback code:
https://lore.kernel.org/all/89f316ca-936b-4938-9421-2f96cfdc4837@linux.intel.com/
This patch does not propagate the error either. It only drops the WARN,
since the allocator already reports the failure.
The patch only removes the WARN, so failure handling does not change:
the event is still created, and events that need SIMD or extended
register sampling get -ENOMEM until the last x86 PMU event is gone.
x86_reserve_hardware() could return the error instead, but that would
also make plain counting events fail, which seemed out of scope here.
The reproducer is available on request.
arch/x86/events/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
index 9b1a9032e..4df792b13 100644
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -438,7 +438,7 @@ static void reserve_ext_regs_buffers(void)
for_each_possible_cpu(cpu) {
per_cpu(ext_regs_buf, cpu) = kzalloc_node(size, GFP_KERNEL,
cpu_to_node(cpu));
- if (WARN_ON_ONCE(!per_cpu(ext_regs_buf, cpu)))
+ if (!per_cpu(ext_regs_buf, cpu))
goto err;
}
--
2.25.1
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH] perf/x86: Don't WARN when the ext_regs_buf allocation fails
2026-10-13 8:13 [PATCH] perf/x86: Don't WARN when the ext_regs_buf allocation fails vineash
@ 2026-10-13 8:23 ` sashiko-bot
0 siblings, 0 replies; 2+ messages in thread
From: sashiko-bot @ 2026-10-13 8:23 UTC (permalink / raw)
To: vineash; +Cc: linux-perf-users
> reserve_ext_regs_buffers() wraps the per-CPU ext_regs_buf allocation in
> WARN_ON_ONCE(). The allocator already prints a warning with a stack dump
> when a GFP_KERNEL allocation fails, so the WARN only repeats it, which
> Documentation/process/coding-style.rst asks not to do. The failure is
> also handled: the buffers are freed again, the event is still created,
> and events that ask for SIMD or extended register sampling are rejected
> with -ENOMEM in x86_pmu_hw_config() and event_simd_regs_validate().
>
> syzkaller hit this with fault injection on next-20261002. The trigger
> is a plain hardware cycles event opened while no other x86 PMU event
> exists, with the allocation failed:
>
> !per_cpu(ext_regs_buf, cpu)
> WARNING: arch/x86/events/core.c:441 at reserve_ext_regs_buffers arch/x86/events/core.c:441 [inline]
> WARNING: arch/x86/events/core.c:441 at x86_reserve_hardware+0x6ff/0x880 arch/x86/events/core.c:458
> [ ... ]
> warning.
>
> Fixes: b84c96283684 ("perf/x86: Enable XMM register sampling for non-PEBS events")
> Assisted-by: Claude:claude-opus-5-5 syzkaller
> Signed-off-by: vineash <vineash30640@gmail.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/179187920064.3441876.15687522011658301558@gmail.com?part=1
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-10-13 8:23 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-10-13 8:13 [PATCH] perf/x86: Don't WARN when the ext_regs_buf allocation fails vineash
2026-10-13 8:23 ` sashiko-bot
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox