Re: [PATCH] man/man2/move_mount.2: document EINVAL on multiple instances

[Christian Brauner <brauner@kernel.org>]

On Mon, Oct 06, 2025 at 02:44:58PM +0100, Luca Boccassi wrote:
> On Mon, 6 Oct 2025 at 14:41, Aleksa Sarai <cyphar@cyphar.com> wrote:
> >
> > On 2025-10-06, Luca Boccassi <luca.boccassi@gmail.com> wrote:
> > > On Mon, 6 Oct 2025 at 12:57, Alejandro Colomar <alx@kernel.org> wrote:
> > > >
> > > > Hi Luca,
> > > >
> > > > On Mon, Oct 06, 2025 at 12:46:41PM +0100, Luca Boccassi wrote:
> > > > > > > > >  .TP
> > > > > > > > > +.B EINVAL
> > > > > > > > > +The source mount is already mounted somewhere else. Clone it via
> > > > > > [...]
> > > > > > > > > +.BR open_tree (2)
> > > > > > > > > +with
> > > > > > > > > +.B \%OPEN_TREE_CLONE
> > > > > > > > > +and use that as the source instead (since Linux 6.15).
> > > > > > > >
> > > > > > > > The parenthetical in that position makes it unclear if you're saying
> > > > > > > > that one should use open_tree(2) with OPEN_TREE_CLONE since Linux 6.15,
> > > > > > > > or if you're saying that this error can happen since that version.
> > > > > > > > Would you mind clarifying?  I think if you mean that the error can
> > > > > > > > happen since Linux 6.15, we could make it part of the paragraph tag, as
> > > > > > > > in unshare(2).
> > > > > > >
> > > > > > > I meant the former, the error is always there, but OPEN_TREE_CLONE can
> > > > > > > be used since 6.15 to avoid it. Sent v2 with this and the other fix,
> > > > > > > thanks for the prompt review.
> > > > > >
> > > > > > Hmmm, I see.  Why not use open_tree(2) and OPEN_TREE_CLONE before 6.15?
> > > > > > The syscall and flag existed, AFAICS.  I think we should clarify --at
> > > > > > least in the commit message--, why that version is important.
> > > > >
> > > > > It was just not supported at all, so it would still fail with EINVAL
> > > > > before 6.15 even with the clone.
> > > >
> > > > Thanks!  What's the exact commit (or set of commits) that changed this?
> > > > That would be useful for the commit message.
> > > >
> > > > > Would you like me to send a v3 or would you prefer to amend the commit
> > > > > message yourself?
> > > >
> > > > I can amend myself.
> > >
> > > Sorry, I am not a kernel dev so I do not know where it was introduced
> > > exactly, and quickly skimming the commits list doesn't immediately
> > > reveal anything. I only know that by testing it, it works on 6.15 and
> > > fails earlier.
> >
> > If I'm understanding the new error entry correctly, this might be commit
> > c5c12f871a30 ("fs: create detached mounts from detached mounts"), but
> > Christian can probably verify that.
> >
> > Just to double check that I understand this new error explanation -- the
> > issue is that you had a file descriptor that you thought was a detached
> > mount object but it was actually attached at some point, and the
> > suggestion is to create a new detached bind-mount to use with
> > move_mount(2)? Do you really get EINVAL in that case or does this move
> > the mount?
> 
> Almost - the use case is that I prep an image as a detached mount, and
> then I want to apply it multiple times, without having to reopen it
> again and again. If I just do 'move_mount()' multiple times, the
> second one returns EINVAL. From 6.15, I can do open_tree with
> OPEN_TREE_CLONE before applying with move_mount, and everything works.

Your use-case was to create a new detached filesystem via fsmount().
And then send that fd to multiple different mount namespaces. One of
those mount namespaces would manage to attach that mount. At that point
it's not possible to attach that mount in another different mount
namespace again. IOW, it's fine to move it around in the same mount
namespace but it's not fine to move it _across_ mount namespaces after
it has been attached to one. Only a detached mount can be moved across
mount namespaces freely.

And fyi, your original idea wouldn't have been able to address the
use-case. Even if it would've worked you would've simply moved the same
mount between different mount points defeating the purpose of having it
available at multiple locations.

Being able to create detached mounts from detached mounts mounts enables
that use-case. Now you can distribute the same filesystem across
different mount namespaces.