Re: Converting dev->mutex into dev->spinlock ?

[Hillf Danton <hdanton@sina.com>]

On Sat, 4 Feb 2023 10:40:52 -0500 Alan Stern <stern@rowland.harvard.edu>
> On Sun, Feb 05, 2023 at 12:30:07AM +0900, Tetsuo Handa wrote:
> > On 2023/02/05 0:12, Alan Stern wrote:
> > >>  it would solve many deadlocks in driver code if you can update
> > > 
> > > What deadlocks?  If there are so many deadlocks floating around in 
> > > driver code, why haven't we heard about them before now?
> > 
> > Since dev->mutex is hidden from lockdep checks, nobody can see lockdep warnings.
> > syzbot is reporting real deadlocks without lockdep warnings, for the fundamental
> > problem you mentioned in https://lkml.kernel.org/r/Pine.LNX.4.44L0.0804171117450.18040-100000@iolanthe.rowland.org
> > is remaining. I'm suggesting you that now is time to address this fundamental problem.
> 
> Maybe so.  But the place to address it is inside lockdep, not in the 
> driver core.
> 
> > >> (by e.g. replacing dev->mutex with dev->spinlock and dev->atomic_flags).
> > >> But I'm not familiar enough to propose such change...
> > > 
> > > Such a change cannot be made.  Consider this: Driver callbacks often
> > > need to sleep.  But when a thread holds a spinlock, it is not allowed to 
> > > sleep.  Therefore driver callbacks must not be invoked while a spinlock 
> > > is held.
> > 
> > What I'm suggesting is "Do not call driver callbacks with dev->mutex held,
> > by rewriting driver core code".
> 
> That cannot be done.  The only possible solution is to teach lockdep how 
> to handle recursive locking structures.

It works in dcache - see the slow path in dentry_kill() for instance.

Hillf