On Tue, 7 Oct 2025 at 19:37, Aleksa Sarai [off-list ref] wrote:

On 2025-10-06, Luca Boccassi [off-list ref] wrote:

quoted

On Mon, 6 Oct 2025 at 14:41, Aleksa Sarai [off-list ref] wrote:

quoted

On 2025-10-06, Luca Boccassi [off-list ref] wrote:

quoted

On Mon, 6 Oct 2025 at 12:57, Alejandro Colomar [off-list ref] wrote:

quoted

Hi Luca,

On Mon, Oct 06, 2025 at 12:46:41PM +0100, Luca Boccassi wrote:

quoted

quoted

quoted

quoted

quoted

 .TP
+.B EINVAL
+The source mount is already mounted somewhere else. Clone it via

[...]

quoted

quoted

quoted

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

quoted

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