y with it by raising a task struct flag, and
using
it in a return to userspace notifier (where we can actually take a fault), where
we touch the userspace TLS area.
If we can find a way to solve this limitation, then the rest of your design
makes sense to me.
Thanks!
Mathieu
-
y with it by raising a task struct flag, and
using
it in a return to userspace notifier (where we can actually take a fault), where
we touch the userspace TLS area.
If we can find a way to solve this limitation, then the rest of your design
makes sense to me.
Thanks!
Mathieu
-
.
TODO: wire up rseq_syscall() on return from system call. It is used with
CONFIG_DEBUG_RSEQ=y to ensure system calls are not issued within rseq critical
section
Signed-off-by: Mathieu Desnoyers <mathieu.desnoy...@efficios.com>
CC: Russell King <li...@arm.linux.org.uk>
CC: Cat
.
TODO: wire up rseq_syscall() on return from system call. It is used with
CONFIG_DEBUG_RSEQ=y to ensure system calls are not issued within rseq critical
section
Signed-off-by: Mathieu Desnoyers
CC: Russell King
CC: Catalin Marinas
CC: Will Deacon
CC: Thomas Gleixner
CC: Paul Turner
CC
sequences system call
Mathieu Desnoyers (12):
uapi headers: Provide types_32_64.h (v2)
rseq: Introduce restartable sequences system call (v13)
arm: Add restartable sequences support
arm: Wire up restartable sequences system call
x86: Add support for restartable sequences (v2)
x86: Wire up
sequences system call
Mathieu Desnoyers (12):
uapi headers: Provide types_32_64.h (v2)
rseq: Introduce restartable sequences system call (v13)
arm: Add restartable sequences support
arm: Wire up restartable sequences system call
x86: Add support for restartable sequences (v2)
x86: Wire up
r-cpu data.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoy...@efficios.com>
Reviewed-by: Thomas Gleixner <t...@linutronix.de>
CC: Russell King <li...@arm.linux.org.uk>
CC: Catalin Marinas <catalin.mari...@arm.com>
CC: Will Deacon <will.dea...@arm.com>
CC: Paul Tu
ogle.com
Link:
http://lkml.kernel.org/r/20150624222609.6116.86035.st...@kitami.mtv.corp.google.com
Signed-off-by: Mathieu Desnoyers <mathieu.desnoy...@efficios.com>
CC: Thomas Gleixner <t...@linutronix.de>
CC: Paul Turner <p...@google.com>
CC: Andrew Hunter <a...@google.com>
r-cpu data.
Signed-off-by: Mathieu Desnoyers
Reviewed-by: Thomas Gleixner
CC: Russell King
CC: Catalin Marinas
CC: Will Deacon
CC: Paul Turner
CC: Andrew Hunter
CC: Peter Zijlstra
CC: Andy Lutomirski
CC: Andi Kleen
CC: Dave Watson
CC: Chris Lameter
CC: Ingo Molnar
CC: "H. Peter
ogle.com
Link:
http://lkml.kernel.org/r/20150624222609.6116.86035.st...@kitami.mtv.corp.google.com
Signed-off-by: Mathieu Desnoyers
CC: Thomas Gleixner
CC: Paul Turner
CC: Andrew Hunter
CC: Peter Zijlstra
CC: Andy Lutomirski
CC: Andi Kleen
CC: Dave Watson
CC: Chris Lameter
CC: Ingo Molnar
t;boqun.f...@gmail.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoy...@efficios.com>
CC: Benjamin Herrenschmidt <b...@kernel.crashing.org>
CC: Paul Mackerras <pau...@samba.org>
CC: Michael Ellerman <m...@ellerman.id.au>
CC: Peter Zijlstra <pet...@infr
u
data compared to using load-reservation/store-conditional atomics.
TODO: wire up rseq_syscall() on return from system call. It is used with
CONFIG_DEBUG_RSEQ=y to ensure system calls are not issued within rseq critical
section
Signed-off-by: Boqun Feng <boqun.f...@gmail.com>
Signed-off-by: Mathi
From: Boqun Feng
Call the rseq_handle_notify_resume() function on return to userspace if
TIF_NOTIFY_RESUME thread flag is set.
Perform fixup on the pre-signal when a signal is delivered on top of a
restartable sequence critical section.
Signed-off-by: Boqun Feng
Signed-off-by: Mathieu
-reservation/store-conditional atomics.
TODO: wire up rseq_syscall() on return from system call. It is used with
CONFIG_DEBUG_RSEQ=y to ensure system calls are not issued within rseq critical
section
Signed-off-by: Boqun Feng
Signed-off-by: Mathieu Desnoyers
CC: Benjamin Herrenschmidt
CC: Paul
"basic_test" only asserts that RSEQ works moderately correctly. E.g.
that the CPUID pointer works.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoy...@efficios.com>
CC: Shuah Khan <shua...@osg.samsung.com>
CC: Russell King <li...@arm.linux.org.uk>
CC: Catalin Marinas
Introduce OVERRIDE_TARGETS to allow tests to express dependencies on
header files and .so, which require to override the selftests lib.mk
targets.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoy...@efficios.com>
Acked-by: Shuah Khan <shua...@osg.samsung.com>
CC: Russ
"basic_test" only asserts that RSEQ works moderately correctly. E.g.
that the CPUID pointer works.
Signed-off-by: Mathieu Desnoyers
CC: Shuah Khan
CC: Russell King
CC: Catalin Marinas
CC: Will Deacon
CC: Thomas Gleixner
CC: Paul Turner
CC: Andrew Hunter
CC: Peter Zijlstra
Introduce OVERRIDE_TARGETS to allow tests to express dependencies on
header files and .so, which require to override the selftests lib.mk
targets.
Signed-off-by: Mathieu Desnoyers
Acked-by: Shuah Khan
CC: Russell King
CC: Catalin Marinas
CC: Will Deacon
CC: Thomas Gleixner
CC: Paul Turner
"basic_percpu_ops_test" is a slightly more "realistic" variant,
implementing a few simple per-cpu operations and testing their
correctness.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoy...@efficios.com>
CC: Shuah Khan <shua...@osg.samsung.com>
CC: Russell
"basic_percpu_ops_test" is a slightly more "realistic" variant,
implementing a few simple per-cpu operations and testing their
correctness.
Signed-off-by: Mathieu Desnoyers
CC: Shuah Khan
CC: Russell King
CC: Catalin Marinas
CC: Will Deacon
CC: Thomas Gleixner
CC: Pau
.
The order of padding and 32-bit integer depends on the
endianness.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoy...@efficios.com>
CC: "Paul E. McKenney" <paul...@linux.vnet.ibm.com>
CC: Peter Zijlstra <pet...@infradead.org>
CC: Paul Turner <p...@google.com>
CC: T
.
The order of padding and 32-bit integer depends on the
endianness.
Signed-off-by: Mathieu Desnoyers
CC: "Paul E. McKenney"
CC: Peter Zijlstra
CC: Paul Turner
CC: Thomas Gleixner
CC: Andrew Hunter
CC: Andy Lutomirski
CC: Andi Kleen
CC: Dave Watson
CC: Chris Lameter
CC: Ingo Moln
may know where to place breakpoints when single-stepping
through assembly blocks which may be aborted at any point by the kernel.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoy...@efficios.com>
CC: Shuah Khan <shua...@osg.samsung.com>
CC: Russell King <li...@arm.linux.org.uk>
C
may know where to place breakpoints when single-stepping
through assembly blocks which may be aborted at any point by the kernel.
Signed-off-by: Mathieu Desnoyers
CC: Shuah Khan
CC: Russell King
CC: Catalin Marinas
CC: Will Deacon
CC: Thomas Gleixner
CC: Paul Turner
CC: Andrew Hunter
CC
A run_param_test.sh script runs many variants of the parametrizable
tests.
Wire up the rseq Makefile, add directory entry into MAINTAINERS file.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoy...@efficios.com>
CC: Shuah Khan <shua...@osg.samsung.com>
CC: Russell King <li...@arm.l
A run_param_test.sh script runs many variants of the parametrizable
tests.
Wire up the rseq Makefile, add directory entry into MAINTAINERS file.
Signed-off-by: Mathieu Desnoyers
CC: Shuah Khan
CC: Russell King
CC: Catalin Marinas
CC: Will Deacon
CC: Thomas Gleixner
CC: Paul Turner
CC
Call the rseq_handle_notify_resume() function on return to
userspace if TIF_NOTIFY_RESUME thread flag is set.
Perform fixup on the pre-signal frame when a signal is delivered on top
of a restartable sequence critical section.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoy...@efficios.com&
Call the rseq_handle_notify_resume() function on return to
userspace if TIF_NOTIFY_RESUME thread flag is set.
Perform fixup on the pre-signal frame when a signal is delivered on top
of a restartable sequence critical section.
Signed-off-by: Mathieu Desnoyers
CC: Russell King
CC: Catalin
is the same as "param_test", but it performs
each comparison within rseq critical section twice, thus validating
invariants. If any of the second comparisons fails, an error message
is printed and the test aborts.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoy...@efficios.com
is the same as "param_test", but it performs
each comparison within rseq critical section twice, thus validating
invariants. If any of the second comparisons fails, an error message
is printed and the test aborts.
Signed-off-by: Mathieu Desnoyers
CC: Shuah Khan
CC: Russell King
CC: Cat
sections by invoking rseq_signal() from syscall_return_slowpath().
With CONFIG_DEBUG_RSEQ, such behavior results in termination of the
process with SIGSEGV.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoy...@efficios.com>
Reviewed-by: Thomas Gleixner <t...@linutronix.de>
CC: Russ
sections by invoking rseq_signal() from syscall_return_slowpath().
With CONFIG_DEBUG_RSEQ, such behavior results in termination of the
process with SIGSEGV.
Signed-off-by: Mathieu Desnoyers
Reviewed-by: Thomas Gleixner
CC: Russell King
CC: Catalin Marinas
CC: Will Deacon
CC: Paul Turner
CC
u_ops_test
ok 1..2 selftests: basic_percpu_ops_test [PASS]
selftests: param_test
ok 1..3 selftests: param_test [PASS]
Signed-off-by: Mathieu Desnoyers <mathieu.desnoy...@efficios.com>
Fixes: 1f87c7c15d7 ("selftests: lib.mk: change RUN_TE
u_ops_test
ok 1..2 selftests: basic_percpu_ops_test [PASS]
selftests: param_test
ok 1..3 selftests: param_test [PASS]
Signed-off-by: Mathieu Desnoyers
Fixes: 1f87c7c15d7 ("selftests: lib.mk: change RUN_TESTS to print messages in
TAP13 for
- On Apr 27, 2018, at 5:05 PM, shuah sh...@kernel.org wrote:
> On 04/27/2018 02:42 PM, Shuah Khan wrote:
>> On 04/27/2018 02:17 PM, Mathieu Desnoyers wrote:
>>> - On Nov 1, 2017, at 6:28 PM, Shuah Khan shua...@osg.samsung.com wrote:
>>>
>>>> On 11/01
- On Apr 27, 2018, at 5:05 PM, shuah sh...@kernel.org wrote:
> On 04/27/2018 02:42 PM, Shuah Khan wrote:
>> On 04/27/2018 02:17 PM, Mathieu Desnoyers wrote:
>>> - On Nov 1, 2017, at 6:28 PM, Shuah Khan shua...@osg.samsung.com wrote:
>>>
>>>> On 11/01
- On Nov 1, 2017, at 6:28 PM, Shuah Khan shua...@osg.samsung.com wrote:
> On 11/01/2017 04:24 PM, Mathieu Desnoyers wrote:
>> - On Nov 1, 2017, at 6:22 PM, Mathieu Desnoyers
>> mathieu.desnoy...@efficios.com wrote:
>>
>>> - On Nov 1, 201
- On Nov 1, 2017, at 6:28 PM, Shuah Khan shua...@osg.samsung.com wrote:
> On 11/01/2017 04:24 PM, Mathieu Desnoyers wrote:
>> - On Nov 1, 2017, at 6:22 PM, Mathieu Desnoyers
>> mathieu.desnoy...@efficios.com wrote:
>>
>>> - On Nov 1, 201
27, 2018 at 7:47 AM, Steven Rostedt <rost...@goodmis.org> wrote:
>>> > On Fri, 27 Apr 2018 10:26:29 -0400 (EDT)
>>> > Mathieu Desnoyers <mathieu.desnoy...@efficios.com> wrote:
>>> >
>>> >> The general approach and the implemen
>> > On Fri, 27 Apr 2018 10:26:29 -0400 (EDT)
>>> > Mathieu Desnoyers wrote:
>>> >
>>> >> The general approach and the implementation look fine, except for
>>> >> one small detail: I would be tempted to explicitly disable preemption
s already deals with all sorts of
> context - normal, softirq, irq, NMI, preemption disabled, irq
> disabled.
It does so by disabling preemption in the callbacks, even when it's
redundant with the guarantees already provided by tracepoint-sched-rcu
and by kprobes. It's not that great for a fast-path.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Apr 27, 2018, at 11:40 AM, rostedt rost...@goodmis.org wrote:
> On Fri, 27 Apr 2018 08:38:26 -0700
> "Paul E. McKenney" wrote:
>
>> On Fri, Apr 27, 2018 at 10:47:47AM -0400, Steven Rostedt wrote:
>> > On Fri, 27 Apr 2018 10:26:29 -0400 (
- On Apr 27, 2018, at 10:47 AM, rostedt rost...@goodmis.org wrote:
> On Fri, 27 Apr 2018 10:26:29 -0400 (EDT)
> Mathieu Desnoyers <mathieu.desnoy...@efficios.com> wrote:
>
>> The general approach and the implementation look fine, except for
>> one small
- On Apr 27, 2018, at 10:47 AM, rostedt rost...@goodmis.org wrote:
> On Fri, 27 Apr 2018 10:26:29 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
>> The general approach and the implementation look fine, except for
>> one small detail: I would be tempted to explicitly disable
el.org/patch/10344297/
>
> Cc: Steven Rostedt <rost...@goodmis.org>
> Cc: Peter Zilstra <pet...@infradead.org>
> Cc: Ingo Molnar <mi...@redhat.com>
> Cc: Mathieu Desnoyers <mathieu.desnoy...@efficios.com>
> Cc: Tom Zanussi <tom.zanu...@linux.intel.com>
/patch/10344297/
>
> Cc: Steven Rostedt
> Cc: Peter Zilstra
> Cc: Ingo Molnar
> Cc: Mathieu Desnoyers
> Cc: Tom Zanussi
> Cc: Namhyung Kim
> Cc: Thomas Glexiner
> Cc: Boqun Feng
> Cc: Paul McKenney
> Cc: Frederic Weisbecker
> Cc: Randy Dunlap
> Cc:
across different
RCU read-side critical sections without any reference counting
(or locking) to ensure protection against removal.
Thanks,
Mathieu
> + * @pos: the type * to use as a loop cursor.
> + * @head:the head for your list.
> + * @member: the name of the list_node within the struct.
> + */
> +#define list_for_each_entry_from_rcu(pos, head, member)
> \
> + for (; &(pos)->member != (head);
> \
> + pos = list_entry_rcu(pos->member.next, typeof(*(pos)), member))
> +
> /**
> * hlist_del_rcu - deletes entry from hash list without re-initialization
> * @n: the element to delete from the hash list.
> --
> 2.14.0.rc0.dirty
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
read-side critical sections without any reference counting
(or locking) to ensure protection against removal.
Thanks,
Mathieu
> + * @pos: the type * to use as a loop cursor.
> + * @head:the head for your list.
> + * @member: the name of the list_node within the struct.
> + */
> +#define list_for_each_entry_from_rcu(pos, head, member)
> \
> + for (; &(pos)->member != (head);
> \
> + pos = list_entry_rcu(pos->member.next, typeof(*(pos)), member))
> +
> /**
> * hlist_del_rcu - deletes entry from hash list without re-initialization
> * @n: the element to delete from the hash list.
> --
> 2.14.0.rc0.dirty
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
Considering that user-space expects CLOCK_MONOTONIC not to account time
during which system is suspended, explicitly document this behavior as
ABI.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoy...@efficios.com>
CC: Michael Kerrisk <mtk.manpa...@gmail.com>
CC: Thomas
Considering that user-space expects CLOCK_MONOTONIC not to account time
during which system is suspended, explicitly document this behavior as
ABI.
Signed-off-by: Mathieu Desnoyers
CC: Michael Kerrisk
CC: Thomas Gleixner
CC: John Stultz
CC: Stephen Boyd
CC: Linus Torvalds
---
man2
- On Apr 26, 2018, at 11:03 AM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Apr 25, 2018, at 6:51 PM, rostedt rost...@goodmis.org wrote:
>
>> On Wed, 25 Apr 2018 17:40:56 -0400 (EDT)
>> Mathieu Desnoyers <mathieu.desnoy...@efficios.com> wr
- On Apr 26, 2018, at 11:03 AM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Apr 25, 2018, at 6:51 PM, rostedt rost...@goodmis.org wrote:
>
>> On Wed, 25 Apr 2018 17:40:56 -0400 (EDT)
>> Mathieu Desnoyers wrote:
>>
>>> One problem w
- On Apr 25, 2018, at 7:13 PM, Joel Fernandes joe...@google.com wrote:
> Hi Mathieu,
>
> On Wed, Apr 25, 2018 at 2:40 PM, Mathieu Desnoyers
> <mathieu.desnoy...@efficios.com> wrote:
>> - On Apr 25, 2018, at 5:27 PM, Joel Fernandes joe...@google.com wrote:
>>
- On Apr 25, 2018, at 7:13 PM, Joel Fernandes joe...@google.com wrote:
> Hi Mathieu,
>
> On Wed, Apr 25, 2018 at 2:40 PM, Mathieu Desnoyers
> wrote:
>> - On Apr 25, 2018, at 5:27 PM, Joel Fernandes joe...@google.com wrote:
>>
>>> On Tue, Apr 24,
- On Apr 25, 2018, at 6:51 PM, rostedt rost...@goodmis.org wrote:
> On Wed, 25 Apr 2018 17:40:56 -0400 (EDT)
> Mathieu Desnoyers <mathieu.desnoy...@efficios.com> wrote:
>
>> One problem with your approach is that you can have multiple callers
>> for the same tracep
- On Apr 25, 2018, at 6:51 PM, rostedt rost...@goodmis.org wrote:
> On Wed, 25 Apr 2018 17:40:56 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
>> One problem with your approach is that you can have multiple callers
>> for the same tracepoint name, where some cou
kernel without debug options enabled.
Regarding the name, I'm OK with having something along the lines of
trace_*event*_blocking or such. Please don't use "srcu" or other naming
that is explicitly tied to the underlying mechanism used internally
however: what we want to convey is that this specific tracepoint probe
can be preempted and block. The underlying implementation could move to
a different RCU flavor brand in the future, and it should not impact
users of the tracepoint APIs.
In order to ensure that probes that may block only register themselves
to tracepoints that allow blocking, we should introduce new tracepoint
declaration/definition *and* registration APIs also contain the
"BLOCKING/blocking" keywords (or such), so we can ensure that a
tracepoint probe being registered to a "blocking" tracepoint is indeed
allowed to block.
Thanks,
Mathieu
>
> Thanks,
>
> - Joel
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
Regarding the name, I'm OK with having something along the lines of
trace_*event*_blocking or such. Please don't use "srcu" or other naming
that is explicitly tied to the underlying mechanism used internally
however: what we want to convey is that this specific tracepoint probe
can be preempted and block. The underlying implementation could move to
a different RCU flavor brand in the future, and it should not impact
users of the tracepoint APIs.
In order to ensure that probes that may block only register themselves
to tracepoints that allow blocking, we should introduce new tracepoint
declaration/definition *and* registration APIs also contain the
"BLOCKING/blocking" keywords (or such), so we can ensure that a
tracepoint probe being registered to a "blocking" tracepoint is indeed
allowed to block.
Thanks,
Mathieu
>
> Thanks,
>
> - Joel
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
> On Mon, Apr 23, 2018 at 05:22:44PM -0400, Steven Rostedt wrote:
>>> > > >> On Mon, 23 Apr 2018 13:12:21 -0400 (EDT)
>>> > > >> Mathieu Desnoyers <mathieu.desnoy...@efficios.com> wrote:
>>> > > >>
>>> > > &
700, Paul E. McKenney wrote:
>>> > On Tue, Apr 24, 2018 at 09:01:34AM -0700, Joel Fernandes wrote:
>>> > > On Tue, Apr 24, 2018 at 8:56 AM, Paul E. McKenney
>>> > > wrote:
>>> > > > On Mon, Apr 23, 2018 at 05:22:44PM -0400, Steven Rostedt wrote:
- On Apr 23, 2018, at 12:18 PM, rostedt rost...@goodmis.org wrote:
> On Mon, 23 Apr 2018 10:59:43 -0400 (EDT)
> Mathieu Desnoyers <mathieu.desnoy...@efficios.com> wrote:
>
>> The main open question here is whether we want one SRCU grace period
>> domain per
- On Apr 23, 2018, at 12:18 PM, rostedt rost...@goodmis.org wrote:
> On Mon, 23 Apr 2018 10:59:43 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
>> The main open question here is whether we want one SRCU grace period
>> domain per SRCU tracepoint definition, or just on
- On Apr 23, 2018, at 10:53 AM, rostedt rost...@goodmis.org wrote:
> On Mon, 23 Apr 2018 10:31:28 -0400 (EDT)
> Mathieu Desnoyers <mathieu.desnoy...@efficios.com> wrote:
>
>> I've been wanting to introduce an alternative tracepoint instrumentation
>> "flavor&
- On Apr 23, 2018, at 10:53 AM, rostedt rost...@goodmis.org wrote:
> On Mon, 23 Apr 2018 10:31:28 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
>> I've been wanting to introduce an alternative tracepoint instrumentation
>> "flavor" for e.g. system call entry/exit
the
>> rcu_irq_enter_* was added in the first place. Would be nice if we can
>> just avoid these RCU calls for the preempt/irq tracepoints... Any
>> thoughts about this or any other ideas to solve this?
>
> In theory, the tracepoint code could use SRCU instead of RCU, given that
can
>> just avoid these RCU calls for the preempt/irq tracepoints... Any
>> thoughts about this or any other ideas to solve this?
>
> In theory, the tracepoint code could use SRCU instead of RCU, given that
> SRCU readers can be in the idle loop, although at the expense of a couple
> of smp_mb() calls in each tracepoint. In practice, I must defer to the
> people who know the tracepoint code better than I.
I've been wanting to introduce an alternative tracepoint instrumentation
"flavor" for e.g. system call entry/exit which rely on SRCU rather than
sched-rcu (preempt-off). This would allow taking faults within the
instrumentation
probe, which makes lots of things easier when fetching data from user-space
upon system call entry/exit. This could also be used to cleanly instrument
the idle loop.
I would be tempted to proceed carefully and introduce a new kind of SRCU
tracepoint rather than changing all existing ones from sched-rcu to SRCU
though.
So the lockdep stuff could use the SRCU tracepoint flavor, which I guess
would be faster than the rcu_irq_enter_*().
Thanks,
Mathieu
>
> Thanx, Paul
>
>> Meanwhile I'll also do some performance testing with Matsami's idea as well..
>>
>> thanks,
>>
>> - Joel
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Apr 16, 2018, at 3:26 PM, Linus Torvalds torva...@linux-foundation.org
wrote:
> On Mon, Apr 16, 2018 at 12:21 PM, Mathieu Desnoyers
> <mathieu.desnoy...@efficios.com> wrote:
>>
>> And I try very hard to avoid being told I'm the one breaking
>> u
- On Apr 16, 2018, at 3:26 PM, Linus Torvalds torva...@linux-foundation.org
wrote:
> On Mon, Apr 16, 2018 at 12:21 PM, Mathieu Desnoyers
> wrote:
>>
>> And I try very hard to avoid being told I'm the one breaking
>> user-space. ;-)
>
> You *can't* be breaking
- On Apr 16, 2018, at 2:39 PM, Linus Torvalds torva...@linux-foundation.org
wrote:
> On Mon, Apr 16, 2018 at 11:35 AM, Mathieu Desnoyers
> <mathieu.desnoy...@efficios.com> wrote:
>> Specifically for single-stepping, the __rseq_table section introduced
>> at use
- On Apr 16, 2018, at 2:39 PM, Linus Torvalds torva...@linux-foundation.org
wrote:
> On Mon, Apr 16, 2018 at 11:35 AM, Mathieu Desnoyers
> wrote:
>> Specifically for single-stepping, the __rseq_table section introduced
>> at user-level will allow newer debuggers and t
- On Apr 14, 2018, at 6:44 PM, Andy Lutomirski l...@amacapital.net wrote:
> On Thu, Apr 12, 2018 at 12:43 PM, Linus Torvalds
> <torva...@linux-foundation.org> wrote:
>> On Thu, Apr 12, 2018 at 12:27 PM, Mathieu Desnoyers
>> <mathieu.desnoy...@efficios.com> wrot
- On Apr 14, 2018, at 6:44 PM, Andy Lutomirski l...@amacapital.net wrote:
> On Thu, Apr 12, 2018 at 12:43 PM, Linus Torvalds
> wrote:
>> On Thu, Apr 12, 2018 at 12:27 PM, Mathieu Desnoyers
>> wrote:
>>> The cpu_opv system call executes a vector of operations
17:
https://lkml.org/lkml/2017/11/20/803
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
17:
https://lkml.org/lkml/2017/11/20/803
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Apr 13, 2018, at 12:37 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
> On Fri, Apr 13, 2018 at 5:16 AM, Mathieu Desnoyers
> <mathieu.desnoy...@efficios.com> wrote:
>> The vmalloc space needed by cpu_opv is bound by the number of pages
>> a cpu_opv call
- On Apr 13, 2018, at 12:37 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
> On Fri, Apr 13, 2018 at 5:16 AM, Mathieu Desnoyers
> wrote:
>> The vmalloc space needed by cpu_opv is bound by the number of pages
>> a cpu_opv call can touch.
>
> No it'
- On Apr 12, 2018, at 4:07 PM, Linus Torvalds torva...@linux-foundation.org
wrote:
> On Thu, Apr 12, 2018 at 12:59 PM, Mathieu Desnoyers
> <mathieu.desnoy...@efficios.com> wrote:
>>
>> What are your concerns about page pinning ?
>
> Pretty much everything.
&
- On Apr 12, 2018, at 4:07 PM, Linus Torvalds torva...@linux-foundation.org
wrote:
> On Thu, Apr 12, 2018 at 12:59 PM, Mathieu Desnoyers
> wrote:
>>
>> What are your concerns about page pinning ?
>
> Pretty much everything.
>
> It's the most complex part
- On Apr 12, 2018, at 3:43 PM, Linus Torvalds torva...@linux-foundation.org
wrote:
> On Thu, Apr 12, 2018 at 12:27 PM, Mathieu Desnoyers
> <mathieu.desnoy...@efficios.com> wrote:
>> The cpu_opv system call executes a vector of operations on behalf of
>> user
- On Apr 12, 2018, at 3:43 PM, Linus Torvalds torva...@linux-foundation.org
wrote:
> On Thu, Apr 12, 2018 at 12:27 PM, Mathieu Desnoyers
> wrote:
>> The cpu_opv system call executes a vector of operations on behalf of
>> user-space on a specific CPU with preemption disabl
Signed-off-by: Mathieu Desnoyers <mathieu.desnoy...@efficios.com>
CC: Russell King <li...@arm.linux.org.uk>
CC: Catalin Marinas <catalin.mari...@arm.com>
CC: Will Deacon <will.dea...@arm.com>
CC: Thomas Gleixner <t...@linutronix.de>
CC: Paul Turner <p
Signed-off-by: Mathieu Desnoyers
CC: Russell King
CC: Catalin Marinas
CC: Will Deacon
CC: Thomas Gleixner
CC: Paul Turner
CC: Andrew Hunter
CC: Peter Zijlstra
CC: Andy Lutomirski
CC: Andi Kleen
CC: Dave Watson
CC: Chris Lameter
CC: Ingo Molnar
CC: Ben Maurer
CC: Steven Rostedt
CC
Signed-off-by: Mathieu Desnoyers <mathieu.desnoy...@efficios.com>
CC: Benjamin Herrenschmidt <b...@kernel.crashing.org>
CC: Paul Mackerras <pau...@samba.org>
CC: Michael Ellerman <m...@ellerman.id.au>
CC: Boqun Feng <boqun.f...@gmail.com>
CC: Peter Zijlstra <
Signed-off-by: Mathieu Desnoyers
CC: Benjamin Herrenschmidt
CC: Paul Mackerras
CC: Michael Ellerman
CC: Boqun Feng
CC: Peter Zijlstra
CC: "Paul E. McKenney"
CC: linuxppc-...@lists.ozlabs.org
---
arch/powerpc/include/asm/systbl.h | 1 +
arch/powerpc/include/asm/unistd.
r-cpu data.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoy...@efficios.com>
Reviewed-by: Thomas Gleixner <t...@linutronix.de>
CC: Russell King <li...@arm.linux.org.uk>
CC: Catalin Marinas <catalin.mari...@arm.com>
CC: Will Deacon <will.dea...@arm.com>
CC: Paul Tu
r-cpu data.
Signed-off-by: Mathieu Desnoyers
Reviewed-by: Thomas Gleixner
CC: Russell King
CC: Catalin Marinas
CC: Will Deacon
CC: Paul Turner
CC: Andrew Hunter
CC: Peter Zijlstra
CC: Andy Lutomirski
CC: Andi Kleen
CC: Dave Watson
CC: Chris Lameter
CC: Ingo Molnar
CC: "H. Peter
may know where to place breakpoints when single-stepping
through assembly blocks which may be aborted at any point by the kernel.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoy...@efficios.com>
CC: Shuah Khan <shua...@osg.samsung.com>
CC: Russell King <li...@arm.linux.org.uk>
C
may know where to place breakpoints when single-stepping
through assembly blocks which may be aborted at any point by the kernel.
Signed-off-by: Mathieu Desnoyers
CC: Shuah Khan
CC: Russell King
CC: Catalin Marinas
CC: Will Deacon
CC: Thomas Gleixner
CC: Paul Turner
CC: Andrew Hunter
CC
Call the rseq_handle_notify_resume() function on return to
userspace if TIF_NOTIFY_RESUME thread flag is set.
Perform fixup on the pre-signal frame when a signal is delivered on top
of a restartable sequence critical section.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoy...@efficios.com&
Call the rseq_handle_notify_resume() function on return to
userspace if TIF_NOTIFY_RESUME thread flag is set.
Perform fixup on the pre-signal frame when a signal is delivered on top
of a restartable sequence critical section.
Signed-off-by: Mathieu Desnoyers
CC: Russell King
CC: Catalin
"basic_percpu_ops_test" is a slightly more "realistic" variant,
implementing a few simple per-cpu operations and testing their
correctness.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoy...@efficios.com>
CC: Shuah Khan <shua...@osg.samsung.com>
CC: Russell
Signed-off-by: Mathieu Desnoyers <mathieu.desnoy...@efficios.com>
CC: "Paul E. McKenney" <paul...@linux.vnet.ibm.com>
CC: Peter Zijlstra <pet...@infradead.org>
CC: Paul Turner <p...@google.com>
CC: Thomas Gleixner <t...@linutronix.de>
CC: Andrew Hunter
"basic_percpu_ops_test" is a slightly more "realistic" variant,
implementing a few simple per-cpu operations and testing their
correctness.
Signed-off-by: Mathieu Desnoyers
CC: Shuah Khan
CC: Russell King
CC: Catalin Marinas
CC: Will Deacon
CC: Thomas Gleixner
CC: Pau
Signed-off-by: Mathieu Desnoyers
CC: "Paul E. McKenney"
CC: Peter Zijlstra
CC: Paul Turner
CC: Thomas Gleixner
CC: Andrew Hunter
CC: Andy Lutomirski
CC: Andi Kleen
CC: Dave Watson
CC: Chris Lameter
CC: Ingo Molnar
CC: "H. Peter Anvin"
CC: Ben Maurer
CC: Stev
0.st...@pjt-glaptop.roam.corp.google.com
Link:
http://lkml.kernel.org/r/20150624222609.6116.86035.st...@kitami.mtv.corp.google.com
Signed-off-by: Mathieu Desnoyers <mathieu.desnoy...@efficios.com>
CC: Thomas Gleixner <t...@linutronix.de>
CC: Paul Turner <p...@google.com>
C
0.st...@pjt-glaptop.roam.corp.google.com
Link:
http://lkml.kernel.org/r/20150624222609.6116.86035.st...@kitami.mtv.corp.google.com
Signed-off-by: Mathieu Desnoyers
CC: Thomas Gleixner
CC: Paul Turner
CC: Andrew Hunter
CC: Peter Zijlstra
CC: Andy Lutomirski
CC: Andi Kleen
CC: Dave Watson
CC
.
TODO: wire up rseq_syscall() on return from system call. It is used with
CONFIG_DEBUG_RSEQ=y to ensure system calls are not issued within rseq critical
section
Signed-off-by: Mathieu Desnoyers <mathieu.desnoy...@efficios.com>
CC: Russell King <li...@arm.linux.org.uk>
CC: Cat
.
TODO: wire up rseq_syscall() on return from system call. It is used with
CONFIG_DEBUG_RSEQ=y to ensure system calls are not issued within rseq critical
section
Signed-off-by: Mathieu Desnoyers
CC: Russell King
CC: Catalin Marinas
CC: Will Deacon
CC: Thomas Gleixner
CC: Paul Turner
CC
(2):
powerpc: Add support for restartable sequences
powerpc: Wire up restartable sequences system call
Mathieu Desnoyers (21):
uapi headers: Provide types_32_64.h (v2)
rseq: Introduce restartable sequences system call (v13)
arm: Add restartable sequences support
arm: Wire up
(2):
powerpc: Add support for restartable sequences
powerpc: Wire up restartable sequences system call
Mathieu Desnoyers (21):
uapi headers: Provide types_32_64.h (v2)
rseq: Introduce restartable sequences system call (v13)
arm: Add restartable sequences support
arm: Wire up
1201 - 1300 of 7281 matches
Mail list logo
