On Wed, May 25, 2022 at 3:17 PM Piyush Malgujar <pmalgujar@xxxxxxxxxxx> wrote: > > 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@xxxxxxxxxxx> 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@xxxxxxxxxxx> > > > --- Thanks. What I meant exactly was: resend it with that info in the commit message. Bart