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: <20260121103921.q-r7pAzL@linutronix.de>
Date: Wed, 21 Jan 2026 11:39:21 +0100
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: Hans de Goede <hansg@...nel.org>
Cc: "Borah, Chaitanya Kumar" <chaitanya.kumar.borah@...el.com>,
	"Kurmi, Suresh Kumar" <suresh.kumar.kurmi@...el.com>,
	"Saarinen, Jani" <jani.saarinen@...el.com>,
	"intel-gfx@...ts.freedesktop.org" <intel-gfx@...ts.freedesktop.org>,
	"intel-xe@...ts.freedesktop.org" <intel-xe@...ts.freedesktop.org>,
	linux-kernel@...r.kernel.org, linux-rt-devel@...ts.linux.dev,
	sfr@...b.auug.org.au, ilpo.jarvinen@...ux.intel.com,
	regressions@...mhuis.info
Subject: Re: REGRESSION on linux-next (next-20260115)

On 2026-01-21 11:20:53 [+0100], Hans de Goede wrote:
> Hi,
Hi,

> Right, so as the commit message of commit 8f812373d195 ("platform/x86: intel:
> int0002_vgpio: Pass IRQF_ONESHOT to request_irq()") explains
> the int0002_vgpio driver *must* use the same flags to request
> the IRQ as the ACPI core does, which is why it passes IRQF_ONESHOT
> even though it does not have a threaded handler.
> 
> This worked fine until commit aef30c8d569c ("genirq: Warn about using
> IRQF_ONESHOT without a threaded handler") as Chaitanya's bisect
> pointed out.

Avoiding forced-threading on the int0002_vgpio handler is actually a
problem on PREEMPT_RT. But yeah no complains from the stack.

> Sebastian as I agree that switching to IRQF_COND_ONESHOT on
> the int0002_vgpio.c side is a good way to fix this.
> 
> But If I'm reading your proposed changes correct then your suggestion
> is to drop IRQF_ONESHOT from int0002_vgpio.c and then instead of
> replacing it with IRQF_COND_ONESHOT you want to always pass
> IRQF_COND_ONESHOT when using the non-threaded request_irq functions?

Correct.

> I'm not objecting against this, just making sure I understand
> correctly.
> 
> Note in that case you should also add this to the non devm_
> prefixed version.

You mean request_irq() as it has been done in commit
   c37927a203fa2 ("genirq: Set IRQF_COND_ONESHOT in request_irq()")

or did I miss yet another wrapper?

> Regards,
> 
> Hans

Sebastian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