linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: carlos <carlos@redhat.com>,
	Joseph Myers <joseph@codesourcery.com>,
	Szabolcs Nagy <szabolcs.nagy@arm.com>,
	libc-alpha <libc-alpha@sourceware.org>,
	Thomas Gleixner <tglx@linutronix.de>, Ben Maurer <bmaurer@fb.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Paul <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 <linux-kernel@vger.kernel.org>,
	linux-api <linux-api@vger.kernel.org>
Subject: Re: [PATCH 1/3] glibc: Perform rseq registration at C startup and thread creation (v21)
Date: Wed, 24 Jun 2020 15:00:03 -0400 (EDT)	[thread overview]
Message-ID: <1158112159.11628.1593025203438.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <87d05obl4w.fsf@oldenburg2.str.redhat.com>

----- On Jun 24, 2020, at 10:20 AM, Florian Weimer fweimer@redhat.com wrote:

> * Mathieu Desnoyers:
> 
>> diff --git a/manual/threads.texi b/manual/threads.texi
>> index bb7a42c655..d5069d5581 100644
>> --- a/manual/threads.texi
>> +++ b/manual/threads.texi
> 
>> +@deftypevar {struct rseq} __rseq_abi
>> +@standards{Linux, sys/rseq.h}
>> +@Theglibc{} implements a @code{__rseq_abi} TLS symbol to interact with
>> +the Restartable Sequences system call.  The layout of this structure is
>> +defined by the @file{sys/rseq.h} header.  Registration of each thread's
>> +@code{__rseq_abi} is performed by @theglibc{} at library initialization
>> +and thread creation. The manual for the rseq system call can be found
>> +at
>> @uref{https://git.kernel.org/pub/scm/libs/librseq/librseq.git/tree/doc/man/rseq.2}.
> 
> Should be “creation.  The” (two spaces after a sentence-ending period).

OK

> 
>> diff --git a/sysdeps/unix/sysv/linux/sys/rseq.h
>> b/sysdeps/unix/sysv/linux/sys/rseq.h
>> new file mode 100644
>> index 0000000000..5e118c1781
>> --- /dev/null
>> +++ b/sysdeps/unix/sysv/linux/sys/rseq.h
> 
>> +#ifdef __cplusplus
>> +# if  __cplusplus >= 201103L
>> +#  define __rseq_static_assert(expr, diagnostic) static_assert (expr,
>> diagnostic)
>> +#  define __rseq_alignof(type)                   alignof (type)
>> +#  define __rseq_tls_storage_class               thread_local
>> +# endif
>> +#elif (defined __STDC_VERSION__ ? __STDC_VERSION__ : 0) >= 201112L
>> +# define __rseq_static_assert(expr, diagnostic)  _Static_assert (expr,
>> diagnostic)
>> +# define __rseq_alignof(type)                    _Alignof (type)
>> +# define __rseq_tls_storage_class                _Thread_local
>> +#endif
>> +
>> +#ifndef __rseq_static_assert
>> +/* Try to use _Static_assert macro from sys/cdefs.h.  */
>> +# ifdef _Static_assert
>> +#  define __rseq_static_assert(expr, diagnostic) _Static_assert (expr,
>> diagnostic)
>> +# else
>> +#  define __rseq_static_assert(expr, diagnostic) /* Nothing.  */
>> +# endif
>> +#endif
>> +
>> +/* Rely on GNU extensions for older standards and tls model.  */
>> +#ifdef __GNUC__
>> +# ifndef __rseq_alignof
>> +#  define __rseq_alignof(x) __alignof__ (x)
>> +# endif
>> +# define __rseq_tls_model_ie __attribute__ ((__tls_model__ ("initial-exec")))
>> +#else
>> +/* Specifying the TLS model on the declaration is optional.  */
>> +# define __rseq_tls_model_ie /* Nothing.  */
>> +#endif
> 
> I'm still worried that __rseq_static_assert and __rseq_alignof will show
> up in the UAPI with textually different definitions.  (This does not
> apply to __rseq_tls_model_ie.)

