From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: 'core-updates' spring 2018 Date: Wed, 28 Mar 2018 15:32:40 +0200 Message-ID: <87bmf8fhqf.fsf@elephly.net> References: <87h8p3jfke.fsf@fastmail.com> <87a7uuhejf.fsf@elephly.net> <87po3ph0t1.fsf@fastmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:57602) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1BQw-00043I-8s for guix-devel@gnu.org; Wed, 28 Mar 2018 09:48:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f1BQr-0007n5-6b for guix-devel@gnu.org; Wed, 28 Mar 2018 09:48:10 -0400 Received: from sender-of-o51.zoho.com ([135.84.80.216]:21120) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1f1BQq-0007mG-U4 for guix-devel@gnu.org; Wed, 28 Mar 2018 09:48:05 -0400 In-reply-to: <87po3ph0t1.fsf@fastmail.com> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Marius Bakke Cc: guix-devel@gnu.org 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=E2=80=99m not sure, but I looked at the RHEL6 kernel=E2=80=99s syscall ta= ble: 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=E2=80=99t know what =E2=80=9Cavailable=E2=80=9D is supposed to mean f= or number 285 (fallocate?) when the syscall is not implemented. =E2=80=9Cvserver=E2=80= =9D is not implemented on purpose according to man 2 unimplemented. Also, I=E2=80=99ve been using a bunch of applications with the grafted glib= c, and the only thing I had problems with was Java=E2=80=99s use of prlimit64.= If the other missing syscalls are problematic they don=E2=80=99t seem to affec= t the software that is in use on the cluster. Below I=E2=80=99ll refer to Linux 2.6.32-696.3.2.el6.x86_64, i.e. the curre= nt RHEL6 kernel for x86_64. > Here is the commit that removes the fallback code for missing prlimit64: > https://sourceware.org/git/?p=3Dglibc.git;a=3Dcommitdiff;h=3D695d7d138eda= 449678a1650a8b8b58181033353f > > And here are similar commits I found by grepping the log for '3.2': > https://sourceware.org/git/?p=3Dglibc.git;a=3Dcommitdiff;h=3De92030239abb= 4038d4f915d47021d6c037239309 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=3Dglibc.git;a=3Dcommitdiff;h=3D1721145f0341= d70a6d7807b172c5eb400b508fc0 This is about /proc/self/task/$PID/comm, which exists. > https://sourceware.org/git/?p=3Dglibc.git;a=3Dcommitdiff;h=3D9a45f5431057= 3c190fa270e1f80d8307750305e9 This is about recvmmsg, which is implemented. > https://sourceware.org/git/?p=3Dglibc.git;a=3Dcommitdiff;h=3De8f1225ca4d4= afa4043c5267ae6dbe12268e2637 This is about the flags from statvfs. I don=E2=80=99t know how to ascertai= n 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=E2=80=99m not too happy with this, because the longer we delay this the m= ore 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=E2=80=99t just r= evert 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=E2=80=99t want to spend time investigating this, but if someone wants= to work on this I=E2=80=99d 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