linux-kernel - Re: [PATCH] gpio: timberdale: Fix potential deadlock on &tgpio->lock

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:   Tue, 26 Sep 2023 15:58:09 +0300
From:   Andy Shevchenko <andy@...nel.org>
To:     Chengfeng Ye <dg573847474@...il.com>
Cc:     linus.walleij@...aro.org, brgl@...ev.pl, alex@...uggie.ro,
        aboutphysycs@...il.com, linux-gpio@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] gpio: timberdale: Fix potential deadlock on &tgpio->lock

On Tue, Sep 26, 2023 at 10:29:14AM +0000, Chengfeng Ye wrote:
> As timbgpio_irq_enable()/timbgpio_irq_disable() callback could be
> executed under irq context, it could introduce double locks on
> &tgpio->lock if it preempts other execution units requiring
> the same locks.
> 
> timbgpio_gpio_set()
> --> timbgpio_update_bit()
> --> spin_lock(&tgpio->lock)
> <interrupt>
>    --> timbgpio_irq_disable()
>    --> spin_lock_irqsave(&tgpio->lock)
> 
> This flaw was found by an experimental static analysis tool I am
> developing for irq-related deadlock.
> 
> To prevent the potential deadlock, the patch uses spin_lock_irqsave()
> on &tgpio->lock inside timbgpio_gpio_set() to prevent the possible
> deadlock scenario.

Okay, makes sense.
Reviewed-by: Andy Shevchenko <andy@...nel.org>

Question to the users of this hardware if they ever want to have this IRQ chip
in the RT environment. In that case the locking type needs to be raw.

-- 
With Best Regards,
Andy Shevchenko