linux-kernel - Re: [PATCH] gpiolib: Don't implicitly disable irq when masking

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]

Date:   Wed, 10 May 2023 20:58:57 +0000
From:   Chris Packham <Chris.Packham@...iedtelesis.co.nz>
To:     "andy.shevchenko@...il.com" <andy.shevchenko@...il.com>
CC:     "linus.walleij@...aro.org" <linus.walleij@...aro.org>,
        "brgl@...ev.pl" <brgl@...ev.pl>,
        Ben Brown <Ben.Brown@...iedtelesis.co.nz>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Marc Zyngier <maz@...nel.org>
Subject: Re: [PATCH] gpiolib: Don't implicitly disable irq when masking

Hi Andy,

On 10/05/23 19:42, andy.shevchenko@...il.com wrote:
> Wed, May 10, 2023 at 12:11:51PM +1200, Chris Packham kirjoitti:
>> When preparing to kexec into a new kernel the kexec code will mask all
>> interrupts for all interrupt domains before disabling them. In the case
>> of a gpio chip which has a mix of gpio and irq pins a warning would be
>> triggered as follows
>>    [root@...alhost ~]# echo c >/proc/sysrq-trigger
> Besides the very noisy traceback in the commit message (read
> https://kernel.org/doc/html/latest/process/submitting-patches.html#backtraces-in-commit-messages)
> see below.
>
>> This is because gpiochip_irq_mask was being used to mask all possible
> We refer to the functions in the form as follows gpiochip_irq_mask().
>
>
>> irqs in the domain but gpiochip_disable_irq will WARN if any of those
> IRQs
> gpiochip_disable_irq()
>
>> gpios haven't been requested as interrupts yet. Remove the call to
> GPIOs
>
>> gpiochip_disable_irq to stop the warning.
> gpiochip_disable_irq()
Will take the above points onboard for v2.
>
>> Fixes: a8173820f441 ("gpio: gpiolib: Allow GPIO IRQs to lazy disable")
>> Signed-off-by: Chris Packham <chris.packham@...iedtelesis.co.nz>
>> ---
>>   drivers/gpio/gpiolib.c | 1 -
>>   1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
>> index 8c041a8dd9d8..903f5185ae55 100644
>> --- a/drivers/gpio/gpiolib.c
>> +++ b/drivers/gpio/gpiolib.c
>> @@ -1451,7 +1451,6 @@ static void gpiochip_irq_mask(struct irq_data *d)
>>   
>>   	if (gc->irq.irq_mask)
>>   		gc->irq.irq_mask(d);
>> -	gpiochip_disable_irq(gc, d->hwirq);
>>   }
> At the same time the gpiochip_irq_unmask() has the symmetrical call. Why?

Hmm you're right I never noticed that. I think that would also trigger a 
similar warning if it were ever hit. It's not hit in my use-case because 
nothing is running through all the irq domains unmasking interrupts.

The coupling of gpiochip_irq_mask()/gpiochip_irq_unmask() with 
gpiochip_disable_irq()/gpiochip_enable_irq() goes back to the same 
commit a8173820f441 ("gpio: gpiolib: Allow GPIO IRQs to lazy disable"). 
It's not immediately obvious to me why the coupling is needed. I was 
hoping that someone seeing my patch would confirm that it's not needed 
or say why it's needed suggest an alternative approach.

> Also it's obvious that you have used outdated repository. You need to rebase
> against subsystem tree for-next branch.
Yeah that's the tricky part. I'm currently based on lts-5.15 and in 
order to actually test this I need all of the support for my platform so 
I can use kdump to demonstrate the issue. I might be able to use a 
different platform that is already supported in a newer kernel
>
> P.S. It's also makes sense to Cc to Marc Zyngier <maz@...nel.org>.
>
Added.