Re: [PATCH glibc 1/3] glibc: Perform rseq registration at C startup and thread creation (v20)
- On Jun 11, 2020, at 4:26 PM, Joseph Myers jos...@codesourcery.com wrote: > On Thu, 11 Jun 2020, Mathieu Desnoyers wrote: > >> I managed to get a repository up and running for librseq, and have integrated >> the rseq.2 man page with comments from Michael Kerrisk here: >> >> https://git.kernel.org/pub/scm/libs/librseq/librseq.git/tree/doc/man/rseq.2 >> >> Is that a suitable URL ? Can we simply point to it from glibc's manual ? > > Yes, that seems something reasonable to link to. OK, I'll point to that then. I've been waiting for Michael Kerrisk to act on rseq(2) for more than a year now, and this is getting in the way of upstreaming rseq support into glibc 2.32. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
Re: [PATCH glibc 1/3] glibc: Perform rseq registration at C startup and thread creation (v20)
- On Jun 18, 2020, at 8:22 AM, Szabolcs Nagy szabolcs.n...@arm.com wrote: > The 06/11/2020 20:26, Joseph Myers wrote: >> On Thu, 11 Jun 2020, Mathieu Desnoyers wrote: >> > I managed to get a repository up and running for librseq, and have >> > integrated >> > the rseq.2 man page with comments from Michael Kerrisk here: >> > >> > https://git.kernel.org/pub/scm/libs/librseq/librseq.git/tree/doc/man/rseq.2 >> > >> > Is that a suitable URL ? Can we simply point to it from glibc's manual ? >> >> Yes, that seems something reasonable to link to. > > is there work to make the usage of rseq critical > sections portable? (e.g. transactional memory > critical section has syntax in gcc, but that > doesn't require straight line code with > begin/end/abort labels in a particular layout.) > > the macros and inline asm in rseq-*.h are not > too nice, but if they can completely hide the > non-portable bits then i guess that works. My goal with librseq is indeed to provide static inlines which hide the architecture-specific ugliness of rseq critical section assembly code behind an API which can be used from all supported architectures for most of the known use-cases, so only very specific use-case would have to craft their own assembly. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
Re: [PATCH glibc 1/3] glibc: Perform rseq registration at C startup and thread creation (v20)
The 06/11/2020 20:26, Joseph Myers wrote: > On Thu, 11 Jun 2020, Mathieu Desnoyers wrote: > > I managed to get a repository up and running for librseq, and have > > integrated > > the rseq.2 man page with comments from Michael Kerrisk here: > > > > https://git.kernel.org/pub/scm/libs/librseq/librseq.git/tree/doc/man/rseq.2 > > > > Is that a suitable URL ? Can we simply point to it from glibc's manual ? > > Yes, that seems something reasonable to link to. is there work to make the usage of rseq critical sections portable? (e.g. transactional memory critical section has syntax in gcc, but that doesn't require straight line code with begin/end/abort labels in a particular layout.) the macros and inline asm in rseq-*.h are not too nice, but if they can completely hide the non-portable bits then i guess that works.
Re: [PATCH glibc 1/3] glibc: Perform rseq registration at C startup and thread creation (v20)
On Thu, 11 Jun 2020, Mathieu Desnoyers wrote: > I managed to get a repository up and running for librseq, and have integrated > the rseq.2 man page with comments from Michael Kerrisk here: > > https://git.kernel.org/pub/scm/libs/librseq/librseq.git/tree/doc/man/rseq.2 > > Is that a suitable URL ? Can we simply point to it from glibc's manual ? Yes, that seems something reasonable to link to. -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH glibc 1/3] glibc: Perform rseq registration at C startup and thread creation (v20)
- On Jun 4, 2020, at 1:46 PM, Joseph Myers jos...@codesourcery.com wrote: > On Thu, 4 Jun 2020, Mathieu Desnoyers via Libc-alpha wrote: > >> That external piece of documentation would be part of the Linux man-pages >> project, maintained by Michael Kerrisk. I have submitted a few revisions >> of the rseq(2) man page, but have been waiting for Michael to reply for more >> than a year now: >> >> >> https://lore.kernel.org/r/2021826204.69809.1588000508294.javamail.zim...@efficios.com >> >> I'm thinking about hosting a rseq(2) man-page into my librseq project, would >> that make sense ? > > I'm not particularly concerned with exactly where it goes, as long as it's > somewhere stable we can link to. I managed to get a repository up and running for librseq, and have integrated the rseq.2 man page with comments from Michael Kerrisk here: https://git.kernel.org/pub/scm/libs/librseq/librseq.git/tree/doc/man/rseq.2 Is that a suitable URL ? Can we simply point to it from glibc's manual ? Thanks, Mathieu > > -- > Joseph S. Myers > jos...@codesourcery.com -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
Re: [PATCH glibc 1/3] glibc: Perform rseq registration at C startup and thread creation (v20)
On Thu, 4 Jun 2020, Mathieu Desnoyers via Libc-alpha wrote: > That external piece of documentation would be part of the Linux man-pages > project, maintained by Michael Kerrisk. I have submitted a few revisions > of the rseq(2) man page, but have been waiting for Michael to reply for more > than a year now: > > > https://lore.kernel.org/r/2021826204.69809.1588000508294.javamail.zim...@efficios.com > > I'm thinking about hosting a rseq(2) man-page into my librseq project, would > that make sense ? I'm not particularly concerned with exactly where it goes, as long as it's somewhere stable we can link to. -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH glibc 1/3] glibc: Perform rseq registration at C startup and thread creation (v20)
- On Jun 3, 2020, at 1:22 PM, Joseph Myers jos...@codesourcery.com wrote: > On Wed, 3 Jun 2020, Florian Weimer via Libc-alpha wrote: > >> I'm still waiting for feedback from other maintainers whether the level >> of documentation and testing is appropriate. > > Looking at the documentation in the manual, it doesn't look like it has > enough information for someone to use this functionality, or to know when > they might want to use it, and nor does it point to external documentation > of it. It would seem appropriate at least to include a link to wherever > the external documentation is of what this functionality is good for, how > to create and use a "Restartable Sequence critical section", and how to > "perform rseq registration to the kernel". That external piece of documentation would be part of the Linux man-pages project, maintained by Michael Kerrisk. I have submitted a few revisions of the rseq(2) man page, but have been waiting for Michael to reply for more than a year now: https://lore.kernel.org/r/2021826204.69809.1588000508294.javamail.zim...@efficios.com I'm thinking about hosting a rseq(2) man-page into my librseq project, would that make sense ? librseq is currently a development branch in my own repository for now. It still needs to be tweaked to adapt to the various changes that went into the glibc rseq enablement patchset, and then I plan to move it to a more "formal" home: https://github.com/compudj/librseq Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
Re: [PATCH glibc 1/3] glibc: Perform rseq registration at C startup and thread creation (v20)
On Wed, 3 Jun 2020, Florian Weimer via Libc-alpha wrote: > I'm still waiting for feedback from other maintainers whether the level > of documentation and testing is appropriate. Looking at the documentation in the manual, it doesn't look like it has enough information for someone to use this functionality, or to know when they might want to use it, and nor does it point to external documentation of it. It would seem appropriate at least to include a link to wherever the external documentation is of what this functionality is good for, how to create and use a "Restartable Sequence critical section", and how to "perform rseq registration to the kernel". -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH glibc 1/3] glibc: Perform rseq registration at C startup and thread creation (v20)
- On Jun 3, 2020, at 8:31 AM, Florian Weimer fwei...@redhat.com wrote: > * Mathieu Desnoyers: > >> - On Jun 3, 2020, at 8:05 AM, Florian Weimer fwei...@redhat.com wrote: >> >>> * Mathieu Desnoyers: >>> +#ifdef __cplusplus +# if __cplusplus >= 201103L +# define __rseq_static_assert(expr, diagnostic) static_assert (expr, diagnostic) +# define __rseq_alignof(type) alignof (type) +# define __rseq_alignas(x) alignas (x) +# 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_alignas(x) _Alignas (x) +# define __rseq_tls_storage_class_Thread_local +#endif >>> >>> This does not seem to work. I get this with GCC 9: >>> >>> In file included from /tmp/cih_test_gsrKbC.cc:8:0: >>> ../sysdeps/unix/sysv/linux/sys/rseq.h:42:50: error: attribute ignored >>> [-Werror=attributes] >>> # define __rseq_alignas(x) alignas (x) >>> ^ >>> ../sysdeps/unix/sysv/linux/sys/rseq.h:122:14: note: in expansion of macro >>> ‘__rseq_alignas’ >>> uint32_t __rseq_alignas (32) version; >>> ^ >> >> Is that when compiling C or C++ code ? If it's C code, I would expect >> "_Alignas" to be used, not "alignas". >> >> Which exact version of gcc do you use ? > > C++ code. CXX was set to this compiler at configure time: > > gcc version 9.3.1 20200408 (Red Hat 9.3.1-2) (GCC) I think I found the culprit: it should be: __rseq_alignas (32) uint32_t version; rather than the other way around. > >>> In any case, these changes really have to go into the UAPI header first. >>> Only the __thread handling should remain. Otherwise, we'll have a tough >>> situation on our hands changing the UAPI header, without introducing >>> macro definition conflicts. I'd suggest to stick to the aligned >>> attribute for the time being, like the current UAPI headers. OK, so I just remove the __rseq_alignas for now and use "aligned()" instead like the UAPI header. I plan to keep the other macros for now. >> >> OK. Should I do that in a separate patch, or you do it on top of my patchset, >> or should I re-spin another round of the series ? > > I think the initial commit should mirror the current UAPI header > contents. > > Keep the macros for the UAPI patch though. 8-) We can pick up these > changes once they have been merged into Linux. OK, Thanks! Mathieu > > Thanks, > Florian -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
Re: [PATCH glibc 1/3] glibc: Perform rseq registration at C startup and thread creation (v20)
* Mathieu Desnoyers: > - On Jun 3, 2020, at 8:05 AM, Florian Weimer fwei...@redhat.com wrote: > >> * Mathieu Desnoyers: >> >>> +#ifdef __cplusplus >>> +# if __cplusplus >= 201103L >>> +# define __rseq_static_assert(expr, diagnostic) static_assert (expr, >>> diagnostic) >>> +# define __rseq_alignof(type) alignof (type) >>> +# define __rseq_alignas(x) alignas (x) >>> +# 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_alignas(x) _Alignas (x) >>> +# define __rseq_tls_storage_class_Thread_local >>> +#endif >> >> This does not seem to work. I get this with GCC 9: >> >> In file included from /tmp/cih_test_gsrKbC.cc:8:0: >> ../sysdeps/unix/sysv/linux/sys/rseq.h:42:50: error: attribute ignored >> [-Werror=attributes] >> # define __rseq_alignas(x) alignas (x) >> ^ >> ../sysdeps/unix/sysv/linux/sys/rseq.h:122:14: note: in expansion of macro >> ‘__rseq_alignas’ >> uint32_t __rseq_alignas (32) version; >> ^ > > Is that when compiling C or C++ code ? If it's C code, I would expect > "_Alignas" to be used, not "alignas". > > Which exact version of gcc do you use ? C++ code. CXX was set to this compiler at configure time: gcc version 9.3.1 20200408 (Red Hat 9.3.1-2) (GCC) >> In any case, these changes really have to go into the UAPI header first. >> Only the __thread handling should remain. Otherwise, we'll have a tough >> situation on our hands changing the UAPI header, without introducing >> macro definition conflicts. I'd suggest to stick to the aligned >> attribute for the time being, like the current UAPI headers. > > OK. Should I do that in a separate patch, or you do it on top of my patchset, > or should I re-spin another round of the series ? I think the initial commit should mirror the current UAPI header contents. Keep the macros for the UAPI patch though. 8-) We can pick up these changes once they have been merged into Linux. Thanks, Florian
Re: [PATCH glibc 1/3] glibc: Perform rseq registration at C startup and thread creation (v20)
- On Jun 3, 2020, at 8:05 AM, Florian Weimer fwei...@redhat.com wrote: > * Mathieu Desnoyers: > >> +#ifdef __cplusplus >> +# if __cplusplus >= 201103L >> +# define __rseq_static_assert(expr, diagnostic) static_assert (expr, >> diagnostic) >> +# define __rseq_alignof(type) alignof (type) >> +# define __rseq_alignas(x) alignas (x) >> +# 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_alignas(x) _Alignas (x) >> +# define __rseq_tls_storage_class_Thread_local >> +#endif > > This does not seem to work. I get this with GCC 9: > > In file included from /tmp/cih_test_gsrKbC.cc:8:0: > ../sysdeps/unix/sysv/linux/sys/rseq.h:42:50: error: attribute ignored > [-Werror=attributes] > # define __rseq_alignas(x) alignas (x) > ^ > ../sysdeps/unix/sysv/linux/sys/rseq.h:122:14: note: in expansion of macro > ‘__rseq_alignas’ > uint32_t __rseq_alignas (32) version; > ^ Is that when compiling C or C++ code ? If it's C code, I would expect "_Alignas" to be used, not "alignas". Which exact version of gcc do you use ? > > In any case, these changes really have to go into the UAPI header first. > Only the __thread handling should remain. Otherwise, we'll have a tough > situation on our hands changing the UAPI header, without introducing > macro definition conflicts. I'd suggest to stick to the aligned > attribute for the time being, like the current UAPI headers. OK. Should I do that in a separate patch, or you do it on top of my patchset, or should I re-spin another round of the series ? > > The resut looks okay to me. > > I'm still waiting for feedback from other maintainers whether the level > of documentation and testing is appropriate. OK. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
Re: [PATCH glibc 1/3] glibc: Perform rseq registration at C startup and thread creation (v20)
* Mathieu Desnoyers: > +#ifdef __cplusplus > +# if __cplusplus >= 201103L > +# define __rseq_static_assert(expr, diagnostic) static_assert (expr, > diagnostic) > +# define __rseq_alignof(type) alignof (type) > +# define __rseq_alignas(x) alignas (x) > +# 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_alignas(x) _Alignas (x) > +# define __rseq_tls_storage_class_Thread_local > +#endif This does not seem to work. I get this with GCC 9: In file included from /tmp/cih_test_gsrKbC.cc:8:0: ../sysdeps/unix/sysv/linux/sys/rseq.h:42:50: error: attribute ignored [-Werror=attributes] # define __rseq_alignas(x) alignas (x) ^ ../sysdeps/unix/sysv/linux/sys/rseq.h:122:14: note: in expansion of macro ‘__rseq_alignas’ uint32_t __rseq_alignas (32) version; ^ In any case, these changes really have to go into the UAPI header first. Only the __thread handling should remain. Otherwise, we'll have a tough situation on our hands changing the UAPI header, without introducing macro definition conflicts. I'd suggest to stick to the aligned attribute for the time being, like the current UAPI headers. The resut looks okay to me. I'm still waiting for feedback from other maintainers whether the level of documentation and testing is appropriate. Thanks, Florian
[PATCH glibc 1/3] glibc: Perform rseq registration at C startup and thread creation (v20)
Register rseq 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 Those are based on glibc master branch commit 415d0b0b3f16. The rseq system call was merged into Linux 4.18. CC: Carlos O'Donell CC: Florian Weimer CC: Joseph Myers CC: Szabolcs Nagy CC: Thomas Gleixner CC: Ben Maurer CC: Peter Zijlstra CC: "Paul E. McKenney" CC: Boqun Feng CC: Will Deacon CC: Dave Watson CC: Paul Turner CC: Rich Felker CC: libc-al...@sourceware.org CC: linux-kernel@vger.kernel.org CC: linux-...@vger.kernel.org --- Changes since v1: - Move __rseq_refcount to an extra field at the end of __rseq_abi to eliminate one symbol. All libraries/programs which try to register rseq (glibc, early-adopter applications, early-adopter libraries) should use the rseq refcount. It becomes part of the ABI within a user-space process, but it's not part of the ABI shared with the kernel per se. - Restructure how this code is organized so glibc keeps building on non-Linux targets. - Use non-weak symbol for __rseq_abi. - Move rseq registration/unregistration implementation into its own nptl/rseq.c compile unit. - Move __rseq_abi symbol under GLIBC_2.29. Changes since v2: - Move __rseq_refcount to its own symbol, which is less ugly than trying to play tricks with the rseq uapi. - Move __rseq_abi from nptl to csu (C start up), so it can be used across glibc, including memory allocator and sched_getcpu(). The __rseq_refcount symbol is kept in nptl, because there is no reason to use it elsewhere in glibc. Changes since v3: - Set __rseq_refcount TLS to 1 on register/set to 0 on unregister because glibc is the first/last user. - Unconditionally register/unregister rseq at thread start/exit, because glibc is the first/last user. - Add missing abilist items. - Rebase on glibc master commit a502c5294. - Add NEWS entry. Changes since v4: - Do not use "weak" symbols for __rseq_abi and __rseq_refcount. Based on "System V Application Binary Interface", weak only affects the link editor, not the dynamic linker. - Install a new sys/rseq.h system header on Linux, which contains the RSEQ_SIG definition, __rseq_abi declaration and __rseq_refcount declaration. Move those definition/declarations from rseq-internal.h to the installed sys/rseq.h header. - Considering that rseq is only available on Linux, move csu/rseq.c to sysdeps/unix/sysv/linux/rseq-sym.c. - Move __rseq_refcount from nptl/rseq.c to sysdeps/unix/sysv/linux/rseq-sym.c, so it is only defined on Linux. - Move both ABI definitions for __rseq_abi and __rseq_refcount to sysdeps/unix/sysv/linux/Versions, so they only appear on Linux. - Document __rseq_abi and __rseq_refcount volatile. - Document the RSEQ_SIG signature define. - Move registration functions from rseq.c to rseq-internal.h static inline functions. Introduce empty stubs in misc/rseq-internal.h, which can be overridden by architecture code in sysdeps/unix/sysv/linux/rseq-internal.h. - Rename __rseq_register_current_thread and __rseq_unregister_current_thread to rseq_register_current_thread and rseq_unregister_current_thread, now that those are only visible as internal static inline functions. - Invoke rseq_register_current_thread() from libc-start.c LIBC_START_MAIN rather than nptl init, so applications not linked against libpthread.so have rseq registered for their main() thread. Note that it is invoked separately for SHARED and !SHARED builds. Changes since v5: - Replace __rseq_refcount by __rseq_lib_abi, which contains two uint32_t: register_state and refcount. The "register_state" field allows inhibiting rseq registration from signal handlers nested on top of glibc registration and occuring after rseq unregistration by glibc. - Introduce enum rseq_register_state, which contains the states allowed for the struct rseq_lib_abi register_state field. Changes since v6: - Introduce bits/rseq.h to define RSEQ_SIG for each architecture. The generic bits/rseq.h does not define RSEQ_SIG, meaning that each architecture implementing rseq needs to implement bits/rseq.h. - Rename enum item RSEQ_REGISTER_NESTED to RSEQ_REGISTER_ONGOING. - Port to glibc-2.29. Changes since v7: - Remove __rseq_lib_abi symbol, including refcount and register_state fields. - Remove reference counting and nested signals handling from registration/unregistration functions. - Introduce new __rseq_handled exported symbol, which is set to 1 by glibc on C startup when it handles restartable sequences. This allows glibc to coexist with early adopter libraries and applications wishing to register restartable sequences when it is not handled by glibc. - Introduce rseq_init (), which sets __rseq_handled to 1 from C startup. - Update NEWS entry. - Update comments at the beginning of new files. - Registration depends on
