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
