From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 537BDC433E5 for ; Wed, 15 Jul 2020 13:56:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2F60420657 for ; Wed, 15 Jul 2020 13:56:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729670AbgGON4H (ORCPT ); Wed, 15 Jul 2020 09:56:07 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:48121 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729086AbgGON4H (ORCPT ); Wed, 15 Jul 2020 09:56:07 -0400 Received: from ip5f5af08c.dynamic.kabel-deutschland.de ([95.90.240.140] helo=wittgenstein) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1jvht5-0005LP-Jl; Wed, 15 Jul 2020 13:55:55 +0000 Date: Wed, 15 Jul 2020 15:55:54 +0200 From: Christian Brauner To: Florian Weimer Cc: Mathieu Desnoyers , carlos , Peter Zijlstra , linux-kernel , Thomas Gleixner , paulmck , Boqun Feng , "H. Peter Anvin" , Paul Turner , linux-api Subject: Re: [RFC PATCH 2/4] rseq: Allow extending struct rseq Message-ID: <20200715135554.4q6aamx4iqd4mnqh@wittgenstein> References: <20200714030348.6214-1-mathieu.desnoyers@efficios.com> <87mu42bepq.fsf@oldenburg2.str.redhat.com> <131549905.11442.1594731035989.JavaMail.zimbra@efficios.com> <87a7028d5u.fsf@oldenburg2.str.redhat.com> <2452161.11491.1594732791558.JavaMail.zimbra@efficios.com> <71f08b3a-56f5-0e0f-53b0-cc680f7e8181@redhat.com> <2053637148.14136.1594818777608.JavaMail.zimbra@efficios.com> <87y2nk29rp.fsf@oldenburg2.str.redhat.com> <882700738.14181.1594819884049.JavaMail.zimbra@efficios.com> <87mu4028uk.fsf@oldenburg2.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87mu4028uk.fsf@oldenburg2.str.redhat.com> Sender: linux-api-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org On Wed, Jul 15, 2020 at 03:42:11PM +0200, Florian Weimer wrote: > * Mathieu Desnoyers: > > > So indeed it could be done today without upgrading the toolchains by > > writing custom assembler for each architecture to get the thread's > > struct rseq. AFAIU the ABI to access the thread pointer is fixed for > > each architecture, right ? > > Yes, determining the thread pointer and access initial-exec TLS > variables is baked into the ABI. > > > How would this allow early-rseq-adopter libraries to interact with > > glibc ? > > Under all extension proposals I've seen so far, early adopters are > essentially incompatible with glibc rseq registration. I don't think > you can have it both ways. Who are the early adopters? And if we aren't being compatible with them under the extensible schemes proposed we should be able to achieve compatibility with non-early adopters, right? Which I guess is more important. (I still struggle to make sense what qualifies as an early adopter/what the difference to a non-early adopter is.) Christian