Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 15 Jul 2020 09:12:57 -0400 (EDT)
From:   Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To:     carlos <carlos@redhat.com>
Cc:     Florian Weimer <fweimer@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        paulmck <paulmck@linux.ibm.com>,
        Boqun Feng <boqun.feng@gmail.com>,
        "H. Peter Anvin" <hpa@zytor.com>, Paul Turner <pjt@google.com>,
        linux-api <linux-api@vger.kernel.org>,
        Christian Brauner <christian.brauner@ubuntu.com>
Message-ID: <2053637148.14136.1594818777608.JavaMail.zimbra@efficios.com>
In-Reply-To: <71f08b3a-56f5-0e0f-53b0-cc680f7e8181@redhat.com>
References: <20200714030348.6214-1-mathieu.desnoyers@efficios.com> <20200714030348.6214-3-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>
Subject: Re: [RFC PATCH 2/4] rseq: Allow extending struct rseq
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Thread-Topic: rseq: Allow extending struct rseq
Thread-Index: 1MYp5kfIfB2JXymSbY4v1NcGryrEAQ==
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

----- On Jul 14, 2020, at 5:30 PM, carlos carlos@redhat.com wrote:

> On 7/14/20 9:19 AM, Mathieu Desnoyers wrote:
>> Is there an arch-agnostic way to get the thread pointer from user-space code ?
>> That
>> would be needed by all rseq critical section implementations.
> 
> Yes, and no. We have void *__builtin_thread_pointer (void), but
> few architectures implement the builtin so we'd have to go through
> a round of compiler updates and backports. All targets know how to
> access the thread pointer because the compiler has to generate
> IE-mode accesses to the TLS variables.

Practically speaking, I suspect this would mean postponing availability of
rseq for widely deployed applications for a few more years ? I can very well
see end users upgrading their kernel and using an early-adoption library
to use rseq today, but requiring to upgrade the entire toolchain will likely
postpone adoption to many years from now.

It would be good to start getting feedback from rseq users so we can progress
on the system call feature development. Unfortunately everything has been in
a stand-still for the past years due to lack of rseq registration coordination
in user-space.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com