On Fri, Nov 15, 2019 at 08:38:13AM -0500, Steven Rostedt wrote: > On Fri, 15 Nov 2019 13:16:25 +0000 > Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > > I want to understand the overall situation. No argument, list_empty() > > in there is BS, for many reasons. But I wonder if trying to keep the > > current structure of the iterator _and_ the use of simple_rmdir()/simple_unlink() > > is the right approach. > > My guess is that debugfs was written to be as simple as possible. > Nothing too complex. And in doing so, may have issues as you are > pointing out. Just a way to allow communications between user space and > kernel space (as tracefs started out). > > BTW, what do you mean by "can debugfs_remove_recursive() rely upon the > lack of attempts to create new entries inside the subtree it's trying > to kill?" Is it possible for something to call e.g. debugfs_create_dir() (or any similar primitive) with parent inside the subtree that has been passed to debugfs_remove_recursive() call that is still in progress? If debugfs needs to cope with that, debugfs_remove_recursive() needs considerably heavier locking, to start with.
