On Fri, Nov 15, 2019 at 10:10:37PM +0000, Al Viro wrote: > I'll probably throw that into #next.dcache - if nothing else, > that cuts down on the size of patch converting d_subdirs/d_child > from list to hlist... > > Need to get some sleep first, though - only 5 hours today, so > I want to take another look at that thing tomorrow morning - > I don't trust my ability to spot obvious bugs right now... ;-/ > > Oh, well - that at least might finally push the old "kernel-side > rm -rf done right" pile of half-baked patches into more useful > state, probably superseding most of them. Curious... Is there any point keeping debugfs_remove() and debugfs_remove_recursive() separate? The thing is, the only case when their behaviours differ is when the victim is non-empty. In that case the former quietly does nothing; the latter (also quietly) removes the entire subtree. And the caller has no way to tell if that case has happened - they can't even look at the dentry they'd passed, since in the normal case it's already pointing to freed (and possibly reused) memory by that point. The same goes for tracefs, except that there we have only one caller of tracefs_remove(), and it's guaranteed to be a non-directory. So there we definitely can fold them together. Greg, could we declare debufs_remove() to be an alias for debugfs_remove_recursive()?
