lkml.org 
[lkml]   [2022]   [Dec]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: possible deadlock in __ata_sff_interrupt
On Fri, Dec 16, 2022 at 11:39:21PM +0000, Al Viro wrote:
> [Boqun Feng Cc'd]
>
> On Fri, Dec 16, 2022 at 03:26:21AM -0800, Linus Torvalds wrote:
> > On Thu, Dec 15, 2022 at 7:41 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
> > >
> > > CPU1: ptrace(2)
> > > ptrace_check_attach()
> > > read_lock(&tasklist_lock);
> > >
> > > CPU2: setpgid(2)
> > > write_lock_irq(&tasklist_lock);
> > > spins
> > >
> > > CPU1: takes an interrupt that would call kill_fasync(). grep and the
> > > first instance of kill_fasync() is in hpet_interrupt() - it's not
> > > something exotic. IRQs disabled on CPU2 won't stop it.
> > > kill_fasync(..., SIGIO, ...)
> > > kill_fasync_rcu()
> > > read_lock_irqsave(&fa->fa_lock, flags);
> > > send_sigio()
> > > read_lock_irqsave(&fown->lock, flags);
> > > read_lock(&tasklist_lock);
> > >
> > > ... and CPU1 spins as well.
> >
> > Nope. See kernel/locking/qrwlock.c:
>
> [snip rwlocks are inherently unfair, queued ones are somewhat milder, but
> all implementations have writers-starving behaviour for read_lock() at least
> when in_interrupt()]
>
> D'oh... Consider requested "Al, you are a moron" duly delivered... I plead
> having been on way too low caffeine and too little sleep ;-/
>
> Looking at the original report, looks like the scenario there is meant to be
> the following:
>
> CPU1: read_lock(&tasklist_lock)
> tasklist_lock grabbed
>
> CPU2: get an sg write(2) feeding request to libata; host->lock is taken,
> request is immediately completed and scsi_done() is about to be called.
> host->lock grabbed
>
> CPU3: write_lock_irq(&tasklist_lock)
> spins on tasklist_lock until CPU1 gets through.
>
> CPU2: get around to kill_fasync() called by sg_rq_end_io() and to grabbing
> tasklist_lock inside send_sigio()
> spins, since it's not in an interrupt and there's a pending writer
> host->lock is held, spin until CPU3 gets through.

Right, for a reader not in_interrupt(), it may be blocked by a random
waiting writer because of the fairness, even the lock is currently held
by a reader:

CPU 1 CPU 2 CPU 3
read_lock(&tasklist_lock); // get the lock

write_lock_irq(&tasklist_lock); // wait for the lock

read_lock(&tasklist_lock); // cannot get the lock because of the fairness

Regards,
Boqun

>
> CPU1: take an interrupt, which on libata will try to grab host->lock
> tasklist_lock is held, spins on host->lock until CPU2 gets through
>
> Am I reading it correctly?

\
 
 \ /
  Last update: 2022-12-17 00:55    [W:0.198 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site