From: "tip-bot2 for Thomas Gleixner" <tip-bot2@linutronix.de>
To: linux-tip-commits@vger.kernel.org
Cc: Frederic Weisbecker <frederic@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
x86@kernel.org, linux-kernel@vger.kernel.org, maz@kernel.org
Subject: [tip: irq/core] genirq: Prevent early spurious wake-ups of interrupt threads
Date: Fri, 21 Nov 2025 20:01:30 -0000 [thread overview]
Message-ID: <176375529017.498.4701344518061876052.tip-bot2@tip-bot2> (raw)
In-Reply-To: <20251121143500.42111-2-frederic@kernel.org>
The following commit has been merged into the irq/core branch of tip:
Commit-ID: 9d5ca2edd74e479ad09bc7d02820395a9d46e2bd
Gitweb: https://git.kernel.org/tip/9d5ca2edd74e479ad09bc7d02820395a9d46e2bd
Author: Thomas Gleixner <tglx@linutronix.de>
AuthorDate: Fri, 21 Nov 2025 15:34:58 +01:00
Committer: Thomas Gleixner <tglx@linutronix.de>
CommitterDate: Fri, 21 Nov 2025 20:50:30 +01:00
genirq: Prevent early spurious wake-ups of interrupt threads
During initialization, the interrupt thread is created before the interrupt
is enabled. The interrupt enablement happens before the actual kthread wake
up point. Once the interrupt is enabled the hardware can raise an interrupt
and once setup_irq() drops the descriptor lock a interrupt wake-up can
happen.
Even when such an interrupt can be considered premature, this is not a
problem in general because at the point where the descriptor lock is
dropped and the wakeup can happen, the data which is used by the thread is
fully initialized.
Though from the perspective of least surprise, the initial wakeup really
should be performed by the setup code and not randomly by a premature
interrupt.
Prevent this by performing a wake-up only if the target is in state
TASK_INTERRUPTIBLE, which the thread uses in wait_for_interrupt().
If the thread is still in state TASK_UNINTERRUPTIBLE, the wake-up is not
lost because after the setup code completed the initial wake-up the thread
will observe the IRQTF_RUNTHREAD and proceed with the handling.
Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://patch.msgid.link/20251121143500.42111-2-frederic@kernel.org
---
kernel/irq/handle.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/kernel/irq/handle.c b/kernel/irq/handle.c
index e103451..786f557 100644
--- a/kernel/irq/handle.c
+++ b/kernel/irq/handle.c
@@ -133,7 +133,15 @@ void __irq_wake_thread(struct irq_desc *desc, struct irqaction *action)
*/
atomic_inc(&desc->threads_active);
- wake_up_process(action->thread);
+ /*
+ * This might be a premature wakeup before the thread reached the
+ * thread function and set the IRQTF_READY bit. It's waiting in
+ * kthread code with state UNINTERRUPTIBLE. Once it reaches the
+ * thread function it waits with INTERRUPTIBLE. The wakeup is not
+ * lost in that case because the thread is guaranteed to observe
+ * the RUN flag before it goes to sleep in wait_for_interrupt().
+ */
+ wake_up_state(action->thread, TASK_INTERRUPTIBLE);
}
static DEFINE_STATIC_KEY_FALSE(irqhandler_duration_check_enabled);
next prev parent reply other threads:[~2025-11-21 20:01 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20251121143513eucas1p15c03a2c15aa5a0a15cc46d8f0a4e534e@eucas1p1.samsung.com>
2025-11-21 14:34 ` [PATCH 0/3 v3] genirq: Fix IRQ threads VS cpuset Frederic Weisbecker
2025-11-21 14:34 ` [PATCH 1/3 v3] genirq: Prevent from early irq thread spurious wake-ups Frederic Weisbecker
2025-11-21 19:12 ` Thomas Gleixner
2025-11-21 22:04 ` Frederic Weisbecker
2025-11-21 20:01 ` tip-bot2 for Thomas Gleixner [this message]
2025-11-22 8:30 ` [tip: irq/core] genirq: Prevent early spurious wake-ups of interrupt threads tip-bot2 for Frederic Weisbecker
2025-11-21 14:34 ` [PATCH 2/3 v3] genirq: Fix interrupt threads affinity vs. cpuset isolated partitions Frederic Weisbecker
2025-11-21 16:29 ` Waiman Long
2025-11-21 20:01 ` [tip: irq/core] " tip-bot2 for Frederic Weisbecker
2025-11-22 8:30 ` tip-bot2 for Frederic Weisbecker
2025-12-12 1:48 ` [PATCH 2/3 v3] " Chris Mason
2025-12-12 2:26 ` Thomas Gleixner
2025-12-12 4:01 ` [PATCH] genirq: Don't overwrite interrupt thread flags on setup Thomas Gleixner
2025-12-12 11:57 ` Frederic Weisbecker
2025-12-13 1:37 ` [tip: irq/urgent] " tip-bot2 for Thomas Gleixner
2025-12-18 10:07 ` [PATCH 2/3 v3] genirq: Fix interrupt threads affinity vs. cpuset isolated partitions Guenter Roeck
2025-11-21 14:35 ` [PATCH 3/3 v3] genirq: Remove cpumask availability check on kthread affinity setting Frederic Weisbecker
2025-11-21 20:01 ` [tip: irq/core] " tip-bot2 for Frederic Weisbecker
2025-11-22 8:30 ` tip-bot2 for Frederic Weisbecker
2025-11-21 20:05 ` [PATCH 0/3 v3] genirq: Fix IRQ threads VS cpuset Marek Szyprowski
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=176375529017.498.4701344518061876052.tip-bot2@tip-bot2 \
--to=tip-bot2@linutronix.de \
--cc=frederic@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=maz@kernel.org \
--cc=tglx@linutronix.de \
--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
all inboxes | Powered by JetHome®