Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
IronPort-SDR: t55jqdCV3wBtN4/pD4zlk/x1thvNuQ8O9KI9LfZPpOjwfRE6MYOpMk4ClCshp9X8T//LqHC0Ml
 BQcC8W/HAxX3XFWAgC5BaD+6q2fvTTq2X95JuO4JpZXCMI2lsREFsLPHOgo0+KKkUZ+Zj4Y+gI
 T7UYxJUQvP2bjnS2pUeny7LsAcH+Hypn6SH6h8kM89JDGEpdwGhVk3V4qMxGTizU/ShIWCDWM2
 9WJBTsrTn4CvzARuLAOo4EtuFjSxnoYfXA0dKtnK4RmLx5LzK39YcKPJCU1R/gtsxuSbCCB4TW
 zjw=
IronPort-SDR: C+h7RS+sDhm/60syVsZobEIrsCTc+VQyvUvqc6oGRI9WW1wSVnNXyqcI1ysgHul9XH+yIqp6/B
 INa885yywMwNeIowrp5yFM2WG62FwhSQWjp0eu4s11wTs3/qFz3A85B39yomanTXDeLMgd9pmn
 YJjwkB9oH2XVH8jHkWPouo97Uobr/VLnuGGEhTrrhwt0v195YbqLHEdXbYWPTUuqbFUYotLTQ+
 ajzmw0eZAXHY2+0dBdEBxLmQ2vz32D6d45X/c3Cd3cohyqveeP2PlHFTCtj1DtVrFQdrwImOoy
 Sgs=
WDCIronportException: Internal
Message-ID: <80dc24c5-2c4c-b8da-5017-31aae65a4dfa@opensource.wdc.com>
Date:   Fri, 16 Dec 2022 10:44:06 +0900
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.5.1
Subject: Re: possible deadlock in __ata_sff_interrupt
Content-Language: en-US
To:     Al Viro <viro@zeniv.linux.org.uk>
Cc:     Wei Chen <harperchen1110@gmail.com>, linux-ide@vger.kernel.org,
        linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com,
        syzbot <syzkaller@googlegroups.com>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        Chuck Lever <chuck.lever@oracle.com>,
        Jeff Layton <jlayton@kernel.org>
References: <CAO4mrfcX8J73DWunmdYjf_SK5TyLfp9W9rmESTj57PCkG2qkBw@mail.gmail.com>
 <5eff70b8-04fc-ee87-973a-2099a65f6e29@opensource.wdc.com>
 <Y5s7F/4WKe8BtftB@ZenIV>
From:   Damien Le Moal <damien.lemoal@opensource.wdc.com>
Organization: Western Digital Research
In-Reply-To: <Y5s7F/4WKe8BtftB@ZenIV>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

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