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

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

[luca.boccassi]

From: Luca Boccassi <luca.boccassi@gmail.com>

open_tree() with OPEN_TREE_CLONE is needed to apply a mount multiple
times, otherwise EINVAL is returned by move_mount().

Signed-off-by: Luca Boccassi <luca.boccassi@gmail.com>
---
As requested by Aleksa on https://github.com/brauner/man-pages-md/pull/19
and based on the 'fs' branch where move_mount(2) was added

 man/man2/move_mount.2 | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/man/man2/move_mount.2 b/man/man2/move_mount.2
index 13063ac1f..e3dfc1ea8 100644
--- a/man/man2/move_mount.2
+++ b/man/man2/move_mount.2
@@ -457,6 +457,13 @@ which would otherwise cause the unbindable mounts to be propagated
 was attempted,
 but one of the listed restrictions was violated.
 .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).
+.TP
 .B ELOOP
 Too many symbolic links encountered
 when resolving one of
-- 
2.47.3

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

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 3956 bytes --]

Hi Luca,

On Mon, Oct 06, 2025 at 11:38:12AM +0100, luca.boccassi@gmail.com wrote:
> From: Luca Boccassi <luca.boccassi@gmail.com>
> 
> open_tree() with OPEN_TREE_CLONE is needed to apply a mount multiple
> times, otherwise EINVAL is returned by move_mount().
> 
> Signed-off-by: Luca Boccassi <luca.boccassi@gmail.com>
> ---
> As requested by Aleksa on https://github.com/brauner/man-pages-md/pull/19
> and based on the 'fs' branch where move_mount(2) was added
> 
>  man/man2/move_mount.2 | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/man/man2/move_mount.2 b/man/man2/move_mount.2
> index 13063ac1f..e3dfc1ea8 100644
> --- a/man/man2/move_mount.2
> +++ b/man/man2/move_mount.2
> @@ -457,6 +457,13 @@ which would otherwise cause the unbindable mounts to be propagated
>  was attempted,
>  but one of the listed restrictions was violated.
>  .TP
> +.B EINVAL
> +The source mount is already mounted somewhere else. Clone it via

Please use semantic newlines.  See man-pages(7):

$ MANWIDTH=72 man 7 man-pages | sed -n '/Use semantic newlines/,/^$/p'
   Use semantic newlines
     In the source of a manual page, new sentences should be started on
     new lines, long sentences should be split  into  lines  at  clause
     breaks  (commas,  semicolons, colons, and so on), and long clauses
     should be split at phrase boundaries.  This convention,  sometimes
     known as "semantic newlines", makes it easier to see the effect of
     patches, which often operate at the level of individual sentences,
     clauses, or phrases.

To be precise, that would mean breaking the line after period in this
case.


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

alx@devuan:~$ man -w 2 unshare
/usr/local/man/man2/unshare.2
alx@devuan:~$ MANWIDTH=72
alx@devuan:~$ man -w 2 unshare | xargs mansect ERRORS | man /dev/stdin | grep -C3 'since Linux'
            Cannot allocate sufficient memory to copy parts of caller’s context
            that need to be unshared.

     ENOSPC (since Linux 3.7)
            CLONE_NEWPID  was  specified in flags, but the limit on the nesting
            depth of PID namespaces would have  been  exceeded;  see  pid_name‐
            spaces(7).

     ENOSPC (since Linux 4.9; beforehand EUSERS)
            CLONE_NEWUSER  was specified in flags, and the call would cause the
            limit on the number of nested user namespaces to be exceeded.   See
            user_namespaces(7).
--
            From  Linux 3.11 to Linux 4.8, the error diagnosed in this case was
            EUSERS.

     ENOSPC (since Linux 4.9)
            One of the values in flags specified the creation  of  a  new  user
            namespace,  but doing so would have caused the limit defined by the
            corresponding file in /proc/sys/user to be exceeded.   For  further
