(-Wunused-parameter)
* fix: shadowed local variable (-Wshadow)
* cleanup: all functions have declarations (-Wmissing-prototypes)
* Import libtap from babeltrace
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
___
lttng-dev
registration
of events internally fails within LTTng-modules, for example in case of
out-of-memory error.
As always, feedback is welcome!
Thanks,
Mathieu
Project website: https://lttng.org
Documentation: https://lttng.org/docs
Download link: https://lttng.org/download
--
Mathieu Desnoyers
EfficiOS Inc
nch to stable-2.13
* Fix: add extern "C" to two header files
Project website: https://lttng.org
Documentation: https://lttng.org/docs
Download link: https://lttng.org/download
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
lled
application), just skipping this sub-buffer
will not allow applications to continue using this buffer for tracing until it
is destroyed.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
___
lttng-dev mailing list
l
eturned 0 at line 238 ($consume_old:0x86c400000, $commint_count:0x86c0,
> $write_offset:0x86d40).
> Buffer type: per UID
> Channels:
> -
> - channel0: [enabled]
> Attributes:
> overwrite mode: 0
> subbufers size: 1048576
> number of subbufers: 16
> switch timer interval: 2000
> read timer interval: 6000
> trace file count: 80
> trace file size (bytes): 2097152
> output: mmap()
> PS: Lttng version is 2.7(I know it is an very old version:) )
> Do you have any ideas about this problem? Thanks in advance
> Thanks a lot
> zhenyu.ren
> ___
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
;) - 1U)
>
> #include "trace_mytracepoints.h"
> ___
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
izing
away
unreachable calls.
If you really intend on using "-Og" on arm32, trying building with
"-DUATOMIC_NO_LINK_ERROR".
It should take care of making sure to generate an illegal instruction rather
than rely on the linker
error.
Thanks,
Mathieu
> T
other
> defect which might affect any computer or system into which they are received
> and opened, it is the responsibility of the recipient to ensure that they are
> virus free and no responsibility is accepted by disguise for any loss or
> damage
> from receipt or use thereof.
> _
t;x86/kvm: Use generic xfer
> to guest work function"), where TIF_NOTIFY_RESUME would be cleared by KVM
> without updating rseq, leading to a stale CPU ID and other badness.
>
> Signed-off-by: Sean Christopherson
Thanks!
Acked-by: Mathieu Desnoyers
> ---
> tools/testing/self
- On Aug 27, 2021, at 7:23 PM, Sean Christopherson sea...@google.com wrote:
> On Fri, Aug 27, 2021, Mathieu Desnoyers wrote:
[...]
>> Does it reproduce if we randomize the delay to have it picked randomly from
>> 0us
>> to 100us (with 1us step) ? It would remo
- On Aug 26, 2021, at 7:54 PM, Sean Christopherson sea...@google.com wrote:
> On Thu, Aug 26, 2021, Mathieu Desnoyers wrote:
>> - On Aug 25, 2021, at 8:51 PM, Sean Christopherson sea...@google.com
>> wrote:
>> >> >> + r = sched_s
- On Aug 25, 2021, at 8:51 PM, Sean Christopherson sea...@google.com wrote:
> On Mon, Aug 23, 2021, Mathieu Desnoyers wrote:
>> [ re-send to Darren Hart ]
>>
>> - On Aug 23, 2021, at 11:18 AM, Mathieu Desnoyers
>> mathieu.desnoy...@efficios.com wrote:
>>
[ re-send to Darren Hart ]
- On Aug 23, 2021, at 11:18 AM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Aug 20, 2021, at 6:50 PM, Sean Christopherson sea...@google.com
> wrote:
>
>> Add a test to verify an rseq's CPU ID is updated correctly if the task
*/
> + snapshot = atomic_read(_cnt) & ~1;
> + smp_rmb();
> + cpu = sched_getcpu();
> + rseq_cpu = READ_ONCE(__rseq.cpu_id);
> + smp_rmb();
> + } while (snapshot != atomic_r
g TIF_NOTIFY_RESUME without informing rseq can lead to segfaults
> and other badness in userspace VMMs that use rseq in combination with KVM,
> e.g. due to the CPU ID being stale after task migration.
Acked-by: Mathieu Desnoyers
>
> Fixes: 72c3c0fe54a3 ("x86/kvm: Use generic xfer to gues
- On Aug 19, 2021, at 7:48 PM, Sean Christopherson sea...@google.com wrote:
> On Thu, Aug 19, 2021, Mathieu Desnoyers wrote:
>> - On Aug 17, 2021, at 8:12 PM, Sean Christopherson sea...@google.com
>> wrote:
>> > @@ -250,7 +250,7 @@ static int rseq_ip_fi
- On Aug 19, 2021, at 7:33 PM, Sean Christopherson sea...@google.com wrote:
> On Thu, Aug 19, 2021, Mathieu Desnoyers wrote:
>> - On Aug 17, 2021, at 8:12 PM, Sean Christopherson sea...@google.com
>> wrote:
>>
>> > Add a test to verify an rseq's CPU ID is
== cpu || cpu != sched_getcpu(),
> + "rseq CPU = %d, sched CPU = %d\n", rseq_cpu, cpu);
> + }
> +
> + pthread_join(migration_thread, NULL);
> +
> + kvm_vm_free(vm);
> +
> + sys_rseq(RSEQ_FLAG_UNREGISTER);
> +
> + return 0;
> +}
> --
> 2.33.0.rc1.237.g0d66db33f3-goog
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
t relevant to do any fixup here, because it is nested in a ioctl system
call.
Effectively, this would preserve the SIGSEGV behavior when this ioctl is
erroneously called by user-space from a rseq critical section.
Thanks for looking into this !
Mathieu
> return clear_rseq_cs(t);
> ret = rseq_need_restart(t, rseq_cs.flags);
> if (ret <= 0)
> --
> 2.33.0.rc1.237.g0d66db33f3-goog
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
s which consume the
NOTIFY_RESUME without calling the rseq callback, which introduces issues.
Agreed.
Acked-by: Mathieu Desnoyers
>
> Signed-off-by: Sean Christopherson
> ---
> arch/arm/kernel/signal.c | 1 -
> arch/arm64/kernel/signal.c | 1 -
> arch/csky/kernel/signal.c| 4
-2.13.0.tar.bz2
GPG signatures:
https://lttng.org/files/lttng-tools/lttng-tools-2.13.0.tar.bz2.asc
https://lttng.org/files/lttng-ust/lttng-ust-2.13.0.tar.bz2.asc
https://lttng.org/files/lttng-modules/lttng-modules-2.13.0.tar.bz2.asc
--
Mathieu Desnoyers
EfficiOS Inc.
htt
kernel tracer
don't seem to be mentioned.
Thanks,
Mathieu
> ___
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
_
quot;, which
is faster, but
requires that preemption (or migration) be disabled between the
"smp_processor_id()" and writes to
the ring buffer per-cpu data structures.
Thanks,
Mathieu
> Thanks
> zhenyu.ren
> _______
> lttng-dev
- On Jun 18, 2021, at 3:58 PM, Andy Lutomirski l...@kernel.org wrote:
> On Fri, Jun 18, 2021, at 9:31 AM, Mathieu Desnoyers wrote:
>> - On Jun 17, 2021, at 8:12 PM, Andy Lutomirski l...@kernel.org wrote:
>>
>> > On 6/17/21 7:47 AM, Mathieu Desnoyers wrote:
>&g
;sync" : : : "memory")
So the original motivation here was to skip a "sync" instruction whenever
switching between threads which are part of the same process. But based on
recent discussions, I suspect my implementation may be inaccurately doing
so though.
Thank
probably something we'll want to fix right away before we release 2.13
final.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
- On Jun 17, 2021, at 8:12 PM, Andy Lutomirski l...@kernel.org wrote:
> On 6/17/21 7:47 AM, Mathieu Desnoyers wrote:
>
>> Please change back this #ifndef / #else / #endif within function for
>>
>> if (!IS_ENABLED(CONFIG_ARCH_HAS_MEMBARRIER_SYNC_COR
h and the CPU's cache type.
> +#
> +# On powerpc, a program can use MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE
> +# similarly to arm64. It would be nice if the powerpc maintainers could
> +# add a more clear explanantion.
We should document the requirements on ARMv7 as well.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
xing up preprocessor and code logic makes it more readable.
Thanks,
Mathieu
> } else if (flags == MEMBARRIER_FLAG_RSEQ) {
> if (!IS_ENABLED(CONFIG_RSEQ))
> return -EINVAL;
> --
> 2.31.1
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
a
smaller example program and change the custom trace format source to "ctf.fs" ?
Or anything else ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.ltt
some methods ?
Did you follow this section of the documentation ?
https://lttng.org/docs/#doc-instrumenting-32-bit-app-on-64-bit-system
Thanks,
Mathieu
> Regards,
> _______
> lttng-dev mailing list
ent_state() READ_ONCE(current->state)
Why use a macro rather than a static inline here ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lis
t,
> -_event,
> -NULL);
> + perf_iterate_sb(perf_event_switch_output, _event, NULL);
> }
There is a lot of code cleanup going on here which does not seem to belong
to a "Fix" patch.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.ef
- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -4869,7 +4869,7 @@ static void kvm_sched_out(struct preempt
> {
> struct kvm_vcpu *vcpu = preempt_notifier_to_vcpu(pn);
>
> - if (current->state == TASK_RUNNING) {
> + if (current->
\
> + WRITE_ONCE(current->__state, (state_value));\
> } while (0)
Why not introduce set_task_state(p) and get_task_state(p) rather than sprinkle
READ_ONCE() and WRITE_ONCE() all over the kernel ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
hich bumps the
library soname major number.
Thanks,
Mathieu
Project website: http://liburcu.org
Git repository: git://git.liburcu.org/urcu.git
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.lttng
\
> + WRITE_ONCE(current->__state, (state_value));\
> } while (0)
Why not introduce set_task_state(p) and get_task_state(p) rather than sprinkle
READ_ONCE() and WRITE_ONCE() all over the kernel ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
t,
> -_event,
> -NULL);
> + perf_iterate_sb(perf_event_switch_output, _event, NULL);
> }
There is a lot of code cleanup going on here which does not seem to belong
to a "Fix" patch.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.ef
ent_state() READ_ONCE(current->state)
Why use a macro rather than a static inline here ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -4869,7 +4869,7 @@ static void kvm_sched_out(struct preempt
> {
> struct kvm_vcpu *vcpu = preempt_notifier_to_vcpu(pn);
>
> - if (current->state == TASK_RUNNING) {
> + if (current->on_rq) {
> W
cover the entire function with a single read-side critical section.
[ Applies to stable-2.12 and possibly prior versions. Does _not_ apply
to stable-2.13+. ]
Signed-off-by: Mathieu Desnoyers
Change-Id: I5b20c229a5df22d22ecfdc64dbbb87ee118649d2
---
src/bin/lttng-sessiond/cmd.c | 4
1 file
- On May 20, 2021, at 1:43 PM, Norbert Lange nolang...@gmail.com wrote:
> Am Do., 20. Mai 2021 um 19:18 Uhr schrieb Mathieu Desnoyers
> :
>>
>>
>>
>> - On May 20, 2021, at 12:51 PM, Norbert Lange nolang...@gmail.com wrote:
>>
>> > Am D
- On May 20, 2021, at 12:51 PM, Norbert Lange nolang...@gmail.com wrote:
> Am Do., 20. Mai 2021 um 18:25 Uhr schrieb Mathieu Desnoyers
> :
>>
>> - On May 20, 2021, at 11:54 AM, Norbert Lange nolang...@gmail.com wrote:
>> [...]
>>
>> >> Wh
ng the tracelog/tracef providers is not an intended use-case.
I'd very much prefer if we move their implementation to
liblttng-ust-tracepoint.so.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
- On May 20, 2021, at 10:57 AM, Norbert Lange nolang...@gmail.com wrote:
> Am Do., 20. Mai 2021 um 16:19 Uhr schrieb Mathieu Desnoyers
> :
>>
>> - On May 20, 2021, at 8:18 AM, lttng-dev lttng-dev@lists.lttng.org wrote:
>>
>> > Instead of creating functio
- On May 20, 2021, at 9:56 AM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On May 20, 2021, at 9:54 AM, lttng-dev lttng-...@lists.lttng.org wrote:
>
>> - On May 20, 2021, at 5:11 AM, lttng-dev lttng-...@lists.lttng.org wrote:
>>
>>> Am Do.
- On May 20, 2021, at 9:56 AM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On May 20, 2021, at 9:54 AM, lttng-dev lttng-dev@lists.lttng.org wrote:
>
>> - On May 20, 2021, at 5:11 AM, lttng-dev lttng-dev@lists.lttng.org wrote:
>>
>>> Am Do.
vasprintf(, fmt, ap);
> +
> + /* len does not include the final \0 */
> + if (len >= 0)
> + goto end;
> + (*callback)(source->file, source->line, source->func, msg, len,
> + LTTNG_UST_CALLER_IP());
> + free(msg);
> +end:
>
- On May 20, 2021, at 9:42 AM, Norbert Lange nolang...@gmail.com wrote:
> Am Do., 20. Mai 2021 um 15:28 Uhr schrieb Mathieu Desnoyers
> :
>>
>> - On May 20, 2021, at 8:46 AM, Norbert Lange nolang...@gmail.com wrote:
>>
>> > Am Mi., 19. Mai 2021 um 20
gt;
> https://lwn.net/Articles/831540/ The seqcount latch lock type
>
> It basically keeps two copies of the clock data structures, so the
> read-side never has to loop waiting for the updater: it simply gets
> redirected to the "stable" copy of the data.
>
> The trade-of
trade-off here is that with the latch lock used for clocks, a
reader may observe time going slightly backwards between two clock
reads when reading while specific clock rate adjustments are made
by an updater. The clock user needs to be aware of this.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS In
right ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
- On May 20, 2021, at 8:46 AM, Norbert Lange nolang...@gmail.com wrote:
> Am Mi., 19. Mai 2021 um 20:52 Uhr schrieb Mathieu Desnoyers
> :
>>
>> - On May 19, 2021, at 8:11 AM, lttng-dev lttng-dev@lists.lttng.org wrote:
>>
>> > Hello,
>> >
>&g
LTTNG_UST_CALLER_IP()); \
> - free(msg); \
> end: \
> + if (msg != local_buf) \
> + free(msg); \
> va_end(ap); \
> }
>
> --
> 2.30.2
>
> ___
simply initialize
them all.
Thanks,
Mathieu
>
> regards, Norbert
> ___
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
_
- On May 14, 2021, at 3:52 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> Hi,
>
> The 2.11.9 and 2.12.6 releases of the LTTng kernel tracer are the latest bug
> fix
> releases
> of the 2.11 and 2.12 stable branches of the LTTng modules project.
>
> T
and user strcpy), the strlen
will fail on access ok when calculating the space to reserve, which will
match what happens on strcpy.
Thanks,
Mathieu
Project website: https://lttng.org
Documentation: https://lttng.org/docs
Download link: https://lttng.org/download
--
Mathieu Desnoyers
EfficiOS
branches, especially given the major rework done in the upcoming 2.13 version.
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
- On May 5, 2021, at 3:54 AM, Martin Wilck mwi...@suse.com wrote:
> On Fri, 2021-04-30 at 14:41 -0400, Mathieu Desnoyers wrote:
>> - On Apr 29, 2021, at 9:49 AM, lttng-dev
>> lttng-dev@lists.lttng.org wrote:
>>
>> > In multipath-tools, we are using a c
should take care of not leaking data
structures
in the common case where call_rcu does not enqueue further callbacks.
Thoughts ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
.13.0-rc1.tar.bz2
GPG signatures:
https://lttng.org/files/lttng-tools/lttng-tools-2.13.0-rc1.tar.bz2.asc
https://lttng.org/files/lttng-ust/lttng-ust-2.13.0-rc1.tar.bz2.asc
https://lttng.org/files/lttng-modules/lttng-modules-2.13.0-rc1.tar.bz2.asc
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios
- 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
o 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
- On Apr 19, 2021, at 11:41 AM, Duncan Sands baldr...@free.fr wrote:
> Hi Mathieu,
>
> On 4/19/21 5:31 PM, Mathieu Desnoyers wrote:
>> - On Apr 19, 2021, at 5:41 AM, Duncan Sands baldr...@free.fr wrote:
>>
>>
>>>
>>>
e is the resulting commit for review on gerrit:
https://review.lttng.org/c/userspace-rcu/+/5455 Fix: use __atomic_load() rather
than atomic load explicit [NEW]
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
___
lttng-dev ma
- On Apr 16, 2021, at 11:22 AM, lttng-dev lttng-dev@lists.lttng.org wrote:
> Hi Mathieu,
>
Hi Duncan,
> On 4/16/21 4:52 PM, Mathieu Desnoyers via lttng-dev wrote:
>> Hi Paul, Will, Peter,
>>
>> I noticed in this discussion https://lkml.org/lkml/2021/4/16/118 t
# define rcu_dereference(x) CMM_LOAD_SHARED(x)
# endif
# endif
#endif
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
# 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
- 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
w 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
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-
w 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
der of callback execution from FIFO to LIFO if it leads
to
performance improvements due to better cache locality.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://list
ine();
in that specific order within the call-rcu worker thread. Note that the qsbr
state
of the call-rcu worker thread is "online" when it invokes the callbacks, so
each callback
should make sure that state is back to "online" before it returns control back
to its call
n sleeping.
So yes, you should be able to have a RCU read-side from within a call-rcu worker
thread, and it's OK to assume you can do a RCU traversal with the QSBR urcu
flavor
from a call-rcu worker thread as well.
Thanks,
Mathieu
>
> Jeff
>
>
>
> Sent from my iPhone
>
>
ation is needed!
When you say "the reclamation thread for the policy", do you refer to a call-rcu
worker thread ?
Also, you are aware that RCU read-side lock/unlock are effectively no-ops for
QSBR rcu, right ?
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 mi
- 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
>
-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: Peter Zijlstra
> Cc:
#endif
>
> 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
h.
>
> 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
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
G */
>> "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 )
>> : "memory" , &quo
_pid_tracker ust 0 "${EVENT_NAME}"
> - test_event_pid_track_untrack ust 0 "${EVENT_NAME}"
The approach looks good to me, thanks!
Acked-by: Mathieu Desnoyers
>
> Signed-off-by: Anders Wallin
> ---
> .../tools/tracker/test_event_tracker | 18 +-
> 1 file change
uot; or in "utils.sh"
Actually, this helper already exists in utils.sh:
validate_trace_session_ust_empty (), which
internally uses validate_directory_empty (). As you point out, we should use
validate_trace_session_ust_empty for the validation of those test cases which
populate no
trace whatsoever.
ion stopped."
> - rm "$BEFORE_LAST_PATH"
> - rm "$AFTER_FIRST_PATH"
> + rm "$BEFORE_FIRST_PATH"
> }
>
> function prepare_kernel_app
> --
> 2.31.1
>
> ___
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
}
> @@ -175,22 +238,28 @@ int main(int argc, char **argv)
> }
>
> if (before_exit_file_path_touch) {
> + TRACE("before_exit_file_path_touch(%i): %s\n",
> + i, before_exit_file_path_touch);
> ret = create_file(bef
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,
> Mingyi
--
Mat
ad exit, and unregister qsbr that way,
Hoping this help!
Best regards,
Mathieu
>
> Jeff
> ___
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
--
Mathieu Desnoyer
CI workers.
>
> We need to add proper rendez-vous based synchronization to the test if some
> is missing.
>
> Adding Jérémie in CC.
And then I read on the rest of the email thread... so it's being taken care of,
good! :)
Thanks,
Mathieu
>
> Thanks,
>
> Mathieu
>
>
>> }
>>
>> functi
ons on the CI workers.
We need to add proper rendez-vous based synchronization to the test if some
is missing.
Adding Jérémie in CC.
Thanks,
Mathieu
> }
>
> function trace_ust_app
> --
> 2.31.1
>
> ___
> lttng-dev mailing list
> l
- 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 userspac
ddress 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
Reviewed-by
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,
>> > +
401 - 500 of 11947 matches
Mail list logo
