linux-kernel - Re: [PATCH 1/3 v3] genirq: Prevent from early irq thread spurious wake-ups

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aSDh8q_UdNtU3KZN@pavilion.home>
Date: Fri, 21 Nov 2025 23:04:34 +0100
From: Frederic Weisbecker <frederic@...nel.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: LKML <linux-kernel@...r.kernel.org>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	Marco Crivellari <marco.crivellari@...e.com>,
	Waiman Long <llong@...hat.com>, cgroups@...r.kernel.org
Subject: Re: [PATCH 1/3 v3] genirq: Prevent from early irq thread spurious
 wake-ups

Le Fri, Nov 21, 2025 at 08:12:38PM +0100, Thomas Gleixner a écrit :
> On Fri, Nov 21 2025 at 15:34, Frederic Weisbecker wrote:
> > During initialization, the IRQ thread is created before the IRQ get a
> > chance to be enabled. But the IRQ enablement may happen before the first
> > official kthread wake up point. As a result, the firing IRQ can perform
> > an early wake-up of the IRQ thread before the first official kthread
> > wake up point.
> >
> > Although this has happened to be harmless so far, this uncontrolled
> > behaviour is a bug waiting to happen at some point in the future with
> > the threaded handler accessing halfway initialized states.
> 
> No. At the point where the first wake up can happen, the state used by
> the thread is completely initialized. That's right after setup_irq()
> drops the descriptor lock. Even if the hardware raises it immediately on
> starting the interrupt up, the handler is stuck on the descriptor lock,
> which is not released before everything is ready.
> 
> That kthread_bind() issue is a special case as it makes the assumption
> that the thread is still in that UNINTERRUPTIBLE state waiting for the
> initial wake up. That assumption is only true, when the thread creator
> guarantees that there is no wake up before kthread_bind() is invoked.
> 
> I'll rephrase that a bit. :)

Eh, thanks and sorry for the misinterpretation.

-- 
Frederic Weisbecker
SUSE Labs