Re: [PATCH 1/2] genirq: Fix IRQ threads affinity VS cpuset isolated partitions

[Frederic Weisbecker <frederic@kernel.org>]

Le Thu, Nov 20, 2025 at 12:51:31PM +0100, Marek Szyprowski a écrit :
> On 18.11.2025 15:30, Frederic Weisbecker wrote:
> > When a cpuset isolated partition is created / updated or destroyed,
> > the IRQ threads are affine blindly to all the non-isolated CPUs. And
> > this happens without taking into account the IRQ thread initial
> > affinity that becomes ignored.
> >
> > For example in a system with 8 CPUs, if an IRQ and its kthread are
> > initially affine to CPU 5, creating an isolated partition with only
> > CPU 2 inside will eventually end up affining the IRQ kthread to all
> > CPUs but CPU 2 (that is CPUs 0,1,3-7), losing the kthread preference for
> > CPU 5.
> >
> > Besides the blind re-affinity, this doesn't take care of the actual
> > low level interrupt which isn't migrated. As of today the only way to
> > isolate non managed interrupts, along with their kthreads, is to
> > overwrite their affinity separately, for example through /proc/irq/
> >
> > To avoid doing that manually, future development should focus on
> > updating the IRQs affinity whenever cpuset isolated partitions are
> > updated.
> >
> > 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

Erm, does this means that the IRQ thread got awaken before the first official
wakeup in wake_up_and_wait_for_irq_thread_ready()? This looks wrong...

irq_startup() may be called on a few occcasions before. So perhaps
the IRQ already fired and woke up the kthread once before the "official"
first wake up?

There seem to be some initialization ordering issue here...

Thomas?

Thanks.
-- 
Frederic Weisbecker
SUSE Labs