Hi Marius,
> Are you sure prlimit64 is the only syscall that needs to be adjusted? A
> quick grep through through the commit log reveals some other interfaces
> that may need to be restored.
I’m not sure, but I looked at the RHEL6 kernel’s syscall table:
curl
http://vault.centos.org/6.9/os/Source/SPackages/kernel-2.6.32-696.el6.src.rpm |
rpm2cpio - | cpio -idmv
tar xf linux-*bz2
less linux-*?/arch/x86/kernel/syscall_table_32.S
Looking at the table I see that the following syscalls are not
implemented and not marked as old or reserved:
.long sys_ni_syscall /* sys_vserver */
.long sys_ni_syscall /* 285 */ /* available */
.long sys_ni_syscall /* sys_fanotify_init */
.long sys_ni_syscall /* sys_fanotify_mark */
.long sys_ni_syscall /* sys_prlimit64 340 */
.long sys_ni_syscall /* sys_name_to_handle_at */
.long sys_ni_syscall /* sys_open_by_handle_at */
I don’t know what “available” is supposed to mean for number 285
(fallocate?) when the syscall is not implemented. “vserver” is
not implemented on purpose according to man 2 unimplemented.
Also, I’ve been using a bunch of applications with the grafted glibc,
and the only thing I had problems with was Java’s use of prlimit64. If
the other missing syscalls are problematic they don’t seem to affect the
software that is in use on the cluster.
Below I’ll refer to Linux 2.6.32-696.3.2.el6.x86_64, i.e. the current
RHEL6 kernel for x86_64.
> Here is the commit that removes the fallback code for missing prlimit64:
> https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=695d7d138eda449678a1650a8b8b58181033353f
>
> And here are similar commits I found by grepping the log for '3.2':
> https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=e92030239abb4038d4f915d47021d6c037239309
This is about accept4, which I cannot find in the syscall table, but
which is defined in include/linux/net.h and include/linux/syscalls.h.
> https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=1721145f0341d70a6d7807b172c5eb400b508fc0
This is about /proc/self/task/$PID/comm, which exists.
> https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=9a45f54310573c190fa270e1f80d8307750305e9
This is about recvmmsg, which is implemented.
> https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=e8f1225ca4d4afa4043c5267ae6dbe12268e2637
This is about the flags from statvfs. I don’t know how to ascertain
whether this is implemented or not.
> Since it's fairly late in the core-updates cycle, I think it would be
> better to try restoring the prlimit64 fallback on the "rhel6" branch and
> then revisit this during the next core-updates.
I’m not too happy with this, because the longer we delay this the more
packages we have to build. The longer the rhel6 branch has to be kept
alive the more urgent it becomes to build rhel6-core-updates and
duplicate efforts for the variant where glibc 2.25 is used. I want to
keep this situation as short-lived as possible.
The change would only affect the 2.6.32 kernel (we shouldn’t just revert
that prlimit64 commit, but pick only the relevant parts).
> This got me thinking, perhaps it's possible to run Guix through a thin
> hypervisor layer that uses the host virtualization facilities, or a Qemu
> built against glibc 2.25. This is similar to how "Docker" runs on
> macOS, maybe it could be used for Guix in "hostile environments" too?
I don’t want to spend time investigating this, but if someone wants to
work on this I’d be happy to test the results on my RHEL6 systems.
--
Ricardo
GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC
https://elephly.net