--
            ID or the effective group ID of the caller does not have a  mapping
            in the parent namespace (see user_namespaces(7)).

     EPERM (since Linux 3.9)
            CLONE_NEWUSER  was specified in flags and the caller is in a chroot
            environment (i.e., the caller’s root directory does not  match  the
            root directory of the mount namespace in which it resides).


Have a lovely day!
Alex


> +.TP
>  .B ELOOP
>  Too many symbolic links encountered
>  when resolving one of
> -- 
> 2.47.3
> 

-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Luca Boccassi]

On Mon, 6 Oct 2025 at 12:19, Alejandro Colomar <alx@kernel.org> wrote:
>
> Hi Luca,
>
> On Mon, Oct 06, 2025 at 11:38:12AM +0100, luca.boccassi@gmail.com wrote:
> > From: Luca Boccassi <luca.boccassi@gmail.com>
> >
> > open_tree() with OPEN_TREE_CLONE is needed to apply a mount multiple
> > times, otherwise EINVAL is returned by move_mount().
> >
> > Signed-off-by: Luca Boccassi <luca.boccassi@gmail.com>
> > ---
> > As requested by Aleksa on https://github.com/brauner/man-pages-md/pull/19
> > and based on the 'fs' branch where move_mount(2) was added
> >
> >  man/man2/move_mount.2 | 7 +++++++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/man/man2/move_mount.2 b/man/man2/move_mount.2
> > index 13063ac1f..e3dfc1ea8 100644
> > --- a/man/man2/move_mount.2
> > +++ b/man/man2/move_mount.2
> > @@ -457,6 +457,13 @@ which would otherwise cause the unbindable mounts to be propagated
> >  was attempted,
> >  but one of the listed restrictions was violated.
> >  .TP
> > +.B EINVAL
> > +The source mount is already mounted somewhere else. Clone it via
>
> Please use semantic newlines.  See man-pages(7):
>
> $ MANWIDTH=72 man 7 man-pages | sed -n '/Use semantic newlines/,/^$/p'
>    Use semantic newlines
>      In the source of a manual page, new sentences should be started on
>      new lines, long sentences should be split  into  lines  at  clause
>      breaks  (commas,  semicolons, colons, and so on), and long clauses
>      should be split at phrase boundaries.  This convention,  sometimes
>      known as "semantic newlines", makes it easier to see the effect of
>      patches, which often operate at the level of individual sentences,
>      clauses, or phrases.
>
> To be precise, that would mean breaking the line after period in this
> case.
>
>
> > +.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.

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

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 1203 bytes --]

Hi Luca,

On Mon, Oct 06, 2025 at 12:32:42PM +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.


Cheers,
Alex

-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Luca Boccassi]

On Mon, 6 Oct 2025 at 12:42, Alejandro Colomar <alx@kernel.org> wrote:
>
> Hi Luca,
>
> On Mon, Oct 06, 2025 at 12:32:42PM +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.
Would you like me to send a v3 or would you prefer to amend the commit
message yourself?

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

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 1646 bytes --]

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.


Cheers,
Alex

-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Luca Boccassi]

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.

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

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 1262 bytes --]

Hi Luca,

On Mon, Oct 06, 2025 at 01:28:47PM +0100, Luca Boccassi wrote:
> > > > 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.

Okay, I'll wait a few days to apply the patch, in case Aleksa can
comment on this.  I think it would be interesting to know.  But if by
the end of this week we don't have any comments, I'll merge it.

Thanks!


Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 1572 bytes --]

BTW, I'll add Askar, since it was involved in the discussion of Aleksa's
patches.


