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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