VERSION: release v1.2.7

[cyphar]

runc v1.2.7 -- "さんをつけろよデコ助野郎！"

This is the seventh patch release of the 1.2.z release branch of runc.
It contains some fixes for issues found in runc 1.3.z that were
considered "significant" bugfixes (as per our new release and support
policy) and thus be worth backporting.

Fixed:

 * Removed preemptive "full access to cgroups" warning when calling runc
   pause or runc unpause as an unprivileged user without
   --systemd-cgroups. Now the warning is only emitted if an actual
   permission error was encountered. (#4709, #4720)
 * Add time namespace to container config after checkpoint/restore. CRIU
   since version 3.14 uses a time namespace for checkpoint/restore,
   however it was not joining the time namespace in runc. (#4696, #4714)
 * Container processes will no longer inherit the CPU affinity of runc
   by default. Instead, the default CPU affinity of container processes
   will be the largest set of CPUs permitted by the container's cpuset
   cgroup and any other system restrictions (such as isolated CPUs).
   (#4041, #4815, #4858)
 * Close seccomp agent connection to prevent resource leaks. (#4796,
   #4800)
 * Several fixes to our CI, mainly related to AlmaLinux and CRIU.
   (#4670, #4728, #4736, #4742)
 * Setting linux.rootfsPropagation to shared or unbindable now functions
   properly. (#1755, #1815, #4724, #4791)
 * runc update will no longer clear intelRdt state information. (#4828,
   #4834)

Changed:

 * In runc 1.2, we changed our mount behaviour to correctly handle
   clearing flags. However, the error messages we returned did not
   provide as much information to users about what clearing flags were
   conflicting with locked mount flags. We now provide more diagnostic
   information if there is an error when in the fallback path to handle
   locked mount flags. (#4734, #4740)
 * Ignore the dmem controller in our cgroup tests, as systemd does not
   yet support it. (#4806, #4811)
 * /proc/net/dev is no longer included in the permitted procfs overmount
   list. Its inclusion was almost certainly an error, and because
   /proc/net is a symlink to /proc/self/net, overmounting this was
   almost certainly never useful (and will be blocked by future kernel
   versions). (#4817, #4820)
 * CI: Switch to GitHub-hosted ARM runners. Thanks again to @alexellis
   for supporting runc's ARM CI up until now. (#4844, #4856, #4867)
 * Simplify the prepareCriuRestoreMounts logic for checkpoint-restore.
   (#4765, #4872)

Thanks to the following contributors for making this release possible:

 * Akihiro Suda <[email protected]>
 * Aleksa Sarai <[email protected]>
 * Andrei Vagin <[email protected]>
 * Kir Kolyshkin <[email protected]>
 * Markus Lehtonen <[email protected]>
 * Martin Sivak <[email protected]>
 * Pavel Liubimov <[email protected]>
 * Peter Hunt <[email protected]>
 * Rodrigo Campos <[email protected]>
 * Yusuke Sakurai <[email protected]>
 * lfbzhm <[email protected]>
 * ningmingxiao <[email protected]>

Signed-off-by: Aleksa Sarai <[email protected]>

[rata]

Thanks! I found one typo here on the PR numbers.

I'm fine with having the PRs to the main branch referenced here, however I'm not sure how much value it adds, as the backported PR usually says it's a backport of PR X and has the link.

I'd not change it now, but I don't see the value it adds. If there is some automation that does this and it's simpler to keep it in the future, I'm completely fine with it too :)

[cyphar]

@rata Personally I think the main branch PRs are more useful than the per-release-branch PRs for three reasons:

1. Almost all of the backports we do are trivial, so in most cases the per-release-branch PRs are just like the main branch PRs except they miss most of the useful information about what the change is for and discussions about the change. Whenever I need to look into a patch, I end up going to the main branch PR -- maybe someone would want to see the actual patch applied but I usually get to that point from git blame not the changelog.
2. It lets us copy-paste the changelog entries between release branches (if we only included the main branch PRs). It would be nice if we had identical changelog entries for backported patches.
3. If a main branch PR is referenced in a changelog, then by definition the reader knows it was backported, so I don't really see what they would gain from seeing the backport PR first. GitHub shows the

Honestly, I would prefer only having the main branch PRs (except for backports which were non-trivial) as well as any issues that are related to the issue. I only keep the backport PRs because @kolyshkin seems to prefer them.

Also, none of this is automated at the moment -- to be honest, I think we should start requiring contributors to include an entry in CHANGELOG.md for non-trivial PRs to make this work less tiring. Writing changelogs for minor releases in particular is quite a chore, and I often need to re-read the patch multiple times to figure out what a reasonable changelog entry looks like (the PR descriptions and commit messages are often more confusing than they are helpful...).

[rata]

@cyphar Makes sense to me. I'll be fine with just the main branch PRs, the duplication of both PRs is what I dislike and adds more toil to the task. The c&p of changelog entries are also a great thing for me, great point :). As long as it's manual, that helps.

But I guess in the not-so-distant future we can create scripts to automate more of this, like a simple tool that checks PRs with the changelog label on github and parse the PR description for the changelog entry to use.

[kolyshkin]

Honestly, I would prefer only having the main branch PRs (except for backports which were non-trivial) as well as any issues that are related to the issue. I only keep the backport PRs because @kolyshkin seems to prefer them.

It's not a big deal but I prefer the backport PRs because in some cases they are not so straightforward. They may miss some patches present in the "main" PR, or have some extra patches. Sometimes a backport PR may incorporate patches from a few "main" PRs.

Another reason is, a backport PR almost always refer to main one(s), but not vice versa.

[cyphar]

@kolyshkin

I agree that for non-trivial backports we should reference them, but for trivial ones I'm not so sure it's worth the effort (given that the process is still very manual).

Another reason is, a backport PR almost always refer to main one(s), but not vice versa.

Well, in the GitHub UI back-links are shown when the PR gets referenced. It's more explicit with backport PRs but not much more so IMHO.

[rata]

@cyphar you marked comments as resolved, but it seems you forgot to push. Nothing is changed here.

[cyphar]

@rata My bad, pushed.

[rata]

LGTM, thanks!

[cyphar]

This should be ready @AkihiroSuda @kolyshkin. 😸

I'll push both updates at the same time.