On Sat, 2023-12-02 at 15:37 +0900, Sergey Senozhatsky wrote: > On (23/11/09 22:22), Johannes Berg wrote: > > From: Johannes Berg <johannes.berg@xxxxxxxxx> > > > > When you take a lock in a debugfs handler but also try > > to remove the debugfs file under that lock, things can > > deadlock since the removal has to wait for all users > > to finish. > > > > Add lockdep annotations in debugfs_file_get()/_put() > > to catch such issues. > > So this triggers when I reset zram device (zsmalloc compiled with > CONFIG_ZSMALLOC_STAT). I shouldn't have put that into the rc, that was more or less an accident. I think I'll do a revert. > debugfs_create_file() and debugfs_remove_recursive() are called > under zram->init_lock, and zsmalloc never calls into zram code. > What I don't really get is where does the > `debugfs::classes -> zram->init_lock` > dependency come from? "debugfs:classes" means a file is being accessed and "classes" is the name, so that's static int zs_stats_size_show(struct seq_file *s, void *v) which uses seq_file, so there we have a seq_file lock. I think eventually the issue is that lockdep isn't telling the various seq_file instances apart, and you have one that's removed under lock (classes) and another one that's taking the lock (reset). Anyway, I'll send a revert, don't think this is ready yet. I was fixing the wireless debugfs lockdep and had used that to debug it. johannes
