linux-kernel - Re: [PATCH] genirq: Simplify the check for __irq_get_desc

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a75c2818-11eb-3f78-1699-94a5b10ef232@huawei.com>
Date: Tue, 7 May 2024 09:16:07 +0800
From: Jinjie Ruan <ruanjinjie@...wei.com>
To: Thomas Gleixner <tglx@...utronix.de>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] genirq: Simplify the check for __irq_get_desc_lock()



On 2024/5/7 1:55, Thomas Gleixner wrote:
> On Mon, May 06 2024 at 20:50, Jinjie Ruan wrote:
> 
>> If it set "_IRQ_DESC_PERCPU" in "check" but the desc is not percpu, or if
>> the desc is percpu but it not set "_IRQ_DESC_PERCPU" in "check", it both
>> return NULL, so simplify the check in __irq_get_desc_lock() with "!=".
> 
> What is exactly simplified here?
> 
>> Signed-off-by: Jinjie Ruan <ruanjinjie@...wei.com>
>> ---
>>  kernel/irq/irqdesc.c | 6 +-----
>>  1 file changed, 1 insertion(+), 5 deletions(-)
>>
>> diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
>> index 88ac3652fcf2..6c52deb134b9 100644
>> --- a/kernel/irq/irqdesc.c
>> +++ b/kernel/irq/irqdesc.c
>> @@ -882,11 +882,7 @@ __irq_get_desc_lock(unsigned int irq, unsigned long *flags, bool bus,
>>  
>>  	if (desc) {
>>  		if (check & _IRQ_DESC_CHECK) {
>> -			if ((check & _IRQ_DESC_PERCPU) &&
>> -			    !irq_settings_is_per_cpu_devid(desc))
>> -				return NULL;
>> -
>> -			if (!(check & _IRQ_DESC_PERCPU) &&
>> +			if (!!(check & _IRQ_DESC_PERCPU) !=
>>  			    irq_settings_is_per_cpu_devid(desc))
>>  				return NULL;
> 
> The existing code is readable and obvious. This is not.

Thank you for your review. The existing code is indeed clear, but it
seems that both judgments are checking whether the percpu flags are
consistent.

> 
> Thanks,
> 
>         tglx