[1.1] Fix set nofile rlimit error

[lifubang]

This is backport of #4268, #4265.

Fix: #4195
Close: #4237

1. Fix a get/set race between runc exec and syscall.rlimit.init()

As @ls-ggg has given the detailed steps to reproduce the issue #4195 , and has given the core reason is that the go runtime will cache the value of rlimit nofile. [1]
When we are running runc exec with nofile limit, runc set it in the parent process, it may cause a race with go runtime init. The race condition is in the time when runc parent process set the container child process's nofile limit just after go runtime init has fetched the nofile limit. [2]
So, we should set nofile limit after syscall.rlimit.init() completed.

2. Fix an edge case caused by nofile rlimit cache in go stdlib

As @kolyshkin have found an edge case for set nofile rlimit by runc, which is also caused by nofile rlimit cache in go stdlib. Although we have a way to resolve the above get/set race, but if the hard value of nofile rlimit configured in config.json is bigger than this value of runc create/run/exec, it will also be incorrect restored by syscall.Exec in runc init. So we need to clear the nofile rlimit cache before we start the container initial process if we need to set nofile rlimit for the container.

[1] golang/go@f5eef58#diff-ec665e9789f8cf5cd1828ad7fa9f0ff4ebc1f5b5dd0fc82a296da5c07da7ece6
[2] https://github.com/golang/go/blob/f5eef58e4381259cbd84b3f2074c79607fb5c821/src/syscall/rlimit.go#L34-L35

---

CHANGELOG:
deprecated: libct.system.Execv is not used in runc anymore, it will be removed in v1.2.0.

[lifubang]

Note that we don’t support go version less than 1.19 anymore once we merge this PR.

[kolyshkin]

Note that we don’t support go version less than 1.19 anymore once we merge this PR.

This is a questionable decision. I think what we should do instead in 1.1 is add two versions of func ClearRlimitNofileCache -- one for Go 1.19+ which does what it does now, and the other is for !go1.19, which does nothing.

[lifubang]

I think what we should do instead in 1.1 is add two versions of func ClearRlimitNofileCache -- one for Go 1.19+ which does what it does now, and the other is for !go1.19, which does nothing.

Thanks your suggestion.

[kolyshkin]

No need to repeat the comment I guess.

[kolyshkin]

@lifubang thanks for the changes! Can you tell why are you still bumping go version?

[lifubang]

The complete generic features are supported since go 1.18

The complete generic features are supported since go 1.18, because go 1.19 and above need this change.

[kolyshkin]

The complete generic features are supported since go 1.18

The complete generic features are supported since go 1.18, because go 1.19 and above need this change.

I'm sorry, I still don't understand what do you mean :(

This code works with Go 1.17 AFAICS. Can you explain why you changed go version to 1.18 in go.mod in the last commit?

[lifubang]

This code works with Go 1.17 AFAICS.

Yes, this works with go 1.17, but if we use go 1.19, because of the ‘go 1.17’ defined in ‘go.mod’, it can’t work.

[kolyshkin]

Ah, I see! This is what happens without the commit bumping the go version in go.mod:

[kir@kir-rhat runc]$ make all GO=go1.20
go1.20 build -trimpath "-buildmode=pie"  -tags "seccomp" -ldflags "-X main.gitCommit=v1.1.12-21-ge36b3ae7 -X main.version=1.1.12+dev " -o runc .
# github.com/opencontainers/runc/libcontainer/system
libcontainer/system/rlimit_go119.go:13:43: type instantiation requires go1.18 or later (-lang was set to go1.17; check go.mod)
make: *** [Makefile:61: runc] Error 1

So, despite libcontainer/system/rlimit_go119.go being guarded with //go:build go1.19, go build still complains. To me this looks like a bug, and there's an issue opened about this (golang/go#52880), but it looks like it won't be fixed.

This is why the go version bump is needed.

[kolyshkin]

LGTM

[thaJeztah]

So, despite libcontainer/system/rlimit_go119.go being guarded with //go:build go1.19, go build still complains. To me this looks like a bug, and there's an issue opened about this (golang/go#52880), but it looks like it won't be fixed.

This is why the go version bump is needed.

Wait, so we're using go1.20, but the go version in go.mod causes it to downgrade to language version 1.17, but ... then it does not use the < go1.19 fallback (through //go:build constraints) implementation? So what's the value of go build-constraints now if the only version used is the version specified in go.mod, and consumers of the module MUST be using that version (or above)? Does that mean it's no longer possible to provide fallback implementations?

This stuff is getting more and more confusing.

[thaJeztah]

Curious why we're back porting this one;

• Remove unused system.Execv #4268

Technically that's a breaking change so not something were could include in a patch release. Perhaps we're not using it ourselves (so it would be "dead code" for us), but someone using the module could be using it.

I couldn't find external consumers, but if we have no strong reason, perhaps we should skip it to reduce the diff for path releases?

[lifubang]

Curious why we're back porting this one;

• Remove unused system.Execv #4268

Technically that's a breaking change so not something were could include in a patch release. Perhaps we're not using it ourselves (so it would be "dead code" for us), but someone using the module could be using it.

I couldn't find external consumers, but if we have no strong reason, perhaps we should skip it to reduce the diff for path releases?

I agree. In fact we have no strong reason to back port this commit, we just only need a comment change from this commit.
I'll remove this backport later.
Thanks.

[thaJeztah]

Thanks! Yes, it's probably fine, but if we don't have a strong need, we may as well skip it (just in case).

[thaJeztah]

^ I'd be fine adding a Deprecated: comment on it (for the 1.1 branch) if we want to raise visibility for it going away. I think there's some other exported functions that we removed in 1.2 as well, and I guess every bit could help to raise awareness.

[lifubang]

Wait, so we're using go1.20, but the go version in go.mod causes it to downgrade to language version 1.17, but ... then it does not use the < go1.19 fallback (through //go:build constraints) implementation?

No, because go version still be go1.20.

There are two explanations related to go directive in go.mod:

1. The go directive affects use of new language features
   This means that if we using go 1.19 to compile runc, we can’t use any new language features provided after 1.17, for example generic type;

2. Before Go 1.21, the directive was advisory only
   This means that we can support go 1.17 like before.

Refer:
https://go.dev/doc/modules/gomod-ref#go

[lifubang]

^ I'd be fine adding a Deprecated: comment on it (for the 1.1 branch) if we want to raise visibility for it going away. I think there's some other exported functions that we removed in 1.2 as well, and I guess every bit could help to raise awareness.

Switched to this suggection, make it deprecated in 1.1 .

[kolyshkin]

A single nit: I think libct: clean cached rlimit nofile in go runtime should come AFTER use go 1.18 in go.mod, as otherwise we're breaking git-bisect.

[lifubang]

A single nit: I think libct: clean cached rlimit nofile in go runtime should come AFTER use go 1.18 in go.mod, as otherwise we're breaking git-bisect.

done

[AkihiroSuda]

(Ideally we should not bump up Go version in backport releases, but it's not a huge deal, as Go 1.17 has already reached EOL)

[kolyshkin]

This is needed here because we rely on a feature that is only available since Go 1.18, and despite the feature being guarded by go1.20 build tag, this bump is still required (see #4277 (comment) above).

Nevertheless, go 1.17 can still be used just fine to compile this (as you can see in CI).

All that doesn't make much sense to me either, but Go developers seem to disagree (golang/go#52880).