Re: [PATCH glibc 2.31 1/5] glibc: Perform rseq(2) registration at C startup and thread creation (v12)

[Florian Weimer <fweimer@redhat.com>]

* Mathieu Desnoyers:

> +#ifdef SHARED
> +  if (rtld_active ())
> +    {
> +      /* Register rseq ABI to the kernel.   */
> +      (void) rseq_register_current_thread ();
> +    }
> +#else

I think this will need *another* check for the inner libc in an audit
module.  See what we do in malloc.  __libc_multiple_libcs is supposed to
cover that, but it's unfortunately not reliable.

I believe without that additional check, the first audit module we load
will claim rseq, and the main program will not have control over the
rseq area.  Reversed roles would be desirable here.

In October, I hope to fix __libc_multiple_libcs, and then you can use
just that.  (We have a Fedora patch that is supposed to fix it, I need
to documen the mechanism and upstream it.)

> +/* Advertise Restartable Sequences registration ownership across
> +   application and shared libraries.
> +
> +   Libraries and applications must check whether this variable is zero or
> +   non-zero if they wish to perform rseq registration on their own. If it
> +   is zero, it means restartable sequence registration is not handled, and
> +   the library or application is free to perform rseq registration. In
> +   that case, the library or application is taking ownership of rseq
> +   registration, and may set __rseq_handled to 1. It may then set it back
> +   to 0 after it completes unregistering rseq.
> +
> +   If __rseq_handled is found to be non-zero, it means that another
> +   library (or the application) is currently handling rseq registration.
> +
> +   Typical use of __rseq_handled is within library constructors and
> +   destructors, or at program startup.  */
> +
> +int __rseq_handled;

Are there any programs that use __rseq_handled *today*?

I'm less convinced that we actually need this.  I don't think we have
ever done anything like that before, and I don't think it's necessary.
Any secondary rseq library just needs to note if it could perform
registration, and if it failed to do so, do not perform unregistration
in a pthread destructor callback.

Sure, there's the matter of pthread destructor ordering, but that
problem is not different from any other singleton (thread-local or not),
and the fix for the last time this has come up (TLS destructors vs
dlclose) was to upgrade glibc.

Thanks,
Florian