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
