[PATCH AUTOSEL 6.12 07/12] perf/core: Fix WARN in perf_sigtrap()

[PATCH AUTOSEL 6.12 07/12] perf/core: Fix WARN in perf_sigtrap()

[Sasha Levin]

From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>

[ Upstream commit 3da6bb419750f3ad834786d6ba7c9d5d062c770b ]

Since exit_task_work() runs after perf_event_exit_task_context() updated
ctx->task to TASK_TOMBSTONE, perf_sigtrap() from perf_pending_task() might
observe event->ctx->task == TASK_TOMBSTONE.

Swap the early exit tests in order not to hit WARN_ON_ONCE().

Closes: https://syzkaller.appspot.com/bug?extid=2fe61cb2a86066be6985
Reported-by: syzbot <syzbot+2fe61cb2a86066be6985@syzkaller.appspotmail.com>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/b1c224bd-97f9-462c-a3e3-125d5e19c983@I-love.SAKURA.ne.jp
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Based on my analysis of the commit, let me provide my assessment:

**YES**

This commit should be backported to stable kernel trees for the
following reasons:

1. **It fixes a real bug with user-visible impact**: The commit fixes a
   WARN_ON_ONCE() that fires in perf_sigtrap() when the system hits a
   specific race condition. This WARN causes kernel log spam and
   indicates an unexpected state that shouldn't occur.

2. **The fix is small and contained**: The change is minimal - it simply
   reorders two early exit checks in perf_sigtrap():
   - Before: Check `event->ctx->task != current` first, then check
     `PF_EXITING`
   - After: Check `PF_EXITING` first, then check `event->ctx->task !=
     current`

3. **Clear race condition**: The commit message explains the race:
   exit_task_work() runs after perf_event_exit_task_context() has
   updated ctx->task to TASK_TOMBSTONE. When perf_sigtrap() is called
   from perf_pending_task() during this window, it observes
   event->ctx->task == TASK_TOMBSTONE, which doesn't match current,
   triggering the WARN.

4. **Low risk of regression**: The fix simply reorders existing checks
   without changing functionality. If the task is exiting (PF_EXITING is
   set), we return early regardless. The reordering just prevents the
   WARN from firing in this legitimate exit scenario.

