- On Jan 14, 2019, at 2:37 PM, Florian Weimer fwei...@redhat.com wrote:
> * Mathieu Desnoyers:
>
>> - On Jan 14, 2019, at 10:55 AM, Florian Weimer fwei...@redhat.com wrote:
>>
>>> * Mathieu Desnoyers:
>>>
Therefore, both symbols will end up in
sysdeps/unix/sysv/linux/Versions.
* Mathieu Desnoyers:
> - On Jan 14, 2019, at 10:55 AM, Florian Weimer fwei...@redhat.com wrote:
>
>> * Mathieu Desnoyers:
>>
>>> Therefore, both symbols will end up in
>>> sysdeps/unix/sysv/linux/Versions.
>>
>> I'm not sure what you mean by that. The physical location in the
>> directory
- On Jan 14, 2019, at 10:55 AM, Florian Weimer fwei...@redhat.com wrote:
> * Mathieu Desnoyers:
>
>> Therefore, both symbols will end up in
>> sysdeps/unix/sysv/linux/Versions.
>
> I'm not sure what you mean by that. The physical location in the
> directory tree has little effect on which
* Mathieu Desnoyers:
> Now that I think about it, it's important to move the rseq registration
> done at nptl init (in my current code) to some lower-level csu initialiation,
> so applications that happen _not_ to link against libpthread also get
> registered rseq for the main
* Mathieu Desnoyers:
> Therefore, both symbols will end up in
> sysdeps/unix/sysv/linux/Versions.
I'm not sure what you mean by that. The physical location in the
directory tree has little effect on which shared object the symbol is
placed in; that will need other changes.
>> By the way, you
- On Jan 10, 2019, at 12:31 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Dec 11, 2018, at 2:40 AM, Florian Weimer fwei...@redhat.com wrote:
[...]
>>
>>> diff --git a/nptl/Versions b/nptl/Versions
>>> index e7f691da7a..f7890f73fc 100
*/
extern __thread volatile struct rseq __rseq_abi
__attribute__ ((tls_model ("initial-exec")));
/* volatile because refcount can be read/updated by signal handlers. */
extern __thread volatile uint32_t __rseq_refcount
__attribute__ ((tls_model ("initial-exec&
__rseq_refcount
> +__attribute__ ((tls_model ("initial-exec")));
The volatile qualifier needs justification in a comment. (Usually,
volatile is wrong. and it is difficult to get rid of it.)
We need to document these public symbols somewhere. There should be an
installed header f
- On Nov 26, 2018, at 12:07 PM, Rich Felker dal...@libc.org wrote:
> On Mon, Nov 26, 2018 at 11:30:51AM -0500, Mathieu Desnoyers wrote:
>> - On Nov 26, 2018, at 10:51 AM, Mathieu Desnoyers
>> mathieu.desnoy...@efficios.com wrote:
>>
>> > - On Nov 26, 2018, at 3:28 AM, Florian
- On Nov 26, 2018, at 12:07 PM, Rich Felker dal...@libc.org wrote:
> On Mon, Nov 26, 2018 at 11:30:51AM -0500, Mathieu Desnoyers wrote:
>> - On Nov 26, 2018, at 10:51 AM, Mathieu Desnoyers
>> mathieu.desnoy...@efficios.com wrote:
>>
>> > - On Nov 26, 2018, at 3:28 AM, Florian
- On Dec 4, 2018, at 2:44 PM, Florian Weimer fwei...@redhat.com wrote:
> * Mathieu Desnoyers:
>
>> diff --git a/sysdeps/unix/sysv/linux/riscv/rv64/libpthread.abilist
>> b/sysdeps/unix/sysv/linux/riscv/rv64/libpthread.abilist
>> index c370fda73d..9da78d59d2 100644
>> ---
- On Dec 4, 2018, at 2:44 PM, Florian Weimer fwei...@redhat.com wrote:
> * Mathieu Desnoyers:
>
>> diff --git a/sysdeps/unix/sysv/linux/riscv/rv64/libpthread.abilist
>> b/sysdeps/unix/sysv/linux/riscv/rv64/libpthread.abilist
>> index c370fda73d..9da78d59d2 100644
>> ---
* Mathieu Desnoyers:
> diff --git a/sysdeps/unix/sysv/linux/riscv/rv64/libpthread.abilist
> b/sysdeps/unix/sysv/linux/riscv/rv64/libpthread.abilist
> index c370fda73d..9da78d59d2 100644
> --- a/sysdeps/unix/sysv/linux/riscv/rv64/libpthread.abilist
> +++
* Mathieu Desnoyers:
> diff --git a/sysdeps/unix/sysv/linux/riscv/rv64/libpthread.abilist
> b/sysdeps/unix/sysv/linux/riscv/rv64/libpthread.abilist
> index c370fda73d..9da78d59d2 100644
> --- a/sysdeps/unix/sysv/linux/riscv/rv64/libpthread.abilist
> +++
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.
-
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.
-
it would make sense to require use of rseq from signal
handlers to depend on rseq registration by glibc at thread start, and limit
the use-case of out-of-libc rseq registration to those that do not nest
within signal handlers.
If we _never_ even want to allow signal handlers to register rseq, we cou
it would make sense to require use of rseq from signal
handlers to depend on rseq registration by glibc at thread start, and limit
the use-case of out-of-libc rseq registration to those that do not nest
within signal handlers.
If we _never_ even want to allow signal handlers to register rseq, we cou
- On Nov 26, 2018, at 12:10 PM, Rich Felker dal...@libc.org wrote:
> On Mon, Nov 26, 2018 at 05:03:02PM +0100, Florian Weimer wrote:
>> * Mathieu Desnoyers:
>>
>> > So let's make __rseq_abi and __rseq_refcount strong symbols then ?
>>
>> Yes, please. (But I'm still not sure we need the
- On Nov 26, 2018, at 12:10 PM, Rich Felker dal...@libc.org wrote:
> On Mon, Nov 26, 2018 at 05:03:02PM +0100, Florian Weimer wrote:
>> * Mathieu Desnoyers:
>>
>> > So let's make __rseq_abi and __rseq_refcount strong symbols then ?
>>
>> Yes, please. (But I'm still not sure we need the
On Mon, Nov 26, 2018 at 05:03:02PM +0100, Florian Weimer wrote:
> * Mathieu Desnoyers:
>
> > So let's make __rseq_abi and __rseq_refcount strong symbols then ?
>
> Yes, please. (But I'm still not sure we need the reference counter.)
The reference counter is needed for out-of-libc
On Mon, Nov 26, 2018 at 05:03:02PM +0100, Florian Weimer wrote:
> * Mathieu Desnoyers:
>
> > So let's make __rseq_abi and __rseq_refcount strong symbols then ?
>
> Yes, please. (But I'm still not sure we need the reference counter.)
The reference counter is needed for out-of-libc
On Mon, Nov 26, 2018 at 11:30:51AM -0500, Mathieu Desnoyers wrote:
> - On Nov 26, 2018, at 10:51 AM, Mathieu Desnoyers
> mathieu.desnoy...@efficios.com wrote:
>
> > - On Nov 26, 2018, at 3:28 AM, Florian Weimer fwei...@redhat.com wrote:
> >
> >> * Mathieu Desnoyers:
> >>
> >>> Using a
On Mon, Nov 26, 2018 at 11:30:51AM -0500, Mathieu Desnoyers wrote:
> - On Nov 26, 2018, at 10:51 AM, Mathieu Desnoyers
> mathieu.desnoy...@efficios.com wrote:
>
> > - On Nov 26, 2018, at 3:28 AM, Florian Weimer fwei...@redhat.com wrote:
> >
> >> * Mathieu Desnoyers:
> >>
> >>> Using a
- On Nov 26, 2018, at 10:51 AM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Nov 26, 2018, at 3:28 AM, Florian Weimer fwei...@redhat.com wrote:
>
>> * Mathieu Desnoyers:
>>
>>> Using a "weak" symbol in early adopter libraries is important, so they
>>> can be loaded
- On Nov 26, 2018, at 10:51 AM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Nov 26, 2018, at 3:28 AM, Florian Weimer fwei...@redhat.com wrote:
>
>> * Mathieu Desnoyers:
>>
>>> Using a "weak" symbol in early adopter libraries is important, so they
>>> can be loaded
* Mathieu Desnoyers:
> So let's make __rseq_abi and __rseq_refcount strong symbols then ?
Yes, please. (But I'm still not sure we need the reference counter.)
Thanks,
Florian
* Mathieu Desnoyers:
> So let's make __rseq_abi and __rseq_refcount strong symbols then ?
Yes, please. (But I'm still not sure we need the reference counter.)
Thanks,
Florian
- On Nov 26, 2018, at 3:28 AM, Florian Weimer fwei...@redhat.com wrote:
> * Mathieu Desnoyers:
>
>> Using a "weak" symbol in early adopter libraries is important, so they
>> can be loaded together into the same process without causing loader
>> errors due to many definitions of the same
- On Nov 26, 2018, at 3:28 AM, Florian Weimer fwei...@redhat.com wrote:
> * Mathieu Desnoyers:
>
>> Using a "weak" symbol in early adopter libraries is important, so they
>> can be loaded together into the same process without causing loader
>> errors due to many definitions of the same
On 23/11/18 21:09, Mathieu Desnoyers wrote:
> - On Nov 23, 2018, at 1:35 PM, Rich Felker dal...@libc.org wrote:
>
>> On Fri, Nov 23, 2018 at 12:52:21PM -0500, Mathieu Desnoyers wrote:
>>> - On Nov 23, 2018, at 12:30 PM, Rich Felker dal...@libc.org wrote:
>>>
On Fri, Nov 23, 2018 at
On 23/11/18 21:09, Mathieu Desnoyers wrote:
> - On Nov 23, 2018, at 1:35 PM, Rich Felker dal...@libc.org wrote:
>
>> On Fri, Nov 23, 2018 at 12:52:21PM -0500, Mathieu Desnoyers wrote:
>>> - On Nov 23, 2018, at 12:30 PM, Rich Felker dal...@libc.org wrote:
>>>
On Fri, Nov 23, 2018 at
* Mathieu Desnoyers:
> Using a "weak" symbol in early adopter libraries is important, so they
> can be loaded together into the same process without causing loader
> errors due to many definitions of the same strong symbol.
This is not how ELF dynamic linking works. If the symbol name is the
* Mathieu Desnoyers:
> Using a "weak" symbol in early adopter libraries is important, so they
> can be loaded together into the same process without causing loader
> errors due to many definitions of the same strong symbol.
This is not how ELF dynamic linking works. If the symbol name is the
- On Nov 23, 2018, at 1:35 PM, Rich Felker dal...@libc.org wrote:
> On Fri, Nov 23, 2018 at 12:52:21PM -0500, Mathieu Desnoyers wrote:
>> - On Nov 23, 2018, at 12:30 PM, Rich Felker dal...@libc.org wrote:
>>
>> > On Fri, Nov 23, 2018 at 12:05:20PM -0500, Mathieu Desnoyers wrote:
>> >>
- On Nov 23, 2018, at 1:35 PM, Rich Felker dal...@libc.org wrote:
> On Fri, Nov 23, 2018 at 12:52:21PM -0500, Mathieu Desnoyers wrote:
>> - On Nov 23, 2018, at 12:30 PM, Rich Felker dal...@libc.org wrote:
>>
>> > On Fri, Nov 23, 2018 at 12:05:20PM -0500, Mathieu Desnoyers wrote:
>> >>
On Fri, Nov 23, 2018 at 12:52:21PM -0500, Mathieu Desnoyers wrote:
> - On Nov 23, 2018, at 12:30 PM, Rich Felker dal...@libc.org wrote:
>
> > On Fri, Nov 23, 2018 at 12:05:20PM -0500, Mathieu Desnoyers wrote:
> >> - On Nov 23, 2018, at 9:28 AM, Rich Felker dal...@libc.org wrote:
> >>
On Fri, Nov 23, 2018 at 12:52:21PM -0500, Mathieu Desnoyers wrote:
> - On Nov 23, 2018, at 12:30 PM, Rich Felker dal...@libc.org wrote:
>
> > On Fri, Nov 23, 2018 at 12:05:20PM -0500, Mathieu Desnoyers wrote:
> >> - On Nov 23, 2018, at 9:28 AM, Rich Felker dal...@libc.org wrote:
> >>
* Rich Felker:
> On Fri, Nov 23, 2018 at 06:39:04PM +0100, Florian Weimer wrote:
>> * Rich Felker:
>>
>> > On Fri, Nov 23, 2018 at 12:05:20PM -0500, Mathieu Desnoyers wrote:
>> >> There has been presumptions about signals being blocked when the thread
>> >> exits throughout this email thread.
* Rich Felker:
> On Fri, Nov 23, 2018 at 06:39:04PM +0100, Florian Weimer wrote:
>> * Rich Felker:
>>
>> > On Fri, Nov 23, 2018 at 12:05:20PM -0500, Mathieu Desnoyers wrote:
>> >> There has been presumptions about signals being blocked when the thread
>> >> exits throughout this email thread.
- On Nov 23, 2018, at 12:30 PM, Rich Felker dal...@libc.org wrote:
> On Fri, Nov 23, 2018 at 12:05:20PM -0500, Mathieu Desnoyers wrote:
>> - On Nov 23, 2018, at 9:28 AM, Rich Felker dal...@libc.org wrote:
>> [...]
>> >
>> > Absolutely. As long as it's in libc, implicit destruction will
- On Nov 23, 2018, at 12:30 PM, Rich Felker dal...@libc.org wrote:
> On Fri, Nov 23, 2018 at 12:05:20PM -0500, Mathieu Desnoyers wrote:
>> - On Nov 23, 2018, at 9:28 AM, Rich Felker dal...@libc.org wrote:
>> [...]
>> >
>> > Absolutely. As long as it's in libc, implicit destruction will
On Fri, Nov 23, 2018 at 06:39:04PM +0100, Florian Weimer wrote:
> * Rich Felker:
>
> > On Fri, Nov 23, 2018 at 12:05:20PM -0500, Mathieu Desnoyers wrote:
> >> There has been presumptions about signals being blocked when the thread
> >> exits throughout this email thread. Out of curiosity, what
On Fri, Nov 23, 2018 at 06:39:04PM +0100, Florian Weimer wrote:
> * Rich Felker:
>
> > On Fri, Nov 23, 2018 at 12:05:20PM -0500, Mathieu Desnoyers wrote:
> >> There has been presumptions about signals being blocked when the thread
> >> exits throughout this email thread. Out of curiosity, what
* Rich Felker:
> On Fri, Nov 23, 2018 at 12:05:20PM -0500, Mathieu Desnoyers wrote:
>> There has been presumptions about signals being blocked when the thread
>> exits throughout this email thread. Out of curiosity, what code is
>> responsible for disabling signals in this situation ? Related to
* Rich Felker:
> On Fri, Nov 23, 2018 at 12:05:20PM -0500, Mathieu Desnoyers wrote:
>> There has been presumptions about signals being blocked when the thread
>> exits throughout this email thread. Out of curiosity, what code is
>> responsible for disabling signals in this situation ? Related to
On Fri, Nov 23, 2018 at 12:05:20PM -0500, Mathieu Desnoyers wrote:
> - On Nov 23, 2018, at 9:28 AM, Rich Felker dal...@libc.org wrote:
> [...]
> >
> > Absolutely. As long as it's in libc, implicit destruction will happen.
> > Actually I think the glibc code shound unconditionally unregister
On Fri, Nov 23, 2018 at 12:05:20PM -0500, Mathieu Desnoyers wrote:
> - On Nov 23, 2018, at 9:28 AM, Rich Felker dal...@libc.org wrote:
> [...]
> >
> > Absolutely. As long as it's in libc, implicit destruction will happen.
> > Actually I think the glibc code shound unconditionally unregister
- On Nov 23, 2018, at 9:28 AM, Rich Felker dal...@libc.org wrote:
[...]
>
> Absolutely. As long as it's in libc, implicit destruction will happen.
> Actually I think the glibc code shound unconditionally unregister the
> rseq address at exit (after blocking signals, so no application code
>
- On Nov 23, 2018, at 9:28 AM, Rich Felker dal...@libc.org wrote:
[...]
>
> Absolutely. As long as it's in libc, implicit destruction will happen.
> Actually I think the glibc code shound unconditionally unregister the
> rseq address at exit (after blocking signals, so no application code
>
On Fri, Nov 23, 2018 at 02:10:14PM +0100, Florian Weimer wrote:
> * Rich Felker:
>
> >> I'm not entirely sure because the glibc terminology is confusing, but I
> >> think it places intial-exec TLS into the static TLS area (so that it has
> >> a fixed offset from the TCB). The static TLS area is
On Fri, Nov 23, 2018 at 02:10:14PM +0100, Florian Weimer wrote:
> * Rich Felker:
>
> >> I'm not entirely sure because the glibc terminology is confusing, but I
> >> think it places intial-exec TLS into the static TLS area (so that it has
> >> a fixed offset from the TCB). The static TLS area is
* Mathieu Desnoyers:
I don't think you need unregistering if the memory is initial-exec TLS
memory. Initial-exec TLS memory is tied directly to the TCB and cannot
be freed while the thread is running, so it should be safe to put the
rseq area there even if glibc knows nothing
* Mathieu Desnoyers:
I don't think you need unregistering if the memory is initial-exec TLS
memory. Initial-exec TLS memory is tied directly to the TCB and cannot
be freed while the thread is running, so it should be safe to put the
rseq area there even if glibc knows nothing
* Rich Felker:
>> I'm not entirely sure because the glibc terminology is confusing, but I
>> think it places intial-exec TLS into the static TLS area (so that it has
>> a fixed offset from the TCB). The static TLS area is placed on the
>> user-supplied stack.
>
> This is an implementation detail
* Rich Felker:
>> I'm not entirely sure because the glibc terminology is confusing, but I
>> think it places intial-exec TLS into the static TLS area (so that it has
>> a fixed offset from the TCB). The static TLS area is placed on the
>> user-supplied stack.
>
> This is an implementation detail
- On Nov 22, 2018, at 2:01 PM, Rich Felker dal...@libc.org wrote:
> On Thu, Nov 22, 2018 at 01:35:44PM -0500, Mathieu Desnoyers wrote:
>> - On Nov 22, 2018, at 11:24 AM, Szabolcs Nagy szabolcs.n...@arm.com
>> wrote:
>>
>> > On 22/11/18 15:33, Mathieu Desnoyers wrote:
>> >> - On Nov
- On Nov 22, 2018, at 2:01 PM, Rich Felker dal...@libc.org wrote:
> On Thu, Nov 22, 2018 at 01:35:44PM -0500, Mathieu Desnoyers wrote:
>> - On Nov 22, 2018, at 11:24 AM, Szabolcs Nagy szabolcs.n...@arm.com
>> wrote:
>>
>> > On 22/11/18 15:33, Mathieu Desnoyers wrote:
>> >> - On Nov
On Thu, Nov 22, 2018 at 01:35:44PM -0500, Mathieu Desnoyers wrote:
> - On Nov 22, 2018, at 11:24 AM, Szabolcs Nagy szabolcs.n...@arm.com wrote:
>
> > On 22/11/18 15:33, Mathieu Desnoyers wrote:
> >> - On Nov 22, 2018, at 10:21 AM, Florian Weimer fwei...@redhat.com
> >> wrote:
> >>>
On Thu, Nov 22, 2018 at 01:35:44PM -0500, Mathieu Desnoyers wrote:
> - On Nov 22, 2018, at 11:24 AM, Szabolcs Nagy szabolcs.n...@arm.com wrote:
>
> > On 22/11/18 15:33, Mathieu Desnoyers wrote:
> >> - On Nov 22, 2018, at 10:21 AM, Florian Weimer fwei...@redhat.com
> >> wrote:
> >>>
- On Nov 22, 2018, at 11:24 AM, Szabolcs Nagy szabolcs.n...@arm.com wrote:
> On 22/11/18 15:33, Mathieu Desnoyers wrote:
>> - On Nov 22, 2018, at 10:21 AM, Florian Weimer fwei...@redhat.com wrote:
>>> Right, but in case of user-supplied stacks, we actually free TLS memory
>>> at this
- On Nov 22, 2018, at 11:24 AM, Szabolcs Nagy szabolcs.n...@arm.com wrote:
> On 22/11/18 15:33, Mathieu Desnoyers wrote:
>> - On Nov 22, 2018, at 10:21 AM, Florian Weimer fwei...@redhat.com wrote:
>>> Right, but in case of user-supplied stacks, we actually free TLS memory
>>> at this
- On Nov 22, 2018, at 11:59 AM, Florian Weimer fwei...@redhat.com wrote:
> * Mathieu Desnoyers:
>
>> - On Nov 22, 2018, at 11:28 AM, Florian Weimer fwei...@redhat.com wrote:
>>
>>> * Mathieu Desnoyers:
>>>
Here is one scenario: we have 2 early adopter libraries using rseq which
- On Nov 22, 2018, at 11:59 AM, Florian Weimer fwei...@redhat.com wrote:
> * Mathieu Desnoyers:
>
>> - On Nov 22, 2018, at 11:28 AM, Florian Weimer fwei...@redhat.com wrote:
>>
>>> * Mathieu Desnoyers:
>>>
Here is one scenario: we have 2 early adopter libraries using rseq which
On Thu, Nov 22, 2018 at 05:59:44PM +0100, Florian Weimer wrote:
> * Mathieu Desnoyers:
>
> > - On Nov 22, 2018, at 11:28 AM, Florian Weimer fwei...@redhat.com wrote:
> >
> >> * Mathieu Desnoyers:
> >>
> >>> Here is one scenario: we have 2 early adopter libraries using rseq which
> >>> are
On Thu, Nov 22, 2018 at 05:59:44PM +0100, Florian Weimer wrote:
> * Mathieu Desnoyers:
>
> > - On Nov 22, 2018, at 11:28 AM, Florian Weimer fwei...@redhat.com wrote:
> >
> >> * Mathieu Desnoyers:
> >>
> >>> Here is one scenario: we have 2 early adopter libraries using rseq which
> >>> are
* Mathieu Desnoyers:
> - On Nov 22, 2018, at 11:28 AM, Florian Weimer fwei...@redhat.com wrote:
>
>> * Mathieu Desnoyers:
>>
>>> Here is one scenario: we have 2 early adopter libraries using rseq which
>>> are deployed in an environment with an older glibc (which does not
>>> support rseq).
* Mathieu Desnoyers:
> - On Nov 22, 2018, at 11:28 AM, Florian Weimer fwei...@redhat.com wrote:
>
>> * Mathieu Desnoyers:
>>
>>> Here is one scenario: we have 2 early adopter libraries using rseq which
>>> are deployed in an environment with an older glibc (which does not
>>> support rseq).
- On Nov 22, 2018, at 11:28 AM, Florian Weimer fwei...@redhat.com wrote:
> * Mathieu Desnoyers:
>
>> Here is one scenario: we have 2 early adopter libraries using rseq which
>> are deployed in an environment with an older glibc (which does not
>> support rseq).
>>
>> Of course, none of those
- On Nov 22, 2018, at 11:28 AM, Florian Weimer fwei...@redhat.com wrote:
> * Mathieu Desnoyers:
>
>> Here is one scenario: we have 2 early adopter libraries using rseq which
>> are deployed in an environment with an older glibc (which does not
>> support rseq).
>>
>> Of course, none of those
* Mathieu Desnoyers:
> Here is one scenario: we have 2 early adopter libraries using rseq which
> are deployed in an environment with an older glibc (which does not
> support rseq).
>
> Of course, none of those libraries can be dlclose'd unless they somehow
> track all registered threads.
Well,
* Mathieu Desnoyers:
> Here is one scenario: we have 2 early adopter libraries using rseq which
> are deployed in an environment with an older glibc (which does not
> support rseq).
>
> Of course, none of those libraries can be dlclose'd unless they somehow
> track all registered threads.
Well,
On 22/11/18 15:33, Mathieu Desnoyers wrote:
> - On Nov 22, 2018, at 10:21 AM, Florian Weimer fwei...@redhat.com wrote:
>> Right, but in case of user-supplied stacks, we actually free TLS memory
>> at this point, so signals need to be blocked because the TCB is
>> (partially) gone after that.
>
On 22/11/18 15:33, Mathieu Desnoyers wrote:
> - On Nov 22, 2018, at 10:21 AM, Florian Weimer fwei...@redhat.com wrote:
>> Right, but in case of user-supplied stacks, we actually free TLS memory
>> at this point, so signals need to be blocked because the TCB is
>> (partially) gone after that.
>
- On Nov 22, 2018, at 10:14 AM, Rich Felker dal...@libc.org wrote:
> On Thu, Nov 22, 2018 at 10:04:16AM -0500, Mathieu Desnoyers wrote:
>> - On Nov 22, 2018, at 9:36 AM, Rich Felker dal...@libc.org wrote:
>>
>> > On Wed, Nov 21, 2018 at 01:39:32PM -0500, Mathieu Desnoyers wrote:
>> >>
- On Nov 22, 2018, at 10:14 AM, Rich Felker dal...@libc.org wrote:
> On Thu, Nov 22, 2018 at 10:04:16AM -0500, Mathieu Desnoyers wrote:
>> - On Nov 22, 2018, at 9:36 AM, Rich Felker dal...@libc.org wrote:
>>
>> > On Wed, Nov 21, 2018 at 01:39:32PM -0500, Mathieu Desnoyers wrote:
>> >>
On Thu, Nov 22, 2018 at 10:33:19AM -0500, Mathieu Desnoyers wrote:
> - On Nov 22, 2018, at 10:21 AM, Florian Weimer fwei...@redhat.com wrote:
>
> > * Rich Felker:
> >
> >> On Thu, Nov 22, 2018 at 04:11:45PM +0100, Florian Weimer wrote:
> >>> * Mathieu Desnoyers:
> >>>
> >>> > Thoughts ?
>
On Thu, Nov 22, 2018 at 10:33:19AM -0500, Mathieu Desnoyers wrote:
> - On Nov 22, 2018, at 10:21 AM, Florian Weimer fwei...@redhat.com wrote:
>
> > * Rich Felker:
> >
> >> On Thu, Nov 22, 2018 at 04:11:45PM +0100, Florian Weimer wrote:
> >>> * Mathieu Desnoyers:
> >>>
> >>> > Thoughts ?
>
- On Nov 22, 2018, at 10:21 AM, Florian Weimer fwei...@redhat.com wrote:
> * Rich Felker:
>
>> On Thu, Nov 22, 2018 at 04:11:45PM +0100, Florian Weimer wrote:
>>> * Mathieu Desnoyers:
>>>
>>> > Thoughts ?
>>> >
>>> > /* Unregister rseq TLS from kernel. */
>>> > if (has_rseq &&
- On Nov 22, 2018, at 10:21 AM, Florian Weimer fwei...@redhat.com wrote:
> * Rich Felker:
>
>> On Thu, Nov 22, 2018 at 04:11:45PM +0100, Florian Weimer wrote:
>>> * Mathieu Desnoyers:
>>>
>>> > Thoughts ?
>>> >
>>> > /* Unregister rseq TLS from kernel. */
>>> > if (has_rseq &&
* Rich Felker:
> On Thu, Nov 22, 2018 at 04:11:45PM +0100, Florian Weimer wrote:
>> * Mathieu Desnoyers:
>>
>> > Thoughts ?
>> >
>> > /* Unregister rseq TLS from kernel. */
>> > if (has_rseq && __rseq_unregister_current_thread ())
>> > abort();
>> >
>> > advise_stack_range
* Rich Felker:
> On Thu, Nov 22, 2018 at 04:11:45PM +0100, Florian Weimer wrote:
>> * Mathieu Desnoyers:
>>
>> > Thoughts ?
>> >
>> > /* Unregister rseq TLS from kernel. */
>> > if (has_rseq && __rseq_unregister_current_thread ())
>> > abort();
>> >
>> > advise_stack_range
On Thu, Nov 22, 2018 at 04:11:45PM +0100, Florian Weimer wrote:
> * Mathieu Desnoyers:
>
> > Thoughts ?
> >
> > /* Unregister rseq TLS from kernel. */
> > if (has_rseq && __rseq_unregister_current_thread ())
> > abort();
> >
> > advise_stack_range (pd->stackblock, pd->stackblock_size,
On Thu, Nov 22, 2018 at 04:11:45PM +0100, Florian Weimer wrote:
> * Mathieu Desnoyers:
>
> > Thoughts ?
> >
> > /* Unregister rseq TLS from kernel. */
> > if (has_rseq && __rseq_unregister_current_thread ())
> > abort();
> >
> > advise_stack_range (pd->stackblock, pd->stackblock_size,
On Thu, Nov 22, 2018 at 10:04:16AM -0500, Mathieu Desnoyers wrote:
> - On Nov 22, 2018, at 9:36 AM, Rich Felker dal...@libc.org wrote:
>
> > On Wed, Nov 21, 2018 at 01:39:32PM -0500, Mathieu Desnoyers wrote:
> >> Register rseq(2) TLS for each thread (including main), and unregister
> >> for
On Thu, Nov 22, 2018 at 10:04:16AM -0500, Mathieu Desnoyers wrote:
> - On Nov 22, 2018, at 9:36 AM, Rich Felker dal...@libc.org wrote:
>
> > On Wed, Nov 21, 2018 at 01:39:32PM -0500, Mathieu Desnoyers wrote:
> >> Register rseq(2) TLS for each thread (including main), and unregister
> >> for
* Mathieu Desnoyers:
> Thoughts ?
>
> /* Unregister rseq TLS from kernel. */
> if (has_rseq && __rseq_unregister_current_thread ())
> abort();
>
> advise_stack_range (pd->stackblock, pd->stackblock_size, (uintptr_t) pd,
> pd->guardsize);
>
> /* If the thread is
* Mathieu Desnoyers:
> Thoughts ?
>
> /* Unregister rseq TLS from kernel. */
> if (has_rseq && __rseq_unregister_current_thread ())
> abort();
>
> advise_stack_range (pd->stackblock, pd->stackblock_size, (uintptr_t) pd,
> pd->guardsize);
>
> /* If the thread is
- On Nov 22, 2018, at 9:36 AM, Rich Felker dal...@libc.org wrote:
> On Wed, Nov 21, 2018 at 01:39:32PM -0500, Mathieu Desnoyers wrote:
>> Register rseq(2) TLS for each thread (including main), and unregister
>> for each thread (excluding main). "rseq" stands for Restartable
>> Sequences.
>
>
- On Nov 22, 2018, at 9:36 AM, Rich Felker dal...@libc.org wrote:
> On Wed, Nov 21, 2018 at 01:39:32PM -0500, Mathieu Desnoyers wrote:
>> Register rseq(2) TLS for each thread (including main), and unregister
>> for each thread (excluding main). "rseq" stands for Restartable
>> Sequences.
>
>
On Wed, Nov 21, 2018 at 01:39:32PM -0500, Mathieu Desnoyers wrote:
> Register rseq(2) TLS for each thread (including main), and unregister
> for each thread (excluding main). "rseq" stands for Restartable
> Sequences.
Maybe I'm missing something obvious, but "unregister" does not seem to
be a
On Wed, Nov 21, 2018 at 01:39:32PM -0500, Mathieu Desnoyers wrote:
> Register rseq(2) TLS for each thread (including main), and unregister
> for each thread (excluding main). "rseq" stands for Restartable
> Sequences.
Maybe I'm missing something obvious, but "unregister" does not seem to
be a
__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
__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
e small but nonzero overhead,
> right?
There is indeed a small overhead at thread creation/exit (total of 2
system calls) and one system call in nptl init. Once registered, there
is very small, infrequent, a hard to measure overhead at thread preemption
and signal delivery.
> Should this perhaps
e small but nonzero overhead,
> right?
There is indeed a small overhead at thread creation/exit (total of 2
system calls) and one system call in nptl init. Once registered, there
is very small, infrequent, a hard to measure overhead at thread preemption
and signal delivery.
> Should this perhaps
On Fri, Nov 2, 2018 at 4:53 AM Mathieu Desnoyers
wrote:
>
> Here is a third round of prototype registering rseq(2) TLS for each
> thread (including main), and unregistering for each thread (excluding
> main). "rseq" stands for Restartable Sequences.
>
> Remaining open questions:
>
> - How early
On Fri, Nov 2, 2018 at 4:53 AM Mathieu Desnoyers
wrote:
>
> Here is a third round of prototype registering rseq(2) TLS for each
> thread (including main), and unregistering for each thread (excluding
> main). "rseq" stands for Restartable Sequences.
>
> Remaining open questions:
>
> - How early
ve 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
ve 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
1 - 100 of 250 matches
Mail list logo