On Mon, Oct 06, 2025 at 02:37:26PM +0200, Alejandro Colomar wrote:
> Hi Luca,
> 
> On Mon, Oct 06, 2025 at 01:28:47PM +0100, Luca Boccassi wrote:
> > > > > 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.
> 
> Okay, I'll wait a few days to apply the patch, in case Aleksa can
> comment on this.  I think it would be interesting to know.  But if by
> the end of this week we don't have any comments, I'll merge it.
> 
> Thanks!
> 
> 
> Have a lovely day!
> Alex
> 
> -- 
> <https://www.alejandro-colomar.es>
> Use port 80 (that is, <...:80/>).



-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Aleksa Sarai]

[-- Attachment #1: Type: text/plain, Size: 2720 bytes --]

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?

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]

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

[Luca Boccassi]

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.

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

[Aleksa Sarai]

[-- Attachment #1: Type: text/plain, Size: 4558 bytes --]

On 2025-10-06, Luca Boccassi <luca.boccassi@gmail.com> 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.

Before each move_mount(2) or just doing it once before all of them? My
quick testing seems to indicate that it needs to be before each one.

I just tried the example in move_mount(2) that I copied from David, and
it doesn't actually work for the reason you outlined (it doesn't work at
all without OPEN_TREE_CLONE, with OPEN_TREE_CLONE the first move works
because it's an attachment but the rest fail with -EINVAL).

   move_mount()  can  also be used in conjunction with file descriptors
   returned from open_tree(2) or open(2):

       int fd = open_tree(AT_FDCWD, "/mnt", 0); /* open("/mnt", O_PATH); */
       move_mount(fd, "", AT_FDCWD, "/mnt2", MOVE_MOUNT_F_EMPTY_PATH);
       move_mount(fd, "", AT_FDCWD, "/mnt3", MOVE_MOUNT_F_EMPTY_PATH);
       move_mount(fd, "", AT_FDCWD, "/mnt4", MOVE_MOUNT_F_EMPTY_PATH);

   This would move the mount object mounted at /mnt to /mnt2, then
   /mnt3, and then /mnt4.

This example needs to be reworked then...

I'm taking a look at where the error is coming from. As far as I can
see, I think it's from the check_mnt() section in do_move_mount().

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]

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

[Luca Boccassi]

On Tue, 7 Oct 2025 at 19:37, Aleksa Sarai <cyphar@cyphar.com> wrote:
>
> On 2025-10-06, Luca Boccassi <luca.boccassi@gmail.com> 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.
>
> Before each move_mount(2) or just doing it once before all of them? My
> quick testing seems to indicate that it needs to be before each one.

Yep, a clone before each move is what I am doing, otherwise it doesn't work

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

[Askar Safin]

Luca Boccassi <luca.boccassi@gmail.com>:
> 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.

This sounds like a bug. Please, give all reproduction steps. Both for
EINVAL and for non-working open_tree before 6.15. I want to reproduce it.

-- 
Askar Safin

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

[Luca Boccassi]

On Sun, 12 Oct 2025 at 07:14, Askar Safin <safinaskar@gmail.com> wrote:
>
> Luca Boccassi <luca.boccassi@gmail.com>:
> > 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.
>
> This sounds like a bug. Please, give all reproduction steps. Both for
> EINVAL and for non-working open_tree before 6.15. I want to reproduce it.

IIRC Christian said this was working as intended? Just fsmount() to
create a detached mount, and then try to apply it multiple times with
multiple move_mount(), and the second and subsequent ones will fail
with EINVAL

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

[Askar Safin]

Luca Boccassi <luca.boccassi@gmail.com>:
> IIRC Christian said this was working as intended? Just fsmount() to
> create a detached mount, and then try to apply it multiple times with
> multiple move_mount(), and the second and subsequent ones will fail
> with EINVAL

I just tested current mainline kernel (67029a49db6c).
And move_mount doesn't return EINVAL in this case (move_mount succeds).
This means that either EINVAL is not intended, either current mainline kernel
is buggy.

I tested this in Qemu in very minimal environment (rdinit=/bin/busybox sh).

See C source below.

