Add new mount api syscall for linux

[yujincheng08]

Fix #744

[yujincheng08]

@sunfishcode we need to distinguish two move_mount's, any idea?

[sunfishcode]

@yujincheng08 I'm not familiar with the move_mount API; could you describe the problem in more detail?

[yujincheng08]

There's a new linux syscall named move_mount, but now rustix has used the name move_mount for mount MS_MOVE, so we need to distinguish them

[sunfishcode]

Oh, I see. Next time we have a semver bump, we should rename that move_mount function, and have the actual move_mount syscall be named move_mount. I've now made a note of that in #753. But it will likely be quite a while before the next semver bump, so for now, how about naming the new function move_mount_syscall and add some comments in the existing move_mount mentioning that it's not the move_mount syscall?

[yujincheng08]

how about naming the new function move_mount_syscall and add some comments in the existing move_mount mentioning that it's not the move_mount syscall?

sounds good to me. i am afk for serval hours, and will update it then. or maybe you can help me correct it?

[yujincheng08]

@sunfishcode changed as requested. plz review again.

[sunfishcode]

This looks good! Would it be possible to write some simple tests that exercise these new functions? Or do these APIs require elevated privileges?

[yujincheng08]

Thanks for your review. About testing, all of these APIs need the same privileges as mount:

• fsopen: https://github.com/torvalds/linux/blob/57f1f9dd3abea322173ea75a15887ccf14bbbe51/fs/fsopen.c#L122-L123
• fspick: https://github.com/torvalds/linux/blob/57f1f9dd3abea322173ea75a15887ccf14bbbe51/fs/fsopen.c#L165-L166
• fsconfig: As we cannot open a filesystem fd by fsopen and fspick, we cannot test this syscall
• move_mount: https://github.com/torvalds/linux/blob/57f1f9dd3abea322173ea75a15887ccf14bbbe51/fs/namespace.c#L4067-L4068
• fsmount: https://github.com/torvalds/linux/blob/57f1f9dd3abea322173ea75a15887ccf14bbbe51/fs/namespace.c#L3941-L3942
• open_tree: https://github.com/torvalds/linux/blob/57f1f9dd3abea322173ea75a15887ccf14bbbe51/fs/namespace.c#L2713-L2714

[sunfishcode]

Thanks! Thinking about this more, I have a few additional thoughts.

It appears that documentation for these syscalls was posted as patches but never finished. What would you think about adding the following as documentation links?

fspick: https://lwn.net/ml/linux-kernel/159827189767.306468.1803062787718957199.stgit@warthog.procyon.org.uk/
fsconfig: https://lwn.net/ml/linux-kernel/159827191245.306468.4903071494263813779.stgit@warthog.procyon.org.uk/
open_tree: https://lwn.net/ml/linux-kernel/159827188271.306468.16962617119460123110.stgit@warthog.procyon.org.uk/
move_mount: https://lwn.net/ml/linux-kernel/159827189025.306468.4916341547843731338.stgit@warthog.procyon.org.uk/
fsopen: https://lwn.net/ml/linux-kernel/159827190508.306468.12755090833140558156.stgit@warthog.procyon.org.uk/
fsmount: https://lwn.net/ml/linux-kernel/159827190508.306468.12755090833140558156.stgit@warthog.procyon.org.uk/

Also, with the addition of these new functions, alongside the existing mount/remount/bind_mount/move_mount etc., it's starting to feel like there are enough of these functions and they're distinct enough that they should live in a new top-level rustix::mount instead of including them all in rustix::fs. We'd still need the existing rustix::fs names for semver compat, but they could become aliases for the real functions in rustix::mount that we remove when we bump. That would also be an opportunity to rename the existing move_mount. Do you think that would make sense? If you'd like, I'd be willing to make the actual change.

[yujincheng08]

What would you think about adding the following as documentation links?

I also noticed these docs but I intently not adding them because they are not merged, and they are not in well format (not very human readable).

Do you think that would make sense?

Looks good to me! I like this idea :).

[yujincheng08]

For documentation, maybe we can copy some contents of the unfinished patches to rust doc as a temporarily workaround? Once their docs finished, we can change them to link then.

[sunfishcode]

I'd be ok with copying the unfinished documentation content into the tree; we should just be sure to cite where we copied it from, include their license, and mention why we need our own copy.

[yujincheng08]

Thanks.

You previously said you would like to do the actual change. Is there anything else I need to do for this PR for merging?

[sunfishcode]

Ah, no, this is fine. I'll merge this and make the change soon.