://lore.kernel.org/r/20200302192811.n6o5645rsib44vco@localhost [1]
Link:
https://lore.kernel.org/r/20200409193543.18115-1-mathieu.desnoy...@efficios.com
[2]
Link: https://lwn.net/Articles/817988/
Signed-off-by: Mathieu Desnoyers
CC: Thomas Gleixner
CC: Will Deacon
CC: a...@linux-foundation.org
CC
://lore.kernel.org/r/20200302192811.n6o5645rsib44vco@localhost [1]
Link:
https://lore.kernel.org/r/20200409193543.18115-1-mathieu.desnoy...@efficios.com
[2]
Link: https://lwn.net/Articles/817988/
Signed-off-by: Mathieu Desnoyers
CC: Thomas Gleixner
CC: Will Deacon
CC: a...@linux-foundation.org
CC
- On May 4, 2020, at 11:31 AM, Joerg Roedel jroe...@suse.de wrote:
> On Mon, May 04, 2020 at 11:28:46AM -0400, Mathieu Desnoyers wrote:
>> - On May 4, 2020, at 11:12 AM, Joerg Roedel jroe...@suse.de wrote:
>> Placing this here is inefficient. It syncs mappings
hould be moved to:
static void pcpu_mem_free(void *ptr)
{
/* Add comments here... */
if (is_vmalloc_addr(ptr))
vmalloc_sync_unmappings();
kvfree(ptr);
}
So it is only called before the underlying vmalloc'd chunk is freed, rather than
at each and every percpu free.
Thanks,
Mathieu
> +
> spin_unlock_irqrestore(_lock, flags);
>
> if (need_balance)
> --
> 2.12.3
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Apr 30, 2020, at 10:39 PM, rostedt rost...@goodmis.org wrote:
> On Thu, 30 Apr 2020 22:26:55 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
>> - On Apr 30, 2020, at 9:13 PM, rostedt rost...@goodmis.org wrote:
>>
>> > [ Joerg, sending again this time not jus
- On May 1, 2020, at 12:20 AM, rostedt rost...@goodmis.org wrote:
> On Thu, 30 Apr 2020 22:26:55 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
>> The tracers just have to make sure they perform their vmalloc'd memory
>> allocation before registering the tracepoint whi
tion.
This approach is not new: register_die_notifier() does exactly that today.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
When available, use the cpu_id field from __rseq_abi on Linux to
implement sched_getcpu(). Fall-back on the vgetcpu vDSO if unavailable.
Benchmarks:
x86-64: Intel E5-2630 v3@2.40GHz, 16-core, hyperthreading
glibc sched_getcpu(): 13.7 ns (baseline)
glibc sched_getcpu() using
ch is unexpected.
- Abort libc in rseq_register_current_thread () on all
errno except EPERM (seccomp), EACCES (seccomp), and ENOSYS
(not implemented).
Signed-off-by: Mathieu Desnoyers
CC: Carlos O'Donell
CC: Florian Weimer
CC: Joseph Myers
CC: Szabolcs Nagy
CC: Thomas Gleixner
CC: Ben Mau
fatal ("glibc fatal error: "
"rseq already initialized for this thread\n");
?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Apr 30, 2020, at 12:36 PM, Florian Weimer fwei...@redhat.com wrote:
> * Mathieu Desnoyers:
>
[...]
>
>>>> + if (__rseq_abi.cpu_id == RSEQ_CPU_ID_REGISTRATION_FAILED)
>>>> +return;
>>>> + ret = INTERNAL_SYSCALL
- On Apr 30, 2020, at 12:30 PM, rostedt rost...@goodmis.org wrote:
> On Thu, 30 Apr 2020 12:18:22 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
>> - On Apr 30, 2020, at 12:16 PM, rostedt rost...@goodmis.org wrote:
>>
>> > On Thu, 30 Apr 2020 11:20:15 -040
- On Apr 30, 2020, at 12:16 PM, rostedt rost...@goodmis.org wrote:
> On Thu, 30 Apr 2020 11:20:15 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
>> > The right fix is to call vmalloc_sync_mappings() right after allocating
>> > tracing or perf buffers via v[zm]alloc()
dr; It's not an issue with the vmalloc, it's an issue with per_cpu
> allocations!
Did I mention that alloc_percpu uses:
static void *pcpu_mem_zalloc(size_t size, gfp_t gfp)
{
if (WARN_ON_ONCE(!slab_is_available()))
return NULL;
if (size <= PAGE_SIZE)
return kzalloc(size, gfp);
else
return __vmalloc(size, gfp | __GFP_ZERO, PAGE_KERNEL);
}
So yeah, it's vmalloc'd memory when size > PAGE_SIZE.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Apr 30, 2020, at 8:20 AM, Florian Weimer fwei...@redhat.com wrote:
> * Mathieu Desnoyers:
>
>> diff --git a/NEWS b/NEWS
>> index 0e627b3405..0b85a02c12 100644
>> --- a/NEWS
>> +++ b/NEWS
>> @@ -18,6 +18,16 @@ Major new features:
>> * The GN
) {
if (eflags & EVENT_FILE_FL_TRIGGER_MODE)
event_triggers_call(file, NULL, NULL);
if (eflags & EVENT_FILE_FL_SOFT_DISABLED)
return true;
if (eflags & EVENT_FILE_FL_PID_FILTER)
return trace_event_ignore_this_pid(file);
}
return false;
}
Thanks,
Mathieu
>
> Regards,
>
> Joerg
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
ween* allocation
and publishing the pointer for instrumentation, it's fine.
I'll let Steven decide on which approach works best for him.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
text switch, next->pid is checked against this bitmask, and
> if it is set, it means we should allow this process to be traced.
>
> This mask should only be accessed at sched_switch time, not at other times.
> And it may read any possible page in that mask depending on the process id
- On Apr 28, 2020, at 2:51 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Apr 28, 2020, at 2:40 PM, Philippe Proulx ppro...@efficios.com wrote:
>
>> - Original Message -
>>> From: "Mathieu Desnoyers"
>>>
Signed-off-by: Mathieu Desnoyers
---
common-trace-format-specification.md | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/common-trace-format-specification.md
b/common-trace-format-specification.md
index 5732e92..8a3a745 100644
--- a/common-trace-format
Signed-off-by: Mathieu Desnoyers
---
common-trace-format-specification.md | 3 +++
1 file changed, 3 insertions(+)
diff --git a/common-trace-format-specification.md
b/common-trace-format-specification.md
index fd49e59..d6d196c 100644
--- a/common-trace-format-specification.md
+++ b/common
Signed-off-by: Mathieu Desnoyers
---
common-trace-format-specification.md | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/common-trace-format-specification.md
b/common-trace-format-specification.md
index 55d0601..5732e92 100644
--- a/common-trace-format
Signed-off-by: Mathieu Desnoyers
---
common-trace-format-specification.md | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/common-trace-format-specification.md
b/common-trace-format-specification.md
index d6d196c..55d0601 100644
--- a/common-trace-format
- On Apr 28, 2020, at 2:42 PM, Philippe Proulx ppro...@efficios.com wrote:
> - Original Message -
>> From: "Mathieu Desnoyers"
>> To: "gbastien+lttng" , "Matthew Khouzam"
>> ,
>> diamon-disc...@linuxfoundation.org, ppro..
- On Apr 28, 2020, at 2:40 PM, Philippe Proulx ppro...@efficios.com wrote:
> - Original Message -
>> From: "Mathieu Desnoyers"
>> To: "gbastien+lttng" , "Matthew Khouzam"
>> ,
>> diamon-disc...@linuxfoundation.org, ppro..
When available, use the cpu_id field from __rseq_abi on Linux to
implement sched_getcpu(). Fall-back on the vgetcpu vDSO if unavailable.
Benchmarks:
x86-64: Intel E5-2630 v3@2.40GHz, 16-core, hyperthreading
glibc sched_getcpu(): 13.7 ns (baseline)
glibc sched_getcpu() using
void.
- Coding style fixes.
- sys/rseq.h: use "32" for alignment.
- Change http:// for https:// in comments.
- Add const struct rseq_cs * field to rseq_cs union.
Signed-off-by: Mathieu Desnoyers
CC: Carlos O'Donell
CC: Florian Weimer
CC: Joseph Myers
CC: Szabolcs Nagy
CC: Thoma
- On Apr 28, 2020, at 8:54 AM, Florian Weimer f...@deneb.enyo.de wrote:
> * Mathieu Desnoyers:
>
>> - On Apr 28, 2020, at 8:35 AM, Florian Weimer f...@deneb.enyo.de wrote:
>>
>>> * Mathieu Desnoyers:
>>>
>>>> One issue I'm currently fac
- On Apr 28, 2020, at 8:33 AM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Apr 28, 2020, at 8:02 AM, Florian Weimer f...@deneb.enyo.de wrote:
>
[...]
>>
>>> x32 should not be an issue as explained above, so I'm very open to
>>> add t
- On Apr 28, 2020, at 8:35 AM, Florian Weimer f...@deneb.enyo.de wrote:
> * Mathieu Desnoyers:
>
>> One issue I'm currently facing when running "make check": because
>> nptl/tst-rseq-nptl.c uses pthread_cancel(), I run into an Abort
>> with:
>
- On Apr 28, 2020, at 8:02 AM, Florian Weimer f...@deneb.enyo.de wrote:
> * Mathieu Desnoyers:
>
>>>>>> +/* struct rseq is aligned on 4 * 8 bytes to ensure it is always
>>>>>> + contained within a single cache-line.
>>>>>
- On Apr 23, 2020, at 6:51 PM, Jeremie Galarneau
jeremie.galarn...@efficios.com wrote:
> On Thu, 23 Apr 2020 at 16:52, Mathieu Desnoyers
> wrote:
>>
>> From: Geneviève Bastien
>>
>> Signed-off-by: Geneviève Bastien
>> Signed-off-by: Mathieu Desno
Signed-off-by: Mathieu Desnoyers
---
common-trace-format-specification.md | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/common-trace-format-specification.md
b/common-trace-format-specification.md
index f5fea51..53b70f4 100644
--- a/common-trace-format
are implementation-defined
Mathieu Desnoyers (2):
Clarify monotonicity requirement on timestamp begin
Clarify that timestamp begin/end need to be complete clock values
common-trace-format-specification.md | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
--
2.11.0
From: Geneviève Bastien
Signed-off-by: Geneviève Bastien
Signed-off-by: Mathieu Desnoyers
---
common-trace-format-specification.md | 3 +++
1 file changed, 3 insertions(+)
diff --git a/common-trace-format-specification.md
b/common-trace-format-specification.md
index fd49e59..f5fea51 100644
Signed-off-by: Mathieu Desnoyers
---
common-trace-format-specification.md | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/common-trace-format-specification.md
b/common-trace-format-specification.md
index 53b70f4..7681ce5 100644
--- a/common-trace-format
been a priority to fix this issue so far.
Thanks,
Mathieu
> --
> Regards,
> Sergei Dyshel
>
> On Wed, Apr 22, 2020 at 2:15 AM Mathieu Desnoyers
> wrote:
>>
>> - On Apr 21, 2020, at 5:37 PM, Sergei Dyshel qyron.priv...@gmail.com
>> wrote:
>>
>>
is possible.
liburcu-cds provides efficient data structures based on RCU and
lock-free algorithms. Those structures include hash tables, queues,
stacks, and doubly-linked lists.
Project website: http://liburcu.org
Git repository: git://git.liburcu.org/urcu.git
Enjoy!
Mathieu
--
Mathieu
"tracefile size". It was implemented at
the same time as the live mode for exactly the purpose you describe.
See https://lttng.org/docs/#doc-tracefile-rotation for more information.
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 much more
complex and require a very significant testing effort.
Considering that there are few compelling use-cases for using both
features together, and no customer have expressed interest in this,
it is not part of our roadmap.
Thanks,
Mathieu
--
Mathieu Desnoyer
://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.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
://lttng.org/docs
Download link: https://lttng.org/download
--
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
Tng filter interpreter when dealing with
floating point numbers loaded from lttng contexts.
Thanks,
Mathieu
Project website: https://lttng.org
Documentation: https://lttng.org/docs
Download link: https://lttng.org/download
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.ef
well use this time to
download and try the latest LTTng 2.12 release candidates.
Feedback is welcome!
Thanks, and please stay home,
Mathieu
Project website: https://lttng.org
Documentation: https://lttng.org/docs
Download link: https://lttng.org/download
[1] https://bugs.lttng.org/issues/1245
--
< [
> mailto:milian.wo...@kdab.com |
> milian.wo...@kdab.com ] > wrote:
>> On Donnerstag, 26. März 2020 20:41:17 CET Mathieu Desnoyers via lttng-dev
>> wrote:
>>> - On Mar 26, 2020, at 1:39 PM, lttng-dev < [
>> > mailto:lttng-dev@lists.lttng.org | lt
customers
showing interest in getting this done.
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
case TH_ICMP: {
> + ctf_align(uint32_t)
> + ctf_array_type(uint8_t,
> icmp_hdr(skb),
> + sizeof(struct
> icmphdr))
> +
sizeof(struct
> icmphdr))
> + break;
> + }
> + default:
> + /*
> + * For any other transport
> header type,
> + * there is nothing to do.
> + */
> + break;
> }
> - /*
> - * For any other transport header type,
> - * there is nothing to do.
> - */
> }
> )
> )
> --
> 2.17.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
/* Find the spot where to insert this index entry. */
> for (i = 0; i < index->entries->len; i++) {
> --
> 2.7.4
>
> _______
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
--
Ma
break;
> }
> - /*
> - * For any other transport header type,
> - * there is nothing to do.
> - */
> }
> )
> )
--
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
g with -fno-common is
enforced to prepare for the upcoming default behavior change
in gcc 10.
Please try it out, and as usual, feedback is welcome!
Thanks,
Mathieu
Project website: https://lttng.org
Documentation: https://lttng.org/docs
Download link: https://lttng.org/download
--
Mathie
29,32 @@
> #define TRACEPOINT_DEFINE
> #include "lttng-ust-tracef-provider.h"
>
> -void _lttng_ust_tracef(const char *fmt, ...)
> +static inline __attribute__((always_inline))
> +void __lttng_ust_vtracef(const char *fmt, va_list ap)
> {
>
- On Feb 26, 2020, at 4:14 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Feb 24, 2020, at 12:34 PM, Maxime Roussin-Belanger
> maxime.roussinbelan...@gmail.com wrote:
> [...]
>> diff --git a/liblttng-ust/tracef.c b/liblttng-ust/tracef.c
>> ind
RACE_ALERT)
> --
> 2.20.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
return;
> +}
> +
> +void _lttng_ust_tracef(const char *fmt, ...)
> +{
> + va_list ap;
> +
> + va_start(ap, fmt);
> + _lttng_ust_vtracef(fmt, ap);
> +
> va_end(ap);
> }
> --
> 2.20.1
>
> _______
> lttng-de
; 2 as well.
> + delay = atoi(argv[1]);
> +
> + fprintf(stderr, "Demo program starting.\n");
> +
> + sleep(delay);
> +
> + fprintf(stderr, "Tracing... ");
> +
> + for (i = 0; i < 5; i++) {
> +
sult of the generated binary (compiled with -O2) to see if
there is an additional call added for _lttng_ust_trace() compared to the prior
generated code ? I would hate to add an extra call indirection there.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
,
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
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng
configure XML man page header
> -ifdef::doctype-manpage[]
> -ifdef::backend-docbook[]
> -[header]
> -template::[header-declarations]
> -
> -
> -{mantitle}
> -{manvolnum}
> -LTTng
> -{lttng_version}
> -LTTng Manual
> -
> -
ine TRACEPOINT_DEFINE
> #include "lttng-ust-tracef-provider.h"
>
> -void _lttng_ust_tracef(const char *fmt, ...)
> +void _lttng_ust_vtracef(const char *fmt, va_list ap)
> {
> - va_list ap;
> char *msg;
> - int len;
> -
> - va_start(ap, fmt);
> - len = vasprintf(, fmt, ap);
> + const int len = vasprintf(, fmt, ap);
> /* len does not include the final \0 */
> if (len < 0)
> goto end;
> __tracepoint_cb_lttng_ust_tracef___event(msg, len,
> LTTNG_UST_CALLER_IP());
> free(msg);
> end:
> + return;
> +}
> +
> +void _lttng_ust_tracef(const char *fmt, ...)
> +{
> + va_list ap;
> +
> + va_start(ap, fmt);
> + _lttng_ust_vtracef(fmt, ap);
> +
> va_end(ap);
> }
> --
> 2.20.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
mtx_uaddr, umtx_uaddr2);
> +}
> +
> +static inline int futex_noasync(int32_t *uaddr, int op, int32_t val,
> + const struct timespec *timeout, int32_t *uaddr2, int32_t val3)
> +{
> + return futex_async(uaddr, op, val, timeout, uaddr2, val3);
> +}
> +
> #elif
quot;Add platform support to urcu/syscall-compat.h"
> --
> 2.25.0
>
> ___
> 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
_
.
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
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https
- On Jan 27, 2020, at 10:45 PM, paulmck paul...@kernel.org wrote:
> On Mon, Jan 27, 2020 at 10:38:05AM -0500, Mathieu Desnoyers wrote:
>> - On Jan 23, 2020, at 7:19 PM, lttng-dev lttng-dev@lists.lttng.org wrote:
>>
>> > Hi,
>> >
>> > I re
> 2.25.0
>
> _______
> 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
backends and all completed successfully.
>
> I think that the other two usages of futex_async are also a little
> suspicious, but I didn't look too closely.
>
> Thanks,
> Alex.
> ___
> lttng-dev mailing list
> lttng-
- On Jan 6, 2020, at 8:58 PM, Benjamin Poirier benjamin.poir...@gmail.com
wrote:
> On 2020/01/06 09:39, Mathieu Desnoyers wrote:
>> - On Jan 6, 2020, at 12:19 AM, Benjamin Poirier
>> benjamin.poir...@gmail.com
>> wrote:
>>
>> > INADDR_ANY is 0.0.0
ompletely, the trace can be processed by
> any tool that can process an LTTng trace located on the local
> --
> 2.25.0.rc0
>
> ___
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> https://list
FYI, a similar approach should be taken for lttng-ust 2.12, as
pushed into the master branch:
commit 677423ebf26cc17916bddd0334b1a9f7614035c9
Author: Mathieu Desnoyers
Date: Fri Dec 20 10:49:20 2019 -0500
Bump LTTNG_UST_ABI_MINOR_VERSION to 1
Increment the minor version of lttng
gt; #define LTTNG_MODULES_ABI_MAJOR_VERSION 2
> -#define LTTNG_MODULES_ABI_MINOR_VERSION 4
> +#define LTTNG_MODULES_ABI_MINOR_VERSION 5
>
> #define LTTNG_KERNEL_SYM_NAME_LEN 256
> #define LTTNG_KERNEL_SESSION_NA
ession->vgid_tracker.p); \
> if (__lf && likely(!lttng_id_tracker_lookup(__lf, \
> - from_kgid(current_user_ns(), current_gid()\
> + lttng_current_vgid( \
> return;
apper/mm.h
> index 672855b..405248a 100644
> --- a/wrapper/mm.h
> +++ b/wrapper/mm.h
> @@ -62,7 +62,7 @@ void wrapper_set_current_oom_origin(void)
> }
>
> static inline
> -void wrapper_clear_current_oom_origin()
> +void wrapper_clear_current_oom_origin(void)
> {
>
_desc transport_header_type = {
> @@ -510,15 +633,32 @@ LTTNG_TRACEPOINT_EVENT_CLASS(net_dev_template,
> ctf_integer_type(unsigned char, th_type)
> /* Copy the transport header. */
> - if (th_type == TH_TCP) {
> + switch (th_type) {
> + case TH_TCP: {
> ctf_align(uint32_t)
> ctf_array_type(uint8_t, tcp_hdr(skb),
> sizeof(struct tcphdr))
> + break;
> + }
> + case TH_UDP: {
> + ctf_align(uint32_t)
> + ctf_array_type(uint8_t, udp_hdr(skb),
> + sizeof(struct udphdr))
> + break;
> + }
> + case TH_ICMP: {
> + ctf_align(uint32_t)
> + ctf_array_type(uint8_t, icmp_hdr(skb),
> + sizeof(struct udphdr))
> + break;
> + }
> + default:
> + /*
> + * For any other transport header type,
> + * there is nothing to do.
> + */
> + break;
> }
> - /*
> - * For any other transport header type,
> - * there is nothing to do.
> - */
> }
> )
> )
> --
> 2.17.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
Merged into lttng-modules master, 2.11, 2.10 branches, thanks!
I added the following commits on top, taking care of another OOPS
that was missed by this patch, and adapting the type of the field
to a signed integer:
commit b6903d57e4c3234ec5b1c7f72e232023cdee0fab
Author: Mathieu Desnoyers
Date
need to
>pass it down the callchain.
>
> Signed-off-by: Michael Jeanson
>Signed-off-by: Mathieu Desnoyers
>
> Signed-off-by: Michael Jeanson
> ---
> instrumentation/events/lttng-module/btrfs.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
# stgit generated dirs
> patches-*
> @@ -76,8 +117,35 @@ GRTAGS
> GSYMS
> GTAGS
>
> +# id-utils files
> +ID
> +
> *.orig
> *~
> \#*#
>
> +#
> +# Leavings from module signing
> +#
> +extra_certificates
> +signing_key.pem
> +signing_key.priv
> +sign
- On Dec 6, 2019, at 3:51 PM, Yuxin Ren wrote:
> On Fri, Dec 6, 2019 at 5:49 AM Mathieu Desnoyers < [
> mailto:mathieu.desnoy...@efficios.com | mathieu.desnoy...@efficios.com ] >
> wrote:
>> - On Dec 5, 2019, at 8:17 PM, Yuxin Ren < [ mailto:r...@gwmail.gwu.edu
_
> 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
Attaching to a stream hung up before providing any trace packet
causes ctf_open_mmap_stream_read() to return an error.
This kind of scenario can happen with the upcoming "lttng clear"
feature.
Signed-off-by: Mathieu Desnoyers
---
formats/ctf/ctf.c | 7 ++-
1 file changed, 6
When get_next_index sets the index position to EOF,
ctf_live_packet_seek() should in turn set the stream position to EOF
to propagate the hung up state.
Signed-off-by: Mathieu Desnoyers
---
formats/lttng-live/lttng-live-comm.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff
Missing context put in iterator init error path.
Signed-off-by: Mathieu Desnoyers
---
lib/iterator.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/lib/iterator.c b/lib/iterator.c
index 639a2d29..77093217 100644
--- a/lib/iterator.c
+++ b/lib/iterator.c
@@ -778,6 +778,8 @@ int
The trace collection should copy the trace clock object rather
than take a reference to the first trace's trace clock, because
it may be freed when the trace is removed (e.g. application going
away in per-pid live tracing).
Signed-off-by: Mathieu Desnoyers
---
lib/trace-collection.c | 21
Running babeltrace under valgrind with a test-cases doing per-pid
lttng tracing in live mode triggers this use-after-free in
get_next_index() when stream is hung up.
Signed-off-by: Mathieu Desnoyers
---
formats/lttng-live/lttng-live-comm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
This series of fixes comes from testing babeltrace 1.5 lttng-live
under valgrind with per-pid lttng buffers. This was done in the
context of testing of the "lttng clear" feature.
Thanks,
Mathieu
Mathieu Desnoyers (6):
Fix: lttng-live: use-after-free in get_next_index()
Fix: trace-
Signed-off-by: Mathieu Desnoyers
---
formats/lttng-live/lttng-live-plugin.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/formats/lttng-live/lttng-live-plugin.c
b/formats/lttng-live/lttng-live-plugin.c
index ed52a995..0bebdd89 100644
--- a/formats/lttng-live/lttng-live-plugin.c
+++ b
mendation?
> Regards
> Hai
> --
> 该邮件从移动设备发送
> --原始邮件--
> 发件人："Mathieu Desnoyers ";
> 发送时间：2019年11月20日(星期三) 晚上10:32
> 收件人："杨海" ;
> 抄送："lttng-dev ";
> 主题：Re: [lttng-dev] documentation about CTF event payload
> -
- On Nov 22, 2019, at 2:57 PM, Norbert Lange nolang...@gmail.com wrote:
> Am Fr., 22. Nov. 2019 um 20:00 Uhr schrieb Mathieu Desnoyers
> :
>>
>> - On Nov 22, 2019, at 12:44 PM, Norbert Lange nolang...@gmail.com wrote:
>>
>> > Am Fr., 22. Nov. 201
- On Nov 22, 2019, at 2:57 PM, Norbert Lange nolang...@gmail.com wrote:
> Am Fr., 22. Nov. 2019 um 20:00 Uhr schrieb Mathieu Desnoyers
> :
>>
>> - On Nov 22, 2019, at 12:44 PM, Norbert Lange nolang...@gmail.com wrote:
>>
>> > Am Fr., 22. Nov. 201
u want it figuring out you forget one config.
Indeed. I'm not sure what's the best way forward however.
Thanks,
Mathieu
>
> Thanks for the speedy support, Norbert
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
___
lttng-dev mailing list
that you counted clock-cycles for every operation
> ;)
Well it's just a new API that allows tweaking the state of a boolean which
controls
branches which are already there on the fast-path. ;)
> Not sure, maybe a separate lib for realtime is the better way. Having no
> option
> can be co
that you counted clock-cycles for every operation
> ;)
Well it's just a new API that allows tweaking the state of a boolean which
controls
branches which are already there on the fast-path. ;)
> Not sure, maybe a separate lib for realtime is the better way. Having no
> option
> can be co
- On Nov 22, 2019, at 12:44 PM, Norbert Lange nolang...@gmail.com wrote:
> Am Fr., 22. Nov. 2019 um 16:52 Uhr schrieb Jan Kiszka
> :
>>
>> On 22.11.19 16:42, Mathieu Desnoyers wrote:
[...]
>
>
>> >
>> > That's indeed a good point. I suspect memba
- On Nov 22, 2019, at 12:44 PM, Norbert Lange nolang...@gmail.com wrote:
> Am Fr., 22. Nov. 2019 um 16:52 Uhr schrieb Jan Kiszka
> :
>>
>> On 22.11.19 16:42, Mathieu Desnoyers wrote:
[...]
>
>
>> >
>> > That's indeed a good point. I suspect memba
- On Nov 22, 2019, at 12:00 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> Real-time applications with Xenomai threads wishing to use urcu-bp
> read-side within real-time threads require to disable use of the
> membarrier system call, relying on the fall-back based o
- On Nov 22, 2019, at 12:00 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> Real-time applications with Xenomai threads wishing to use urcu-bp
> read-side within real-time threads require to disable use of the
> membarrier system call, relying on the fall-back based o
- On Nov 22, 2019, at 10:52 AM, Jan Kiszka jan.kis...@siemens.com wrote:
> On 22.11.19 16:42, Mathieu Desnoyers wrote:
>> - On Nov 22, 2019, at 4:14 AM, Norbert Lange nolang...@gmail.com wrote:
>>
>>> Hello,
>>>
>>> I already started a threa
first use.
Signed-off-by: Mathieu Desnoyers
---
include/urcu/urcu-bp.h | 12
src/urcu-bp.c | 38 +++---
2 files changed, 47 insertions(+), 3 deletions(-)
diff --git a/include/urcu/urcu-bp.h b/include/urcu/urcu-bp.h
index 2ea17e6..bfab965
xenomai.org/pipermail/xenomai/2019-November/042027.html
> ___
> lttng-dev mailing list
> lttng-...@lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
t;>>> Q: I guess this will *not* interrupt xenomai threads, as their shadow linux
>>> thread is not *running*?
>>>> Q: x86_64 accesses are strictly ordered, do you actually need membarriers
>>> at all?
>>>>
>>>
>>> I didn't look into
xenomai.org/pipermail/xenomai/2019-November/042027.html
> ___
> 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
901 - 1000 of 11966 matches
Mail list logo
