- On Jun 15, 2018, at 1:09 AM, Florian Weimer fwei...@redhat.com wrote:
> On 06/14/2018 03:01 PM, Mathieu Desnoyers wrote:
>> Another alternative would be to somehow let glibc handle the registration,
>> perhaps only doing it for applications expressing their interest for rseq.
>
> That's not
- On Jun 15, 2018, at 1:10 AM, Florian Weimer fwei...@redhat.com wrote:
> On 06/14/2018 03:46 PM, Mathieu Desnoyers wrote:
>> This would allow registering various TLS data structures with a single
>> system call without hindering flexibility on the user-space side. For
>> instance, we could st
On 06/14/2018 03:46 PM, Mathieu Desnoyers wrote:
This would allow registering various TLS data structures with a single
system call without hindering flexibility on the user-space side. For
instance, we could still use initial-exec and the __rseq_abi symbol for
rseq with this approach.
Thoughts
On 06/14/2018 03:01 PM, Mathieu Desnoyers wrote:
Another alternative would be to somehow let glibc handle the registration,
perhaps only doing it for applications expressing their interest for rseq.
That's not really possible. We can't rely on the visibility of symbol
bindings due to lazy bin
On 06/14/2018 02:27 PM, Pavel Machek wrote:
Should we treat it the same way? Always allocate it for each new thread
and register it with the kernel?
That would be an efficient way to do it, indeed. There is very little
performance overhead to have rseq registered for all threads, whether or
n
- On Jun 14, 2018, at 10:41 AM, Florian Weimer fwei...@redhat.com wrote:
> On 06/14/2018 04:36 PM, Mathieu Desnoyers wrote:
>> - On Jun 14, 2018, at 10:00 AM, Florian Weimer fwei...@redhat.com wrote:
>>
>>> On 06/14/2018 03:49 PM, Pavel Machek wrote:
Hi!
>>> - rseq_preempt()
On 06/14/2018 04:36 PM, Mathieu Desnoyers wrote:
- On Jun 14, 2018, at 10:00 AM, Florian Weimer fwei...@redhat.com wrote:
On 06/14/2018 03:49 PM, Pavel Machek wrote:
Hi!
- rseq_preempt(): on preemption, the scheduler sets the TIF_NOTIFY_RESUME thread
flag, so rseq_handle_notify_resum
- On Jun 14, 2018, at 10:00 AM, Florian Weimer fwei...@redhat.com wrote:
> On 06/14/2018 03:49 PM, Pavel Machek wrote:
>> Hi!
>>
> - rseq_preempt(): on preemption, the scheduler sets the TIF_NOTIFY_RESUME
> thread
>flag, so rseq_handle_notify_resume() can check whether it's i
On 06/14/2018 03:49 PM, Pavel Machek wrote:
Hi!
- rseq_preempt(): on preemption, the scheduler sets the TIF_NOTIFY_RESUME thread
flag, so rseq_handle_notify_resume() can check whether it's in a rseq
critical
section when returning to user-space,
- rseq_signal_deliver(): on signal deliver
Hi!
> >> - rseq_preempt(): on preemption, the scheduler sets the TIF_NOTIFY_RESUME
> >> thread
> >> flag, so rseq_handle_notify_resume() can check whether it's in a rseq
> >> critical
> >> section when returning to user-space,
> >> - rseq_signal_deliver(): on signal delivery, rseq_handle_not
- On Jun 14, 2018, at 9:32 AM, Florian Weimer fwei...@redhat.com wrote:
> On 06/14/2018 03:25 PM, Pavel Machek wrote:
>
>> But the proposal wanted to add a syscall to thread creation, right?
>> And I believe that may be noticeable.
>
> We already call set_robust_list, so we could just pass a
- On Jun 14, 2018, at 9:25 AM, Pavel Machek pa...@ucw.cz wrote:
> Hi!
>
>> >> It should be noted that there can be only one rseq TLS area
>> >> registered per
>> >> thread,
>> >> which can then be used by many libraries and by the executable, so
>> >> this is a
>> >
On 06/14/2018 03:25 PM, Pavel Machek wrote:
But the proposal wanted to add a syscall to thread creation, right?
And I believe that may be noticeable.
We already call set_robust_list, so we could just pass a larger area to
that and the kernel could use it. Then no additional system call would
Hi!
> >> It should be noted that there can be only one rseq TLS area
> >> registered per
> >> thread,
> >> which can then be used by many libraries and by the executable, so
> >> this is a
> >> process-wide (per-thread) resource that we need to manage carefully.
> >
- On Jun 14, 2018, at 8:27 AM, Pavel Machek pa...@ucw.cz wrote:
> On Tue 2018-06-12 12:31:24, Mathieu Desnoyers wrote:
>> - On Jun 12, 2018, at 9:11 AM, Florian Weimer fwei...@redhat.com wrote:
>>
>> > On 06/11/2018 10:04 PM, Mathieu Desnoyers wrote:
>> >> - On Jun 11, 2018, at 3:55 P
On Tue 2018-06-12 12:31:24, Mathieu Desnoyers wrote:
> - On Jun 12, 2018, at 9:11 AM, Florian Weimer fwei...@redhat.com wrote:
>
> > On 06/11/2018 10:04 PM, Mathieu Desnoyers wrote:
> >> - On Jun 11, 2018, at 3:55 PM, Florian Weimer fwei...@redhat.com wrote:
> >>
> >>> On 06/11/2018 09:49
- On Jun 13, 2018, at 12:14 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Jun 13, 2018, at 7:48 AM, heiko carstens heiko.carst...@de.ibm.com
> wrote:
[...]
>>
>> Is there any documentation available of what is the exact semantics of the
>> functions that have to be i
- On Jun 13, 2018, at 7:48 AM, heiko carstens heiko.carst...@de.ibm.com
wrote:
> On Mon, Jun 11, 2018 at 03:49:18PM -0400, Mathieu Desnoyers wrote:
>> Hi!
>>
>> Good news! The restartable sequences (rseq) system call is now merged into
>> the
>> master
>> branch of the Linux kernel within t
On Mon, Jun 11, 2018 at 03:49:18PM -0400, Mathieu Desnoyers wrote:
> Hi!
>
> Good news! The restartable sequences (rseq) system call is now merged into
> the master
> branch of the Linux kernel within the 4.18 merge window:
>
> https://github.com/torvalds/linux/commit/d82991a8688ad128b46db1b42d5
On 06/12/2018 06:31 PM, Mathieu Desnoyers wrote:
- On Jun 12, 2018, at 9:11 AM, Florian Weimer fwei...@redhat.com wrote:
On 06/11/2018 10:04 PM, Mathieu Desnoyers wrote:
- On Jun 11, 2018, at 3:55 PM, Florian Weimer fwei...@redhat.com wrote:
On 06/11/2018 09:49 PM, Mathieu Desnoyers
- On Jun 12, 2018, at 9:11 AM, Florian Weimer fwei...@redhat.com wrote:
> On 06/11/2018 10:04 PM, Mathieu Desnoyers wrote:
>> - On Jun 11, 2018, at 3:55 PM, Florian Weimer fwei...@redhat.com wrote:
>>
>>> On 06/11/2018 09:49 PM, Mathieu Desnoyers wrote:
It should be noted that there
On 06/11/2018 10:04 PM, Mathieu Desnoyers wrote:
- On Jun 11, 2018, at 3:55 PM, Florian Weimer fwei...@redhat.com wrote:
On 06/11/2018 09:49 PM, Mathieu Desnoyers wrote:
It should be noted that there can be only one rseq TLS area registered per
thread,
which can then be used by many librar
- On Jun 11, 2018, at 3:55 PM, Florian Weimer fwei...@redhat.com wrote:
> On 06/11/2018 09:49 PM, Mathieu Desnoyers wrote:
>> It should be noted that there can be only one rseq TLS area registered per
>> thread,
>> which can then be used by many libraries and by the executable, so this is a
>>
On 06/11/2018 09:49 PM, Mathieu Desnoyers wrote:
It should be noted that there can be only one rseq TLS area registered per
thread,
which can then be used by many libraries and by the executable, so this is a
process-wide (per-thread) resource that we need to manage carefully.
Is it possible t
Hi!
Good news! The restartable sequences (rseq) system call is now merged into the
master
branch of the Linux kernel within the 4.18 merge window:
https://github.com/torvalds/linux/commit/d82991a8688ad128b46db1b42d5d84396487a508
It would be important to discuss how we should proceed to integrat
25 matches
Mail list logo
