When perf samples a tracepoint like trace_lock_acquire with high
frequency, it can trigger a WARN_ON in perf_event_throttle_group()
due to lockdep assertion failure in for_each_sibling_event().

The issue is that for_each_sibling_event() requires either:
1. Holding ctx->mutex, OR
2. Having IRQs disabled (since ctx->lock is IRQ-safe)

The call trace shows the problematic path:
futex_wake
  lock_acquire
    trace_lock_acquire
      perf_trace_lock_acquire
        perf_tp_event
          perf_swevent_event
            __perf_event_overflow
              __perf_event_account_interrupt
                perf_event_throttle_group
                  for_each_sibling_event [WARN]

In this tracepoint path, IRQs may be enabled and neither ctx->lock
nor ctx->mutex is held.

The fix adds guard(irqsave)() protection around the sibling list
iteration in perf_event_throttle_group().

Reported-by: syzbot+a945e9d15c8a49a7a7f0@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/all/69122cb3.a70a0220.22f260.00ff.GAE@google.com/T/
Signed-off-by: Jianhui Zhou <jianhuizz@qq.com>
---
 kernel/events/core.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 1fd347da9026..253c514e9452 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -2700,6 +2700,11 @@ static void perf_event_throttle_group(struct perf_event *event)
 	struct perf_event *sibling, *leader = event->group_leader;
 
 	perf_event_throttle(leader);
+    /*
+     * Disable IRQs to protect sibling iteration; for_each_sibling_event()
+     * needs ctx->mutex or IRQs off.
+     */
+	guard(irqsave)();
 	for_each_sibling_event(sibling, leader)
 		perf_event_throttle(sibling);
 }
-- 
2.43.0

On 11/12/2025 8:34 PM, Jianhui Zhou wrote:
> When perf samples a tracepoint like trace_lock_acquire with high
> frequency, it can trigger a WARN_ON in perf_event_throttle_group()
> due to lockdep assertion failure in for_each_sibling_event().
>
> The issue is that for_each_sibling_event() requires either:
> 1. Holding ctx->mutex, OR
> 2. Having IRQs disabled (since ctx->lock is IRQ-safe)
>
> The call trace shows the problematic path:
> futex_wake
>   lock_acquire
>     trace_lock_acquire
>       perf_trace_lock_acquire
>         perf_tp_event
>           perf_swevent_event
>             __perf_event_overflow
>               __perf_event_account_interrupt
>                 perf_event_throttle_group
>                   for_each_sibling_event [WARN]
>
> In this tracepoint path, IRQs may be enabled and neither ctx->lock
> nor ctx->mutex is held.
>
> The fix adds guard(irqsave)() protection around the sibling list
> iteration in perf_event_throttle_group().
>
> Reported-by: syzbot+a945e9d15c8a49a7a7f0@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/all/69122cb3.a70a0220.22f260.00ff.GAE@google.com/T/
> Signed-off-by: Jianhui Zhou <jianhuizz@qq.com>
> ---
>  kernel/events/core.c | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 1fd347da9026..253c514e9452 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -2700,6 +2700,11 @@ static void perf_event_throttle_group(struct perf_event *event)
>  	struct perf_event *sibling, *leader = event->group_leader;
>  
>  	perf_event_throttle(leader);
> +    /*
> +     * Disable IRQs to protect sibling iteration; for_each_sibling_event()
> +     * needs ctx->mutex or IRQs off.
> +     */
> +	guard(irqsave)();

This seems the simplest way to fix the issue although it may bring a slight
overhead if hard irq is already disabled. Thanks.

Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com>


>  	for_each_sibling_event(sibling, leader)
>  		perf_event_throttle(sibling);
>  }