n the
buffer size is rather inconvenient.
It would be better to print the partial line, and end the line with
a tag.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
I would expect the tests under tools/testing/selftests/ftrace/* to
be affected by those changes. If they are not, then it's a hole in
the test coverage and should be taken care of as this behavior is
modified.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
lld] delta:%lld TIME EXTEND\n",
Please prefix hex values with "0x", as in:
pr_warn(" 0x%x: [%lld] delta:%lld TIME EXTEND\n"
Otherwise it can be confusing.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
In order to make sure I get CC'd on tracing changes for which my input
would be relevant, add my name as reviewer of the TRACING subsystem.
Signed-off-by: Mathieu Desnoyers
Cc: Steven Rostedt
Cc: Masami Hiramatsu
Cc: linux-trace-ker...@vger.kernel.org
---
MAINTAINERS | 1 +
1 file chang
ist_ptr,
+ (intptr_t*)&args->percpu_list_ptr,
sizeof(struct percpu_list_entry) * cpu, 1, cpu);
} while (rseq_unlikely(ret));
}
---
base-commit: 2dde18cd1d8fac735875f2e4987f11817cc0bc2c
change-id: 20230908-kselftest-param_test-c-1763b62
- On Apr 20, 2021, at 10:55 AM, rostedt rost...@goodmis.org wrote:
> On Tue, 20 Apr 2021 09:29:27 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
>> - On Apr 20, 2021, at 8:55 AM, rostedt rost...@goodmis.org wrote:
>> [...]
>> >
>> > Would adding automa
r does a typo when entering an event name.
So I think those command line parameters should be tracer-specific, do you
agree ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
# define rcu_dereference(x) CMM_LOAD_SHARED(x)
# endif
# endif
#endif
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Apr 16, 2021, at 12:01 PM, paulmck paul...@kernel.org wrote:
> On Fri, Apr 16, 2021 at 05:17:11PM +0200, Peter Zijlstra wrote:
>> On Fri, Apr 16, 2021 at 10:52:16AM -0400, Mathieu Desnoyers wrote:
>> > Hi Paul, Will, Peter,
>> >
>> > I noticed in t
how this could be done in the context of user-space.
4) [ Insert better idea here. ]
Thoughts ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
; v2: Addressed Peter and Mathieu feedbacks, thanks !
For the whole series:
Reviewed-by: Mathieu Desnoyers
Thanks Eric!
Mathieu
>
> Eric Dumazet (3):
> rseq: optimize rseq_update_cpu_id()
> rseq: remove redundant access_ok()
> rseq: optimise rseq_get_rseq_cs() and cle
- On Apr 13, 2021, at 2:22 PM, Eric Dumazet eduma...@google.com wrote:
> On Tue, Apr 13, 2021 at 8:00 PM Mathieu Desnoyers
> wrote:
>>
>
>> As long as the ifdefs are localized within clearly identified wrappers in the
>> rseq code I don't mind doing the
- On Apr 13, 2021, at 1:33 PM, Eric Dumazet eduma...@google.com wrote:
> On Tue, Apr 13, 2021 at 7:20 PM Mathieu Desnoyers
> wrote:
>>
>> - On Apr 13, 2021, at 1:07 PM, Eric Dumazet eduma...@google.com wrote:
>>
>> > On Tue, Apr 13, 2021 at 7:01 PM Eric D
- On Apr 13, 2021, at 1:07 PM, Eric Dumazet eduma...@google.com wrote:
> On Tue, Apr 13, 2021 at 7:01 PM Eric Dumazet wrote:
>>
>> On Tue, Apr 13, 2021 at 6:57 PM Eric Dumazet wrote:
>> >
>> > On Tue, Apr 13, 2021 at 6:54 PM Mathieu Desnoyers
>> >
- On Apr 13, 2021, at 12:57 PM, Eric Dumazet eduma...@google.com wrote:
> On Tue, Apr 13, 2021 at 6:54 PM Mathieu Desnoyers
> wrote:
>>
>> - On Apr 13, 2021, at 12:22 PM, Eric Dumazet eric.duma...@gmail.com
>> wrote:
>>
>> > From: Eric Dumazet
>
or in a 32-bit compat mode on a 64-bit kernel.
So although I'm fine with making 64-bit kernels faster, we'll want to keep
updating the entire 64-bit ptr field on 32-bit kernels as well.
Thanks,
Mathieu
>
> Signed-off-by: Eric Dumazet
> Cc: Mathieu Desnoyers
> Cc: Pete
dif
>
> Then have one copy of the code and the #undefs.
Good point, agreed.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
ume()
While we are doing that, should we also remove the access_ok() check in
rseq_syscall() ? It look like it can also be removed for the exact same
reason outlined here.
Thanks,
Mathieu
>
> Signed-off-by: Eric Dumazet
> Cc: Mathieu Desnoyers
> Cc: Peter Zijlstra
> Cc: "Pau
>
> Signed-off-by: Eric Dumazet
> Cc: Mathieu Desnoyers
> Cc: Peter Zijlstra
> Cc: "Paul E. McKenney"
> Cc: Boqun Feng
> Cc: Arjun Roy
> Cc: Ingo Molnar
> ---
> kernel/rseq.c | 15 +++
> 1 file changed, 11 insertions(+), 4 deletio
not right. It should be &t->rseq->rseq_cs.ptr.ptr32.
Thanks,
Mathieu
>> +return -EFAULT;
>> +#endif
>> if (!ptr) {
>> memset(rseq_cs, 0, sizeof(*rseq_cs));
>> return 0;
>> }
>> if (ptr >= TASK_SIZE)
>> return -EINVAL;
>> -urseq_cs = (struct rseq_cs __user *)(unsigned long)ptr;
>> +urseq_cs = (struct rseq_cs __user *)ptr;
>> if (copy_from_user(rseq_cs, urseq_cs, sizeof(*rseq_cs)))
>> return -EFAULT;
>>
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
> UK
> Registration No: 1397386 (Wales)
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
\t " /* RSEQ_SIG */
>> "4: \n\t "
>> "jmp % l[aborted] \n\t "
>> : /* no outputs */
>> : [cpu_id] "r" (cpu),
>> [current_cpu_id] "m" ( __rseq_abi . cpu_id ),
>> [rseq_cs] "m" ( __rseq_abi . rseq_cs )
>> : "mem
'm a bit
stretched on time
here, so maybe they will have time to answer before I do.
Meanwhile, if you could provide details about your architecture, kernel
.config, and a
small reproducer program, it would help bootstrapping the discussion.
Thanks,
Mathieu
> Best,
>
- On Mar 11, 2021, at 11:51 AM, Peter Zijlstra pet...@infradead.org wrote:
> On Thu, Mar 11, 2021 at 09:51:56AM -0500, Mathieu Desnoyers wrote:
>>
>>
>> - On Feb 26, 2021, at 8:51 AM, Piotr Figiel fig...@google.com wrote:
>>
>> > For userspace c
ABI address and the signature value
> with the new ptrace request PTRACE_GET_RSEQ_CONFIGURATION.
>
> This new ptrace request can also be used by debuggers so they are aware
> of stops within restartable sequences in progress.
>
> Signed-off-by: Piotr Figiel
> Reviewed-by: Michal Miroslaw
Review
The following commit has been merged into the sched/core branch of tip:
Commit-ID: ce29ddc47b91f97e7f69a0fb7cbb5845f52a9825
Gitweb:
https://git.kernel.org/tip/ce29ddc47b91f97e7f69a0fb7cbb5845f52a9825
Author:Mathieu Desnoyers
AuthorDate:Wed, 17 Feb 2021 11:56:51 -05:00
- On Feb 26, 2021, at 9:11 AM, Piotr Figiel fig...@google.com wrote:
> Hi,
>
> On Mon, Feb 22, 2021 at 09:53:17AM -0500, Mathieu Desnoyers wrote:
>
>> I notice that other structures defined in this UAPI header are not
>> packed as well. Should we add an attribute
- On Feb 26, 2021, at 11:06 AM, Piotr Figiel fig...@google.com wrote:
> Hi,
>
> On Fri, Feb 26, 2021 at 10:32:35AM -0500, Mathieu Desnoyers wrote:
>> > +static long ptrace_get_rseq_configuration(struct task_struct *task,
>> > +
The following commit has been merged into the sched/urgent branch of tip:
Commit-ID: fba111913e51a934eaad85734254eab801343836
Gitweb:
https://git.kernel.org/tip/fba111913e51a934eaad85734254eab801343836
Author:Mathieu Desnoyers
AuthorDate:Wed, 17 Feb 2021 11:56:51 -05:00
- On Feb 26, 2021, at 11:04 AM, emmir em...@google.com wrote:
> On Fri, 26 Feb 2021 at 16:32, Mathieu Desnoyers
> wrote:
>>
>> - On Feb 26, 2021, at 8:51 AM, Piotr Figiel fig...@google.com wrote:
>> [...]
>> > ---
>> > v2:
>> > Applie
;
__u32 pad;
};
where:
.size = sizeof(struct ptrace_rseq_configuration),
This way, the configuration structure can be expanded in the future. The
rseq ABI structure is by definition fixed-size, so there is no point in
having its size here.
Florian, did I understand your request correctly, or am I missing your point ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Feb 24, 2021, at 1:14 PM, rostedt rost...@goodmis.org wrote:
> On Wed, 24 Feb 2021 11:59:35 -0500 (EST)
> Mathieu Desnoyers wrote:
>>
>> As a prototype solution, what I've done currently is to copy the user-space
>> data into a kmalloc'd buffer in a
f readers (for IPIed readers) and by
> +// scheduler context-switch ordering (for locked-down non-running readers).
The rest looks good, thanks!
Mathieu
>
> // The lockdep state must be outside of #ifdef to be useful.
> #ifdef CONFIG_DEBUG_LOCK_ALLOC
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Feb 25, 2021, at 10:36 AM, paulmck paul...@kernel.org wrote:
> On Thu, Feb 25, 2021 at 09:22:48AM -0500, Mathieu Desnoyers wrote:
>> Hi Paul,
>>
>> Answering a question from Peter on IRC got me to look at
>> rcu_read_lock_trace(),
>> and I se
d not to
prevent
progress of the grace period.
Without this, a steady flow of incoming tasks-trace-RCU readers can prevent the
grace period from ever completing.
Or is this handled in a clever way that I am missing here ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- Mathieu Desnoyers wrote:
> - On Feb 24, 2021, at 11:22 AM, Michael Jeanson mjean...@efficios.com
> wrote:
>
> > [ Adding Mathieu Desnoyers in CC ]
> >
> > On 2021-02-23 21 h 16, Steven Rostedt wrote:
> >> On Thu, 18 Feb 2021 17:21:
- On Feb 24, 2021, at 11:22 AM, Michael Jeanson mjean...@efficios.com wrote:
> [ Adding Mathieu Desnoyers in CC ]
>
> On 2021-02-23 21 h 16, Steven Rostedt wrote:
>> On Thu, 18 Feb 2021 17:21:19 -0500
>> Michael Jeanson wrote:
>>
>>> This s
,
> + .signature = task->rseq_sig,
> + };
> +
> + size = min_t(unsigned long, size, sizeof(conf));
> + if (copy_to_user(data, &conf, size))
> + return -EFAULT;
> + return size;
See other email about returning 0 here.
Thanks,
Mathieu
> +
> default:
> break;
> }
> --
> 2.30.0.617.g56c4b15f3c-goog
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
or ptrace requests would be to return 0 when
everything
is OK. Unless there a strong motivation for doing different for this new
request, I
would be tempted to use the same expected behavior than other requests on
success:
return 0.
Unless there is a strong motivation for returning either size or sizeof(conf) ?
If we
return sizeof(conf) to user-space, it means it should check it and deal with the
size mismatch. Is that size ever expected to change ?
Thanks,
Mathieu
>
>
> --
> ldv
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
enabled by default as well. Or if some new options should enable "typical"
usage scenarios.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
iler prior to version 5.1, because they perform
unsafe access
to deallocated stack.
Thanks,
Mathieu
Project website: https://lttng.org
Documentation: https://lttng.org/docs
Download link: https://lttng.org/download
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
between rcu_barrier() and call_rcu_data_free()
Project website: http://liburcu.org
Git repository: git://git.liburcu.org/urcu.git
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
on_each_cpu_mask().
Fixes: 227a4aadc75b ("sched/membarrier: Fix p->mm->membarrier_state racy load")
Link: https://lore.kernel.org/r/74f1e842-4a84-47bf-b6c2-5407dfdd4...@gmail.com
Signed-off-by: Mathieu Desnoyers
Reported-by: Nadav Amit
Cc: Peter Zijlstra
Cc: Nadav Amit
Cc: sta...@vger.ke
;sched/membarrier: Fix p->mm->membarrier_state racy load")
> Is that the intention of the code?
Clearly not! If we look at sync_runqueues_membarrier_state(), there is even a
special-case for mm_users==1 || num online cpus == 1 where it writes the
membarrier
state into the current cpu
- On Oct 28, 2020, at 5:23 PM, Alexei Starovoitov
alexei.starovoi...@gmail.com wrote:
> On Tue, Oct 27, 2020 at 09:37:08AM -0400, Mathieu Desnoyers wrote:
>>
>> - On Oct 26, 2020, at 6:43 PM, Alexei Starovoitov
>> alexei.starovoi...@gmail.com wrote:
>>
>
- On Feb 10, 2021, at 12:09 PM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
> On Wed, Feb 10, 2021 at 11:04:19AM -0500, Mathieu Desnoyers wrote:
>> Hi,
>>
>> While reconciling the lttng-modules writeback instrumentation with its
>> counterpart
>> wi
68f23b89067fdf187763e75a56087550624fdbee
("memcg: fix a crash in wb_workfn when a device disappears")
Considering that this fix was CC'd to the stable mailing list, is there any
reason why it has not been integrated into those LTS branches ?
Thanks,
Mathieu
--
Mathieu Desnoyers
Eff
- On Feb 8, 2021, at 3:09 PM, rostedt rost...@goodmis.org wrote:
> Broke this up into two patches now. See the second patch for the
> description of waht this series is doing.
For both patches:
Reviewed-by: Mathieu Desnoyers
>
> Changes since v2:
>
> Added a patch to
- On Feb 5, 2021, at 10:40 AM, Peter Zijlstra pet...@infradead.org wrote:
> On Fri, Feb 05, 2021 at 10:09:26AM -0500, Mathieu Desnoyers wrote:
>> Then we should be able to generate the following using static keys as a
>> jump table and N static calls:
>>
>> j
_N:
stack setup
call
label_N-1:
stack setup
call
label_N-2:
stack setup
call
...
label_0:
jump end
label_fallback:
end:
So the static keys would be used to jump to the appropriate label (using
a static branch, which has pretty much 0 overhead). Static calls would
be used to implement each of the calls.
Thoughts ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
__DO_TRACE_CALL(name)(args);\
> - } \
> + __DO_TRACE_CALL(name, TP_ARGS(args)); \
> \
> if (rcuidle) { \
> rcu_irq_exit_irqson(); \
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
keep his signature, but I will take the responsibility of this
> being correct, and keep the authorship.
>
> Signed-off-by: Mathieu Desnoyers
> Signed-off-by: Steven Rostedt (VMware)
> ---
> include/linux/tracepoint.h | 2 +-
> kernel/tracepoint.c| 92 +
This patch is only compile-tested.
Signed-off-by: Mathieu Desnoyers
---
include/linux/tracepoint.h | 2 +-
kernel/tracepoint.c| 80 +-
2 files changed, 28 insertions(+), 54 deletions(-)
diff --git a/include/linux/tracepoint.h b/include/linux
ses RCU tricks and is more complex, but
> can be an alternative if this solution becomes an issue.
>
> Link:
> https://lore.kernel.org/lkml/20210127170721.58bce...@gandalf.local.home/
> ]
>
> Cc: Peter Zijlstra
> Cc: Josh Poimboeuf
> Cc: Mathieu Desnoyers
> C
- On Jan 27, 2021, at 2:16 PM, rostedt rost...@goodmis.org wrote:
> On Wed, 27 Jan 2021 13:13:22 -0500 (EST)
> Mathieu Desnoyers wrote:
>
>> > Thanks for bringing that up.
>>
>> Requiring an RCU synchronize on element removal is quite intrusive, and can
&
- On Jan 27, 2021, at 1:07 PM, rostedt rost...@goodmis.org wrote:
> On Wed, 27 Jan 2021 13:00:46 -0500 (EST)
> Mathieu Desnoyers wrote:
>
>> > Instead of allocating a new array for removing a tracepoint, allocate twice
>> > the needed size when adding tracepoint
> }
>
> static void tracepoint_update_call(struct tracepoint *tp, struct
> tracepoint_func
> *tp_funcs, bool sync)
> @@ -309,8 +339,8 @@ static int tracepoint_remove_func(struct tracepoint *tp,
> rcu_assign_pointer(tp->funcs, tp_funcs);
> } else {
> rcu_assign_pointer(tp->funcs, tp_funcs);
> - tracepoint_update_call(tp, tp_funcs,
> -tp_funcs[0].func != old[0].func);
> + /* Need to sync, if going back to a single caller */
> + tracepoint_update_call(tp, tp_funcs, tp_funcs[1].func == NULL);
> }
> release_probes(old);
> return 0;
> --
> 2.25.4
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
thread is stopped/frozen while the read is done.
Maybe we should consider validating that the proc file is used from the right
context
(from self or when the target thread is stopped/frozen) rather than add dubious
locking ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
ot;, S_IRUGO, proc_tgid_stat),
> @@ -3522,6 +3540,9 @@ static const struct pid_entry tid_base_stuff[] = {
>&proc_pid_set_comm_operations, {}),
> #ifdef CONFIG_HAVE_ARCH_TRACEHOOK
> ONE("syscall", S_IRUSR, proc_pid_syscall),
> +#ifdef CONFIG_RSEQ
> + ONE("rseq", S_IRUSR, proc_pid_rseq),
> +#endif
> #endif
> REG("cmdline", S_IRUGO, proc_pid_cmdline_ops),
> ONE("stat", S_IRUGO, proc_tid_stat),
> --
> 2.30.0.284.gd98b1dd5eaa7-goog
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
: https://lttng.org/download
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
ck".
>
> So, the core executing this call is not allowed to block, but the
> other part indicates that the other CPUs _have_ executed a serialising
> instruction before this call returns... one wonders how that happens
> without blocking. Maybe the CPU spins waiting for completion instead?
Membarrier expedited sync-core issues IPIs to all CPUs running sibling
threads. AFAIR the IPI mechanism uses the "csd lock" which is basically
busy waiting. So it does not "block", it busy-waits.
For completeness of the explanation, other (non-running) threads acting
on the same mm will eventually issue the context synchronizing instruction
before returning to user-space whenever they are scheduled back.
Thanks,
Mathieu
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
pose to user-space, e.g. flush_icache_user_range on arm32.
So between code modification and allowing other threads to jump to that code,
it should be expected that architectures without coherent i/d cache will need
to flush caches to ensure coherency *and* to issue membarrier to make sure
core serializing instructions will be issued by every thread acting on the
same mm either immediately by means of the IPI, or before they return to
user-space if they do not happen to be currently running when the membarrier
system call is invoked.
Hoping this clarifies things. I suspect we will need to clarify documentation
about what membarrier *does not* guarantee, given that you mistakenly expected
membarrier to take care of cache flushing.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Dec 28, 2020, at 4:06 PM, Andy Lutomirski l...@kernel.org wrote:
> On Mon, Dec 28, 2020 at 12:32 PM Mathieu Desnoyers
> wrote:
>>
>> - On Dec 28, 2020, at 2:44 PM, Andy Lutomirski l...@kernel.org wrote:
>>
>> > On Mon, Dec 28, 2020 at 11:09
4/a/Memory-Ordering/Barriers/ISB-in-more-detail
[2]
https://montcs.bloomu.edu/Information/ARMv8/ARMv8-A_Architecture_Reference_Manual_(Issue_A.a).pdf
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
?
Based on the notes I have, use of `eret` on aarch64 guarantees a context
synchronizing
instruction when returning to user-space.
Thanks,
Mathieu
>
> Cc: Michael Ellerman
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: linuxppc-...@lists.ozlabs.org
> Cc: Nich
// the mm check for?
>> +membarrier_mm_sync_core_before_usermode(next);
>
> On the other hand the reason for this mm check that you mention contradicts
> my previous understanding as the git log says:
>
> commit 2840cf02fae627860156737e83326df354ee4ec
re is the meat. The current code is using the (possibly incomplete)
lazy TLB state known by the scheduler to sync core, and it appears it may be
a bit more heavy that what is strictly needed.
Your change instead rely on the internal knowledge of lazy TLB within x86
switch_mm_irqs_off to achie
ll.
>
> As an optimization, this avoids an extra smp_mb() in the default
> barrier-only mode.
^ we could also add to the commit message that it avoids doing rseq preempt
on the caller as well.
Other than that:
Reviewed-by: Mathieu Desnoyers
Thanks!
Mathieu
>
> Cc: sta...
> surprised that the core membarrier code doesn't currently show up in a
> such a search.)
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Andy Lutomirski
Reviewed-by: Mathieu Desnoyers
> ---
> kernel/sched/membarrier.c | 18 ++
> 1 file changed, 18 in
ice, nothing actually guarantees it by a strict reading of the
> x86 manuals. Rather than providing this guarantee by accident and
> potentially causing a problem down the road, just add an explicit
> barrier.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Andy Lutomirski
func == ipi_mb) {
> + preempt_disable();
> + smp_call_function_many(tmpmask, ipi_func, NULL, true);
> + preempt_enable();
> + } else {
> + on_each_cpu_mask(tmpmask, ipi_func, NULL, true);
> + }
> + }
>
> out:
> if (cpu_id < 0)
> --
> 2.28.0
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Dec 1, 2020, at 1:48 PM, Andy Lutomirski l...@kernel.org wrote:
> On Tue, Dec 1, 2020 at 10:29 AM Mathieu Desnoyers
> wrote:
>>
>> - On Dec 1, 2020, at 1:12 PM, Andy Lutomirski l...@kernel.org wrote:
>>
>> > On Tue, Dec 1, 2020 at 6:28
- On Dec 1, 2020, at 1:12 PM, Andy Lutomirski l...@kernel.org wrote:
> On Tue, Dec 1, 2020 at 6:28 AM Mathieu Desnoyers
> wrote:
>>
>> - On Dec 1, 2020, at 5:16 AM, Peter Zijlstra pet...@infradead.org wrote:
>>
>> > On Mon, Nov 30, 2020 at 09:50:
arriers. However, if another CPU switches to/from the
target mm concurrently with membarrier(), it can cause that CPU not to receive
the
IPI when it really should issue a memory barrier."
For the rest of this patch:
Reviewed-by: Mathieu Desnoyers
Thanks!
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
e by the calling thread are visible
>> + * to the current task before the current task resumes. We could
>> + * probably optimize this away on most architectures, but by the
>> + * time we've already sent an IPI, the cost of the extra smp_mb()
>> + * is negligible.
>> + */
>> +smp_mb();
>> rseq_preempt(current);
>> }
>
> So I think this really isn't right.
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
or the current thread
will be conditionally executed after we have sent the IPIs, and unconditionally
when issuing smp_call_function* on self.
About the documentation of the membarrier scenario, I think it is redundant
with a documentation patch I already have sitting in -tip (scenario A):
https://git.kernel.org/tip/25595eb6aaa9fbb31330f1e0b400642694bc6574
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
tter put in x86 lazy tlb code.
Ideally yes this complexity should sit within the x86 architecture code
if only that architecture requires it.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
rier_worker_thread':
> param_test.c:1164: undefined reference to `rseq_offset_deref_addv'
> param_test.c:1164: undefined reference to `rseq_offset_deref_addv'
> collect2: error: ld returned 1 exit status
> make: *** [/selftests/rseq/param_test_benchmark] Error 1
>
&
__string( name, regmap_name(map))
> __string( status, status )
> __string( type, type)
> - __field(int,type)
> ),
>
> TP_fast_assign(
> --
> 2.25.1
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
p the original version.
It works for me. Bonus points if you can document in a comment that this
trick depends on the cdecl calling convention.
Thanks,
Mathieu
>
> This way Alexei can't complain about adding a check in the fast path of
> more than one callback attached.
>
> -- Steve
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
llees prototypes are compatible at runtime when the actual
calls happen, this all works fine.
Thanks,
Mathieu
>
> -- Steve
>
>
> } while ((++it_func_ptr)->func);\
> return 0; \
> } \
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Nov 16, 2020, at 5:10 PM, rostedt rost...@goodmis.org wrote:
> On Mon, 16 Nov 2020 16:34:41 -0500 (EST)
> Mathieu Desnoyers wrote:
[...]
>> I think you'll want a WRITE_ONCE(old[i].func, tp_stub_func) here, matched
>> with a READ_ONCE() in __DO_TRACE. This int
- On Nov 17, 2020, at 5:16 PM, rostedt rost...@goodmis.org wrote:
> On Tue, 17 Nov 2020 16:22:23 -0500 (EST)
> Mathieu Desnoyers wrote:
>
>> If we don't call the stub, then there is no point in having the stub at
>> all, and we should just compare to a constant
he stub, then there is no point in having the stub at
all, and we should just compare to a constant value, e.g. 0x1UL. As far
as I can recall, comparing with a small immediate constant is more efficient
than comparing with a loaded value on many architectures.
Thanks,
Mathieu
--
Mathieu Desnoy
- On Nov 17, 2020, at 3:34 PM, rostedt rost...@goodmis.org wrote:
> On Tue, 17 Nov 2020 14:47:20 -0500 (EST)
> Mathieu Desnoyers wrote:
>
>> There seems to be more effect on the data size: adding the "stub_func" field
>> in struct tracepoint adds 8320 b
- On Nov 17, 2020, at 2:21 PM, rostedt rost...@goodmis.org wrote:
> On Tue, 17 Nov 2020 14:15:10 -0500 (EST)
> Mathieu Desnoyers wrote:
>
>
>> diff --git a/include/linux/tracepoint-defs.h
>> b/include/linux/tracepoint-defs.h
>> index e7c2276be33e..e0351b
+ .funcs = NULL, \
+ .stub_func = __tracepoint_stub_func_##_name, }; \
__TRACEPOINT_ENTRY(_name); \
int __traceiter_##_name(void *__data, proto)\
{ \
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
bug_print_probes(*funcs);
> return old;
> @@ -300,6 +312,10 @@ static int tracepoint_remove_func(struct tracepoint *tp,
> return PTR_ERR(old);
> }
>
> + if (tp_funcs == old)
> + /* Failed allocating new tp_funcs, replaced func with stub */
> + return 0;
> +
> if (!tp_funcs) {
> /* Removed last function */
> if (tp->unregfunc && static_key_enabled(&tp->key))
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Nov 16, 2020, at 3:44 PM, rostedt rost...@goodmis.org wrote:
> On Mon, 16 Nov 2020 15:37:27 -0500 (EST)
> Mathieu Desnoyers wrote:
>> >
>> > Mathieu,
>> >
>> > Can't we do something that would still allow to unregister a probe even if
>
at much about using slightly more memory
than required after a failed reallocation due to ENOMEM. Perhaps the irq work
is not even needed. Chances are that the irq work would fail again and again if
it's in low memory conditions. So maybe it's better to just keep the tombstone
in place u
t those new features.
> .SH NAME
> membarrier \- issue memory barriers on a set of threads
> .SH SYNOPSIS
> @@ -30,7 +37,7 @@ membarrier \- issue memory barriers on a set of threads
> .PP
> .B #include
> .PP
> -.BI "int membarrier(int " cmd ", int " flags ");"
> +.BI "int membarrier(int " cmd ", unsigned int " flags ", int " cpu_id );
> .fi
> .PP
> .IR Note :
> --
> 2.28.0
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
The following commit has been merged into the sched/core branch of tip:
Commit-ID: 5bc78502322a5e4eef3f1b2a2813751dc6434143
Gitweb:
https://git.kernel.org/tip/5bc78502322a5e4eef3f1b2a2813751dc6434143
Author:Mathieu Desnoyers
AuthorDate:Tue, 20 Oct 2020 09:47:13 -04:00
The following commit has been merged into the sched/core branch of tip:
Commit-ID: 618758ed3a4f7d790414d020b362111748ebbf9f
Gitweb:
https://git.kernel.org/tip/618758ed3a4f7d790414d020b362111748ebbf9f
Author:Mathieu Desnoyers
AuthorDate:Tue, 20 Oct 2020 09:47:14 -04:00
The following commit has been merged into the sched/core branch of tip:
Commit-ID: 25595eb6aaa9fbb31330f1e0b400642694bc6574
Gitweb:
https://git.kernel.org/tip/25595eb6aaa9fbb31330f1e0b400642694bc6574
Author:Mathieu Desnoyers
AuthorDate:Tue, 20 Oct 2020 09:47:15 -04:00
- On Oct 26, 2020, at 4:53 PM, paulmck paul...@kernel.org wrote:
> On Mon, Oct 26, 2020 at 03:58:11PM -0400, Mathieu Desnoyers wrote:
>> - On Oct 22, 2020, at 6:30 PM, paulmck paul...@kernel.org wrote:
>>
>> > The current code can lose RCU callbacks at
- On Oct 26, 2020, at 4:44 PM, rostedt rost...@goodmis.org wrote:
> On Mon, 26 Oct 2020 10:28:07 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
>> I agree with Peter. Removing the trace_.*_rcuidle weirdness from the
>> tracepoint
>> API and fixing all callers to ensur
more descriptive
?
(a "faultable" tracepoint sounds weird though)
Thanks,
Mathieu
>
>> +rcu_read_lock_trace(); \
>> +} else {\
>> + /* keep srcu and sched-rcu usage consistent */ \
>> +preempt_disable_notrace(); \
> > + } \
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
merge in liburcu master, stable-0.12, and
stable-2.11.
Out of curiosity, which test is hanging ? Is it a test which is part of the
liburcu
tree or some out-of-tree test ? I wonder why we did not catch it in our CI [1].
Thanks,
Mathieu
[1] https://ci.lttng.org/view/Liburcu/
>
> Signed
called from a sleepable tracepoint), but have a
truncation behavior when called from non-sleepable context. This can actually
be done by looking at the new "TRACEPOINT_MAYSLEEP" tp flag. Passing that
tp_flags to code shared between sleepable and non-sleepable probes would allow
the callee to know whether it can take a page fault or not.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Oct 26, 2020, at 4:20 AM, Peter Zijlstra pet...@infradead.org wrote:
> On Fri, Oct 23, 2020 at 05:13:59PM -0400, Joel Fernandes wrote:
>> On Fri, Oct 23, 2020 at 03:53:52PM -0400, Michael Jeanson wrote:
>> > From: Mathieu Desnoyers
>> >
>> > Consider
- On Oct 23, 2020, at 1:37 AM, Xing Zhengjun zhengjun.x...@linux.intel.com
wrote:
> On 10/22/2020 9:19 PM, Mathieu Desnoyers wrote:
>> - On Oct 21, 2020, at 9:54 PM, Xing Zhengjun
>> zhengjun.x...@linux.intel.com
>> wrote:
>> [...]
>>> In fac
101 - 200 of 2883 matches
Mail list logo
