On 2024-10-02 17:58, Jens Axboe wrote:
On 10/2/24 9:53 AM, Mathieu Desnoyers wrote:
On 2024-10-02 17:36, Mathieu Desnoyers wrote:
On 2024-10-02 17:33, Matthew Wilcox wrote:
On Wed, Oct 02, 2024 at 11:26:27AM -0400, Mathieu Desnoyers wrote:
On 2024-10-02 16:09, Paul E. McKenney wrote:
On Tue
On 2024-10-02 17:33, Matthew Wilcox wrote:
On Wed, Oct 02, 2024 at 11:26:27AM -0400, Mathieu Desnoyers wrote:
On 2024-10-02 16:09, Paul E. McKenney wrote:
On Tue, Oct 01, 2024 at 09:02:01PM -0400, Mathieu Desnoyers wrote:
Hazard pointers appear to be a good fit for replacing refcount based
On 2024-10-02 16:09, Paul E. McKenney wrote:
On Tue, Oct 01, 2024 at 09:02:01PM -0400, Mathieu Desnoyers wrote:
Hazard pointers appear to be a good fit for replacing refcount based lazy
active mm tracking.
Highlight:
will-it-scale context_switch1_threads
nr threads (-t) speedup
24
Refer to ptr_eq() in the rcu_dereference() documentation.
ptr_eq() is a mechanism that preserves address dependencies when
comparing pointers, and should be favored when comparing a pointer
obtained from rcu_dereference() against another pointer.
Signed-off-by: Mathieu Desnoyers
Acked-by: Alan
31/
Signed-off-by: Mathieu Desnoyers
Cc: Nicholas Piggin
Cc: Michael Ellerman
Cc: Greg Kroah-Hartman
Cc: Sebastian Andrzej Siewior
Cc: "Paul E. McKenney"
Cc: Will Deacon
Cc: Peter Zijlstra
Cc: Boqun Feng
Cc: Alan Stern
Cc: John Stultz
Cc: Neeraj Upadhyay
Cc: Linus Torvalds
C
o see what the build bots have to say about this.
This series applies on top of v6.11.1.
Signed-off-by: Mathieu Desnoyers
Cc: Nicholas Piggin
Cc: Michael Ellerman
Cc: Greg Kroah-Hartman
Cc: Sebastian Andrzej Siewior
Cc: "Paul E. McKenney"
Cc: Will Deacon
Cc: Boqun Feng
Cc: Alan
: 400.
BogoMIPS: 4799.75
Memory: 768 GB ram.
Signed-off-by: Mathieu Desnoyers
Cc: Nicholas Piggin
Cc: Michael Ellerman
Cc: Greg Kroah-Hartman
Cc: Sebastian Andrzej Siewior
Cc: "Paul E. McKenney"
Cc: Will Deacon
Cc: Peter Zijlstra
Cc: Boqun Feng
Cc: Alan Stern
Cc: J
which depend on @a before loading @a.
The same logic applies with @a and @b swapped.
Suggested-by: Linus Torvalds
Suggested-by: Boqun Feng
Signed-off-by: Mathieu Desnoyers
Reviewed-by: Boqun Feng
Acked-by: "Paul E. McKenney"
Acked-by: Alan Stern
Cc: Greg Kroah-Hartman
Cc: Sebasti
On 2024-09-29 17:51, Paul E. McKenney wrote:
On Sun, Sep 29, 2024 at 07:16:08AM -0400, Mathieu Desnoyers wrote:
Refer to ptr_eq() in the rcu_dereference() documentation.
ptr_eq() is a mechanism that preserves address dependencies when
comparing pointers, and should be favored when comparing a
Refer to ptr_eq() in the rcu_dereference() documentation.
ptr_eq() is a mechanism that preserves address dependencies when
comparing pointers, and should be favored when comparing a pointer
obtained from rcu_dereference() against another pointer.
Signed-off-by: Mathieu Desnoyers
Cc: Greg Kroah
which depend on @a before loading @a.
The same logic applies with @a and @b swapped.
Suggested-by: Linus Torvalds
Suggested-by: Boqun Feng
Signed-off-by: Mathieu Desnoyers
Reviewed-by: Boqun Feng
Acked-by: "Paul E. McKenney"
Cc: Greg Kroah-Hartman
Cc: Sebastian Andrzej Siewior
C
Cc: Mark Rutland
Cc: Thomas Gleixner
Cc: Vlastimil Babka
Cc: maged.mich...@gmail.com
Cc: Mateusz Guzik
Cc: Gary Guo
Cc: Jonas Oberhauser
Cc: r...@vger.kernel.org
Cc: linux...@kvack.org
Cc: l...@lists.linux.dev
Cc: Nikita Popov
Cc: l...@lists.linux.dev
Mathieu Desnoyers (2):
compiler.h: Introd
On 2024-09-29 01:24, Gary Guo wrote:
Cc: Nikita Popov
Cc: l...@lists.linux.dev
On Sat, 28 Sep 2024 09:51:27 -0400
Mathieu Desnoyers wrote:
Compiler CSE and SSA GVN optimizations can cause the address dependency
of addresses returned by rcu_dereference to be lost when comparing those
On 2024-09-28 17:49, Alan Stern wrote:
On Sat, Sep 28, 2024 at 11:32:18AM -0400, Mathieu Desnoyers wrote:
On 2024-09-28 16:49, Alan Stern wrote:
On Sat, Sep 28, 2024 at 09:51:27AM -0400, Mathieu Desnoyers wrote:
equality, which does not preserve address dependencies and allows the
following
On 2024-09-28 16:49, Alan Stern wrote:
On Sat, Sep 28, 2024 at 09:51:27AM -0400, Mathieu Desnoyers wrote:
Compiler CSE and SSA GVN optimizations can cause the address dependency
of addresses returned by rcu_dereference to be lost when comparing those
pointers with either constants or previously
On 2024-09-28 16:49, Alan Stern wrote:
On Sat, Sep 28, 2024 at 09:51:27AM -0400, Mathieu Desnoyers wrote:
[...]
+/*
+ * Compare two addresses while preserving the address dependencies for
+ * later use of the address. It should be used when comparing an address
+ * returned by rcu_dereference
On 2024-09-28 16:58, Alan Stern wrote:
On Sat, Sep 28, 2024 at 09:51:28AM -0400, Mathieu Desnoyers wrote:
[...]
-- Be very careful about comparing pointers obtained from
- rcu_dereference() against non-NULL values. As Linus Torvalds
- explained, if the two pointers are equal
d to speculate "ldr w0, [x1]" before
"ldr x2, [x0]".
Based on the RCU documentation, the control dependency does not prevent
the CPU from speculating loads.
Suggested-by: Linus Torvalds
Suggested-by: Boqun Feng
Signed-off-by: Mathieu Desnoyers
Reviewed-by: Boqun Feng
Acked-
Cc: Mark Rutland
Cc: Thomas Gleixner
Cc: Vlastimil Babka
Cc: maged.mich...@gmail.com
Cc: Mateusz Guzik
Cc: Gary Guo
Cc: Jonas Oberhauser
Cc: r...@vger.kernel.org
Cc: linux...@kvack.org
Cc: l...@lists.linux.dev
Mathieu Desnoyers (2):
compiler.h: Introduce ptr_eq() to preserve address
Refer to ptr_eq() in the rcu_dereference() documentation.
ptr_eq() is a mechanism that preserves address dependencies when
comparing pointers, and should be favored when comparing a pointer
obtained from rcu_dereference() against another pointer.
Signed-off-by: Mathieu Desnoyers
Cc: Greg Kroah
On 2024-09-28 13:22, Jonas Oberhauser wrote:
Two more questions below:
Am 9/21/2024 um 6:42 PM schrieb Mathieu Desnoyers:
+#define NR_PERCPU_SLOTS_BITS 3
Have you measured any advantage of this multi-slot version vs a version
with just one normal slot and one emergency slot?
No, I have
On 2024-09-27 22:33, Mathieu Desnoyers wrote:
[...]
---
include/linux/compiler.h | 62
1 file changed, 62 insertions(+)
I'm wondering if this really belongs in compiler.h, or if it's so
RCU/HP specific that it should be implemented in
d be discarded by further
optimization. I'm unsure what you are trying to achieve here.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
d to speculate "ldr w0, [x1]" before
"ldr x2, [x0]".
Based on the RCU documentation, the control dependency does not prevent
the CPU from speculating loads.
Suggested-by: Linus Torvalds
Suggested-by: Boqun Feng
Signed-off-by: Mathieu Desnoyers
Cc: Greg Kroah-Hartman
Cc: Sebastia
On 2024-09-27 20:13, Linus Torvalds wrote:
On Fri, 27 Sept 2024 at 10:53, Mathieu Desnoyers
wrote:
(b) the value barrier needs to be on *both* values so that the order
of the equality testing doesn't matter.
If we use OPTIMIZER_HIDE_VAR() on both parameters, it indeed minimizes
the
On 2024-09-27 19:23, Linus Torvalds wrote:
On Fri, 27 Sept 2024 at 10:17, Mathieu Desnoyers
wrote:
The barrier() is ineffective at fixing the issue.
It does not prevent the compiler CSE from losing the
address dependency:
Ok. Thanks for actually specifying code.
That needs to be
(a) in
uaranteeing
existence of first and second locks in traversal order,
allowing them to be locked in the correct order (which is
reverse from traversal order) rather than try-lock+retry on
nested lock. This can be done with hazard pointers without
requiring object reclaim to be delayed by an RCU grace period.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
On 2024-09-27 16:43, Mathieu Desnoyers wrote:
On 2024-09-27 12:59, Mathieu Desnoyers wrote:
On 2024-09-27 06:28, Boqun Feng wrote:
[...]
I replaced ADDRESS_EQ(a, b) with ADDRESS_EQ(b, a), and the compile
result shows it can prevent the issue:
I see, yes. It prevents the issue by making the
On 2024-09-27 12:59, Mathieu Desnoyers wrote:
On 2024-09-27 06:28, Boqun Feng wrote:
[...]
I replaced ADDRESS_EQ(a, b) with ADDRESS_EQ(b, a), and the compile
result shows it can prevent the issue:
I see, yes. It prevents the issue by making the compiler create
a copy of the value "mod
On 2024-09-27 06:28, Boqun Feng wrote:
On Fri, Sep 27, 2024 at 09:37:50AM +0800, Boqun Feng wrote:
On Fri, Sep 27, 2024, at 9:30 AM, Mathieu Desnoyers wrote:
On 2024-09-27 02:01, Boqun Feng wrote:
#define ADDRESS_EQ(var, expr
x0, x0, :lo12:.LANCHOR0
.L12:
ldr x1, [x0]
ldr x2, [x0]
cmp x1, x2
bne .L12
ldr w0, [x1]
ret
p:
.zero 8
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
]
ldrx9, [x8]
cmpx10, x9
b.ne 4 // b.any
ldrw0, [x9]
ret
fct_volatile_acquire:
adrp x8, 0
addx8, x8, #0x0
ldrx10, [x8]
ldar x9, [x8]
cmpx10, x9
b.ne 24 // b.any
ldrw0, [x9]
ret
fct_asm_compare:
adrp x8, 0
ldrx9, [x8]
ldrx8, [x8]
cmpx9, x8
b.ne 3c // b.any
ldrw0, [x8]
ret
main:
movw0, wzr
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
On 2024-09-25 15:20, Mathieu Desnoyers wrote:
[...]
static inline
bool same_ptr(void *a, void *b)
{
asm goto (
"cmpq %[a], %[b]\n\t"
"jne %l[ne]\n\t"
: : [a] "r" (a), [b] "r" (b)
: : ne);
return true;
On 2024-09-25 15:10, Mathieu Desnoyers wrote:
[...]
Cleaner without goto in the user code:
#include
#include
static inline
bool same_ptr(void *a, void *b)
{
asm goto (
"cmpq %[a], %[b]\n\t"
"jne %l[ne]\n\t"
: : [a] "r" (a), [b] "
On 2024-09-25 14:47, Mathieu Desnoyers wrote:
[...]
Like so:
#include
#define __str_1(x) #x
#define __str(x) __str_1(x)
/* x86-64 */
#define bne_ptr(_a, _b, _label) \
asm goto ( \
"cmpq %[a], %[b]\n\t" \
"jne %l[" __str(_label) "]\n\t&qu
On 2024-09-25 14:16, Boqun Feng wrote:
On Wed, Sep 25, 2024 at 01:59:06PM +0200, Mathieu Desnoyers wrote:
On 2024-09-25 12:45, Boqun Feng wrote:
On Wed, Sep 25, 2024 at 12:11:52PM +0200, Jonas Oberhauser wrote:
Am 9/25/2024 um 12:02 PM schrieb Boqun Feng:
Hi Jonas,
Of
course, if we are
an now be speculated, such that it might happen before the
rcu_dereference(). This could result in bugs due to misordering.
So I am not only concerned about compiler proofs here, as it appears
that the speculation done by the CPU can also cause issues on some
architectures.
Thanks,
On 2024-09-25 12:06, Jonas Oberhauser wrote:
Am 9/25/2024 um 8:35 AM schrieb Mathieu Desnoyers:
On 2024-09-25 07:57, Jonas Oberhauser wrote:
Hi Mathieu,
I haven't read your code in detail but it seems to me you have an ABA
bug: as I explained elsewhere, you could read the same po
ff --git a/src/hpref.c b/src/hpref.c
new file mode 100644
index ..f63530f5
--- /dev/null
+++ b/src/hpref.c
@@ -0,0 +1,78 @@
+// SPDX-FileCopyrightText: 2024 Mathieu Desnoyers
+//
+// SPDX-License-Identifier: LGPL-2.1-or-later
+
+/*
+ * HPREF: Hazard pointers with reference counters
+
lore.kernel.org/lkml/j3scdl5iymjlxavomgc6u5ndg3svhab6ga23dr36o4f5mt333w@7xslvq6b6hmv/
Link: https://lpc.events/event/18/contributions/1731/
Signed-off-by: Mathieu Desnoyers
Change-Id: I6369064a0e1a1f9632394df31ff41c76905d17e3
Cc: "Paul E. McKenney"
Cc: Will Deacon
Cc: Peter Zijlstra
Cc: Boqun Feng
Cc: Alan Ster
* emergency slot to transition to refcount.
+*/
+ caa_cpu_relax();
+ goto retry;
+ }
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
b6ga23dr36o4f5mt333w@7xslvq6b6hmv/
Link: https://lpc.events/event/18/contributions/1731/
Signed-off-by: Mathieu Desnoyers
Change-Id: I6369064a0e1a1f9632394df31ff41c76905d17e3
Cc: "Paul E. McKenney"
Cc: Will Deacon
Cc: Peter Zijlstra
Cc: Boqun Feng
Cc: Alan Stern
Cc: John Stultz
To: Neeraj Up
up readers.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
/20231002202531.3160-1-mathieu.desnoy...@efficios.com/
Co-developed-by: Michael Jeanson
Signed-off-by: Mathieu Desnoyers
Signed-off-by: Michael Jeanson
Reviewed-by: Masami Hiramatsu (Google)
Cc: Steven Rostedt
Cc: Masami Hiramatsu
Cc: Peter Zijlstra
Cc: Alexei Starovoitov
Cc: Yonghong Song
Cc: Paul E
.
This change does not yet allow perf to take page faults per se within
its probe, but allows its existing probes to connect to faultable
tracepoints.
Link:
https://lore.kernel.org/lkml/20231002202531.3160-1-mathieu.desnoy...@efficios.com/
Co-developed-by: Michael Jeanson
Signed-off-by: Mathieu
change does not yet allow bpf to take page faults per se within its
probe, but allows its existing probes to connect to faultable
tracepoints.
Link:
https://lore.kernel.org/lkml/20231002202531.3160-1-mathieu.desnoy...@efficios.com/
Co-developed-by: Michael Jeanson
Signed-off-by: Mathieu Desnoyers
: Michael Jeanson
Signed-off-by: Mathieu Desnoyers
Reviewed-by: Masami Hiramatsu (Google)
Cc: Steven Rostedt
Cc: Masami Hiramatsu
Cc: Peter Zijlstra
Cc: Alexei Starovoitov
Cc: Yonghong Song
Cc: Paul E. McKenney
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Mark Rutland
Cc: Alexander Shishkin
synchronize read-side
marshalling of the registered probes with respect to faultable probes
unregistration and teardown.
Link:
https://lore.kernel.org/lkml/20231002202531.3160-1-mathieu.desnoy...@efficios.com/
Co-developed-by: Michael Jeanson
Signed-off-by: Mathieu Desnoyers
Signed-off-by: Michael
-trace-ker...@vger.kernel.org
Mathieu Desnoyers (5):
tracing: Introduce faultable tracepoints
tracing/ftrace: Add support for faultable tracepoints
tracing/bpf-trace: Add support for faultable tracepoints
tracing/perf: Add support for faultable tracepoints
tracing: Convert sys_enter/exit to
ARD()" to actually
define a guard variable, rename all the guard "DEFINE_" prefix to
"DECLARE_".
Signed-off-by: Mathieu Desnoyers
Cc: Peter Zijlstra (Intel)
Cc: Ingo Molnar
---
crypto/asymmetric_keys/x509_parser.h | 4 +-
drivers/cxl/acpi.c
);
[...]
if (a) {
might_sleep();
activate_guard(preempt_notrace, myguard)();
}
[ protected code ]
}
Signed-off-by: Mathieu Desnoyers
Cc: Peter Zijlstra (Intel)
Cc: Ingo Molnar
Cc: Linus Torvalds
Cc: Kees Cook
Cc: Greg KH
Cc: Sean
ldo Carvalho de Melo
Cc: Mark Rutland
Cc: Alexander Shishkin
Cc: Namhyung Kim
Cc: b...@vger.kernel.org
Cc: Joel Fernandes
Cc: linux-trace-ker...@vger.kernel.org
Mathieu Desnoyers (2):
cleanup.h guard: Rename DEFINE_ prefix to DECLARE_
cleanup.h: Introduce DEFINE_INACTIVE_GUARD and activate_
On 2024-08-20 01:00, Steven Rostedt wrote:
On Thu, 27 Jun 2024 11:23:35 -0400
Mathieu Desnoyers wrote:
To cover scenarios where the scope of the guard differs from the scope
of its activation, introduce DEFINE_INACTIVE_GUARD() and activate_guard().
Here is an example use for a conditionally
On 2024-07-15 15:13, Steven Rostedt wrote:
On Mon, 15 Jul 2024 15:10:17 -0400
Mathieu Desnoyers wrote:
On 2024-07-15 14:47, Steven Rostedt wrote:
From: "Steven Rostedt (Google)"
Gone but never forgotten.
[ Also moved Daniel's name to be consistent with the alphabetical orde
e Oliveira
S:Maintained
F:Documentation/trace/hwlat_detector.rst
F:Documentation/trace/osnoise-tracer.rst
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
On 2024-07-02 12:51, Steven Rostedt wrote:
On Tue, 2 Jul 2024 11:32:53 -0400
Mathieu Desnoyers wrote:
If we use '*' for user events already, perhaps we'd want to consider
using the same range for the ring buffer ioctls ? Arguably one is
about instrumentation and the other is ab
On 2024-07-02 11:18, Steven Rostedt wrote:
On Tue, 2 Jul 2024 10:36:03 -0400
Mathieu Desnoyers wrote:
I can send a patch this week to update it. Or feel free to send a patch
yourself.
You need to reserve an unused ioctl Code and Seq# range within:
Documentation/userspace-api/ioctl/ioctl
ioctl Code and Seq# range within:
Documentation/userspace-api/ioctl/ioctl-number.rst
Otherwise this duplicate will confuse all system call instrumentation
tooling.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
/20231002202531.3160-1-mathieu.desnoy...@efficios.com/
Co-developed-by: Michael Jeanson
Signed-off-by: Mathieu Desnoyers
Signed-off-by: Michael Jeanson
Cc: Steven Rostedt
Cc: Masami Hiramatsu
Cc: Peter Zijlstra
Cc: Alexei Starovoitov
Cc: Yonghong Song
Cc: Paul E. McKenney
Cc: Ingo Molnar
Cc: Arnaldo
.
This change does not yet allow perf to take page faults per se within
its probe, but allows its existing probes to connect to faultable
tracepoints.
Link:
https://lore.kernel.org/lkml/20231002202531.3160-1-mathieu.desnoy...@efficios.com/
Co-developed-by: Michael Jeanson
Signed-off-by: Mathieu
: Michael Jeanson
Signed-off-by: Mathieu Desnoyers
Cc: Steven Rostedt
Cc: Masami Hiramatsu
Cc: Peter Zijlstra
Cc: Alexei Starovoitov
Cc: Yonghong Song
Cc: Paul E. McKenney
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Mark Rutland
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: b
change does not yet allow bpf to take page faults per se within its
probe, but allows its existing probes to connect to faultable
tracepoints.
Link:
https://lore.kernel.org/lkml/20231002202531.3160-1-mathieu.desnoy...@efficios.com/
Co-developed-by: Michael Jeanson
Signed-off-by: Mathieu Desnoyers
ARD()" to actually
define a guard variable, rename all the guard "DEFINE_" prefix to
"DECLARE_".
Signed-off-by: Mathieu Desnoyers
Cc: Peter Zijlstra (Intel)
Cc: Ingo Molnar
---
drivers/cxl/core/cdat.c | 2 +-
drivers/cxl/cxl.h
synchronize read-side
marshalling of the registered probes with respect to faultable probes
unregistration and teardown.
Link:
https://lore.kernel.org/lkml/20231002202531.3160-1-mathieu.desnoy...@efficios.com/
Co-developed-by: Michael Jeanson
Signed-off-by: Mathieu Desnoyers
Signed-off-by: Michael
Starovoitov
Cc: Yonghong Song
Cc: Paul E. McKenney
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Mark Rutland
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: b...@vger.kernel.org
Cc: Joel Fernandes
Mathieu Desnoyers (8):
cleanup.h: Header include guard should match header
);
[...]
if (a) {
might_sleep();
activate_guard(preempt_notrace, myguard)();
}
[ protected code ]
}
Signed-off-by: Mathieu Desnoyers
Cc: Peter Zijlstra (Intel)
Cc: Ingo Molnar
Cc: Linus Torvalds
Cc: Kees Cook
Cc: Greg KH
Cc: Sean
The include guard should match the header name. Rename __LINUX_GUARDS_H
to __LINUX_CLEANUP_H.
Signed-off-by: Mathieu Desnoyers
Cc: Peter Zijlstra (Intel)
Cc: Ingo Molnar
---
include/linux/cleanup.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux
used: some architecture code
choose to bypass this restart notifier and reboot directly from the
architecture code.
Wiring up the architecture code to call this notifier chain is left to
follow-up arch-specific patches.
Signed-off-by: Mathieu Desnoyers
Cc: Dan Williams
Cc: Vishal Verma
Cc: Dave Jian
Invoke the pre_restart notifiers after shutdown, before machine restart.
This allows preserving pmem memory across warm reboots.
Invoke the pre_restart notifiers before emergency machine restart as
well to cover the panic() scenario.
Signed-off-by: Mathieu Desnoyers
Cc: Dan Williams
Cc: Vishal
machine restart use-cases.
Link:
https://lore.kernel.org/linux-kernel/f6067e3e-a2bc-483d-b214-6e3fe6691...@efficios.com/
[1]
Signed-off-by: Mathieu Desnoyers
Cc: Dan Williams
Cc: Vishal Verma
Cc: Dave Jiang
Cc: Ira Weiny
Cc: Steven Rostedt
Cc: nvd...@lists.linux.dev
Cc: Thomas Gleixner
: linux-arm-ker...@lists.infradead.org
Mathieu Desnoyers (4):
kernel/reboot: Introduce pre_restart notifiers
nvdimm/pmem: Flush to memory before machine restart
arm64: Invoke pre_restart notifiers
x86: Invoke pre_restart notifiers
arch/arm64/kernel/process.c | 2 ++
arch/x86/kernel/r
Invoke the pre_restart notifiers after shutdown, before machine restart.
This allows preserving pmem memory across warm reboots.
Invoke the pre_restart notifiers on emergency_machine_restart to cover
the panic() scenario.
Signed-off-by: Mathieu Desnoyers
Cc: Dan Williams
Cc: Vishal Verma
Cc
On 2024-06-06 11:46, Alice Ryhl wrote:
On Thu, Jun 6, 2024 at 5:25 PM Mathieu Desnoyers
wrote:
On 2024-06-06 11:05, Alice Ryhl wrote:
This implementation implements support for static keys in Rust so that
the actual static branch will end up in the Rust object file. However,
it would also be
On 2024-06-06 12:16, Alice Ryhl wrote:
On Thu, Jun 6, 2024 at 5:29 PM Mathieu Desnoyers
wrote:
On 2024-06-06 11:05, Alice Ryhl wrote:
Make it possible to have Rust code call into tracepoints defined by C
code. It is still required that the tracepoint is declared in a C
header, and that this
On 2024-06-06 11:49, Boqun Feng wrote:
On Thu, Jun 06, 2024 at 11:30:03AM -0400, Mathieu Desnoyers wrote:
On 2024-06-06 11:05, Alice Ryhl wrote:
Make it possible to have Rust code call into tracepoints defined by C
code. It is still required that the tracepoint is declared in a C
header, and
rust/kernel/tracepoint.rs | 92 +
scripts/Makefile.build | 2 +-
8 files changed, 315 insertions(+), 1 deletion(-)
---
base-commit: 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0
change-id: 20240606-tracepoint-31e15b90e471
Best rega
more broadly in userspace as well ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
inlining those helpers in Rust ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
On 2024-06-04 12:34, Steven Rostedt wrote:
On Tue, 4 Jun 2024 11:02:16 -0400
Mathieu Desnoyers wrote:
I see.
It looks like there are a few things we could improve there:
1) With your approach, modules need to be already loaded before
attaching an fprobe event to them. This effectively
On 2024-06-03 19:49, Masami Hiramatsu (Google) wrote:
On Mon, 3 Jun 2024 15:50:55 -0400
Mathieu Desnoyers wrote:
On 2024-06-01 04:22, Masami Hiramatsu (Google) wrote:
From: Masami Hiramatsu (Google)
Support raw tracepoint event on module by fprobe events.
Since it only uses
MAX_TRACE_ARGS; i++) {
trace_probe_log_set_index(i + 2);
@@ -1155,6 +1183,8 @@ static int __trace_fprobe_create(int argc, const char
*argv[])
}
out:
+ if (tp_mod)
+ module_put(tp_mod);
traceprobe_finish_parse(&ctx);
trace_probe_log_clear();
kfree(new_argv);
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
and gsbase are used for this.
An option to explore suggested by Mathieu Desnoyers is to utilize rseq
for processes to register a value location that can be included when
profiling if desired. This would allow a tighter contract between user
processes and a profiler. It would allow better labeling/ca
On 2024-03-20 13:58, Steven Rostedt wrote:
On Wed, 20 Mar 2024 13:15:39 -0400
Mathieu Desnoyers wrote:
I would like to introduce restart_critical_timings() and place it in
locations that have this behavior.
Is there any way you could move this to need_resched() rather than
sprinkle those
ched() check needs to be done here.
*/
if (owner_state != OWNER_WRITER) {
+ restart_critical_timings();
if (need_resched())
break;
if (rt_task(current) &&
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
CPU, state,
etc). As trace_seq is made to handle large events (some greater than 4K).
Make the max size of a trace_marker write event be 4K which is guaranteed
to fit in the trace_seq buffer.
Suggested-by: Mathieu Desnoyers
From my perspective I only attempted to clarify the point Linus
he first place, and you should then just add a runtime check that
you don't overflow the output buffer before writing the output to it.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
On 2024-03-04 20:59, Steven Rostedt wrote:
On Mon, 4 Mar 2024 20:42:39 -0500
Mathieu Desnoyers wrote:
#define TRACE_OUTPUT_META_DATA_MAX_LEN 80
and a runtime check in the code generating this header.
This would avoid adding an unchecked upper limit.
That would be a lot of complex
this header.
This would avoid adding an unchecked upper limit.
Thanks,
Mathieu
-- Steve
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
On 2024-03-04 20:35, Steven Rostedt wrote:
On Mon, 4 Mar 2024 20:15:57 -0500
Mathieu Desnoyers wrote:
On 2024-03-04 19:27, Steven Rostedt wrote:
From: "Steven Rostedt (Google)"
Since the size of trace_seq's buffer is the max an event can output, have
the trace_marker be hal
size += FAULTED_SIZE - cnt;
- if (size > TRACE_SEQ_BUFFER_SIZE) {
- cnt -= size - TRACE_SEQ_BUFFER_SIZE;
- goto again;
- }
-
buffer = tr->array_buffer.buffer;
event = __trace_buffer_lock_reserve(buffer, TRACE_PRINT, size,
167...@gandalf.local.home/
Reported-by: Sachin Sant
Fixes: 60be76eeabb3d ("tracing: Add size check when printing trace_marker
output")
Signed-off-by: Steven Rostedt (Google)
This is a step in the right direction IMHO.
Reviewed-by: Mathieu Desnoyers
Just out of curiosity, is the
d just obfuscates the code.
Thanks,
Mathieu
In this case, READ_ONCE() is only needed for the commit_page.
But we can at least keep the READ_ONCE() on the commit_page just because it
is used in the next instruction.
-- Steve
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
On 2024-02-20 09:19, Steven Rostedt wrote:
On Mon, 19 Feb 2024 18:20:32 -0500
Steven Rostedt wrote:
Instead of using local_add_return() to reserve the ring buffer data,
Mathieu Desnoyers suggested using local_cmpxchg(). This would simplify the
reservation with the time keeping code.
Although
id set_dax_nomc(struct dax_device *dax_dev);
-
struct writeback_control;
#if defined(CONFIG_BLOCK) && defined(CONFIG_FS_DAX)
int dax_add_host(struct dax_device *dax_dev, struct gendisk *disk);
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
On 2024-02-09 15:15, Dan Williams wrote:
Mathieu Desnoyers wrote:
Hi Dan,
In the context of extracting user-space trace data when the kernel crashes,
the LTTng user-space tracer recommends using nvdimm/pmem to reserve an area
of physical (volatile) RAM at boot (memmap=nn[KMG]!ss[KMG]), and use
present in the cpu data cache
is not invalidated prior to write back in each of those scenarios ?
- reboot with bios explicitly not clearing memory,
- kexec/kdump.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
On 2024-02-05 13:34, Vincent Donnefort wrote:
On Mon, Feb 05, 2024 at 11:55:08AM -0500, Mathieu Desnoyers wrote:
[...]
How are the kernel linear mapping and the userspace mapping made coherent
on architectures with virtually aliasing data caches ?
Ref.
https://lore.kernel.org/lkml
.unlocked_ioctl = tracing_buffers_ioctl,
.llseek = no_llseek,
+ .mmap = tracing_buffers_mmap,
};
static ssize_t
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index bd312e9afe25..8a96e7a89e6b 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -
On 2024-01-30 22:13, Dan Williams wrote:
Dave Chinner wrote:
On Tue, Jan 30, 2024 at 11:52:55AM -0500, Mathieu Desnoyers wrote:
commit d92576f1167c ("dax: does not work correctly with virtual aliasing
caches")
prevents DAX from building on architectures with virtually aliased
d
On 2024-01-30 21:48, Dave Chinner wrote:
On Tue, Jan 30, 2024 at 11:52:54AM -0500, Mathieu Desnoyers wrote:
Introduce a generic way to query whether the dcache is virtually aliased
on all architectures. Its purpose is to ensure that subsystems which
are incompatible with virtually aliased data
1 - 100 of 2119 matches
Mail list logo
