[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZRLVYWDc/3IRJBor@smile.fi.intel.com>
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
Powered by blists - more mailing lists