What makes this worry not apply to __rseq_tls_model_ie ?

> 
> Is my worry unfounded?

So AFAIU you worry that eventually sys/rseq.h and linux/rseq.h carry different
definitions of __rseq_static_assert and __rseq_alignof.

Indeed, I did not surround those #define with #ifndef/#endif. Maybe we should ?

Just in case the definitions end up being different (worse case scenario), we
should expect their behavior to be pretty much equivalent. So going for the
following should address your concern I think:

#ifdef __cplusplus
# if  __cplusplus >= 201103L
#  ifndef __rseq_static_assert
#   define __rseq_static_assert(expr, diagnostic) static_assert (expr, diagnostic)
#  endif
#  ifndef __rseq_alignof
#   define __rseq_alignof(type)                   alignof (type)
#  endif
#  ifndef __rseq_tls_storage_class
#   define __rseq_tls_storage_class               thread_local
#  endif
# endif
#elif (defined __STDC_VERSION__ ? __STDC_VERSION__ : 0) >= 201112L
# ifndef __rseq_static_assert
#  define __rseq_static_assert(expr, diagnostic)  _Static_assert (expr, diagnostic)
# endif
# ifndef __rseq_alignof
#  define __rseq_alignof(type)                    _Alignof (type)
# endif
# ifndef __rseq_tls_storage_class
#  define __rseq_tls_storage_class                _Thread_local
# endif
#endif

#ifndef __rseq_static_assert
/* Try to use _Static_assert macro from sys/cdefs.h.  */
# ifdef _Static_assert
#  define __rseq_static_assert(expr, diagnostic) _Static_assert (expr, diagnostic)
# else
#  define __rseq_static_assert(expr, diagnostic) /* Nothing.  */
# endif
#endif

/* Rely on GNU extensions for older standards and tls model.  */
#ifdef __GNUC__
# ifndef __rseq_alignof
#  define __rseq_alignof(x) __alignof__ (x)
# endif
# ifndef __rseq_tls_model_ie
#  define __rseq_tls_model_ie __attribute__ ((__tls_model__ ("initial-exec")))
# endif
#else
/* Specifying the TLS model on the declaration is optional.  */
# ifndef __rseq_tls_model_ie
#  define __rseq_tls_model_ie /* Nothing.  */
# endif
#endif

/* Fall back to __thread for TLS storage class.  */
#ifndef __rseq_tls_storage_class
# define __rseq_tls_storage_class __thread
#endif

Thoughts ?

Thanks,

Mathieu



> 
> Thanks,
> Florian

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

  reply	other threads:[~2020-06-24 19:00 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200622180803.1449-1-mathieu.desnoyers@efficios.com>
2020-06-22 18:08 ` [PATCH 1/3] glibc: Perform rseq registration at C startup and thread creation (v21) Mathieu Desnoyers
2020-06-24 14:20   ` Florian Weimer
2020-06-24 19:00     ` Mathieu Desnoyers [this message]
2020-06-24 19:11       ` Florian Weimer
2020-06-24 19:16         ` Mathieu Desnoyers
2020-06-24 19:24           ` Florian Weimer
2020-06-24 19:26             ` Mathieu Desnoyers
2020-06-22 18:08 ` [PATCH 2/3] Linux: Use rseq in sched_getcpu if available (v9) 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=1158112159.11628.1593025203438.JavaMail.zimbra@efficios.com \
    --to=mathieu.desnoyers@efficios.com \
    --cc=bmaurer@fb.com \
    --cc=boqun.feng@gmail.com \
    --cc=carlos@redhat.com \
    --cc=dalias@libc.org \
    --cc=davejwatson@fb.com \
    --cc=fweimer@redhat.com \
    --cc=joseph@codesourcery.com \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).