Re: BUG: possible deadlock in __ata_sff_interrupt

[Damien Le Moal]

On 8/27/24 05:46, Juefei Pu wrote:
> Hello,
> We found the following issue using syzkaller on Linux v6.10.

Can you run the same against the latest 6.13-rc2 ?

> A possible deadlock issue was discovered in function
> `__ata_sff_interrupt` when it attempted to acquire lock `host->lock`.
> 
> Unfortunately, the syzkaller failed to generate a reproducer.
> But at least we have the report:
> 
> sr 1:0:0:0: [sr0] tag#0 FAILED Result: hostbyte=DID_ERROR
> driverbyte=DRIVER_OK cmd_age=0s
> sr 1:0:0:0: [sr0] tag#0 CDB: opcode=0x98 98 61 1e 1d 47 a1 77 90 29 76
> 7f 40 b8 5e 03 63
> =====================================================
> WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
> 6.10.0 #13 Not tainted
> -----------------------------------------------------
> syz.1.961/19801 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
> ffff88802d3a4018 (&new->fa_lock){....}-{2:2}, at: kill_fasync_rcu
> fs/fcntl.c:1028 [inline]
> ffff88802d3a4018 (&new->fa_lock){....}-{2:2}, at:
> kill_fasync+0x196/0x4d0 fs/fcntl.c:1049
> 
> and this task is already holding:
> ffff88801ca06018 (&host->lock){-.-.}-{2:2}, at:
> ata_scsi_queuecmd+0x8a/0x520 drivers/ata/libata-scsi.c:4197
> which would create a new lock dependency:
>  (&host->lock){-.-.}-{2:2} -> (&new->fa_lock){....}-{2:2}

[...]

> Chain exists of:
>   &host->lock --> &new->fa_lock --> tasklist_lock
> 
>  Possible interrupt unsafe locking scenario:
> 
>        CPU0                    CPU1
>        ----                    ----
>   lock(tasklist_lock);
>                                local_irq_disable();
>                                lock(&host->lock);
>                                lock(&new->fa_lock);
>   <Interrupt>
>     lock(&host->lock);

I fail to see how this can happen given that the first thing that
kill_fasync+0x196/0x4d0 fs/fcntl.c:1049 is "write_lock_irq(&fa->fa_lock);" so
IRQs are disabled... Lockdep is confused ?

-- 
Damien Le Moal
Western Digital Research