Re: [git pull] configfs cleanups and fixes (with tag on correct branch now)

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

On Mon, Jun 15, 2026 at 11:44:23AM +0200, Andreas Hindborg wrote:

> Amazing!
> 
> I was sort of dreading having to go through all of this to make heads
> and tails of it, but I put it down as a task that I would have to do
> within the next few months.
> 
> I guess I did not have to worry about that. I am happy that I did not
> have to handle that, but I am also stumped that I did not have to handle
> that.

FWIW, configfs-related stuff I've got for the next cycle:
	* use ..._recursive_removal() for all removals
	* build new subtrees isolated, then move in place
	* kill the lockdep magic, since deep chains of locked directories
are no longer used
	* kill the "is it ready" thing
Those are already more or less linearized into #more.configfs - not the
final form, and there might be some reordering, but basically there.

In local branches, should go into the mix by -rc1:
	* saner waiting for mkdir in progress by rmdir et.al. - doing
that on inode lock for parent directory is not a good way to do it.
	* a bunch of cleanups.

Stuff yet to be figured out:
	configfs_depend_item{,_unlocked}() work; the rules for clients are
less than obvious and in the current form it's seriously racy.	The few
existing users (all 6 of them) _might_ be OK, but I've no idea where to
start with safety proofs on those.  That might end up slipping further -
I hadn't tried to contact the folks who might remember the underlying
history yet.  In particular, configfs_depend_item_unlocked() had been
posted in early 2015 and merged in end of the same year; unfortunately,
it had been changed a _lot_ between the last posting and actual merge
and I hadn't been able to find any traces of discussion anywhere.  Maybe
Andrzej Pietrasiewicz has some memories of that thing - other likely
participants appear to have moved on ;-/