cgroup: Remove deprecated property handling.

[osctobe]

memory.kmem.limit_in_bytes knob is deprecated since Linux 5.4 and not writable since Linux 5.16.

[avagin]

rhel8 hasn't reached EOL and it is based on the 4.18 kernel.

@osctobe Does memory.kmem.limit_in_bytes trigger any problems in your environment?

[codecov-commenter]

Codecov Report

Patch coverage has no change and project coverage change: +0.02 :tada:

Comparison is base (1e90fc8) 70.48% compared to head (8af0667) 70.50%.

:exclamation: Current head 8af0667 differs from pull request most recent head c5f6c63. Consider uploading reports for the commit c5f6c63 to get more accurate results

Additional details and impacted files

```diff @@ Coverage Diff @@ ## criu-dev #2212 +/- ## ============================================ + Coverage 70.48% 70.50% +0.02% ============================================ Files 133 133 Lines 33508 33506 -2 ============================================ + Hits 23619 23625 +6 + Misses 9889 9881 -8 ``` | [Impacted Files](https://app.codecov.io/gh/checkpoint-restore/criu/pull/2212?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=None) | Coverage Δ | | |---|---|---| | [criu/cgroup-props.c](https://app.codecov.io/gh/checkpoint-restore/criu/pull/2212?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=None#diff-Y3JpdS9jZ3JvdXAtcHJvcHMuYw==) | `57.89% <ø> (ø)` | | ... and [5 files with indirect coverage changes](https://app.codecov.io/gh/checkpoint-restore/criu/pull/2212/indirect-changes?src=pr&el=tree-more&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=None)

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

[osctobe]

Other than the tests failing on 5.10-based kernel, currently no (as we migrate to the same kernel). But we'd have to check with other users that do migrate between kernel major version.

[adrianreber]

This is still a thing in RHEL 8:

# cd /sys/fs/cgroup/memory/
# cat memory.kmem.limit_in_bytes
9223372036854771712

I am not sure but I think I have also seen warnings/error messages concerning this entry on newer kernels. Cannot really remember.

I found it. On a Fedora 6.2.14-300.fc38.x86_64 kernel with cgroup v1. The property exists during checkpointing:

(00.122069) cg: Dumping value 9223372036854771712 from /proc/self/fd/19/machine.slice/libpod-9bc60d19cfa3fb6b5ccc25dc7a866765e67a44040d381c34f69f113e166bb2fa.scope/container/memory.kmem.limit_in_bytes

But restoring of that property fails:

(00.001748) cg: Restoring cgroup property value [9223372036854771712] to [memory/machine.slice/libpod-9bc60d19cfa3fb6b5ccc25dc7a866765e67a44040d381c34f69f113e166bb2fa.scope/container/memory.kmem.limit_in_bytes]
(00.001769) Error (criu/cgroup.c:1357): cg: Failed writing 9223372036854771712 to memory/machine.slice/libpod-9bc60d19cfa3fb6b5ccc25dc7a866765e67a44040d381c34f69f113e166bb2fa.scope/container/memory.kmem.limit_in_bytes: Operation not supported
(00.001776) Error (criu/cgroup.c:1624): cg: Restoring memory.kmem.limit_in_bytes special property failed

Which is probably the reason for this PR. It is not writeable. Is there a way to probe if it is writeable?

[Snorch]

Might it be that https://github.com/checkpoint-restore/criu/commit/21f5be91a90a420c7e183b61f0a64ab7f0f8f137 already fixed this problem?

[osctobe]

Might it be that 21f5be9 already fixed this problem?

It looks about right. I wanted to also avoid WARNs showing up in dmesg when reading this knob.