-- 
Askar Safin

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>
#include <sys/stat.h>
#include <sys/mount.h>

#define ASSERT(cond) if (!(cond)) { \
    fprintf (stderr, "%s: assertion failed\n", #cond); \
    exit (1); \
}

#define ASSERT_ERRNO(cond) if (!(cond)) { \
    fprintf (stderr, "%d: ", __LINE__); \
    perror (#cond); \
    exit (1); \
}

int
main (void)
{
    ASSERT_ERRNO (mkdir ("/a", 0777) == 0);
    ASSERT_ERRNO (mkdir ("/b", 0777) == 0);
    ASSERT_ERRNO (mkdir ("/c", 0777) == 0);
    {
        {
            int fsfd = fsopen ("tmpfs", 0);
            ASSERT_ERRNO (fsfd != -1);
            ASSERT_ERRNO (fsconfig (fsfd, FSCONFIG_CMD_CREATE, NULL, NULL, 0) == 0);
            {
                int mntfd = fsmount (fsfd, 0, 0);
                ASSERT_ERRNO (mntfd != -1);
                ASSERT_ERRNO (move_mount (mntfd, "", AT_FDCWD, "/a", MOVE_MOUNT_F_EMPTY_PATH) == 0);
                ASSERT_ERRNO (move_mount (mntfd, "", AT_FDCWD, "/b", MOVE_MOUNT_F_EMPTY_PATH) == 0);
                ASSERT_ERRNO (move_mount (mntfd, "", AT_FDCWD, "/c", MOVE_MOUNT_F_EMPTY_PATH) == 0);
                ASSERT_ERRNO (close (mntfd) == 0);
            }
            ASSERT_ERRNO (close (fsfd) == 0);
        }
        ASSERT_ERRNO (umount ("/c") == 0);
    }
}

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

[Askar Safin]

Okay, I spent some more time researching this.

By default move_mount should work in your case.

But if we try to move mount, residing under shared mount, then move_mount
will not work. This is documented here:

https://elixir.bootlin.com/linux/v6.17/source/Documentation/filesystems/sharedsubtree.rst#L497

"/" is shared by default if we booted using systemd. This is why
you observing EINVAL.

I just found that this is already documented in move_mount(2):

    EINVAL The  source  mount  object's  parent  mount  has  shared  mount propagation, and thus cannot be moved (as described in mount_name‐
    spaces(7)).

So everything is working as intended, and no changes to manual pages are
needed.

On the other hand, this is a good idea to add a bigger warning to
move_mount(2) (and to mount(2), it is affected, too). I. e. to add something
like this to main text of move_mount (as opposed to "ERRORS"):
"Note that systemd makes "/" shared by default. Moving mounts residing
under shared mounts is prohibited, so attempting to move attached
mount using move_mount likely will not work".

(I personally don't have plans to submit this as a patch.)

-- 
Askar Safin

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

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 1477 bytes --]

Hi Askar,

On Sun, Oct 12, 2025 at 03:58:02PM +0300, Askar Safin wrote:
> Okay, I spent some more time researching this.
> 
> By default move_mount should work in your case.
> 
> But if we try to move mount, residing under shared mount, then move_mount
> will not work. This is documented here:
> 
> https://elixir.bootlin.com/linux/v6.17/source/Documentation/filesystems/sharedsubtree.rst#L497
> 
> "/" is shared by default if we booted using systemd. This is why
> you observing EINVAL.
> 
> I just found that this is already documented in move_mount(2):
> 
>     EINVAL The  source  mount  object's  parent  mount  has  shared  mount propagation, and thus cannot be moved (as described in mount_name‐
>     spaces(7)).
> 
> So everything is working as intended, and no changes to manual pages are
> needed.
> 
> On the other hand, this is a good idea to add a bigger warning to
> move_mount(2) (and to mount(2), it is affected, too). I. e. to add something
> like this to main text of move_mount (as opposed to "ERRORS"):
> "Note that systemd makes "/" shared by default. Moving mounts residing
> under shared mounts is prohibited, so attempting to move attached
> mount using move_mount likely will not work".

