Not sure why the CI failed, it does not seem related to the change (but I may be missing something)

You just need to sign your commit and force push

I think it fails because the commit is missing a DCO sign-off

Looking at these changes; perhaps instead we could cherry-pick the commits from master (so backporting #3357 and #3423)

assuming your "upstream" remote (this repository) is named upstream, and the remote for your fork is named origin;

git reset --hard upstream/release/1.2
git cherry-pick -s -x 341c7c144f64d2a621160ba2dc667d67668879ea a1f3ebaec888b5bb816fa5b3437eb3ff7d81b415
git push -f origin

@thaJeztah - @lbernail just needs to sign this commit for this PR

I just signed-off and pushed

If you think it's preferable to cherry-pick the commits instead of updating the vendors I'll do that of course (the end result should be the same because #3423 also updates cgroups to c4b9ac5, right?)

Codecov Report

Merging #4001 into release/1.2 will not change coverage.
The diff coverage is n/a.

@@             Coverage Diff              @@
##           release/1.2    #4001   +/-   ##
============================================
  Coverage        44.19%   44.19%           
============================================
  Files              100      100           
  Lines            10847    10847           
============================================
  Hits              4794     4794           
  Misses            5313     5313           
  Partials           740      740

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 35bd7a5...25a806c. Read the comment docs.

I'm not sure it matters a ton. @dmcgowan - Do you have a preference that this be a cherry pick from mainline?

Whoops, didn't catch up;

If you think it's preferable to cherry-pick the commits instead of updating the vendors I'll do that of course (the end result should be the same because #3423 also updates cgroups to c4b9ac5, right?)

Yes, the end result would the same; it's "metadata" that would differ; I usually try to cherry-pick to keep references to the original commit (the -x option helps there); in some cases one may be interested if a specific commit found its way in other branches, or the original commit / PR has a discussion related to it that can be relevant.

Not a blocker probably

I completely understand how reusing the master commits helps with readability
I tried the cherry-pick but it's not straightforward because we get conflicts with unrelated vendor dependencies (go-runc and console).
Probably easily fixable but it will not be as clean as just getting the 2 commits