On 8 Jan 2023 20:11:55 +0900 Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> > On 2023/01/04 13:01, Hillf Danton wrote: > > > > syz-executor330/3631 kworker/0:1H/120 > > --- --- > > down_write_nested(&s->s_umount); > > glock_work_func() > > down_write(&sb->s_umount); > > flush_workqueue(glock_workqueue); > > > > > > No deadlock is reported yet. Whyyy? > > See if extending the aperture of wq->lockdep_map can catch it. > > As far as I tested, this patch did not change likeliness of hitting lockdep warning. > I feel that it was just by chance that this test request was able to hit lockdep warning. cpu0 cpu1 --- --- lock A work B runs a) lock_map_acquire(&wq->lockdep_map); __flush_workqueue lock_map_acquire(&wq->lockdep_map); lock_map_release(&wq->lockdep_map); b) lock_map_acquire(&wq->lockdep_map); lock A Currently report of deadlock escapes in mode b) because worker takes workqueue lockdep_map after flusher releases it. After this change, mode b) could be caught with no exception. cpu0 cpu1 --- --- lock A work B runs a) lock_map_acquire(&wq->lockdep_map); __flush_workqueue lock_map_acquire(&wq->lockdep_map); b) lock_map_acquire(&wq->lockdep_map); lock A