Maybe under a CAVEATS section?


Have a lovely day!
Alex

> (I personally don't have plans to submit this as a patch.)
> 
> -- 
> Askar Safin

-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Askar Safin]

On Sun, Oct 12, 2025 at 4:17 PM Alejandro Colomar <alx@kernel.org> wrote:
> Maybe under a CAVEATS section?

Yes, good idea.
-- 
Askar Safin

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

[Luca Boccassi]

On Sun, 12 Oct 2025 at 13:58, Askar Safin <safinaskar@gmail.com> wrote:
>
> Okay, I spent some more time researching this.
>
> By default move_mount should work in your case.
>
> But if we try to move mount, residing under shared mount, then move_mount
> will not work. This is documented here:
>
> https://elixir.bootlin.com/linux/v6.17/source/Documentation/filesystems/sharedsubtree.rst#L497
>
> "/" is shared by default if we booted using systemd. This is why
> you observing EINVAL.
>
> I just found that this is already documented in move_mount(2):
>
>     EINVAL The  source  mount  object's  parent  mount  has  shared  mount propagation, and thus cannot be moved (as described in mount_name‐
>     spaces(7)).
>
> So everything is working as intended, and no changes to manual pages are
> needed.

I don't think so. This was in a mount namespace, so it was not shared,
it was a new image, so not shared either, and '/' was not involved at
all. It's probably because you tried with a tmpfs instead of an actual
image.

But it really doesn't matter, I just wanted to save some time for
other people by documenting this, but it's really not worth having a
discussion over it, feel free to just disregard it. Thanks.

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

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 1949 bytes --]

Hi Luca,

On Sun, Oct 12, 2025 at 03:25:37PM +0100, Luca Boccassi wrote:
> On Sun, 12 Oct 2025 at 13:58, Askar Safin <safinaskar@gmail.com> wrote:
> >
> > Okay, I spent some more time researching this.
> >
> > By default move_mount should work in your case.
> >
> > But if we try to move mount, residing under shared mount, then move_mount
> > will not work. This is documented here:
> >
> > https://elixir.bootlin.com/linux/v6.17/source/Documentation/filesystems/sharedsubtree.rst#L497
> >
> > "/" is shared by default if we booted using systemd. This is why
> > you observing EINVAL.
> >
> > I just found that this is already documented in move_mount(2):
> >
> >     EINVAL The  source  mount  object's  parent  mount  has  shared  mount propagation, and thus cannot be moved (as described in mount_name‐
> >     spaces(7)).
> >
> > So everything is working as intended, and no changes to manual pages are
> > needed.
> 
> I don't think so. This was in a mount namespace, so it was not shared,
> it was a new image, so not shared either, and '/' was not involved at
> all. It's probably because you tried with a tmpfs instead of an actual
> image.
> 
> But it really doesn't matter, I just wanted to save some time for
> other people by documenting this, but it's really not worth having a
> discussion over it, feel free to just disregard it. Thanks.

I appreciate you wanting to save time for other people by documenting
it.  But we should also make sure we understand it fully before
documenting it.  I'd like us to continue this discussion, to be able to
understand it and thus document it.  I appreciate Aleksa and Askar's
efforts in understanding this, and the discussion too, which helps me
understand it too.  I can't blindly take patches without review, and
this discussion helps a lot.


Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 2107 bytes --]

Hi Alex,

