- 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 t
- 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 s
* 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 co
- 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
he kernel. */
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 ("ini
32_t __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 hea
- 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 Weime
- 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
>> --- a/sysdeps/unix/sysv/li
* 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
> +++ b/sysdeps/unix/sysv/linux/riscv/rv64/libpth
ts.
- 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 rse
new glibc APIs
anyway. Therefore, 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 signa
- 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 refe
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 implementation
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 tog
* 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 stron
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 12
* 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
sam
- 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:
> >> [...]
* 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. Out
- 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 ha
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 cod
* 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 t
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 th
- 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
> ca
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 p
* 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
- 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 2
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:
> >>> Right,
- 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 point
- 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 dep
* 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
* 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, y
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:
>> >> Reg
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 && __rseq_unr
* 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 (pd->stackblo
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, (u
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 ea
* 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 de
- 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 mean
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
ome 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 per
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 do
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 f
eps 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.
---
nptl/Makefile | 2 +-
nptl/Versions
- On Sep 20, 2018, at 4:20 PM, Joseph Myers jos...@codesourcery.com wrote:
> On Thu, 20 Sep 2018, Mathieu Desnoyers wrote:
>
>> Are you saying glibc has an explicit check for the kernel version visible
>> from /proc before using specific features ? If so, how can this work with
>> the varie
register_current_thread () and
> rseq_unregister_current_thread (), and sysdeps/nptl/rseq-internal.h
> contains stubs.
>
> Am I on the right track ?
It's hard to define the right abstractions for what goes where given that
only Linux uses NPTL since the removal of the NaCl por
On Thu, 20 Sep 2018, Mathieu Desnoyers wrote:
> Are you saying glibc has an explicit check for the kernel version visible
> from /proc before using specific features ? If so, how can this work with
> the variety of feature backports we find in the distribution kernels out
> there ?
See sysdeps/un
- On Sep 19, 2018, at 1:10 PM, Joseph Myers jos...@codesourcery.com wrote:
> On Wed, 19 Sep 2018, Mathieu Desnoyers wrote:
>
>> > This looks like it's coming from the Linux kernel. Can't the relevant
>> > uapi header just be used directly without copying into glibc (with due
>> > care to ens
main). "rseq" stands for Restartable Sequences.
>
> A final patch would need to add documentation and tests and a NEWS entry
> and fix various coding style issues.
Sure,
>
>> diff --git a/nptl/Versions b/nptl/Versions
>> index e7f691da7a..7316c2815d 100644
>>
On 19/09/18 22:01, Mathieu Desnoyers wrote:
- On Sep 19, 2018, at 1:38 PM, Szabolcs Nagy szabolcs.n...@arm.com wrote:
note that libpthread.so is built with -ftls-model=initial-exec
Which would indeed make these annotations redundant. I'll remove
them.
(and if it wasn't then you'd want to
t; i don't think there is precedent for exposing tls symbol in glibc
> (e.g. errno is exposed via __errno_location function) so there
> might be issues with this (but i don't have immediate concerns).
>
>> diff --git a/nptl/pthread_create.c b/nptl/pthread_create.c
>> index fe
- On Sep 19, 2018, at 3:49 PM, Joseph Myers jos...@codesourcery.com wrote:
> On Wed, 19 Sep 2018, Szabolcs Nagy wrote:
>
>> i don't think there is precedent for exposing tls symbol in glibc
>> (e.g. errno is exposed via __errno_location function) so there
>> might be issues with this (but i d
On Wed, 19 Sep 2018, Szabolcs Nagy wrote:
> i don't think there is precedent for exposing tls symbol in glibc
> (e.g. errno is exposed via __errno_location function) so there
> might be issues with this (but i don't have immediate concerns).
There have been suggestions to expose TLS errno - but a
symbol in glibc
(e.g. errno is exposed via __errno_location function) so there
might be issues with this (but i don't have immediate concerns).
diff --git a/nptl/pthread_create.c b/nptl/pthread_create.c
index fe75d04113..20ee197d94 100644
--- a/nptl/pthread_create.c
+++ b/nptl/pthread_create.c
On Wed, 19 Sep 2018, Mathieu Desnoyers wrote:
> > This looks like it's coming from the Linux kernel. Can't the relevant
> > uapi header just be used directly without copying into glibc (with due
> > care to ensure that glibc still builds if the kernel headers used for the
> > build are too old -
main). "rseq" stands for Restartable Sequences.
>
> A final patch would need to add documentation and tests and a NEWS entry
> and fix various coding style issues.
>
>> diff --git a/nptl/Versions b/nptl/Versions
>> index e7f691da7a..7316c2815d 100644
>>
nd tests and a NEWS entry
and fix various coding style issues.
> diff --git a/nptl/Versions b/nptl/Versions
> index e7f691da7a..7316c2815d 100644
> --- a/nptl/Versions
> +++ b/nptl/Versions
> @@ -275,6 +275,7 @@ libpthread {
> mtx_init; mtx_lock; mtx_timedlock;
ot;Paul E. McKenney"
CC: Boqun Feng
CC: Will Deacon
CC: Dave Watson
CC: Paul Turner
CC: libc-al...@sourceware.org
CC: linux-kernel@vger.kernel.org
CC: linux-...@vger.kernel.org
---
nptl/Versions | 1 +
nptl/nptl-init.c | 3 +
nptl/pthreadP.h
On 2017.05.19 at 17:48 +0200, Peter Zijlstra wrote:
> On Thu, May 18, 2017 at 10:34:34AM +0200, Florian Weimer wrote:
> > On 05/18/2017 10:31 AM, Peter Zijlstra wrote:
>
> > > But it does that after building the tst-robustpi8 thing, so I seem to
> > > have all I need here.
> >
> > Great, have fun
On Fri, May 19, 2017 at 05:48:50PM +0200, Peter Zijlstra wrote:
> Markus reported that the glibc/nptl/tst-robustpi8 test was failing after
> commit:
>
> cfafcd117da0 ("futex: Rework futex_lock_pi() to use
> rt_mutex_*_proxy_lock()")
>
> Much tracing later
Please test the below, it cures things for me.
---
Subject: futex,rt_mutex: Fix rt_mutex_cleanup_proxy_lock()
Markus reported that the glibc/nptl/tst-robustpi8 test was failing after
commit:
cfafcd117da0 ("futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()")
Much tracing
On Thu, May 18, 2017 at 01:43:23PM +0200, Peter Zijlstra wrote:
> On Thu, May 18, 2017 at 10:34:34AM +0200, Florian Weimer wrote:
> > On 05/18/2017 10:31 AM, Peter Zijlstra wrote:
>
> > > But it does that after building the tst-robustpi8 thing, so I seem to
> > > have all I need here.
> >
> > Gre
On Thu, May 18, 2017 at 10:34:34AM +0200, Florian Weimer wrote:
> On 05/18/2017 10:31 AM, Peter Zijlstra wrote:
> > But it does that after building the tst-robustpi8 thing, so I seem to
> > have all I need here.
>
> Great, have fun figuring out what's going on. :-/
ld-linux-x86-64-2165 [018]
On 05/18/2017 10:41 AM, Peter Zijlstra wrote:
> On Thu, May 18, 2017 at 10:34:34AM +0200, Florian Weimer wrote:
>> On 05/18/2017 10:31 AM, Peter Zijlstra wrote:
>>> That more or less worked, it still failed:
>>>
>>> /usr/bin/ld: /usr/local/src/glib
On Thu, May 18, 2017 at 10:34:34AM +0200, Florian Weimer wrote:
> On 05/18/2017 10:31 AM, Peter Zijlstra wrote:
> > That more or less worked, it still failed:
> >
> > /usr/bin/ld: /usr/local/src/glibc/build/nptl/tst-once5.o: relocation
> > R_X86_64_32 against `.text&#
On 05/18/2017 10:31 AM, Peter Zijlstra wrote:
> That more or less worked, it still failed:
>
> /usr/bin/ld: /usr/local/src/glibc/build/nptl/tst-once5.o: relocation
> R_X86_64_32 against `.text' can not be used when making a shared object;
> recompile with -fPIC
> /usr/bi
ure --disable-sanity-checks ; make -j40
> > build$ ./nptl/tst-robustpi8
> > -bash: ./nptl/tst-robustpi8: No such file or directory
> >
> > "make tests" doesn't seem to work either even though its a build target
> > listed in the Makefiles.
>
> This bui
gt; > > Author: Peter Zijlstra
> > > Date: Wed Mar 22 11:35:58 2017 +0100
> > >
> > > futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()
> > >
> > > glibc's nptl/tst-robustpi8 testcase fails:
> > >
On 05/18/2017 09:40 AM, Peter Zijlstra wrote:
> OK, so how do I get those tests build?
>
> I did a checkout of glibc.git
>
> glibc$ mkdir build; cd build
> build$ ../configure --disable-sanity-checks ; make -j40
> build$ ./nptl/tst-robustpi8
> -bash: ./nptl/tst-ro
t; > futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()
> >
> > glibc's nptl/tst-robustpi8 testcase fails:
> >
> > glibc-build % ./nptl/tst-robustpi8
> > tst-robustpi8: ../nptl/pthread_mutex_lock.c:424: __pthread_mutex_lock_full:
> > Asser
On Wed, May 17, 2017 at 07:36:46PM +0200, Markus Trippelsdorf wrote:
> Since:
> commit cfafcd117da0216520568c195cb2f6cd1980c4bb
> Author: Peter Zijlstra
> Date: Wed Mar 22 11:35:58 2017 +0100
>
> futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()
>
> gl
; Author: Peter Zijlstra
> > > Date: Wed Mar 22 11:35:58 2017 +0100
> > >
> > > futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()
> > >
> > > glibc's nptl/tst-robustpi8 testcase fails:
> > >
> > > glibc-build % ./np
t; futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()
> >
> > glibc's nptl/tst-robustpi8 testcase fails:
> >
> > glibc-build % ./nptl/tst-robustpi8
> > tst-robustpi8: ../nptl/pthread_mutex_lock.c:424: __pthread_mutex_lock_full:
&g
On 05/17/2017 07:36 PM, Markus Trippelsdorf wrote:
> Since:
> commit cfafcd117da0216520568c195cb2f6cd1980c4bb
> Author: Peter Zijlstra
> Date: Wed Mar 22 11:35:58 2017 +0100
>
> futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()
>
> glibc's nptl
Since:
commit cfafcd117da0216520568c195cb2f6cd1980c4bb
Author: Peter Zijlstra
Date: Wed Mar 22 11:35:58 2017 +0100
futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()
glibc's nptl/tst-robustpi8 testcase fails:
glibc-build % ./nptl/tst-robustpi8
tst-robustpi8: ..
On Sat, 2 Apr 2016, Peter Zijlstra wrote:
> On Sat, Apr 02, 2016 at 11:09:20AM -, Thomas Gleixner wrote:
> > To undo the attachment each involved thread needs to call
> >
> > pthread_mutex_detach_np(&mutex);
> >
> > When the last user detaches the kernel state is destroyed.
>
> S
On Sat, Apr 02, 2016 at 06:30:59PM +0200, Peter Zijlstra wrote:
> On Sat, Apr 02, 2016 at 11:09:20AM -, Thomas Gleixner wrote:
> > pthread_mutexes on Linux are based on the futex mechanism. The standard
> > futex
> > mechanism in the Linux kernel uses a global hash to store transient
> > state
On Sat, Apr 02, 2016 at 11:09:20AM -, Thomas Gleixner wrote:
> pthread_mutexes on Linux are based on the futex mechanism. The standard futex
> mechanism in the Linux kernel uses a global hash to store transient
> state. Collisions on that hash can lead to performance degradation and on
> real-t
hed (similar to FUTEX_PRIVATE). This excludes pthread_condvars for now,
but it will be implemented once the details of this new mechanism are agreed
on.
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
---
nptl/Makefile
On Thu, 15 Jan 2015 07:35:01 +
Alexey Brodkin wrote:
> Hi Clark, John,
>
> On Mon, 2014-11-10 at 10:16 +0300, Alexey Brodkin wrote:
> > Some architectures are still stuck with non-NPTL toolchains.
> > These are for example ARC, Blackfin, Xtensa etc.
> >
>
Hi Clark, John,
On Mon, 2014-11-10 at 10:16 +0300, Alexey Brodkin wrote:
> Some architectures are still stuck with non-NPTL toolchains.
> These are for example ARC, Blackfin, Xtensa etc.
>
> Still rt-tests are very good benchmarks and it would be good to enable use of
> at least
Some architectures are still stuck with non-NPTL toolchains.
These are for example ARC, Blackfin, Xtensa etc.
Still rt-tests are very good benchmarks and it would be good to enable use of
at least selected (those that will be built) tests on those architectures.
This change makes it possible to
On Thu, 2008-02-07 at 10:53 -0500, Parag Warudkar wrote:
>
> On Thu, 7 Feb 2008, Alejandro Riveira Fernández wrote:
>
> > gcc --version
> >
> > gcc-4.2 (GCC) 4.2.1 (Ubuntu 4.2.1-5ubuntu4)
> >
> > If some fields are empty or look unusual you may have an old version.
> > Compare to the current m
On Thu, 7 Feb 2008, Parag Warudkar wrote:
> Yep. I will enable PREEMPT and see if it reproduces for me.
Not reproducible with PREEMPT either.
Parag
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at h
On Thu, 7 Feb 2008, Alejandro Riveira Fernández wrote:
> El Thu, 7 Feb 2008 10:56:16 -0500 (EST)
> Parag Warudkar <[EMAIL PROTECTED]> escribió:
>
> >
> >
> > On Thu, 7 Feb 2008, Parag Warudkar wrote:
> >
> > >x86_64+SMP+PREEMPT+GnuC-4.1.2+Glibc-2.5 = Reproducible.
> > >
> > That
El Thu, 7 Feb 2008 10:56:16 -0500 (EST)
Parag Warudkar <[EMAIL PROTECTED]> escribió:
>
>
> On Thu, 7 Feb 2008, Parag Warudkar wrote:
>
> >x86_64+SMP+PREEMPT+GnuC-4.1.2+Glibc-2.5 = Reproducible.
> >
> That should of course be
> x86_64+SMP+PREEMPT+GnuC-4.1.3+Glibc-2.6.1 = Reproducible.
On Thu, 7 Feb 2008, Parag Warudkar wrote:
>x86_64+SMP+PREEMPT+GnuC-4.1.2+Glibc-2.5 = Reproducible.
>
That should of course be
x86_64+SMP+PREEMPT+GnuC-4.1.3+Glibc-2.6.1 = Reproducible.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Thu, 7 Feb 2008, Alejandro Riveira Fernández wrote:
> gcc --version
>
> gcc-4.2 (GCC) 4.2.1 (Ubuntu 4.2.1-5ubuntu4)
>
> If some fields are empty or look unusual you may have an old version.
> Compare to the current minimal requirements in Documentation/Changes.
>
> Linux Varda 2.6.24 #2
El Wed, 6 Feb 2008 21:57:38 -0500 (EST)
Parag Warudkar <[EMAIL PROTECTED]> escribió:
>
>
> On Wed, 6 Feb 2008, Frank Mayhar wrote:
>
> > On Wed, 2008-02-06 at 16:50 -0800, Andrew Morton wrote:
> > > It's probably better to handle this one via email, so please send that
> > > testcase vie reply-
1 - 100 of 130 matches
Mail list logo
