[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y50BqT3nSF7+JEzt@ZenIV>
Date: Fri, 16 Dec 2022 23:39:21 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Damien Le Moal <damien.lemoal@...nsource.wdc.com>,
Wei Chen <harperchen1110@...il.com>, linux-ide@...r.kernel.org,
linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com,
syzbot <syzkaller@...glegroups.com>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Chuck Lever <chuck.lever@...cle.com>,
Jeff Layton <jlayton@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Boqun Feng <boqun.feng@...il.com>
Subject: Re: possible deadlock in __ata_sff_interrupt
[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@...iv.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.
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?
Powered by blists - more mailing lists