All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Carlos O'Donell <carlos@redhat.com>,
	Joseph Myers <joseph@codesourcery.com>,
	Szabolcs Nagy <szabolcs.nagy@arm.com>,
	libc-alpha@sourceware.org, Thomas Gleixner <tglx@linutronix.de>,
	Ben Maurer <bmaurer@fb.com>,
	Peter Zijlstra <peterz@infradead.org>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Boqun Feng <boqun.feng@gmail.com>,
	Will Deacon <will.deacon@arm.com>,
	Dave Watson <davejwatson@fb.com>, Paul Turner <pjt@google.com>,
	Rich Felker <dalias@libc.org>,
	linux-kernel@vger.kernel.org, linux-api@vger.kernel.org
Subject: Re: [RFC PATCH glibc 09/13] glibc: Perform rseq(2) registration at C startup and thread creation (v13)
Date: Tue, 07 Jan 2020 13:23:59 +0100	[thread overview]
Message-ID: <871rsbv4io.fsf@oldenburg2.str.redhat.com> (raw)
In-Reply-To: <20200106155713.397-10-mathieu.desnoyers@efficios.com> (Mathieu Desnoyers's message of "Mon, 6 Jan 2020 10:57:09 -0500")

* Mathieu Desnoyers:

> Register rseq(2) TLS for each thread (including main), and unregister
> for each thread (excluding main). "rseq" stands for Restartable
> Sequences.
>
> See the rseq(2) man page proposed here:
>   https://lkml.org/lkml/2018/9/19/647
>
> This patch is based on glibc-2.30. The rseq(2) system call was merged
> into Linux 4.18.

This patch needs to be updated for some be/le abilist splits.
Big-endian ABI lists for arm, microblaze, sh, appear to be missing.
This is something that can be checked with build-many-glibcs.py.

> diff --git a/manual/threads.texi b/manual/threads.texi
> index 0858ef8f92..059f781120 100644
> --- a/manual/threads.texi
> +++ b/manual/threads.texi
> @@ -881,3 +881,20 @@ Behaves like @code{pthread_timedjoin_np} except that the absolute time in
>  @c pthread_spin_unlock
>  @c pthread_testcancel
>  @c pthread_yield
> +
> +@node Restartable Sequences
> +@section Restartable Sequences
> +@cindex rseq
> +
> +This section describes the @glibcadj{} Restartable Sequences integration.
> +
> +The @glibcadj{} implements a __rseq_abi TLS symbol to interact with the
   @Theglibc{}                  @code{__rseq_abi}


> +Restartable Sequences system call (Linux-specific). The layout of this
> +structure is defined by the Linux kernel rseq.h UAPI. Registration of each
> +thread's __rseq_abi is performed by @glibcadj{} at libc initialization and
                                       @theglibc{}
           @code{__rseq_abi}
> +pthread creation.

> +Each supported architecture provide a RSEQ_SIG signature in sys/rseq.h. That
                                         @code{RSEQ_SIG}       @file{sys/rseq.h} 

> +signature is expected to be present in the code before each Restartable
> +Sequences abort handler. Failure to provide the expected signature may
> +terminate the process with a Segmentation fault.


Two spaces at the end of setences, please.

The manual should use @deftypevar to create an index entry etc. for
__rseq_abi.  See argp_program_version for an example of how to do this.

I think current policy is to have documentation for at least the minimum
functionality in the manual.  I understand that it makes it a lot of
work to write patches which add system call wrappers.

Thanks,
Florian

  reply	other threads:[~2020-01-07 12:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200106155713.397-1-mathieu.desnoyers@efficios.com>
2020-01-06 15:57 ` [RFC PATCH glibc 09/13] glibc: Perform rseq(2) registration at C startup and thread creation (v13) Mathieu Desnoyers
2020-01-07 12:23   ` Florian Weimer [this message]
2020-01-07 20:44     ` Mathieu Desnoyers
2020-01-06 15:57 ` [RFC PATCH glibc 10/13] glibc: sched_getcpu(): use rseq cpu_id TLS on Linux (v5) Mathieu Desnoyers
     [not found] <20191220213650.11281-1-mathieu.desnoyers@efficios.com>
2019-12-20 21:36 ` [RFC PATCH glibc 09/13] glibc: Perform rseq(2) registration at C startup and thread creation (v13) Mathieu Desnoyers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871rsbv4io.fsf@oldenburg2.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=bmaurer@fb.com \
    --cc=boqun.feng@gmail.com \
    --cc=carlos@redhat.com \
    --cc=dalias@libc.org \
    --cc=davejwatson@fb.com \
    --cc=joseph@codesourcery.com \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=pjt@google.com \
    --cc=szabolcs.nagy@arm.com \
    --cc=tglx@linutronix.de \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.