linux-kernel - Re: [PATCH for next v1 1/2] gpio: omap: Replace raw_spin_lock_irqsave with raw_spin_lock in omap_gpio_irq

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: <d5465b81-bb53-49ee-a556-40d208deb765@ti.com>
Date:   Thu, 11 Feb 2021 22:16:49 +0200
From:   Grygorii Strashko <grygorii.strashko@...com>
To:     Arnd Bergmann <arnd@...nel.org>
CC:     Luo Jiaxing <luojiaxing@...wei.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Santosh Shilimkar <ssantosh@...nel.org>,
        Kevin Hilman <khilman@...nel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        <linuxarm@...neuler.org>
Subject: Re: [PATCH for next v1 1/2] gpio: omap: Replace raw_spin_lock_irqsave
 with raw_spin_lock in omap_gpio_irq_handler()



On 11/02/2021 21:39, Arnd Bergmann wrote:
> On Thu, Feb 11, 2021 at 7:25 PM Grygorii Strashko
> <grygorii.strashko@...com> wrote:
>> On 08/02/2021 10:56, Luo Jiaxing wrote:
>>> There is no need to use API with _irqsave in omap_gpio_irq_handler(),
>>> because it already be in a irq-disabled context.
>>
>> NACK.
>> Who said that this is always hard IRQ handler?
>> What about RT-kernel or boot with "threadirqs"?
> 
> In those cases, the interrupt handler is just a normal thread, so the
> preempt_disable() that is implied by raw_spin_lock() is sufficient.
> 
> Disabling interrupts inside of an interrupt handler is always incorrect,
> the patch looks like a useful cleanup to me, if only for readability.

Note. there is also generic_handle_irq() call inside.

-- 
Best regards,
grygorii