- On Apr 17, 2019, at 12:17 PM, Joseph Myers jos...@codesourcery.com wrote:
> On Wed, 17 Apr 2019, Mathieu Desnoyers wrote:
>
>> > +/* RSEQ_SIG is a signature required before each abort handler code.
>> > +
>> > + It is a 32-bit value that maps to
- On Apr 16, 2019, at 1:32 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
[...]
> diff --git a/sysdeps/unix/sysv/linux/aarch64/bits/rseq.h
> b/sysdeps/unix/sysv/linux/aarch64/bits/rseq.h
> new file mode 100644
> index 00..b02471a89a
> --- /dev/null
>
- On Apr 17, 2019, at 10:43 AM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Apr 17, 2019, at 6:37 AM, richard earnshaw richard.earns...@arm.com
> wrote:
>
>> On 16/04/2019 14:39, Mathieu Desnoyers wrote:
>>> - On Apr 15, 2019, at 9:
- On Apr 17, 2019, at 6:37 AM, richard earnshaw richard.earns...@arm.com
wrote:
> On 16/04/2019 14:39, Mathieu Desnoyers wrote:
>> - On Apr 15, 2019, at 9:37 AM, Mathieu Desnoyers
>> mathieu.desnoy...@efficios.com wrote:
>>
>>> - On Apr 15, 2019, at 9:3
UMP_LABEL
> support in my build.
Looking into this some more, it looks like I was on the wrong track
with my large branch offset theory. Is it just possible that
page_alloc_shuffle() ends up using jump labels before they are
initialized ? Perhaps this has something to do with how early
the page_alloc.shuffle=1 kernel parameter is handled.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Apr 16, 2019, at 3:25 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Apr 16, 2019, at 3:17 PM, Mathieu Desnoyers
> mathieu.desnoy...@efficios.com wrote:
>
>> - On Apr 16, 2019, at 2:54 PM, Dan Williams dan.j.willi...@intel.com
>> wrote
- On Apr 16, 2019, at 3:17 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Apr 16, 2019, at 2:54 PM, Dan Williams dan.j.willi...@intel.com
> wrote:
>
>> On Thu, Apr 11, 2019 at 1:54 PM Guenter Roeck wrote:
>> [..]
>>> > > Boot te
e bool arch_static_branch_jump(struct static_key *key,
bool branch)
{
asm_volatile_goto("1:\n\t"
+WASM(nop) "\n\t"
WASM(b) " %l[l_yes]\n\t"
+ "2:\n\t"
".pushsection __jump_table, \"aw\"\n\t"
-".word 1b, %l[l_yes], %c0\n\t"
+".word 1b, 2b, %c0\n\t"
".popsection\n\t"
: : "i" (&((char *)key)[branch]) : : l_yes);
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
rseq: 2.5 ns (speedup: 5.5x)
inline load cpuid from __rseq_abi TLS: 0.8 ns (speedup: 17.1x)
Signed-off-by: Mathieu Desnoyers
CC: Carlos O'Donell
CC: Florian Weimer
CC: Joseph Myers
CC: Szabolcs Nagy
CC: Thomas Gleixner
CC: Ben Maurer
CC: Peter Zijlstra
CC: "Paul E. McK
was merged
into Linux 4.18.
Signed-off-by: Mathieu Desnoyers
CC: Carlos O'Donell
CC: Florian Weimer
CC: Joseph Myers
CC: Szabolcs Nagy
CC: Thomas Gleixner
CC: Ben Maurer
CC: Peter Zijlstra
CC: "Paul E. McKenney"
CC: Boqun Feng
CC: Will Deacon
CC: Dave Watson
CC: Paul Turner
CC: R
- On Apr 15, 2019, at 9:37 AM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Apr 15, 2019, at 9:30 AM, peter maydell peter.mayd...@linaro.org
> wrote:
>
>> On Mon, 15 Apr 2019 at 14:11, Mathieu Desnoyers
>> wrote:
>>>
>>> -
- On Apr 15, 2019, at 9:30 AM, peter maydell peter.mayd...@linaro.org wrote:
> On Mon, 15 Apr 2019 at 14:11, Mathieu Desnoyers
> wrote:
>>
>> - On Apr 11, 2019, at 3:55 PM, peter maydell peter.mayd...@linaro.org
>> wrote:
>>
>> > On Thu,
- On Apr 11, 2019, at 8:24 AM, Florian Weimer fwei...@redhat.com wrote:
> * Mathieu Desnoyers:
>
>> /*
>> * TODO: document trap instruction objdump output on each sub-architecture
>> * instruction sets, as well as instruction set extensions.
>&
- On Apr 11, 2019, at 3:55 PM, peter maydell peter.mayd...@linaro.org wrote:
> On Thu, 11 Apr 2019 at 18:51, Mathieu Desnoyers
> wrote:
>> - On Apr 11, 2019, at 12:42 PM, Will Deacon will.dea...@arm.com wrote:
>> > Peter suggests that anything of the form 0xe7fxdef
- On Apr 11, 2019, at 12:42 PM, Will Deacon will.dea...@arm.com wrote:
> Hi Mathieu,
>
> On Wed, Apr 10, 2019 at 04:29:19PM -0400, Mathieu Desnoyers wrote:
>> - On Apr 9, 2019, at 3:32 PM, Mathieu Desnoyers
>> mathieu.desnoy...@efficios.com wrote:
>> > We
king a
"group" of menu entries visible without any direct impact on the code,
but it does not appear to be the case for a few exceptions. Perhaps this
is the actual issue ? (and lack of documentation of this Kconfig entry)
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Apr 9, 2019, at 3:32 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> Hi Will,
>
> We are about to include the code signature required prior to restartable
> sequences abort handlers into glibc, which will make this ABI choice final.
> We need architecture m
- On Apr 10, 2019, at 1:57 PM, Peter Zijlstra pet...@infradead.org wrote:
> On Wed, Apr 10, 2019 at 11:47:40AM -0400, Mathieu Desnoyers wrote:
>> - On Apr 10, 2019, at 2:54 AM, Peter Zijlstra pet...@infradead.org wrote:
>>
>> > On Tue, Apr 09, 2019 at 04:43:42PM
- On Apr 10, 2019, at 11:52 AM, schwidefsky schwidef...@de.ibm.com wrote:
> On Wed, 10 Apr 2019 11:50:39 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
>> - On Apr 10, 2019, at 6:32 AM, schwidefsky schwidef...@de.ibm.com wrote:
>>
>> > On Tue, 9 Apr 2019 15:
- On Apr 10, 2019, at 6:32 AM, schwidefsky schwidef...@de.ibm.com wrote:
> On Tue, 9 Apr 2019 15:32:22 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
>> Hi,
>>
>> We are about to include the code signature required prior to restartable
>> sequences abort han
- On Apr 10, 2019, at 2:54 AM, Peter Zijlstra pet...@infradead.org wrote:
> On Tue, Apr 09, 2019 at 04:43:42PM -0400, Mathieu Desnoyers wrote:
>> +/*
>> + * RSEQ_SIG is used with the following privileged instructions, which trap
>> in
>> user-space:
>> +
review.
>>
>> Acked-by: Steven Rostedt (VMware)
>>
>
> Thanks!
>
> Also we could possibly consider adding the tracepoint ptrs array as
> well to the list, which would be useful I think, if one were to over
> write that array by accident (and the bpf tps related array too).
Yes, please!
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Apr 9, 2019, at 9:57 PM, Andy Lutomirski l...@kernel.org wrote:
> On Tue, Apr 9, 2019 at 5:51 PM Zack Weinberg wrote:
>>
>> On Tue, Apr 9, 2019 at 4:43 PM Mathieu Desnoyers
>> wrote:
>> > - On Apr 9, 2019, at 3:32 PM, Mathieu Desnoyers
>> &g
- On Apr 9, 2019, at 3:32 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> Hi,
>
> We are about to include the code signature required prior to restartable
> sequences abort handlers into glibc, which will make this ABI choice final.
> We need architecture m
0x
Ideally we'd need a patch on top of the Linux kernel
tools/testing/selftests/rseq/rseq-arm.h file that updates
the signature value, so I can then pick it up for the glibc
patchset.
Thanks!
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
need a patch on top of the Linux kernel
tools/testing/selftests/rseq/rseq-s390.h file that updates
the signature value, so I can then pick it up for the glibc
patchset.
Thanks!
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
template:
/*
* TODO: document trap instruction objdump output on each sub-architecture
* instruction sets, as well as instruction set extensions.
*/
#define RSEQ_SIG 0x
Thanks!
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
erences I'm
> thinking it may be best to switch to one of these real instructions that
> looks strange. The ugly part would be the nest of #ifdef's to deal with
> endianness & ISA when defining it as a number...
Note that we can have different signatures for each sub-architecture, as
Then, ideally, we'd need a patch on top of the Linux kernel
tools/testing/selftests/rseq/rseq-ppc.h file that updates
the signature value. I think the current discussion leads us
towards a trap:
/*
* TODO: document instruction objdump output on each architecture and VLE
* instruction sets.
*/
#define RSEQ_SIG 0x0fe5000b
Should we do anything specific for big/little endian ? Is the byte order
of the instruction encoding the same as data ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
h the basic instruction set within the same
program.
We need to decide whether we care what those signatures look like in those
instruction set extensions or not. Is it a best effort to match real
instructions
or a hard requirement ? If it's a hard requirement, we may need to extend the
rseq
system call with new flags to accept more than one signature.
Thoughts ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Apr 8, 2019, at 3:35 PM, Joel Fernandes, Google j...@joelfernandes.org
wrote:
> On Mon, Apr 08, 2019 at 01:25:49PM -0400, Mathieu Desnoyers wrote:
>> - On Apr 8, 2019, at 1:10 PM, paulmck paul...@linux.ibm.com wrote:
>>
>> > On Mon, Apr 08, 2019 at 0
- On Apr 8, 2019, at 1:10 PM, paulmck paul...@linux.ibm.com wrote:
> On Mon, Apr 08, 2019 at 01:06:56PM -0400, Mathieu Desnoyers wrote:
>> - On Apr 8, 2019, at 11:21 AM, paulmck paul...@linux.ibm.com wrote:
>>
>> > On Mon, Apr 08, 2019 at 10:57:50PM +0800, Rong
9f9
>> > > [8 .altinstr_replacement] 0xc0497372
>> > > [26 .rodata.str1.8] 0xc03ed1f0
>> > > [11 __verbose] 0xc05c9398
>> > > [1 .rodata.cst16.TWOONE] 0xc0498380
>> > > [1 uevent] KEY=40200 3803078f800d001 fedfffef
>> > > fffe
>> > > [1 .rodata.cst16.ONE] 0xc04983e0
>> > > [8 .altinstructions] 0xc0498430
>> > > [36 modules] crct10dif_pclmul 16384 1 - Live 0xc03f4000
>> > > [1 ___srcu_struct_ptrs] 0xc03840d0
>> > >
This list of "leaked" memory seems to include the __tracepoint_ptrs
as well. So at least you seem to have the same behavior as the tracepoint
code, which was your source of inspiration for this implementation,
which is a good start.
So the remaining question is: is this memory allocated for module sections
really leaked for each module, or is it an issue with memory allocation
tracking ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Mar 28, 2019, at 3:49 AM, schwidefsky schwidef...@de.ibm.com wrote:
> On Wed, 27 Mar 2019 16:38:32 -0400
> "Carlos O'Donell" wrote:
>
>> On 3/27/19 5:16 AM, Martin Schwidefsky wrote:
>> > On Mon, 25 Mar 2019 11:54:32 -0400 (EDT)
>> > Math
- On Mar 27, 2019, at 5:16 AM, schwidefsky schwidef...@de.ibm.com wrote:
> On Mon, 25 Mar 2019 11:54:32 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
>> >> +++ b/sysdeps/unix/sysv/linux/s390/bits/rseq.h
>> [...]
>> >> +
>> >> +/
eq_str(RSEQ_SIG) "\n\t" \
__rseq_str(label) ":\n\t" \
teardown\
"jmp %l[" __rseq_str(abort_label) "]\n\t" \
".popsection\n\t"
x86-64:
#define RSEQ_ASM_DEFINE_ABORT(label, teardown, abort_label) \
".pushsection __rseq_failure, \"ax\"\n\t" \
/* Disassembler-friendly signature: nopl (%rip). */\
".byte 0x0f, 0x1f, 0x05\n\t"\
".long " __rseq_str(RSEQ_SIG) "\n\t"\
__rseq_str(label) ":\n\t" \
teardown\
"jmp %l[" __rseq_str(abort_label) "]\n\t" \
".popsection\n\t"
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
Knowing all exit points is useful to assist debuggers stepping over the
rseq critical sections without requiring them to disassemble the content
of the critical section to figure out the exit points.
Signed-off-by: Mathieu Desnoyers
CC: Thomas Gleixner
CC: Joel Fernandes
CC: Peter Zijlstra
CC
containing packed 64-bit pointers to
those __rseq_cs entries.
Thanks,
Mathieu
Mathieu Desnoyers (2):
rseq/selftests: Add __rseq_exit_point_array section for debuggers
rseq/selftests: Introduce __rseq_cs_ptr_array, rename __rseq_table to
__rseq_cs
tools/testing/selftests/rseq/rseq-arm.h
of items by debuggers.
Considering that __rseq_table does not really consist of a table due to
the presence of padding, rename this section to __rseq_cs.
Create a new __rseq_cs_ptr_array section which contains 64-bit packed
pointers to entries within the __rseq_cs section.
Signed-off-by: Mathieu
- On Mar 6, 2019, at 3:30 AM, Peter Zijlstra pet...@infradead.org wrote:
> On Tue, Mar 05, 2019 at 05:32:10PM -0500, Mathieu Desnoyers wrote:
>
>> >> * Adaptative mutex improvements
>> >>
>> >> I have done a prototype using rseq to implement
- On Mar 5, 2019, at 4:58 PM, Peter Zijlstra pet...@infradead.org wrote:
> On Tue, Mar 05, 2019 at 03:18:35PM -0500, Mathieu Desnoyers wrote:
>> * NUMA node ID in TLS
>>
>> Having the NUMA node ID available in a TLS variable would allow glibc to
>> perform i
- On Mar 5, 2019, at 2:47 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> Those changes aiming at 5.1 include one comment cleanup, the removal of
> the rseq_len field from the task struct which serves no purpose
> considering that the struct size is fixed b
choice that ensures
multiple libraries and application defining __rseq_abi in the same
process agree on its exact size.
Considering that this size is and will always be the same value, there
is no point in saving this value within task_struct rseq_len. Remove
this field from task_struct.
Signed-off-b
for smaller systems.
Thanks,
Mathieu
Mathieu Desnoyers (3):
rseq: cleanup: Reflect removal of event counter in comments
rseq: cleanup: remove rseq_len from task_struct
rseq/selftests: Adapt number of threads to the number of detected cpus
arch/arm/kernel/signal.c | 3
The "event counter" was removed from rseq before it was merged upstream.
However, a few comments in the source code still refer to it. Adapt the
comments to match reality.
Signed-off-by: Mathieu Desnoyers
CC: "Paul E. McKenney"
CC: Peter Zijlstra
CC: Paul Turner
CC: Thoma
On smaller systems, running a test with 200 threads can take a long
time on machines with smaller number of CPUs.
Detect the number of online cpus at test runtime, and multiply that
by 6 to have 6 rseq threads per cpu preempting each other.
Signed-off-by: Mathieu Desnoyers
Cc: Shuah Khan
Cc
d-off-by by maintainers
who pick up the patch. (That's what I am used to see)
What is the intent behind the second Signed-off-by by Sabyasachi Gupta ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Mar 4, 2019, at 1:38 PM, Souptick Joarder jrdr.li...@gmail.com wrote:
> Remove duplicate header which is included twice
>
> Signed-off-by: Sabyasachi Gupta
> Signed-off-by: Souptick Joarder
Acked-by: Mathieu Desnoyers
> ---
> tools/testing/selftests/rseq/rse
- On Feb 28, 2019, at 3:42 AM, Michael Kerrisk mtk.manpa...@gmail.com wrote:
> On 12/6/18 3:42 PM, Mathieu Desnoyers wrote:
>> [ Michael, rseq(2) was merged into 4.18. Can you have a look at this
>> patch which adds rseq documentation to the man-pages project ? ]
> Hi M
- On Feb 22, 2019, at 3:29 AM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
> On Fri, Feb 22, 2019 at 07:25:50AM +0100, Greg Kroah-Hartman wrote:
>> On Thu, Feb 21, 2019 at 07:17:11PM -0500, Mathieu Desnoyers wrote:
>> > - On Feb 21, 2019, at 7:10 PM, Russe
- On Feb 21, 2019, at 7:10 PM, Russell King, ARM Linux
li...@armlinux.org.uk wrote:
> On Thu, Feb 21, 2019 at 03:02:57PM -0500, Mathieu Desnoyers wrote:
>> Hi Arnd, Russell, Linus,
>>
>> Can we ensure the arm32 kprobes fix I submitted gets upstream before 5.0
>&g
instruction OOPS on v5.0-rc7, 4.19.24,
v4.14.102.
My fix is in "accepted" state in the arm patch tracking system:
https://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8834/1
Should I send it directly to Linus as well ?
Thanks,
Mathieu
- On Feb 18, 2019, at 9:55 AM, Mathieu
- On Feb 18, 2019, at 4:55 PM, Rich Felker dal...@libc.org wrote:
> On Mon, Feb 18, 2019 at 10:22:32AM -0500, Mathieu Desnoyers wrote:
>> - On Feb 17, 2019, at 5:08 PM, Rich Felker dal...@libc.org wrote:
>>
>> > On Sun, Feb 17, 2019 at 04:52:35PM -0500, Rich Fe
- On Feb 17, 2019, at 5:08 PM, Rich Felker dal...@libc.org wrote:
> On Sun, Feb 17, 2019 at 04:52:35PM -0500, Rich Felker wrote:
>> On Sun, Feb 17, 2019 at 04:34:45PM -0500, Mathieu Desnoyers wrote:
>> > - On Feb 17, 2019, at 1:48 PM, Rich Felker dal...@libc.org wrote:
&
- On Feb 18, 2019, at 7:26 AM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
> On Wed, Feb 06, 2019 at 01:41:15PM +0900, Masami Hiramatsu wrote:
>> On Tue, 5 Feb 2019 15:06:10 +
>> Kees Cook wrote:
>>
>> > On Mon, Feb 4, 2019 at 7:15 PM
sure all future scheduler executions will observe the
* new thread flag state for this process.
*/
synchronize_rcu();
}
So considering that pre-registration carefully done before the process
becomes multi-threaded just costs a system call (and not a synchronize_sched()),
does it m
rseq: 2.5 ns (speedup: 5.5x)
inline load cpuid from __rseq_abi TLS: 0.8 ns (speedup: 17.1x)
Signed-off-by: Mathieu Desnoyers
CC: Carlos O'Donell
CC: Florian Weimer
CC: Joseph Myers
CC: Szabolcs Nagy
CC: Thomas Gleixner
CC: Ben Maurer
CC: Peter Zijlstra
CC: "Paul E. McK
was merged
into Linux 4.18.
Signed-off-by: Mathieu Desnoyers
CC: Carlos O'Donell
CC: Florian Weimer
CC: Joseph Myers
CC: Szabolcs Nagy
CC: Thomas Gleixner
CC: Ben Maurer
CC: Peter Zijlstra
CC: "Paul E. McKenney"
CC: Boqun Feng
CC: Will Deacon
CC: Dave Watson
CC: Paul Turner
CC: R
+
> +config LD_IS_LLD
> + def_bool $(success,$(LD) --version | head -n 1 | grep -q 'LLD')
> +
> config CONSTRUCTORS
> bool
> depends on !UML
> --
> 2.20.1.791.gb4d0f1c61a-goog
>
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Feb 4, 2019, at 4:28 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> Register rseq(2) TLS for each thread (including main), and unregister
> for each thread (excluding main). "rseq" stands for Restartable
> Sequences.
>
> See the rseq(2) man pag
lore.kernel.org/lkml/342740659.2887.1549307721609.javamail.zim...@efficios.com
Fixes: e46daee53bb5 ("ARM: 8806/1: kprobes: Fix false positive with
FORTIFY_SOURCE")
Signed-off-by: Mathieu Desnoyers
Reported-by: Robert Berger
Tested-by: Robert Berger
Acked-by: Kees Cook
CC: Robert Berger
CC: Masami Hi
lore.kernel.org/lkml/342740659.2887.1549307721609.javamail.zim...@efficios.com
Fixes: e46daee53bb5 ("ARM: 8806/1: kprobes: Fix false positive with
FORTIFY_SOURCE")
Signed-off-by: Mathieu Desnoyers
Reported-by: Robert Berger
Tested-by: Robert Berger
Acked-by: Kees Cook
CC: Robert Berger
CC: Masami Hi
- On Feb 5, 2019, at 10:04 AM, Kees Cook keesc...@chromium.org wrote:
> On Mon, Feb 4, 2019 at 9:52 PM Mathieu Desnoyers
> wrote:
>>
>> commit e46daee53bb5 "ARM: 8806/1: kprobes: Fix false positive with
>> FORTIFY_SOURCE"
>> introduced a regression in
lore.kernel.org/lkml/342740659.2887.1549307721609.javamail.zim...@efficios.com
Signed-off-by: Mathieu Desnoyers
Reported-by: Robert Berger
Tested-by: Robert Berger
CC: Robert Berger
CC: Masami Hiramatsu
CC: William Cohen
CC: Laura Abbott
CC: Kees Cook
CC: Russell King
CC: # v4.14+
---
arch/arm/probes/kprobes
was merged
into Linux 4.18.
Signed-off-by: Mathieu Desnoyers
CC: Carlos O'Donell
CC: Florian Weimer
CC: Joseph Myers
CC: Szabolcs Nagy
CC: Thomas Gleixner
CC: Ben Maurer
CC: Peter Zijlstra
CC: "Paul E. McKenney"
CC: Boqun Feng
CC: Will Deacon
CC: Dave Watson
CC: Paul Turner
CC: R
rseq: 2.5 ns (speedup: 5.5x)
inline load cpuid from __rseq_abi TLS: 0.8 ns (speedup: 17.1x)
Signed-off-by: Mathieu Desnoyers
CC: Carlos O'Donell
CC: Florian Weimer
CC: Joseph Myers
CC: Szabolcs Nagy
CC: Thomas Gleixner
CC: Ben Maurer
CC: Peter Zijlstra
CC: "Paul E. McK
p;" seems to have been stripped away,
which happens to change the behavior significantly.
Has this change ever been runtime-tested ?
It has been backported to:
- 4.19 stable as commit 3fe0c68aea21
- 4.14 stable as commit f9e0bc710347
Thanks,
Mathieu
[1] https://bugs.lttng.org/issues/117
- On Jan 31, 2019, at 11:37 AM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Jan 30, 2019, at 4:10 PM, Joseph Myers jos...@codesourcery.com wrote:
>
>> On Wed, 30 Jan 2019, Mathieu Desnoyers wrote:
>>
>>> #if defined (__NR_rseq) &&a
- On Jan 30, 2019, at 4:10 PM, Joseph Myers jos...@codesourcery.com wrote:
> On Wed, 30 Jan 2019, Mathieu Desnoyers wrote:
>
>> #if defined (__NR_rseq) && !defined (RSEQ_SIG)
>> # error "UAPI headers support rseq system call, but glibc does not define
>&
- On Jan 29, 2019, at 9:40 PM, Joseph Myers jos...@codesourcery.com wrote:
> On Tue, 29 Jan 2019, Mathieu Desnoyers wrote:
>
>> My thinking was to put the #error in the generic header, so architectures
>> that
>> are not supported yet cannot build against rseq.h at
- On Jan 29, 2019, at 4:56 PM, Joseph Myers jos...@codesourcery.com wrote:
> On Tue, 29 Jan 2019, Mathieu Desnoyers wrote:
>
>> I recalled that aarch64 defines RSEQ_SIG to a different value which maps to
>> a valid trap instruction. So I plan to move the RSEQ_SIG
- On Jan 21, 2019, at 4:35 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
[...]
> diff --git a/sysdeps/unix/sysv/linux/sys/rseq.h
> b/sysdeps/unix/sysv/linux/sys/rseq.h
> new file mode 100644
> index 00..61937fb193
> --- /dev/null
> +++ b/sysdeps/u
- On Jan 28, 2019, at 5:39 PM, paulmck paul...@linux.ibm.com wrote:
> On Mon, Jan 28, 2019 at 05:07:07PM -0500, Mathieu Desnoyers wrote:
>> Jann Horn identified a racy access to p->mm in the global expedited
>> command of the membarrier system call.
>>
>>
https://lore.kernel.org/lkml/cag48ez2g8ctf8dhs42tf37pthfr3y0rnooytmxvacm4u8yu...@mail.gmail.com
Signed-off-by: Mathieu Desnoyers
Tested-by: Jann Horn
CC: Jann Horn
CC: Thomas Gleixner
CC: Peter Zijlstra (Intel)
CC: Ingo Molnar
CC: Andrea Parri
CC: Andy Lutomirski
CC: Avi Kivity
CC: Benjamin Herrenschmi
- On Jan 28, 2019, at 3:46 PM, paulmck paul...@linux.ibm.com wrote:
> On Mon, Jan 28, 2019 at 12:27:03PM -0800, Linus Torvalds wrote:
>> On Mon, Jan 28, 2019 at 10:27 AM Mathieu Desnoyers
>> wrote:
>> >
>> > Jann Horn identified a racy access to p->mm
https://lore.kernel.org/lkml/cag48ez2g8ctf8dhs42tf37pthfr3y0rnooytmxvacm4u8yu...@mail.gmail.com
Signed-off-by: Mathieu Desnoyers
CC: Jann Horn
CC: Thomas Gleixner
CC: Peter Zijlstra (Intel)
CC: Ingo Molnar
CC: Andrea Parri
CC: Andrew Hunter
CC: Andy Lutomirski
CC: Avi Kivity
CC: Benjamin Herrenschmi
27113] ? __ia32_sys_read+0x50/0x50
>> [ 212.728596] __x64_sys_membarrier+0x85/0xf0
>> [ 212.730056] do_syscall_64+0x73/0x160
>> [ 212.731428] entry_SYSCALL_64_after_hwframe+0x44/0xa9
>> [ 212.733236] RIP: 0033:0x7fbe8747e229
>> [ 212.734540] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40
>> 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24
>> 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 3f 4c 2b 00 f7 d8 64 89
>> 01 48
>> [ 212.741109] RSP: 002b:7fffcb62a7c8 EFLAGS: 0202 ORIG_RAX:
>> 0144
>> [ 212.743831] RAX: ffda RBX: RCX:
>> 7fbe8747e229
>> [ 212.746335] RDX: 7fbe87475730 RSI: RDI:
>> 0002
>> [ 212.748855] RBP: 7fffcb62a7e0 R08: 7fffcb62a8c0 R09:
>> 7fffcb62a8c0
>> [ 212.751374] R10: 7fbe8793c700 R11: 0202 R12:
>> 563ee2ac9610
>> [ 212.753842] R13: 7fffcb62a8c0 R14: R15:
>>
>> [ 212.756305]
>> ==
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
ystem call
was merged into Linux 4.18.
Signed-off-by: Mathieu Desnoyers
CC: Carlos O'Donell
CC: Florian Weimer
CC: Joseph Myers
CC: Szabolcs Nagy
CC: Thomas Gleixner
CC: Ben Maurer
CC: Peter Zijlstra
CC: "Paul E. McKenney"
CC: Boqun Feng
CC: Will Deacon
CC: Dave Watson
CC: P
rseq: 2.5 ns (speedup: 5.5x)
inline load cpuid from __rseq_abi TLS: 0.8 ns (speedup: 17.1x)
Signed-off-by: Mathieu Desnoyers
CC: Carlos O'Donell
CC: Florian Weimer
CC: Joseph Myers
CC: Szabolcs Nagy
CC: Thomas Gleixner
CC: Ben Maurer
CC: Peter Zijlstra
CC: "Paul E. McK
- On Jan 18, 2019, at 12:41 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Jan 14, 2019, at 8:51 PM, Mathieu Desnoyers
> mathieu.desnoy...@efficios.com wrote:
>
> [...]
>
>> diff --git a/sysdeps/unix/sysv/linux/rseq-sym.c
>> b/sysdeps
- On Jan 14, 2019, at 8:51 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
[...]
> diff --git a/sysdeps/unix/sysv/linux/rseq-sym.c
> b/sysdeps/unix/sysv/linux/rseq-sym.c
> new file mode 100644
> index 00..6856d0388a
[...]
> +/* volatile because fields can
,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
ystem call
was merged into Linux 4.18.
Signed-off-by: Mathieu Desnoyers
CC: Carlos O'Donell
CC: Florian Weimer
CC: Joseph Myers
CC: Szabolcs Nagy
CC: Thomas Gleixner
CC: Ben Maurer
CC: Peter Zijlstra
CC: "Paul E. McKenney"
CC: Boqun Feng
CC: Will Deacon
CC: Dave Watson
CC: P
rseq: 2.5 ns (speedup: 5.5x)
inline load cpuid from __rseq_abi TLS: 0.8 ns (speedup: 17.1x)
Signed-off-by: Mathieu Desnoyers
CC: Carlos O'Donell
CC: Florian Weimer
CC: Joseph Myers
CC: Szabolcs Nagy
CC: Thomas Gleixner
CC: Ben Maurer
CC: Peter Zijlstra
CC: "Paul E. McK
- On Jan 14, 2019, at 5:04 PM, rostedt rost...@goodmis.org wrote:
> On Mon, 14 Jan 2019 16:36:59 -0500 (EST)
> Mathieu Desnoyers wrote:
>
>> Can ftrace end up in the same situation through rb_wake_up_waiters() ? I
>> suspect
>> the tail recursion would be ha
- On Jan 14, 2019, at 8:09 AM, Peter Zijlstra pet...@infradead.org wrote:
> On Thu, Jan 10, 2019 at 12:45:27PM -0500, Mathieu Desnoyers wrote:
>
>> static void perf_pending_event(struct irq_work *entry)
>> {
>> struct perf_event *ev
- 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
- 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
: compat_futex_noasync on Cygwin
Project website: http://liburcu.org
Git repository: git://git.liburcu.org/urcu.git
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- 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
- On Dec 11, 2018, at 2:40 AM, Florian Weimer fwei...@redhat.com wrote:
> * Mathieu Desnoyers:
>
>> I want to keep the __rseq_refcount symbol so out-of-libc users can
>> register rseq if they are linked against a pre-2.29 libc.
>
> Sorry, I was confused.
Hi F
- On Jan 10, 2019, at 9:25 AM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Jan 10, 2019, at 9:11 AM, Mathieu Desnoyers
> mathieu.desnoy...@efficios.com wrote:
>
>> - On Jan 10, 2019, at 8:44 AM, Mathieu Desnoyers
>> mathieu.desnoy.
- On Jan 10, 2019, at 9:11 AM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Jan 10, 2019, at 8:44 AM, Mathieu Desnoyers
> mathieu.desnoy...@efficios.com wrote:
>
>> - On Jan 10, 2019, at 8:08 AM, rostedt rost...@goodmis.org wrote:
>>
>>
- On Jan 10, 2019, at 8:44 AM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Jan 10, 2019, at 8:08 AM, rostedt rost...@goodmis.org wrote:
>
>> On Wed, 9 Jan 2019 20:38:51 -0500 (EST)
>> Mathieu Desnoyers wrote:
>>
>>> Hi Paul
- On Jan 10, 2019, at 8:08 AM, rostedt rost...@goodmis.org wrote:
> On Wed, 9 Jan 2019 20:38:51 -0500 (EST)
> Mathieu Desnoyers wrote:
>
>> Hi Paul,
>>
>> I've had a user report that trace_sched_waking() appears to be
>> invoked while !rcu_is_watching(
- On Jan 9, 2019, at 8:13 PM, paulmck paul...@linux.ibm.com wrote:
> On Wed, Jan 09, 2019 at 08:38:51PM -0500, Mathieu Desnoyers wrote:
>> Hi Paul,
>>
>> I've had a user report that trace_sched_waking() appears to be
>> invoked while !rcu_is_watching() in s
wonder what happens if an interrupt handler (including scheduler code)
happens to issue a RCU read-side critical section before rcu_eqs_exit()
is called ? Is there some code on interrupt entry that ensures rcu eqs
state is exited in such scenario ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS
[ Michael, rseq(2) was merged into 4.18. Can you have a look at this
patch which adds rseq documentation to the man-pages project ? ]
Signed-off-by: Mathieu Desnoyers
CC: "Paul E. McKenney"
CC: Peter Zijlstra
CC: Paul Turner
CC: Thomas Gleixner
CC: Andy Lutomirski
CC: Andi Kleen
[ Michael, rseq(2) was merged into 4.18. Can you have a look at this
patch which adds rseq documentation to the man-pages project ? ]
Signed-off-by: Mathieu Desnoyers
CC: "Paul E. McKenney"
CC: Peter Zijlstra
CC: Paul Turner
CC: Thomas Gleixner
CC: Andy Lutomirski
CC: Andi Kleen
- 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
601 - 700 of 7290 matches
Mail list logo
