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@xxxxxxxxxxxxxxxxxx> 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?
