On Sat, 4 Feb 2023 10:40:52 -0500 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> > 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@xxxxxxxxxxxxxxxxxxxx > > 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
