All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: "Cristian Rodríguez" <crrodriguez@opensuse.org>
Cc: Florian Weimer <fweimer@redhat.com>,
	libc-alpha <libc-alpha@sourceware.org>,
	linux-api <linux-api@vger.kernel.org>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>,
	Jeremy Linton <jeremy.linton@arm.com>,
	Rich Felker <dalias@libc.org>
Subject: Re: Bringing rseq back into glibc
Date: Thu, 18 Nov 2021 14:41:35 -0500 (EST)	[thread overview]
Message-ID: <1748005532.19737.1637264495123.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <CAPBLoAe+KZiM9fb3M7nXXSr_MVGOSQhFWgJYeQH-zXGF3j2cJw@mail.gmail.com>

----- On Nov 18, 2021, at 1:48 PM, Cristian Rodríguez crrodriguez@opensuse.org wrote:

> On Thu, Nov 18, 2021 at 7:17 AM Florian Weimer via Libc-alpha
> <libc-alpha@sourceware.org> wrote:
> 
>> 4. Add public symbols __rseq_abi_offset, __rseq_abi_size (currently 32
>>    or 0), __rseq_abi_flags (currently 0).  __rseq_abi_offset is the
>>    offset to add to the thread pointer (see __builtin_thread_pointer) to
>>    get to the rseq area.  They will be public ABI symbols.  These
>>    variables are initialized before user code runs, and changing the
>>    results in undefined behavior.
> 
> Why not then __get_rseq_whatwever functions and not variables ? or
> maybe writing to these variables results in a compiler or linker error
> instead of UB ?

rseq critical sections cannot issue function calls, and also function calls
are noticeably expensive compared to an rseq critical section. So all users
would end up needing to make a local copy of the information fetched by those
getters.

So rather than require all those extra per-user copies, I suspect exposing
a single copy through public glibc symbols is more efficient.

The downside is indeed that writing to those variables is UB.

Thanks,

Mathieu

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

      reply	other threads:[~2021-11-18 19:41 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-18 10:17 Bringing rseq back into glibc Florian Weimer
2021-11-18 16:32 ` Mathieu Desnoyers
2021-11-18 16:54   ` Florian Weimer
2021-11-18 17:52     ` Mathieu Desnoyers
2021-11-18 18:42 ` Noah Goldstein
2021-11-18 18:55   ` Florian Weimer
2021-11-18 18:48 ` Cristian Rodríguez
2021-11-18 19:41   ` Mathieu Desnoyers [this message]

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=1748005532.19737.1637264495123.JavaMail.zimbra@efficios.com \
    --to=mathieu.desnoyers@efficios.com \
    --cc=crrodriguez@opensuse.org \
    --cc=dalias@libc.org \
    --cc=fweimer@redhat.com \
    --cc=jeremy.linton@arm.com \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-api@vger.kernel.org \
    --cc=vincenzo.frascino@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.