Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor mountFd code #3512

Merged
merged 2 commits into from
May 9, 2023
Merged

Conversation

kolyshkin
Copy link
Contributor

@kolyshkin kolyshkin commented Jun 16, 2022

This is a followup to #3510, doing some refactoring of the code introduced by #2576.

This does the following:

  1. Simplify mount call by removing the procfd argument, and use the new
    simplified mount where procfd is not used. Now, the mount arguments are
    the same as those of unix.Mount.

  2. Introduce a new mountWithFD function, which is similar to the old
    mount(), except it can take procfd for both source and target.
    The new arguments are called srcFD and dstFD.

  3. Modify the mount error to show both srcFD and dstFD so it's clear
    which one is used for which purpose. This fixes the issue of having
    a somewhat cryptic errors like this:

    mount /proc/self/fd/11:/sys/fs/cgroup/systemd (via /proc/self/fd/12), flags: 0x20502f: operation not permitted

    (in which fd 11 is actually the source, and fd 12 is the target).

  4. Fix the mountWithFD callers to use dstFD (rather than procfd) for the
    variable name.

  5. Use srcFD where mountFd is set.

  6. Remove fd field from the mountConfig (since it contains data not specific to
    a particular mount, while fd is a per mount entry attribute). Introduce mountEntry
    structure, which embeds configs.Mount and adds srcFd to replace the
    removed mountConfig.fd.

@kolyshkin kolyshkin force-pushed the fix-mntns-userns-II branch from e42eda5 to 3ca7867 Compare June 17, 2022 04:12
@kolyshkin kolyshkin changed the title [WIP] rework mountFd Refactor mountFd code Jun 22, 2022
@kolyshkin
Copy link
Contributor Author

@rata @alban can you please review this one?

Copy link
Member

@rata rata left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kolyshkin This looks like a nice improvement and looks correct, thanks! Left some comments

