linux-kernel - Re: [tip: irq/core] genirq: Warn about using IRQF

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: <20260207154638.30f3b47b@jic23-huawei>
Date: Sat, 7 Feb 2026 15:46:38 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: Bert Karwatzki <spasswolf@....de>, linux-kernel@...r.kernel.org,
 linux-iio@...r.kernel.org, Jiri Kosina <jikos@...nel.org>, Srinivas
 Pandruvada <srinivas.pandruvada@...ux.intel.com>, Thomas Gleixner
 <tglx@...nel.org>, Laurent Pinchart <laurent.pinchart@...asonboard.com>
Subject: Re: [tip: irq/core] genirq: Warn about using IRQF_ONESHOT without a
 threaded handler

On Tue, 3 Feb 2026 15:58:56 +0100
Sebastian Andrzej Siewior <bigeasy@...utronix.de> wrote:

> On 2026-02-03 11:43:53 [+0100], Bert Karwatzki wrote:
> > Yes, this should call warn_no_thread() when the interrupt is triggered, but
> > I don't know if these sensors are actually functional on my laptop (I've never
> > tried to use them).
> > 
> > So I installed libiio-utils from debian and this is the output from
> > iio_info:  
> …
> > 
> > The iio:device* sensors all report 0 for the "offset value", so these
> > sensors are maybe non-fuctional.
> > 
> >   
> > > What did I miss?  
> > 
> > I don't think you missed something, but the thread function being NULL here
> > could a problem on devices where these sensors actually work. (Or perhaps these sensors
> > need to be polled and the interrupts never trigger (?))  
> 
> I only found one handler where the thread handler was NULL and it
> returned WAKE_THREAD. So this _is_ broken.
> Was it one of the driver I mentioned? If so I suggest to fix those
> first. I have no idea how this should work…
Both the drivers that are called out in this discussion look to
be registering a triggered buffer, but are not using a trigger to fill
it. So they should not be doing that in the first place.

The right fix is either to not use those helpers at all and register
the kfifo directly (so none of the problem infrastructure is used) or
implement a proper trigger / buffer separation by having their interrupt
handlers as the trigger then moving the data reading into the pollfuncs.
At that point there would be a thread here to do that read and we'd
not have the bug.

Jonathan

> 
> > Bert Karwatzki  
> 
> Sebastian