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

[Song Liu]

On Thu, May 29, 2025 at 2:45 PM Al Viro <viro at zeniv.linux.org.uk> wrote:
>
> 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".

Agreed.

>
> > 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.

Is it an issue if we only hold a reference to a MNT_LOCKED mount for
short period of time? "Short period" means it may get interrupted, page
faults, or wait for an IO (read xattr), but it won't hold a reference to the
mount and sleep indefinitely.

>
> 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?

I thought about skipping intermediate mounts (that are hidden by
other mounts). AFAICT, not skipping them will not cause any issue.
So I got the API to also show these mounts.

Thanks,
Song