Re: [PATCH v2 00/14] Sort out fsnotify_nameremove() mess

[Al Viro <viro@zeniv.linux.org.uk>]

On Thu, May 16, 2019 at 04:56:20PM +0300, Amir Goldstein wrote:

> > Why is this a cleanup? detach_groups() is used also from
> > configfs_detach_group() which gets called from configfs_rmdir() which is
> > real deletion.
> 
> True, configfs is a special case where both cleanup and real deletion
> use the same helper. configfs_detach_group() is either called for cleanup
> or from vfs_rmdir->configfs_rmdir()/configfs_unregister_{group,subsystem}()
> the latter 3 cases have new fsnotify hooks.

FWIW, I've an old series on configfs, from the "deal with kernel-side rm -rf
properly" pile.

I'll try to resurrect and post it.  A _lot_ of locking crap in there is
due to the bad idea of having the subtree being built reachable from
root as we are putting it together; massaging it to the form when we
build a subtree and move it in place only when we are past the last
failure makes for much simpler logics, for obvious reasons.  The massage
is not trivial, though.

In general, the problem with kernel-side recursive removals is that
a bunch of places are trying to cobble local solutions for the problem
that is actually a missing primitive.  And fucking it up in all kinds
of ways.  We definitely want a unified primitive for that; the question
is what kind of API would be kludge-free for callers.

I've a pile of notes and half-assed patch series in that direction;
I'll dig it out and try to get something coherent out of it.