Linux Perf Users
 help / color / mirror / Atom feed
From: vineash <vineash30640@gmail.com>
To: peterz@infradead.org, mingo@redhat.com, acme@kernel.org,
	namhyung@kernel.org
Cc: dapeng1.mi@linux.intel.com, kan.liang@linux.intel.com,
	mark.rutland@arm.com, alexander.shishkin@linux.intel.com,
	jolsa@kernel.org, irogers@google.com, adrian.hunter@intel.com,
	james.clark@linaro.org, x86@kernel.org,
	linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH] perf/x86: Don't WARN when the ext_regs_buf allocation fails
Date: Tue, 13 Oct 2026 16:13:20 +0800	[thread overview]
Message-ID: <179187920064.3441876.15687522011658301558@gmail.com> (raw)

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


             reply	other threads:[~2026-10-13  8:13 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-13  8:13 vineash [this message]
2026-10-13  8:23 ` [PATCH] perf/x86: Don't WARN when the ext_regs_buf allocation fails sashiko-bot

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=179187920064.3441876.15687522011658301558@gmail.com \
    --to=vineash30640@gmail.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=dapeng1.mi@linux.intel.com \
    --cc=irogers@google.com \
    --cc=james.clark@linaro.org \
    --cc=jolsa@kernel.org \
    --cc=kan.liang@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=x86@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox