lkml.org 
[lkml]   [2022]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/5] gpio: thunderx: avoid potential deadlock
On Mon, May 02, 2022 at 01:18:49PM +0200, Bartosz Golaszewski wrote:
> On Wed, Apr 27, 2022 at 4:46 PM Piyush Malgujar <pmalgujar@marvell.com> wrote:
> >
> > Using irqsave/irqrestore locking variants to avoid any deadlock.
> >
>
> I see you'll be resending this anyway so would you mind providing an
> example of a deadlock that is possible with no-irqsave variants?
> Thanks.
>
> Bart
>
Hi Bartosz,

Thanks for the review.

Please find below the issue scenario:
In the case when HARDIRQ-safe -> HARDIRQ-unsafe lock order is detected
and interrupt occurs, deadlock could occur.

========================================================
WARNING: possible irq lock inversion dependency detected
5.18.0-rc6 #4 Not tainted
--------------------------------------------------------
swapper/3/0 just changed the state of lock:
ffff000110904cd8 (lock_class){-...}-{2:2}, at: handle_fasteoi_ack_irq+0x2c/0x1b0
but this lock took another, HARDIRQ-unsafe lock in the past:
(&txgpio->lock){+.+.}-{2:2}


and interrupts could create inverse lock ordering between them.


other info that might help us debug this:
Possible interrupt unsafe locking scenario:

CPU0 CPU1
---- ----
lock(&txgpio->lock);
local_irq_disable();
lock(lock_class);
lock(&txgpio->lock);
<Interrupt>
lock(lock_class);

*** DEADLOCK ***

==========================================================

Thanks,
Piyush
> > Signed-off-by: Piyush Malgujar <pmalgujar@marvell.com>
> > ---

\
 
 \ /
  Last update: 2022-05-25 15:20    [W:0.140 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site