On Sat, 2023-12-02 at 15:37 +0900, Sergey Senozhatsky wrote:
> On (23/11/09 22:22), Johannes Berg wrote:
> > From: Johannes Berg <[email protected]>
> >
> > 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