libcontainer/mount_linux.go Show resolved Hide resolved
if e.procfd != "" {
out += " (via " + e.procfd + ")"
if e.srcFD != "" || e.dstFD != "" {
out += " (via " + e.srcFD + ":" + e.dstFD + ")"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm definitely curious to see how this error is shown now.

I wonder how much better this is than a something prints %+v, like fmt.Sprintf("Error: %v trying to: %+v", e.err.Error(), e).

I guess probably what we do here is better, though

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would look like

Error: no such file or directory trying to: {op:mount source:/proc/self/fd/11 srcFD: target:/sys/fs/cgroup/systemd dstFD:/proc/self/fd/12 flags:0x20502f data: err:2}

and using the code in this PR looks like

mount /proc/self/fd/11:/sys/fs/cgroup/systemd (via :/proc/self/fd/12), flags: 0x20502f: operation not permitted

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense to explicitly include dstFD / dest FD (and/or srcXX) in the error? Looks like currently, one would still need to be aware that the colon (:) is used to delimit them, so "before" means "it was dest" and "after" means "it was src".

could be [src=<value>,] dst=<value>

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I took a fresh look and ended up implementing a different format of an error message, using src=, sfd=, dst=, and dfd=, similar to what @thaJeztah suggested.

It makes some error messages look more heavy-weight than they should be, for example:

umount /some/dir, flags: 0x1: device busy

vs

umount dst=/some/dir, flags=0x1: device busy

but, I guess, it's even more clear that way

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup, I like that ("like" as in; easier to interpret the error)

if e.procfd != "" {
out += " (via " + e.procfd + ")"
if e.srcFD != "" || e.dstFD != "" {
out += " (via " + e.srcFD + ":" + e.dstFD + ")"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this line confusing if e.srcFD is empty?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's understandable enough (via :/proc/self/fd/5) yet simple.

Before:

mount /proc/self/fd/11:/sys/fs/cgroup/systemd (via /proc/self/fd/12), flags: 0x20502f: operation not permitted

After:

mount /proc/self/fd/11:/sys/fs/cgroup/systemd (via :/proc/self/fd/12), flags: 0x20502f: operation not permitted

Or would you prefer something like this (untested):

if e.srcFD != "" || e.dstFD != "" {
	const none="<none>"
	s := e.srcFD
	if s == "" {
		s = none
	}
	d := e.dstFD
	if d = "" {
		d  = none
	}
	out += " (via " + s + ":" + d + ")"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you can think of a better way to represent the error, let me know, I tried a few alternatives and did not like them.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Heh, yeah, not sure I like other alternatives I'm thinking either. What the PR currently does is good enough for me, thanks! :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Redid it again, see #3512 (comment)

libcontainer/mount_linux.go Outdated Show resolved Hide resolved
libcontainer/mount_linux.go Outdated Show resolved Hide resolved
@kolyshkin kolyshkin force-pushed the fix-mntns-userns-II branch from 3ca7867 to 58d8f75 Compare June 27, 2022 20:24
@kolyshkin kolyshkin marked this pull request as ready for review June 27, 2022 20:24
@kolyshkin
Copy link
Contributor Author

Rebased, addressed @rata comments, PTAL

@kolyshkin kolyshkin added this to the 1.2.0 milestone Jun 27, 2022
rata
rata previously approved these changes Jun 28, 2022
Copy link
Member

@rata rata left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks @kolyshkin !

@kolyshkin
Copy link
Contributor Author

@AkihiroSuda @cyphar @thaJeztah PTAL

@kolyshkin
Copy link
Contributor Author

@rata @thaJeztah PTAL

Copy link
Member

@rata rata left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kolyshkin Thanks! I left a few nits (super nits, so feel free to ignore). But this LGTM, is a nice improvement :)

}

if e.flags != uintptr(0) {
out += ", flags: 0x" + strconv.FormatUint(uint64(e.flags), 16)
out += ", flags=0x" + strconv.FormatUint(uint64(e.flags), 16)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(unrelated and out of scope, sharing my thoughts :D) I really wish there was a pretty print for the flags

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, thought about it, too, decided to not implement it, since it is only used by developers, and we can cope with numeric values.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeap, I ended up doing the same :-D. Some day it will happen :)

libcontainer/mount_linux.go Outdated Show resolved Hide resolved
libcontainer/mount_linux.go Outdated Show resolved Hide resolved
libcontainer/mount_linux.go Outdated Show resolved Hide resolved
libcontainer/mount_linux.go Outdated Show resolved Hide resolved
@kolyshkin kolyshkin force-pushed the fix-mntns-userns-II branch from 83b7aef to 9157a66 Compare July 27, 2022 22:29
@kolyshkin
Copy link
Contributor Author

@rata addressed your comments, PTAL.

@kolyshkin
Copy link
Contributor Author

CI is broken until #3539 is merged

rata
rata previously approved these changes Jul 28, 2022
Copy link
Member

@rata rata left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks @kolyshkin!

cyphar
cyphar previously approved these changes Aug 2, 2022
Copy link
Member

@cyphar cyphar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@kolyshkin
Copy link
Contributor Author

@AkihiroSuda PTAL

@kolyshkin kolyshkin force-pushed the fix-mntns-userns-II branch from 5de7aa5 to 9f3531d Compare August 18, 2022 22:16
@kolyshkin kolyshkin force-pushed the fix-mntns-userns-II branch from b7aa6b1 to cf070e8 Compare November 2, 2022 22:02
@kolyshkin
Copy link
Contributor Author

@thaJeztah @cyphar PTAL

@kolyshkin
Copy link
Contributor Author

@opencontainers/runc-maintainers anything I can do to move this forward?

AkihiroSuda
AkihiroSuda previously approved these changes Dec 18, 2022
@kolyshkin
Copy link
Contributor Author

@thaJeztah @cyphar PTAL

AkihiroSuda
AkihiroSuda previously approved these changes Mar 1, 2023
@kolyshkin
Copy link
Contributor Author

@thaJeztah @cyphar @hqhq PTAL 🙏🏻

libcontainer/rootfs_linux.go Outdated Show resolved Hide resolved
@kolyshkin kolyshkin force-pushed the fix-mntns-userns-II branch 2 times, most recently from 54c92a4 to a06d66d Compare March 11, 2023 01:46
Copy link
Contributor

@hqhq hqhq left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@kolyshkin kolyshkin requested review from rata and AkihiroSuda and removed request for rata March 17, 2023 18:24
Copy link
Member

@rata rata left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

It was so long that I had to review again. It was mostly unchaged, but I think the mountEntry.src() method is new and makes a lot of sense :)

kolyshkin added 2 commits May 2, 2023 18:41
1. Simplify mount call by removing the procfd argument, and use the new
   mount() where procfd is not used. Now, the mount() arguments are the
   same as for unix.Mount.

2. Introduce a new mountViaFDs function, which is similar to the old
   mount(), except it can take procfd for both source and target.
   The new arguments are called srcFD and dstFD.

3. Modify the mount error to show both srcFD and dstFD so it's clear
   which one is used for which purpose. This fixes the issue of having
   a somewhat cryptic errors like this:

> mount /proc/self/fd/11:/sys/fs/cgroup/systemd (via /proc/self/fd/12), flags: 0x20502f: operation not permitted

  (in which fd 11 is actually the source, and fd 12 is the target).

   After this change, it looks like

> mount src=/proc/self/fd/11, dst=/sys/fs/cgroup/systemd, dstFD=/proc/self/fd/12, flags=0x20502f: operation not permitted

   so it's clear that 12 is a destination fd.

4. Fix the mountViaFDs callers to use dstFD (rather than procfd) for the
   variable name.

5. Use srcFD where mountFd is set.

Signed-off-by: Kir Kolyshkin <[email protected]>
Adding fd field to mountConfig was not a good thing since mountConfig
contains data that is not specific to a particular mount, while fd is
a mount entry attribute.

Introduce mountEntry structure, which embeds configs.Mount and adds
srcFd to replace the removed mountConfig.fd.

Signed-off-by: Kir Kolyshkin <[email protected]>
@kolyshkin kolyshkin force-pushed the fix-mntns-userns-II branch from a06d66d to a60933b Compare May 3, 2023 02:00
@kolyshkin
Copy link
Contributor Author

Rebased; now I need to re-review it myself.

@kolyshkin
Copy link
Contributor Author

Rebased; now I need to re-review it myself.

LGTM

@kolyshkin
Copy link
Contributor Author

@thaJeztah @AkihiroSuda PTAL

@kolyshkin kolyshkin merged commit 8eb801d into opencontainers:main May 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants