Message ID | 20200527185130.5604-1-mathieu.desnoyers@efficios.com |
---|---|
Headers |
Return-Path: <libc-alpha-bounces@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 073B6383F854; Wed, 27 May 2020 18:51:40 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 073B6383F854 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1590605500; bh=KZHe+TVVUJpO//CffNSSpvY7HKoifFiBzqDcUJUPmwA=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=iUWWfsy3+yQnVykrAF39Bipdz496vpCjuIlK9iQRC3FnHiYTn9VnmL6Y1G/ixA0lm 2Q6xKdUwAYgZRIG7vm3qiLiT6lmqcztrKPXMB70rcBQP24pKe5gC1CIYR+L/z9OMqw 1E+0xSSs7zhGTVNTkCofgB9z3J+ZqIRUXcwB6JsA= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mail.efficios.com (mail.efficios.com [167.114.26.124]) by sourceware.org (Postfix) with ESMTPS id 3C431386F45A for <libc-alpha@sourceware.org>; Wed, 27 May 2020 18:51:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3C431386F45A Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id F00D2278D11; Wed, 27 May 2020 14:51:37 -0400 (EDT) Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id SMDpfyrPUIWz; Wed, 27 May 2020 14:51:37 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 8B0AD278D10; Wed, 27 May 2020 14:51:37 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com 8B0AD278D10 X-Virus-Scanned: amavisd-new at efficios.com Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id CEmADZ5uX2oP; Wed, 27 May 2020 14:51:37 -0400 (EDT) Received: from localhost.localdomain (192-222-181-218.qc.cable.ebox.net [192.222.181.218]) by mail.efficios.com (Postfix) with ESMTPSA id 52EBD278C26; Wed, 27 May 2020 14:51:37 -0400 (EDT) To: Florian Weimer <fweimer@redhat.com> Subject: [PATCH glibc 0/3] Restartable Sequences enablement Date: Wed, 27 May 2020 14:51:27 -0400 Message-Id: <20200527185130.5604-1-mathieu.desnoyers@efficios.com> X-Mailer: git-send-email 2.17.1 X-Spam-Status: No, score=-12.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list <libc-alpha.sourceware.org> List-Unsubscribe: <http://sourceware.org/mailman/options/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help> List-Subscribe: <http://sourceware.org/mailman/listinfo/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=subscribe> From: Mathieu Desnoyers via Libc-alpha <libc-alpha@sourceware.org> Reply-To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: libc-alpha@sourceware.org, Joseph Myers <joseph@codesourcery.com>, Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces@sourceware.org> |
Series | Restartable Sequences enablement | |
Message
Mathieu Desnoyers
May 27, 2020, 6:51 p.m. UTC
Hi, Please find the rseq enablement patchset for inclusion into glibc. I took care of the last round of feedback from Florian, and rebased the series on glibc's master branch. I also noticed a few tabs that were still present in some header files, and changed those for spaces to align better with glibc's coding style. Florian, if you find the patches OK and possibly with a bit of tweaking of the commit messages, can you please commit them to glibc ? Thanks! Mathieu Mathieu Desnoyers (3): glibc: Perform rseq registration at C startup and thread creation (v20) Linux: Use rseq in sched_getcpu if available (v9) rseq registration tests (v11) NEWS | 10 + elf/libc_early_init.c | 4 + manual/threads.texi | 63 +++++ nptl/pthread_create.c | 13 + sysdeps/generic/rseq-internal.h | 26 ++ sysdeps/unix/sysv/linux/Makefile | 15 +- sysdeps/unix/sysv/linux/Versions | 1 + sysdeps/unix/sysv/linux/aarch64/bits/rseq.h | 43 +++ sysdeps/unix/sysv/linux/aarch64/libc.abilist | 1 + sysdeps/unix/sysv/linux/alpha/libc.abilist | 1 + sysdeps/unix/sysv/linux/arm/be/libc.abilist | 1 + sysdeps/unix/sysv/linux/arm/bits/rseq.h | 83 ++++++ sysdeps/unix/sysv/linux/arm/le/libc.abilist | 1 + sysdeps/unix/sysv/linux/bits/rseq.h | 29 ++ sysdeps/unix/sysv/linux/csky/libc.abilist | 1 + sysdeps/unix/sysv/linux/hppa/libc.abilist | 1 + sysdeps/unix/sysv/linux/i386/libc.abilist | 1 + sysdeps/unix/sysv/linux/ia64/libc.abilist | 1 + .../sysv/linux/m68k/coldfire/libc.abilist | 1 + .../unix/sysv/linux/m68k/m680x0/libc.abilist | 1 + .../sysv/linux/microblaze/be/libc.abilist | 1 + .../sysv/linux/microblaze/le/libc.abilist | 1 + sysdeps/unix/sysv/linux/mips/bits/rseq.h | 62 +++++ .../sysv/linux/mips/mips32/fpu/libc.abilist | 1 + .../sysv/linux/mips/mips32/nofpu/libc.abilist | 1 + .../sysv/linux/mips/mips64/n32/libc.abilist | 1 + .../sysv/linux/mips/mips64/n64/libc.abilist | 1 + sysdeps/unix/sysv/linux/nios2/libc.abilist | 1 + sysdeps/unix/sysv/linux/powerpc/bits/rseq.h | 37 +++ .../linux/powerpc/powerpc32/fpu/libc.abilist | 1 + .../powerpc/powerpc32/nofpu/libc.abilist | 1 + .../linux/powerpc/powerpc64/be/libc.abilist | 1 + .../linux/powerpc/powerpc64/le/libc.abilist | 1 + .../unix/sysv/linux/riscv/rv64/libc.abilist | 1 + sysdeps/unix/sysv/linux/rseq-internal.h | 73 +++++ sysdeps/unix/sysv/linux/rseq-sym.c | 26 ++ sysdeps/unix/sysv/linux/s390/bits/rseq.h | 37 +++ .../unix/sysv/linux/s390/s390-32/libc.abilist | 1 + .../unix/sysv/linux/s390/s390-64/libc.abilist | 1 + sysdeps/unix/sysv/linux/sched_getcpu.c | 22 +- sysdeps/unix/sysv/linux/sh/be/libc.abilist | 1 + sysdeps/unix/sysv/linux/sh/le/libc.abilist | 1 + .../sysv/linux/sparc/sparc32/libc.abilist | 1 + .../sysv/linux/sparc/sparc64/libc.abilist | 1 + sysdeps/unix/sysv/linux/sys/rseq.h | 228 ++++++++++++++++ sysdeps/unix/sysv/linux/tst-rseq-nptl.c | 256 ++++++++++++++++++ sysdeps/unix/sysv/linux/tst-rseq.c | 64 +++++ sysdeps/unix/sysv/linux/tst-rseq.h | 59 ++++ sysdeps/unix/sysv/linux/x86/bits/rseq.h | 30 ++ .../unix/sysv/linux/x86_64/64/libc.abilist | 1 + .../unix/sysv/linux/x86_64/x32/libc.abilist | 1 + 51 files changed, 1206 insertions(+), 5 deletions(-) create mode 100644 sysdeps/generic/rseq-internal.h create mode 100644 sysdeps/unix/sysv/linux/aarch64/bits/rseq.h create mode 100644 sysdeps/unix/sysv/linux/arm/bits/rseq.h create mode 100644 sysdeps/unix/sysv/linux/bits/rseq.h create mode 100644 sysdeps/unix/sysv/linux/mips/bits/rseq.h create mode 100644 sysdeps/unix/sysv/linux/powerpc/bits/rseq.h create mode 100644 sysdeps/unix/sysv/linux/rseq-internal.h create mode 100644 sysdeps/unix/sysv/linux/rseq-sym.c create mode 100644 sysdeps/unix/sysv/linux/s390/bits/rseq.h create mode 100644 sysdeps/unix/sysv/linux/sys/rseq.h create mode 100644 sysdeps/unix/sysv/linux/tst-rseq-nptl.c create mode 100644 sysdeps/unix/sysv/linux/tst-rseq.c create mode 100644 sysdeps/unix/sysv/linux/tst-rseq.h create mode 100644 sysdeps/unix/sysv/linux/x86/bits/rseq.h
Comments
This series unfortunately needs to be rebased (with conflicts) on current master. There is a new elf/tst-auditmany failure, showing bug 26076, but actually caused by bug 26075 (I think). I will attempt to work around these two issues, which are independent of the rseq changes. As I said before, I would like to see some consensus if the level of testing and documentation in this series is appropriate for this feature. Thanks, Florian
----- On Jun 3, 2020, at 8:07 AM, Florian Weimer fweimer@redhat.com wrote: > This series unfortunately needs to be rebased (with conflicts) on > current master. I can rebase it again if you wish, but I would like to get some consensus on the testing and documentation from other maintainers first. Every now and then a new symbol is added into the master branch for all architectures, and rebasing the rseq patches on top of that at this point is wasted effort unless we are nearly ready to merge. > > There is a new elf/tst-auditmany failure, showing bug 26076, but > actually caused by bug 26075 (I think). I will attempt to work around > these two issues, which are independent of the rseq changes. OK > As I said before, I would like to see some consensus if the level of > testing and documentation in this series is appropriate for this > feature. Likewise, Thanks, Mathieu
* Mathieu Desnoyers: > ----- On Jun 3, 2020, at 8:07 AM, Florian Weimer fweimer@redhat.com wrote: > >> This series unfortunately needs to be rebased (with conflicts) on >> current master. > > I can rebase it again if you wish, but I would like to get some > consensus on the testing and documentation from other maintainers > first. Every now and then a new symbol is added into the master > branch for all architectures, and rebasing the rseq patches on top > of that at this point is wasted effort unless we are nearly ready > to merge. Fine by me. (With a bit of luck, I'll get annoyed enough by this problem and write a custom merge driver for abilist files.) Thanks, Florian
* Florian Weimer via Libc-alpha: > This series unfortunately needs to be rebased (with conflicts) on > current master. > > There is a new elf/tst-auditmany failure, showing bug 26076, but > actually caused by bug 26075 (I think). I will attempt to work around > these two issues, which are independent of the rseq changes. Mathieu, it turns out that a change like this is needed: diff --git a/elf/dl-tls.c b/elf/dl-tls.c index fa03234610..817bcbbf59 100644 --- a/elf/dl-tls.c +++ b/elf/dl-tls.c @@ -31,7 +31,7 @@ /* Amount of excess space to allocate in the static TLS area to allow dynamic loading of modules defining IE-model TLS data. */ -#define TLS_STATIC_SURPLUS 64 + DL_NNS * 100 +#define TLS_STATIC_SURPLUS 64 + DL_NNS * 176 /* Out-of-memory handler. */ I think you can just put that into the main rseq patch. This change needs to be mentioned in the commit message, of course. With this change, elf/tst-auditmany passes again for me. The increase (76 bytes) is larger than 32 bytes because we have not done this in quite a while. The cost in terms of additional TLS storage is quite significant, but it will also obscure some initial-exec-related dlopen failures. Conceptually, we could also switch to 64 + (DL_NNS - 1) * 176, an increase of 1040 bytes over what we have today. Thanks, Florian
----- On Jun 3, 2020, at 9:40 AM, Florian Weimer fweimer@redhat.com wrote: > * Florian Weimer via Libc-alpha: > >> This series unfortunately needs to be rebased (with conflicts) on >> current master. >> >> There is a new elf/tst-auditmany failure, showing bug 26076, but >> actually caused by bug 26075 (I think). I will attempt to work around >> these two issues, which are independent of the rseq changes. > > Mathieu, it turns out that a change like this is needed: > > diff --git a/elf/dl-tls.c b/elf/dl-tls.c > index fa03234610..817bcbbf59 100644 > --- a/elf/dl-tls.c > +++ b/elf/dl-tls.c > @@ -31,7 +31,7 @@ > > /* Amount of excess space to allocate in the static TLS area > to allow dynamic loading of modules defining IE-model TLS data. */ > -#define TLS_STATIC_SURPLUS 64 + DL_NNS * 100 > +#define TLS_STATIC_SURPLUS 64 + DL_NNS * 176 > > > /* Out-of-memory handler. */ > > > I think you can just put that into the main rseq patch. This change > needs to be mentioned in the commit message, of course. > > With this change, elf/tst-auditmany passes again for me. > > The increase (76 bytes) is larger than 32 bytes because we have not done > this in quite a while. The cost in terms of additional TLS storage is > quite significant, but it will also obscure some initial-exec-related > dlopen failures. OK, done! Thanks, Mathieu > > Conceptually, we could also switch to 64 + (DL_NNS - 1) * 176, an > increase of 1040 bytes over what we have today. > > Thanks, > Florian