[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <80dc24c5-2c4c-b8da-5017-31aae65a4dfa@opensource.wdc.com>
Date: Fri, 16 Dec 2022 10:44:06 +0900
From: Damien Le Moal <damien.lemoal@...nsource.wdc.com>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: 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>
Subject: Re: possible deadlock in __ata_sff_interrupt
On 12/16/22 00:19, Al Viro wrote:
> On Thu, Dec 15, 2022 at 06:48:20PM +0900, Damien Le Moal wrote:
>
>> The problem is here: sg_rq_end_io() calling kill_fasync(). But at a quick
>> glance, this is not the only driver calling kill_fasync() with a spinlock
>> held with irq disabled... So there may be a fundamental problem with
>> kill_fasync() function if drivers are allowed to do that, or the reverse,
>> all drivers calling that function with a lock held with irq disabled need
>> to be fixed.
>>
>> Al, Chuck, Jeff,
>>
>> Any thought ?
>
> What is the problem with read_lock_irqsave() called with irqs disabled?
> read_lock_irq() would have been a bug in such conditions, of course, but
> that's not what we use...
The original & complete lockdep splat is in the report email here:
https://marc.info/?l=linux-ide&m=167094379710177&w=2
It looks like a spinlock is taken for the fasync stuff without irq
disabled and that same spinlock is needed in kill_fasync() which is
itself called (potentially) with IRQ disabled. Hence the splat. In any
case, that is how I understand the issue. But as mentioned above, given
that I can see many drivers calling kill_fasync() with irq disabled, I
wonder if this is a genuine potential problem or a false negative.
--
Damien Le Moal
Western Digital Research
Powered by blists - more mailing lists