[PATCH bpf-next 3/4] bpf: Introduce path iterator

[Al Viro]

On Thu, May 29, 2025 at 02:07:31PM -0700, Song Liu wrote:

> We have made it very clear what is needed now: an iterator that iterates
> towards the root. This has been discussed in LPC [1] and
> LSF/MM/BPF [2].
> 
> We don't know what might be needed in the future. That's why nothing
> is shared. If the problem is that this code looks extendible, we sure can
> remove it for now. But we cannot promise there will never be use cases
> that could benefit from a slightly different path iterator.

For the record, "use cases that could benefit from X" != "sufficient reason
to accept X".

> Either way, if we
> are adding/changing anything to the path iterator, you will always be
> CC'ed. You are always welcome to NAK anything if there is real issue
> with the code being developed.

Umm...  What about walking into the mountpoint of MNT_LOCKED mount?
That, BTW, is an example of non-trivial implications - at the moment
you *can* check that in path->mnt->mnt_flags before walking rootwards
and repeat the step if you walked into the parent.  Clumsy and easy
to get wrong, but it's doable.

OTOH, there's a good cause for moving some of the flags, MNT_LOCKED
included, out of ->mnt_flags and into a separate field in struct mount.
However, that would conflict with any code using that to deal with
your iterator safely.

What's more, AFAICS in case of a stack of mounts each covering the root
of parent mount, you stop in each of those.  The trouble is, umount(2)
propagation logics assumes that intermediate mounts can be pulled out of
such stack without causing trouble.  For pathname resolution that is
true; it goes through the entire stack atomically wrt that stuff.
For your API that's not the case; somebody who has no idea about an
intermediate mount being there might get caught on it while it's getting
pulled from the stack.

What exactly do you need around the mountpoint crossing?