linux-kernel - Re: [PATCH 1/2] linux/interrupt.h: allow "guard" notation to disable and reenable IRQ with valid IRQ check

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: <701e739d-2e82-40e7-87b5-b4ec92903af6@mailbox.org>
Date: Wed, 28 Jan 2026 13:23:42 +0100
From: Marek Vasut <marek.vasut@...lbox.org>
To: Thomas Gleixner <tglx@...nel.org>, linux-input@...r.kernel.org
Cc: "Peter Zijlstra (Intel)" <peterz@...radead.org>,
 Cheng-Yang Chou <yphbchou0911@...il.com>,
 Dmitry Torokhov <dmitry.torokhov@...il.com>, Frank Li <Frank.Li@....com>,
 Geert Uytterhoeven <geert+renesas@...der.be>,
 Jinjie Ruan <ruanjinjie@...wei.com>,
 Krzysztof Kozlowski <krzysztof.kozlowski@....qualcomm.com>,
 Marc Zyngier <maz@...nel.org>,
 Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
 linux-kernel@...r.kernel.org, linux-renesas-soc@...r.kernel.org
Subject: Re: [PATCH 1/2] linux/interrupt.h: allow "guard" notation to disable
 and reenable IRQ with valid IRQ check

On 1/27/26 10:14 AM, Thomas Gleixner wrote:
> On Thu, Jan 22 2026 at 00:23, Marek Vasut wrote:
> 
> $Subject: linux/interrupt.h is not a proper prefix. Just use 'genirq:'
> 
> Also what means 'allow ....'? Subject lines should provide a concise
> summary of the change, i.e. something like:
> 
>          Provide conditional disable_irq guard variant

I did admittedly replicate the subject and tags from prior commit

c76494768761 ("linux/interrupt.h: allow "guard" notation to disable and 
reenable IRQ")

Fixed, thanks.

>> Introduce disable_valid_irq scoped guard. This is an extension
>> of disable_irq scoped guard, which disables and enables IRQs
>> around a scope. The disable_valid_irq scoped guard does almost
>> the same, except it handles the case where IRQ is not valid,
>> in which case it does not do anything. This is meant to be used
>> by for example touch controller drivers, which can do both IRQ
>> driven and polling mode of operation, and this makes their code
>> slighly simpler.
> 
> How many of those have this pattern? From a cursory look I found not
> even one as your example is neither applicable to upstream nor to next.

One. I think I have two-ish more candidates for conversion.

>> +static inline void disable_valid_irq(unsigned int irq)
>> +{
>> +	if (irq > 0)
>> +		disable_irq(irq);
>> +}
>> +
>> +static inline void enable_valid_irq(unsigned int irq)
>> +{
>> +	if (irq > 0)
>> +		enable_irq(irq);
>> +}
>> +
>> +DEFINE_LOCK_GUARD_1(disable_valid_irq, int,
> 
> 'int' because it matches the function argument type of the inlines,
> right?
> 
>> +		    disable_valid_irq(*_T->lock), enable_valid_irq(*_T->lock))
> 
> disable_valid_irq is a pretty non-intuitive name if you look at it just
> by reading a usage site. It's not really improving the readability of
> the code, it's in fact obscuring it as the reader has to actually look
> up what the hell this means and then stumble upon a completely
> undocumented lock guard define.
> 
> I'm all for using guards, but using guards just for the sake of using
> guards is not a really good approach.
I wouldn't even be opposed to converting the ili2xxx driver (the piece 
of code in patch 2/2 of this series) back to simple enable/disable_irq() 
. I am not particularly on board even with the disable_irq lock guard, 
or more specifically, lock guard used for non-lock things like this.