5. **Fixes a reproducible issue**: The commit references a specific
   syzbot report
   (https://syzkaller.appspot.com/bug?extid=2fe61cb2a86066be6985),
   indicating this is a real issue that can be triggered, not just
   theoretical.

6. **Follows stable tree rules**: This is an important bugfix (prevents
   kernel warnings), has minimal risk, and doesn't introduce new
   features or make architectural changes.

The fix is appropriate because during task exit, it's expected that
ctx->task might be TASK_TOMBSTONE while the task is still cleaning up
its work items. By checking PF_EXITING first, we properly handle the
legitimate exit case without triggering false warnings.

 kernel/events/core.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 7210104b3345c..5ad445e80af3b 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -6894,18 +6894,18 @@ void perf_event_wakeup(struct perf_event *event)
 static void perf_sigtrap(struct perf_event *event)
 {
 	/*
-	 * We'd expect this to only occur if the irq_work is delayed and either
-	 * ctx->task or current has changed in the meantime. This can be the
-	 * case on architectures that do not implement arch_irq_work_raise().
+	 * Both perf_pending_task() and perf_pending_irq() can race with the
+	 * task exiting.
 	 */
-	if (WARN_ON_ONCE(event->ctx->task != current))
+	if (current->flags & PF_EXITING)
 		return;
 
 	/*
-	 * Both perf_pending_task() and perf_pending_irq() can race with the
-	 * task exiting.
+	 * We'd expect this to only occur if the irq_work is delayed and either
+	 * ctx->task or current has changed in the meantime. This can be the
+	 * case on architectures that do not implement arch_irq_work_raise().
 	 */
-	if (current->flags & PF_EXITING)
+	if (WARN_ON_ONCE(event->ctx->task != current))
 		return;
 
 	send_sig_perf((void __user *)event->pending_addr,
-- 
2.39.5

[PATCH AUTOSEL 6.12 09/12] wifi: mt76: fix queue assignment for deauth packets

[Sasha Levin]

From: Felix Fietkau <nbd@nbd.name>

[ Upstream commit dedf2ec30fe417d181490896adf89cd6b9885b23 ]

When running in AP mode and deauthenticating a client that's in powersave
mode, the disassoc/deauth packet can get stuck in a tx queue along with
other buffered frames. This can fill up hardware queues with frames
that are only released after the WTBL slot is reused for another client.

Fix this by moving deauth packets to the ALTX queue.

Reported-by: Chad Monroe <chad.monroe@adtran.com>
Link: https://patch.msgid.link/20250707154702.1726-2-nbd@nbd.name
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I understand the issue and the fix better. Let me analyze this
commit:

**YES**

This commit should be backported to stable kernel trees for the
following reasons:

1. **It fixes a real bug affecting users**: The commit addresses a
   specific issue where deauthentication packets sent to clients in
   powersave mode can get stuck in hardware TX queues. This causes queue
   exhaustion and prevents the WTBL (Wireless Table) slot from being
   properly reused for new clients. This is a significant functional bug
   that impacts AP mode operation.

2. **The fix is small and contained**: The change is minimal - it only
   adds a single condition (`||
   ieee80211_is_deauth(hdr->frame_control)`) to the existing queue
   assignment logic. This is a low-risk change that doesn't introduce
   new functionality or architectural changes.

3. **Clear problem and solution**: The commit message clearly describes
   the issue (deauth packets getting stuck with other buffered frames)
   and the solution (moving deauth packets to the ALTX/PSD queue). The
   fix is logical because:
   - According to `ieee80211_is_bufferable_mmpdu()` (line 4517), deauth
     frames ARE considered bufferable MMPDUs
   - However, when a client is being deauthenticated, we don't want
     these frames to be buffered with regular data - they need immediate
     transmission
   - The PSD (Power Save Delivery) queue is more appropriate for
     management frames that need immediate handling

4. **Similar to previous backported fixes**: Looking at the similar
   commits, commit #1 (fca9615f1a43) which fixed queue handling for
   loopback packets was backported. This current fix addresses a similar
   class of queue assignment issues.

5. **No architectural changes**: The fix uses existing infrastructure
   (MT_TXQ_PSD queue) and existing helper functions
   (ieee80211_is_deauth). It doesn't introduce new features or change
   any APIs.

6. **Prevents resource exhaustion**: The bug can lead to hardware queue
   exhaustion which is a serious issue in production AP deployments.
   This makes it an important fix for stable kernels.

The code change shows that previously, only non-bufferable MMPDUs were
assigned to the PSD queue, but deauth frames (which are technically
bufferable) were getting stuck in regular data queues when sent to
powersave clients. This fix ensures deauth frames bypass the normal
buffering mechanism and get transmitted promptly via the PSD queue.

 drivers/net/wireless/mediatek/mt76/tx.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mediatek/mt76/tx.c b/drivers/net/wireless/mediatek/mt76/tx.c
index 065a1e4537457..da31bf3c18db8 100644
--- a/drivers/net/wireless/mediatek/mt76/tx.c
+++ b/drivers/net/wireless/mediatek/mt76/tx.c
@@ -615,7 +615,8 @@ mt76_txq_schedule_pending_wcid(struct mt76_phy *phy, struct mt76_wcid *wcid,
 		if ((dev->drv->drv_flags & MT_DRV_HW_MGMT_TXQ) &&
 		    !(info->flags & IEEE80211_TX_CTL_HW_80211_ENCAP) &&
 		    !ieee80211_is_data(hdr->frame_control) &&
-		    !ieee80211_is_bufferable_mmpdu(skb))
+		    (!ieee80211_is_bufferable_mmpdu(skb) ||
+		     ieee80211_is_deauth(hdr->frame_control)))
 			qid = MT_TXQ_PSD;
 
 		q = phy->q_tx[qid];
-- 
2.39.5