Page MenuHomeFreeBSD

linux(4): bump osrelease to 4.4.0.
ClosedPublic

Authored by trasz on Mar 11 2021, 1:06 PM.

Details

Summary

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

PR: 254112

Diff Detail

Repository
rG FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

trasz requested review of this revision.Mar 11 2021, 1:06 PM

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.

trasz added a reviewer: Linux Emulation.

Combined with AT_EMPTY_PATH is this sufficient to make it work?

Combined with AT_EMPTY_PATH is this sufficient to make it work?

Yes.

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
This revision is now accepted and ready to land.Apr 18 2021, 8:08 PM

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

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?

This revision was automatically updated to reflect the committed changes.

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

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".