This is the mail archive of the
mailing list for the glibc project.
Re: [RFC PATCH] glibc: Perform rseq(2) registration at nptl init and thread creation
- From: Mathieu Desnoyers <mathieu dot desnoyers at efficios dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: carlos <carlos at redhat dot com>, Florian Weimer <fweimer at redhat dot com>, Thomas Gleixner <tglx at linutronix dot de>, Ben Maurer <bmaurer at fb dot com>, Peter Zijlstra <peterz at infradead dot org>, "Paul E. McKenney" <paulmck at linux dot vnet dot ibm dot com>, Boqun Feng <boqun dot feng at gmail dot com>, Will Deacon <will dot deacon at arm dot com>, Dave Watson <davejwatson at fb dot com>, Paul Turner <pjt at google dot com>, libc-alpha <libc-alpha at sourceware dot org>, linux-kernel <linux-kernel at vger dot kernel dot org>, linux-api <linux-api at vger dot kernel dot org>
- Date: Thu, 20 Sep 2018 16:14:17 -0400 (EDT)
- Subject: Re: [RFC PATCH] glibc: Perform rseq(2) registration at nptl init and thread creation
- Dkim-filter: OpenDKIM Filter v2.10.3 mail.efficios.com 632C5240D4F
- References: <firstname.lastname@example.org> <alpine.DEB.email@example.com> <67473000.8399.1537375994645.JavaMail.firstname.lastname@example.org> <alpine.DEB.email@example.com>
----- On Sep 19, 2018, at 1:10 PM, Joseph Myers firstname.lastname@example.org wrote:
> On Wed, 19 Sep 2018, Mathieu Desnoyers wrote:
>> > This looks like it's coming from the Linux kernel. Can't the relevant
>> > uapi header just be used directly without copying into glibc (with due
>> > care to ensure that glibc still builds if the kernel headers used for the
>> > build are too old - you need such conditionals anyway if they don't define
>> > the relevant syscall number)?
>> This is indeed in the list of "things to consider" I've put in the patch
>> commit message. If the usual practice is to build against uapi kernel headers
>> outside of the glibc tree, I'm fine with that.
> We build with, currently, 3.2 or later headers (since 3.2 is EOL there's a
> case for updating the minimum in glibc for both compile time and runtime,
> but I haven't proposed that since there isn't much cleanup that would
> enable and there's the open question of Carlos's proposal to eliminate the
> runtime check on the kernel version and just let things try to run anyway
> even if it's older than the configured minimum).
Are you saying glibc has an explicit check for the kernel version visible
from /proc before using specific features ? If so, how can this work with
the variety of feature backports we find in the distribution kernels out
Checking whether specific system calls return ENOSYS errors seems more
> Functions depending on
> new syscalls may return ENOSYS errors if the headers used to build glibc
> were too old. Since this patch is providing a data interface rather than
> functions that can set errno to ENOSYS, presumably you have some other way
> of signalling unavailability which would apply both with a too-old kernel
> at runtime and too-old headers at compile time.
For too-old kernel at runtime, having rseq registration return ENOSYS
leaves the the content of __rseq_abi->cpu_id at its initial value
(RSEQ_CPU_ID_UNINITIALIZED = -1).
For too-old headers at compile time, one possibility is that we don't event
expose the __rseq_abi TLS symbol. OTOH, if we need to keep exposing it anyway
for ABI consistency purposes, then we'd leave its cpu_id field at the initial
value (-1). But that would require that we copy linux/rseq.h into the glibc
> Joseph S. Myers