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] [day] [month] [year] [list]

Message-ID: <a69abd18ea5a30fdb32478183ad16d9aaacd73a3.camel@linux.intel.com>
Date: Sun, 08 Feb 2026 18:00:53 -0800
From: srinivas pandruvada <srinivas.pandruvada@...ux.intel.com>
To: Jonathan Cameron <jic23@...nel.org>, 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>, 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 Sat, 2026-02-07 at 15:46 +0000, Jonathan Cameron wrote:
> 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.

Replacing with devm_iio_kfifo_buffer_setup_ext() breaks user space on
laptops as they expect current_trigger. This is not available for
INDIO_BUFFER_SOFTWARE. Using INDIO_BUFFER_TRIGGERED doesn't help
without poll function. Still breaks user space. This all works from
Linux 3.1x in this mode.

Sensors are powered off till user space writes to current_trigger which
results in call to .set_trigger_state() via
iio_trigger_attach_poll_func(). 

Here the hub is pushing data, not pulled to register a thread handler
and read.

So not sure what to add to thread handler other than dummy function.
 

Thanks,
Srinivas

> 
> 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