Messages in this thread | | | Date | Wed, 25 May 2022 06:17:38 -0700 | From | Piyush Malgujar <> | Subject | Re: [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> > > ---
| |