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. Alan Stern