At 2025-10-12T16:57:22+0200, Alejandro Colomar wrote:
> On Sun, Oct 12, 2025 at 03:25:37PM +0100, Luca Boccassi wrote:
> > On Sun, 12 Oct 2025 at 13:58, Askar Safin <safinaskar@gmail.com> wrote:
> > > So everything is working as intended, and no changes to manual
> > > pages are needed.
> > 
> > I don't think so. This was in a mount namespace, so it was not
> > shared, it was a new image, so not shared either, and '/' was not
> > involved at all. It's probably because you tried with a tmpfs
> > instead of an actual image.
> > 
> > But it really doesn't matter, I just wanted to save some time for
> > other people by documenting this, but it's really not worth having a
> > discussion over it, feel free to just disregard it. Thanks.
> 
> I appreciate you wanting to save time for other people by documenting
> it.  But we should also make sure we understand it fully before
> documenting it.  I'd like us to continue this discussion, to be able
> to understand it and thus document it.  I appreciate Aleksa and
> Askar's efforts in understanding this, and the discussion too, which
> helps me understand it too.  I can't blindly take patches without
> review, and this discussion helps a lot.

I have some unsolicited project management advice to offer.

I think you should say "won't" rather than "can't" in your final
sentence.  You are defending a point of policy--rightly so, in my view.
If someone wants to argue your preference on the subject, policy is the
correct ground upon which to engage.

The practice of distinguishing mechanism from policy is a valuable skill
in domains outside of software design where we most often speak of them.

It's even more important in the instant context to articulate matters of
policy when a contributor indulges a passive-aggressive outburst like
Luca's, above.  Confusion of mechanism with policy is the lever by which
that sort of emotionalism operates; obviously we _could_ just do
whatever a contributor wants without discussion and without
interrogating the wisdom of doing so.

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 4658 bytes --]

Hi Branden, Luca,

On Sun, Oct 12, 2025 at 01:57:03PM -0500, G. Branden Robinson wrote:
> At 2025-10-12T16:57:22+0200, Alejandro Colomar wrote:
> > On Sun, Oct 12, 2025 at 03:25:37PM +0100, Luca Boccassi wrote:
> > > On Sun, 12 Oct 2025 at 13:58, Askar Safin <safinaskar@gmail.com> wrote:
> > > > So everything is working as intended, and no changes to manual
> > > > pages are needed.
> > > 
> > > I don't think so. This was in a mount namespace, so it was not
> > > shared, it was a new image, so not shared either, and '/' was not
> > > involved at all. It's probably because you tried with a tmpfs
> > > instead of an actual image.
> > > 
> > > But it really doesn't matter, I just wanted to save some time for
> > > other people by documenting this, but it's really not worth having a
> > > discussion over it, feel free to just disregard it. Thanks.
> > 
> > I appreciate you wanting to save time for other people by documenting
> > it.  But we should also make sure we understand it fully before
> > documenting it.  I'd like us to continue this discussion, to be able
> > to understand it and thus document it.  I appreciate Aleksa and
> > Askar's efforts in understanding this, and the discussion too, which
> > helps me understand it too.  I can't blindly take patches without
> > review, and this discussion helps a lot.
> 
> I have some unsolicited project management advice to offer.
> 
> I think you should say "won't" rather than "can't" in your final
> sentence.  You are defending a point of policy--rightly so, in my view.
> If someone wants to argue your preference on the subject, policy is the
> correct ground upon which to engage.

Actually, I think I should have said "shouldn't" instead of "can't".

I technically can (in the sense that nothing stops me from doing
'git am && git push' if I wanted to), so "can't" is not appropriate.

And I don't know what I'll do tomorrow, so "won't" is not appropriate
either; I always reserve the right to change my mind later.

However, as a guideline, I "shouldn't" merge stuff without understanding
it.  Sometimes there are reasons for doing so, such as not having
knowledgeable reviewers at hand, and not being knowledgeable myself.
In this specific case, we have Aleksa and Askar willing to help, which
is why I want to follow the policy.

> The practice of distinguishing mechanism from policy is a valuable skill
> in domains outside of software design where we most often speak of them.

Thanks for correcting me on this.

