linux(4): bump osrelease to 4.4.0.

[trasz]

Summary

This is required for the current Arch Linux binaries to work.

PR: 254112

[trasz]

Note that this is necessary, but not sufficient, to make Arch work; see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254112 for details.

[emaste]

Combined with AT_EMPTY_PATH is this sufficient to make it work?

[trasz]

In D29218#669121, @emaste wrote:

Combined with AT_EMPTY_PATH is this sufficient to make it work?

Yes.

[emaste]

I think this change is good.

In D28105 we discussed new syscalls leading up to the bump to 3.17.0. IMO we should (as a separate change) have a fairly descriptive comment here describing our approach for choosing the reported Linux kernel version, as well as techniques to identify new syscalls when bumping (so that we are at least aware of what's added).

For example, tig v3.7..v4.4 include/uapi/asm-generic/unistd.h, turns up these added syscalls, at least some of which we have implemented:

• finit_module
• sched_setattr
• sched_getattr
• renameat2
• seccomp
• getrandom
• memfd_create
• bpf
• execveat
• membarrier
• userfaultfd
• mlock2

[emaste]

And after 4.4 we have:

• copy_file_range
• preadv2
• pwritev2
• pkey_mprotect
• pkey_alloc
• pkey_free
• statx
• io_pgetevents
• rseq
• kexec_file_load
• io_uring_setup
• io_uring_enter
• io_uring_register
• pidfd_send_signal
• open_tree
• move_mount
• fsopen
• fsconfig
• fspick
• pidfd_open
• clone3
• openat2
• pidfd_getfd
• fsaccessat2
• close_range
• process_madvise
• epoll_pwait2
• mount_setattr

also a bunch of 64-bit time_t compat from 2019

removed:

• renameat
• getrlimit
• setrlimit

[trasz]

I'm not sure if I understand the reason for this, though. Are there still places in glibc which decide to fall back to older syscalls based on the kernel version?

[emaste]

I'm not sure if I understand the reason for this, though. Are there still places in glibc which decide to fall back to older syscalls based on the kernel version?

I don't know - I just mean we should give some guidance as to what version we pick, when we change it, and what to look at to figure out what new functionality we need. In other words, why is this 4.4 and not, say, 4.3 or 4.5? Presumably we try to track LTS kernel versions in wide use, as far as the functionality we support. So perhaps we'll go up to 4.15 and then 5.4 next?

https://askubuntu.com/questions/517136/list-of-ubuntu-versions-with-corresponding-linux-kernel-version

[trasz]

Well, in this case - and the last few bumps I've done - it was motivated by newer glibc simply refusing to start the binary with anything older than the number chosen. In other words, the new version is the lowest one for which binaries don't fail with "FATAL: kernel too old".