On Wed, Apr 23, 2025 at 11:20:45PM +0100, Al Viro wrote: > On Mon, Apr 21, 2025 at 05:29:47PM +0100, Al Viro wrote: > > On Mon, Apr 21, 2025 at 09:56:20AM +0200, Christian Brauner wrote: > > > On Mon, Apr 21, 2025 at 04:35:09AM +0100, Al Viro wrote: > > > > Not since 8f2918898eb5 "new helpers: vfs_create_mount(), fc_mount()" > > > > back in 2018. Get rid of the dead checks... > > > > > > > > Signed-off-by: Al Viro <viro@xxxxxxxxxxxxxxxxxx> > > > > --- > > > > > > Good idea. Fwiw, I've put this into vfs-6.16.mount with some other minor > > > stuff. If you're keeping it yourself let me know. > > > > Not sure... I'm going through documenting the struct mount lifecycle/locking/etc. > > and it already looks like there will be more patches, but then some are going > > to be #fixes fodder. > > BTW, could you explain what this is about? > /* > * If this is an attached mount make sure it's located in the callers > * mount namespace. If it's not don't let the caller interact with it. > * > * If this mount doesn't have a parent it's most often simply a > * detached mount with an anonymous mount namespace. IOW, something > * that's simply not attached yet. But there are apparently also users > * that do change mount properties on the rootfs itself. That obviously > * neither has a parent nor is it a detached mount so we cannot > * unconditionally check for detached mounts. > */ > if ((mnt_has_parent(mnt) || !is_anon_ns(mnt->mnt_ns)) && !check_mnt(mnt)) > goto out; > > Why do you care about mnt_has_parent() here? mnt is the root of subtree you > are operating on, so that condition means > * any subtree (including the entire tree) of caller's mount tree is OK > (fair enough) > * full mount tree of anon namespace is OK > * nothing else is acceptable > What about partial subtrees of anon namespaces? Restriction looks odd... No one has ever cared about that ever so far so I specifically only allowed the root of an anonymous mount namespace and this also keeps it in line with other calls. I'm not against opening that up if this is a use-case but so far we haven't had anyone care about mount properties in detached mount subtrees.