> It's even more important in the instant context to articulate matters of
> policy when a contributor indulges a passive-aggressive outburst like
> Luca's, above.  Confusion of mechanism with policy is the lever by which
> that sort of emotionalism operates; obviously we _could_ just do
> whatever a contributor wants without discussion and without
> interrogating the wisdom of doing so.

I was trying to be nice with Luca.  I think confronting his message,
which I agree was a bit passive-aggressive, can be counter-productive in
this case, where I'm interested in having him continue discussing this
matter with Aleksa and Askar.

And in the case of Luca, I have a story, which I should disclose for
context.

A year ago or so, I contributed (or tried to) to systemd, for my first
time, and I experienced what looked to me terrible project management.
<https://github.com/systemd/systemd/pull/35275>
<https://github.com/systemd/systemd/pull/35226>
We had a heated fight, and they banned me from systemd.  I didn't know
Luca before, nor any of the systemd maintainers.

After some time, and seeing Luca engage (aggressively) with other people
elsewhere (mostly, LWN), I have a theory, that Luca's aggressive
behavior might be related to receiving a lot of hate by his work in
systemd.  I still don't know if it's a cause or a consequence, though.

So, I wanted to show Luca the management style we're used to here, and
that a maintainer can be nice with contributors, even if they disagree. 

Even if Luca has behaved in a way that I don't like elsewhere, I'd like
to give him the opportunity to be nice here.  And for that, I was ready
to indulge his previous message.

Luca, I still would like you to engage in discussion with Aleksa and
Askar to better understand this matter.  Please do so.  Taking some
extra time to fully understand it now, can help document this better,
and save many times that amount of time to other programmers.

Peace and love.  :)


Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Askar Safin]

Luca Boccassi <luca.boccassi@gmail.com>:
> I don't think so. This was in a mount namespace, so it was not shared,

If it was not shared, then this seems like a bug. Please, say me
reproduction steps, I will try to fix the bug.

If you don't have reproduction steps, then, at very least, say something
like "this happens at line xxx of this big program".

Also, note that "unshare(CLONE_NEWNS)" and "unshare --mount" behave
differently: if you do "unshare(CLONE_NEWNS)", then all shared mounts
continue to be shared. But if you do "unshare --mount", then it
internally does "unshare(CLONE_NEWNS)" and then equivalent of
"mount --make-rprivate", i. e. makes all mounts inside new namespace
private.

> it was a new image, so not shared either, and '/' was not involved at

When you make a new mount under existing shared mount, it becomes shared, too.
(I just checked this.) Also, on systemd, all mounts (not only '/') are shared
by default, I just checked this, too.

-- 
Askar Safin

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

[Christian Brauner]

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.

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

[luca.boccassi]

From: Luca Boccassi <luca.boccassi@gmail.com>

open_tree() with OPEN_TREE_CLONE is needed to apply a mount multiple
times, otherwise EINVAL is returned by move_mount(). Available since 6.15.

Signed-off-by: Luca Boccassi <luca.boccassi@gmail.com>
---
As requested by Aleksa on https://github.com/brauner/man-pages-md/pull/19
and based on the 'fs' branch where move_mount(2) was added

v2: semantic line break, clarify purpose of mentioning a version

 man/man2/move_mount.2 | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/man/man2/move_mount.2 b/man/man2/move_mount.2
index 13063ac1f..968e6a81a 100644
--- a/man/man2/move_mount.2
+++ b/man/man2/move_mount.2
@@ -457,6 +457,14 @@ which would otherwise cause the unbindable mounts to be propagated
 was attempted,
 but one of the listed restrictions was violated.
 .TP
+.B EINVAL
+The source mount is already mounted somewhere else.
+Since Linux 6.15 it is possible to clone the mount via
+.BR open_tree (2)
+with
+.B \%OPEN_TREE_CLONE
+and use that as the source to avoid this error.
+.TP
 .B ELOOP
 Too many symbolic links encountered
 when resolving one of
-- 
2.47.3