-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Refactor mountFd code #3512
Conversation
e42eda5
to
3ca7867
Compare
There was a problem hiding this 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
Outdated
if e.procfd != "" { | ||
out += " (via " + e.procfd + ")" | ||
if e.srcFD != "" || e.dstFD != "" { | ||
out += " (via " + e.srcFD + ":" + e.dstFD + ")" |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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>
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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)
libcontainer/mount_linux.go
Outdated
if e.procfd != "" { | ||
out += " (via " + e.procfd + ")" | ||
if e.srcFD != "" || e.dstFD != "" { | ||
out += " (via " + e.srcFD + ":" + e.dstFD + ")" |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 + ")"
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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! :)
There was a problem hiding this comment.
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)
3ca7867
to
58d8f75
Compare
Rebased, addressed @rata comments, PTAL |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks @kolyshkin !
58d8f75
to
439d80f
Compare
439d80f
to
83b7aef
Compare
@rata @thaJeztah PTAL |
There was a problem hiding this 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) |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 :)
83b7aef
to
9157a66
Compare
@rata addressed your comments, PTAL. |
CI is broken until #3539 is merged |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks @kolyshkin!
9157a66
to
5de7aa5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
@AkihiroSuda PTAL |
5de7aa5
to
9f3531d
Compare
b7aa6b1
to
cf070e8
Compare
@thaJeztah @cyphar PTAL |
@opencontainers/runc-maintainers anything I can do to move this forward? |
@thaJeztah @cyphar PTAL |
cf070e8
to
7fa4fe7
Compare
@thaJeztah @cyphar @hqhq PTAL 🙏🏻 |
54c92a4
to
a06d66d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this 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 :)
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]>
a06d66d
to
a60933b
Compare
Rebased; now I need to re-review it myself. |
LGTM |
@thaJeztah @AkihiroSuda PTAL |
This is a followup to #3510, doing some refactoring of the code introduced by #2576.
This does the following:
Simplify
mount
call by removing the procfd argument, and use the newsimplified mount where procfd is not used. Now, the mount arguments are
the same as those of
unix.Mount
.Introduce a new
mountWithFD
function, which is similar to the oldmount(), except it can take procfd for both source and target.
The new arguments are called
srcFD
anddstFD
.Modify the mount error to show both
srcFD
anddstFD
so it's clearwhich one is used for which purpose. This fixes the issue of having
a somewhat cryptic errors like this:
(in which fd 11 is actually the source, and fd 12 is the target).
Fix the
mountWithFD
callers to usedstFD
(rather thanprocfd
) for thevariable name.
Use
srcFD
wheremountFd
is set.Remove fd field from the
mountConfig
(since it contains data not specific toa particular mount, while fd is a per mount entry attribute). Introduce
mountEntry
structure, which embeds
configs.Mount
and addssrcFd
to replace theremoved
mountConfig.fd
.