linux-kernel - Re: [PATCH] counter: interrupt-cnt: Drop IRQF_NO

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: <20251118100842.jPZMHpnF@linutronix.de>
Date: Tue, 18 Nov 2025 11:08:42 +0100
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: Oleksij Rempel <o.rempel@...gutronix.de>
Cc: "A. Sverdlin" <alexander.sverdlin@...mens.com>,
	Pengutronix Kernel Team <kernel@...gutronix.de>,
	linux-iio@...r.kernel.org, Ahmad Fatoum <a.fatoum@...gutronix.de>,
	"Paul E . McKenney" <paulmck@...nel.org>,
	linux-kernel@...r.kernel.org, stable@...r.kernel.org,
	Jonathan Cameron <Jonathan.Cameron@...wei.com>,
	William Breathitt Gray <wbg@...nel.org>
Subject: Re: [PATCH] counter: interrupt-cnt: Drop IRQF_NO_THREAD flag

On 2025-11-18 10:12:56 [+0100], Oleksij Rempel wrote:
> Hi Alexander,
Hi,

> > --- a/drivers/counter/interrupt-cnt.c
> > +++ b/drivers/counter/interrupt-cnt.c
> > @@ -229,8 +229,7 @@ static int interrupt_cnt_probe(struct platform_device *pdev)
> >  
> >  	irq_set_status_flags(priv->irq, IRQ_NOAUTOEN);
> >  	ret = devm_request_irq(dev, priv->irq, interrupt_cnt_isr,
> > -			       IRQF_TRIGGER_RISING | IRQF_NO_THREAD,
> > -			       dev_name(dev), counter);
> > +			       IRQF_TRIGGER_RISING, dev_name(dev), counter);
> >  	if (ret)
> >  		return ret;
> >  
> 
> Hm, I guess it will break the requirement to handle at least 10kHz
> interrupts. May be we should move only counter_push_event() to the
> thread? or using delayed worker?

IRQF_NO_THREAD only prohibits threading of interrupts on !RT if
threadirqs was specified on the boot command line. This should not
effect you general use case.
As the threaded interrupt runs as SCHED_FIFO-50 it will be preferred
over any SCHED_OTHER so it still should the most prefer task in the
system. 10kHz interrupt sounds like one interrupt every 100us. This
sounds like a lot if the CPU is also doing other things.
Anyway.

> Right now I do not have needed system for testing to come with better
> proposal.
> 
> Best Regards,
> Oleksij

Sebastian