On Thu, May 29, 2025 at 2:45 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> 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
