Re: Requiring Linux 3.2 for glibc 2.24

[Florian Weimer <fweimer at redhat dot com>]

On 02/11/2016 11:08 AM, Dmitry Mishin wrote:

>> So in short, I don't see how the overall situation with regards to
>> containers worsens if glibc adopts a minimum kernel version of 3.2.

> That's true till some point.
> First, I believe not all distributions have such define already. For
> example, RHEL/CentOS 7 does not.

This isn't really relevant because I am pretty sure that Red Hat
Enterprise Linux will never upgrade to a new upstream glibc version
within a major release.  This means that the minimum kernel version
required by upstream glibc will not affect Red Hat Enterprise Linux 7 or
CentOS 7, and the glibc minimum kernel requirement will stay at 2.6.32.

> Second, our hacks to falsify the kernel version are enabled by a Container
> template parameter, which we specify in templates which are provisioned by
> OpenVZ team. The problem is that some users (VPS hosters) prefer to make
> their own templates. And I doubt they specify fake kernel version unless it is
> absolutely required by a distribution.

Fair enough.  But I still don't see how glibc upstream can influence
minimum kernel requirements by downstream distributions.  It seems to me
that you need to convince those distributions not to require post-2.6.32
kernels even today, despite the 2.6.32 support in glibc upstream.  You
already have code to accommodate them, it seems, so I would expect that
--enable-kernel=3.2 upstream would not cause any additional issues for you.

There is, admittedly, a risk that we make further changes, beyond what
is switched on by --enable-kernel=3.2 today, and that would break your
setups, but the only answer to that seems increased testing.

> So, in short, there could be some users with modern distribution (like
> CentOS 7) with non-fake 2.6.32 kernel version. And they'll be affected by this
> change IF CentOS decides to bump glibc version.

While it's difficult to predict the future, this is excessively unlikely
to happen.  (If you concerned about kernel requirements of Red Hat
Enterprise Linux, maybe you should join a Red Hat partner program, or
make at least sure current Fedora works well, which should approximate
future Red Hat Enterprise Linux kernel requirements.)

A better example may be Debian: A change in minimum kernel version could
fairly quickly land in Debian testing, which some people might to use
with your container technology.  But again, with distributions passing
--enable-kernel=3.2 today, you already are in that situation.

> BTW, is VDSO the only place for glibc to determine kernel version nowadays?

Not sure what you mean.  There are a lot of individual feature checks
scattered throughout the code.  The minimal kernel version check by the
loader (I assume that's what you are referring to) is just a sanity check.

>> (I am worried about /proc and /sys layout differences between the
>> various container technologies out there, and there have already been
>> proposals discussed on this list which would not work in certain
>> containers, without us realizing at the time that there would be a
>> compatibility issue.  Without more upstream testing involving various
>> container technologies, such issues, if they make it into the code base,
>> will only be caught extremely late.)

> How could we help here?

It's not clear to me how much of /sys contents is subject to OpenVZ
configuration.  For example, there were suggestions to obtain CPU
contains from this directory:

$ ls -l /sys/devices/system/cpu/
total 0
drwxr-xr-x. 9 root root    0 Dec 21 11:21 cpu0
drwxr-xr-x. 9 root root    0 Dec 21 11:21 cpu1
drwxr-xr-x. 9 root root    0 Dec 21 11:21 cpu2
drwxr-xr-x. 9 root root    0 Dec 21 11:21 cpu3
drwxr-xr-x. 9 root root    0 Dec 21 11:21 cpu4
drwxr-xr-x. 9 root root    0 Dec 21 11:21 cpu5
drwxr-xr-x. 9 root root    0 Dec 21 11:21 cpu6
drwxr-xr-x. 9 root root    0 Dec 21 11:21 cpu7
drwxr-xr-x. 2 root root    0 Feb  3 17:57 cpuidle
drwxr-xr-x. 2 root root    0 Feb  3 17:57 intel_pstate
-r--r--r--. 1 root root 4096 Feb 11 12:54 isolated
-r--r--r--. 1 root root 4096 Dec 21 11:24 kernel_max
drwxr-xr-x. 2 root root    0 Feb  3 17:57 microcode
-r--r--r--. 1 root root 4096 Feb 11 12:54 modalias
-r--r--r--. 1 root root 4096 Feb 11 12:54 nohz_full
-r--r--r--. 1 root root 4096 Feb 11 12:54 offline
-r--r--r--. 1 root root 4096 Dec 21 11:22 online
-r--r--r--. 1 root root 4096 Dec 21 11:24 possible
drwxr-xr-x. 2 root root    0 Feb  3 17:57 power
-r--r--r--. 1 root root 4096 Dec 21 11:22 present
-rw-r--r--. 1 root root 4096 Jan  7 12:54 uevent

But as I understand it, most of the files (such as kernel_max) are not
available in some OpenVZ configurations.  We had a previous discussion
about using them.

I think the only way to detect such incompatibilities is actual testing
during upstream development (or perhaps timely testing of some
downstreams which track glibc upstream fairly aggressively, such as
Fedora rawhide).

Florian