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

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

[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

[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

[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