From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.efficios.com (mail.efficios.com [167.114.26.124]) by sourceware.org (Postfix) with ESMTPS id 62A34385BF81 for ; Tue, 14 Jul 2020 17:12:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 62A34385BF81 Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 267C42C0153; Tue, 14 Jul 2020 13:12:01 -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 51C9VAA9hw8I; Tue, 14 Jul 2020 13:12:00 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id DB8402C01D0; Tue, 14 Jul 2020 13:12:00 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com DB8402C01D0 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 6Ybz_8nNKk2Z; Tue, 14 Jul 2020 13:12:00 -0400 (EDT) Received: from mail03.efficios.com (mail03.efficios.com [167.114.26.124]) by mail.efficios.com (Postfix) with ESMTP id CF3BB2C0521; Tue, 14 Jul 2020 13:12:00 -0400 (EDT) Date: Tue, 14 Jul 2020 13:12:00 -0400 (EDT) From: Mathieu Desnoyers To: Florian Weimer Cc: Szabolcs Nagy , Christian Brauner , libc-alpha , Joseph Myers Message-ID: <636217176.12080.1594746720754.JavaMail.zimbra@efficios.com> In-Reply-To: <87eepe6ncm.fsf@oldenburg2.str.redhat.com> References: <20200713193434.30440-1-mathieu.desnoyers@efficios.com> <87v9iq6w25.fsf@oldenburg2.str.redhat.com> <1165023597.11584.1594735445006.JavaMail.zimbra@efficios.com> <87lfjm6spp.fsf@oldenburg2.str.redhat.com> <191373869.11732.1594740618639.JavaMail.zimbra@efficios.com> <20200714160120.GA28180@arm.com> <386668376.11934.1594743122356.JavaMail.zimbra@efficios.com> <87eepe6ncm.fsf@oldenburg2.str.redhat.com> Subject: Re: [RFC PATCH glibc] Linux: Use fixed rseq_len value for rseq registration MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [167.114.26.124] X-Mailer: Zimbra 8.8.15_GA_3955 (ZimbraWebClient - FF78 (Linux)/8.8.15_GA_3953) Thread-Topic: Linux: Use fixed rseq_len value for rseq registration Thread-Index: K9aUPpIJLy8Sbol8h8aUNYZYNfSoFw== X-Spam-Status: No, score=-8.5 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2020 17:12:02 -0000 ----- On Jul 14, 2020, at 1:03 PM, Florian Weimer fweimer@redhat.com wrote: > * Mathieu Desnoyers: > >> ----- On Jul 14, 2020, at 12:01 PM, Szabolcs Nagy szabolcs.nagy@arm.com wrote: >> >>> The 07/14/2020 11:30, Mathieu Desnoyers via Libc-alpha wrote: >>>> > I think we are looking at this from the wrong perspective. It's not >>>> > userspace that is setting the size here, it's the kernel based on the >>>> > features it supports. So the kernel should put the size into the >>>> > auxiliary vector, and the registration should use that size. But that >>>> > doesn't align well with the use of an ELF TLS symbol. >>> >>> this is why it is better to use a function that returns >>> a pointer than a tls symbol as public abi. >>> >>>> We have a few possible ways to do things here: >>>> >>>> 1) Kernel exports supported size, incompatible with ELF TLS symbol, >>>> >>>> 2) Userspace dictates supported size, compatible with ELF TLS symbol, >>>> triggers failure if the kernel supports a smaller size, >>>> >>>> 3) Userspace lets kernel know how much space is available for struct rseq >>>> (through user_size field), and the kernel lets user-space know how much >>>> of that structure is being filled (through kernel_size field). This >>>> would also be compatible with ELF TLS symbol AFAIU, and would allow >>>> extending struct rseq. >>>> >>>> Option (3) would allow us to have the speed gains that come with using a >>>> TLS from the fast-path, while allowing extension of struct rseq. >>>> >>>> Or is there anything in that scheme that breaks ELF rules or C language >>>> requirements ? >>> >>> how would users access those extension fields? >> >> if (__rseq_abi.flags & RSEQ_TLS_FLAG_SIZE) { >> /* Allowed to access user_size and kernel_size. */ >> if (__rseq_abi.kernel_size >= offsetof(struct rseq, myfield) + sizeof(((struct >> rseq *)NULL)->myfield)) { >> /* Allowed to access __rseq_abi.myfield. User code should remember this, e.g. in >> a static variable. */ >> } >> } > > Technically, this needs a compiler extension, so that the allowed > accesses to the __rseq_abi.myfield field are not moved before the flags > and size checks. If those accesses are performed as volatile loads, or with atomic relaxed semantic, the compiler should not be allowed to change the order. Likewise if we use asm volatile (::: "memory") clobber between the loads. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com