public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Marek Szyprowski <m.szyprowski@samsung.com>,
	Frederic Weisbecker <frederic@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Marco Crivellari <marco.crivellari@suse.com>,
	Waiman Long <llong@redhat.com>,
	cgroups@vger.kernel.org
Subject: Re: [PATCH 1/2] genirq: Fix IRQ threads affinity VS cpuset isolated partitions
Date: Thu, 20 Nov 2025 14:45:01 +0100	[thread overview]
Message-ID: <87y0o0keci.ffs@tglx> (raw)
In-Reply-To: <73356b5f-ab5c-4e9e-b57f-b80981c35998@samsung.com>

On Thu, Nov 20 2025 at 12:51, Marek Szyprowski wrote:
> On 18.11.2025 15:30, Frederic Weisbecker wrote:
>> In the meantime, cpuset shouldn't fiddle with IRQ threads directly.
>> To prevent from that, set the PF_NO_SETAFFINITY flag to them.
>>
>> Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
>
> This patch landed in today's linux-next as commit 844dcacab287 ("genirq: 
> Fix interrupt threads affinity vs. cpuset isolated partitions"). In my 
> tests I found that it triggers a warnings on some of my test systems. 
> This is example of such warning:
>
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 1 at kernel/kthread.c:599 kthread_bind_mask+0x2c/0x84
> Modules linked in:
> CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 
> 6.18.0-rc1-00031-g844dcacab287 #16177 PREEMPT
> Hardware name: Samsung Exynos (Flattened Device Tree)
> Call trace:
>   unwind_backtrace from show_stack+0x10/0x14
>   show_stack from dump_stack_lvl+0x68/0x88
>   dump_stack_lvl from __warn+0x80/0x1d0
>   __warn from warn_slowpath_fmt+0x1b0/0x1bc
>   warn_slowpath_fmt from kthread_bind_mask+0x2c/0x84
>   kthread_bind_mask from wake_up_and_wait_for_irq_thread_ready+0x3c/0xd4
>   wake_up_and_wait_for_irq_thread_ready from __setup_irq+0x3e8/0x894

Hmm. The only explaination for that is that the thread got woken up
already and left the initial UNINTERRUPTIBLE state and is now waiting
for an interrupt wakeup with INTERRUPTIBLE state.

To validate that theory, can you please apply the patch below? The extra
warning I added should trigger first.

Let me think about a proper cure...

Thanks,

        tglx
---
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -615,6 +615,8 @@ static void __kthread_bind(struct task_s
 void kthread_bind_mask(struct task_struct *p, const struct cpumask *mask)
 {
 	struct kthread *kthread = to_kthread(p);
+
+	WARN_ON_ONCE(kthread->started);
 	__kthread_bind_mask(p, mask, TASK_UNINTERRUPTIBLE);
 	WARN_ON_ONCE(kthread->started);
 }
@@ -631,6 +633,8 @@ void kthread_bind_mask(struct task_struc
 void kthread_bind(struct task_struct *p, unsigned int cpu)
 {
 	struct kthread *kthread = to_kthread(p);
+
+	WARN_ON_ONCE(kthread->started);
 	__kthread_bind(p, cpu, TASK_UNINTERRUPTIBLE);
 	WARN_ON_ONCE(kthread->started);
 }



  parent reply	other threads:[~2025-11-20 13:45 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-18 14:30 [PATCH 0/2] genirq: Fix IRQ threads VS cpuset Frederic Weisbecker
2025-11-18 14:30 ` [PATCH 1/2] genirq: Fix IRQ threads affinity VS cpuset isolated partitions Frederic Weisbecker
2025-11-18 15:26   ` [tip: irq/core] genirq: Fix interrupt threads affinity vs. " tip-bot2 for Frederic Weisbecker
2025-11-18 16:27   ` [PATCH 1/2] genirq: Fix IRQ threads affinity VS " Waiman Long
2025-11-18 17:23     ` Thomas Gleixner
2025-11-18 17:29       ` Waiman Long
2025-11-20 11:51   ` Marek Szyprowski
2025-11-20 13:20     ` Frederic Weisbecker
2025-11-20 15:00       ` Thomas Gleixner
2025-11-20 15:50         ` Frederic Weisbecker
2025-11-20 19:09           ` Thomas Gleixner
2025-11-20 16:34         ` Marek Szyprowski
2025-11-20 13:45     ` Thomas Gleixner [this message]
2025-11-18 14:30 ` [PATCH 2/2] genirq: Remove cpumask availability check on kthread affinity setting Frederic Weisbecker
2025-11-18 15:26   ` [tip: irq/core] " tip-bot2 for Frederic Weisbecker
2025-11-18 15:14 ` [PATCH 0/2] genirq: Fix IRQ threads VS cpuset Thomas Gleixner
2025-11-18 17:44   ` Frederic Weisbecker

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=87y0o0keci.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=cgroups@vger.kernel.org \
    --cc=frederic@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=llong@redhat.com \
    --cc=m.szyprowski@samsung.com \
    --cc=marco.crivellari@suse.com \
    /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