On Sun, Nov 17, 2019 at 10:24:22PM +0000, Al Viro wrote: > 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()? Yes, we can do that there's no reason to keep those separate at all. Especially if it makes things easier overall. thanks, greg k-h
