On 2024-05-17 12:04, Kienan Stewart via lttng-dev wrote:
Hi Martin,
thanks for the patch.
I changed the version range slightly. The RHEL kernel 5.14.0-427.13.1
still has the `isolate_mode` parameter in the `mm_vmscan_lru_isolate`
tracepoint; it was only removed in 5.14.0-427.16.1.
I also
Hi Damien,
If kexec is not an option on your system, you might be able to
access the pmem+dax filesystem after a warm reboot, but it very
much depends on whether your bios clears your memory or not on
warm reboot.
Cheers,
Mathieu
On 2024-05-16 14:22, Damien Berget via lttng-dev wrote:
Thanks
Hi,
This is a stable release announcement for the LTTng kernel tracer,
an out-of-tree kernel tracer for the Linux kernel.
The LTTng project provides low-overhead, correlated userspace and
kernel tracing on Linux. Its use of the Common Trace Format and a
flexible control interface allows it to
On 2024-05-02 10:32, Michael Jeanson wrote:
On 2024-05-02 09:54, Mathieu Desnoyers wrote:
On 2024-05-01 19:42, Benjamin Marzinski via lttng-dev wrote:
If the read() in get_cpu_mask_from_sysfs() fails with EINTR, the code is
supposed to retry, but the while loop condition has (bytes_read > 0),
On 2024-05-01 19:42, Benjamin Marzinski via lttng-dev wrote:
If the read() in get_cpu_mask_from_sysfs() fails with EINTR, the code is
supposed to retry, but the while loop condition has (bytes_read > 0),
which is false when read() fails with EINTR. The result is that the code
exits the loop,
LTTng-UST, the Linux Trace Toolkit Next Generation Userspace Tracer,
is a low-overhead application tracer. The library "liblttng-ust" enables
tracing of applications and libraries.
New in both 2.12.10 and 2.13.8:
* Add close_range wrapper to liblttng-ust-fd.so
GNU libc 2.34 implements a new
On 2024-04-15 10:20, Michael Jeanson via lttng-dev wrote:
On 2024-04-14 20:39, Paul Wise wrote:
On Thu, 2024-04-11 at 13:45 -0400, Michael Jeanson wrote:
I see no issues with this, thanks for the heads-up.
PS: I note that git.liburcu.org and git.lttng.org seem to have
identical contents. I
Hi,
There are a few things missing before I can take this patch:
- Missing commit message describing the issue,
- Missing "Signed-off-by" tag.
Thanks!
Mathieu
On 2024-03-29 10:06, Duncan Sands via lttng-dev wrote:
--- src/urcu-bp.c
+++ src/urcu-bp.c
@@ -409,7 +409,7 @@ void
Hi,
This is a release announcement for the currently maintained
LTTng-modules Linux kernel tracer stables branches.
* New and noteworthy in these releases:
Linux kernel v6.8 is now supported by LTTng modules 2.13.12. If you need
support for recent kernels (v5.18+), you will need to upgrade to
On 2024-02-23 09:26, Steven Rostedt wrote:
On Mon, 19 Feb 2024 13:01:16 -0500
Mathieu Desnoyers wrote:
Between "sched_process_exit" and "sched_process_free", the task can still be
observed by a trace analysis looking at sched and signal events: it's a zombie
at
that stage.
Looking at the
On 2024-01-15 14:42, Florian Weimer wrote:
* Mathieu Desnoyers:
[...]
General use of lttng should be fine, I think, only the malloc wrapper
has this problem.
The purpose of the nesting counter TLS variable in the malloc wrapper
is to catch situations like this where a global-dynamic TLS
On 2024-01-13 07:49, Florian Weimer via lttng-dev wrote:
This commit
commit 8abddb187b33480d8827f44ec655f45734a1749d
Author: Andrew Burgess
Date: Sat Aug 5 14:31:06 2023 +0200
libgcc: support heap-based trampolines
Add support for heap-based trampolines on x86_64-linux,
The LTTng modules provide Linux kernel tracing capability to the LTTng
tracer toolset.
* New and noteworthy in these releases:
Newer Linux kernels (v6.6 and v6.7) are now supported by LTTng modules
2.13.11. If you need support for recent kernels (v5.18+), you will
need to upgrade to a recent
LTTng-UST, the Linux Trace Toolkit Next Generation Userspace Tracer,
is a low-overhead application tracer. The library "liblttng-ust" enables
tracing of applications and libraries.
* New and noteworthy in these releases:
Specific to 2.13.7, a fix for misaligned urcu reader accesses was
On 2023-12-18 05:16, Lei wang via lttng-dev wrote:
Android GKI kernel add limitation on fs interface usage.
Need to import VFS namespace explicitly to make it workable
for lttng-modules.
Merged into lttng-modules master and 2.13 branches, thanks!
Mathieu
Signed-off-by: Lei wang
---
On 9/21/23 21:21, Olivier Dion via lttng-dev wrote:
On Thu, 21 Sep 2023, Ondřej Surý via lttng-dev
wrote:
[...]
It fails with:
rculfhash.c:1189:2: error: address argument to atomic operation must be a
pointer to integer ('typeof (node_next)' (aka 'struct cds_lfht_node **')
invalid)
On 9/10/23 10:18, Mousa, Anas wrote:
Hey Mathieu,
Hi Anas,
We see that upon recording a tracepoint, there are multiple stages of
reserve-commit-write, where atomics and shared memory accesses take up a big part of the
recording time,
we're wondering, is there a "light-mode" of recording
On 8/23/23 10:47, Paul E. McKenney wrote:
On Mon, Aug 21, 2023 at 11:43:32AM -0400, Mathieu Desnoyers wrote:
On 8/15/23 08:38, Mathieu Desnoyers via lttng-dev wrote:
On 8/14/23 17:05, Olivier Dion via lttng-dev wrote:
After discussing it with Mathieu, we agree on the following 3 phases
On 8/15/23 08:38, Mathieu Desnoyers via lttng-dev wrote:
On 8/14/23 17:05, Olivier Dion via lttng-dev wrote:
After discussing it with Mathieu, we agree on the following 3 phases for
deprecating the signal flavor:
1) liburcu-signal will be implemented in term of liburcu-mb. The only
On 8/14/23 17:05, Olivier Dion via lttng-dev wrote:
After discussing it with Mathieu, we agree on the following 3 phases for
deprecating the signal flavor:
1) liburcu-signal will be implemented in term of liburcu-mb. The only
difference between the two flavors will be the public header
On 8/10/23 06:05, Richa Bharti wrote:
From: Richa Bharti
Hi!
Thanks for your patch. I'm adding Michael Jeanson and the lttng-dev
mailing list in CC.
Thanks,
Mathieu
* Linux kernel>=6.1 reads sub-directory from Kbuild
* Kernel < 6.1 reads sub-directory from Makefile
Signed-off-by:
On 7/18/23 15:27, Cook, Layne via lttng-dev wrote:
Can you tell me the status of the beta projects listed on the web site?
LTTng scope
LTTng analyses
The github projects haven't had an activity for quite a while. Have
these projects been abandoned, or superceded by something else?
Hi Layne,
On 7/12/23 14:44, Uttormark, Mike via lttng-dev wrote:
What became of the red-black tree effort? I see it in the git repo, 10
years old. It never made it onto master.
What would it take to get it onto master and into a release branch?
Hi Mike,
There are a few things that are in the way of
On 7/10/23 13:28, Bala Gundeboina via lttng-dev wrote:
Hi ,
i have copied the dependencies that i have installed on TDA4 evm
board and i have copied the dependency to the TI board and i getting
below error , i found the were this lock will create but in that
folder(/var/run/lttng) no
On 7/4/23 14:39, Roxana Nicolescu wrote:
Hi,
Thanks a lot for your feedback.
I realize I did not say the reason why I did not go for
LTTNG_UBUNTU_KERNEL_RANGE. We deliver a bunch of different
derivatives (inherited from the main kernel), each with its own
version and it's impossible to use
On 7/4/23 11:35, Michael Jeanson via lttng-dev wrote:
On 2023-07-03 14:28, Roxana Nicolescu via lttng-dev wrote:
This script described the changes in the linux kernel interface that
affect compatibility with lttng-modules.
It is introduced for a specific usecase where commit
d87a7b4c77a9:
On 6/29/23 13:27, Olivier Dion wrote:
On Thu, 29 Jun 2023, Olivier Dion wrote:
[0] https://godbolt.org/z/3nW14M3v1
[1] https://godbolt.org/z/TcTeMeKbW
Sorry. That was:
[0] https://godbolt.org/z/ETcxnz4TW
Change
(volatile __typeof__(ptr))(ptr);
for:
(volatile
On 6/29/23 13:22, Olivier Dion wrote:
On Thu, 22 Jun 2023, "Paul E. McKenney" wrote:
On Thu, Jun 22, 2023 at 11:55:55AM -0400, Mathieu Desnoyers wrote:
On 6/21/23 19:19, Paul E. McKenney wrote:
I suggest C11 volatile atomic load/store. Load/store fusing is permitted
for non-volatile atomic
On 6/22/23 15:53, Olivier Dion wrote:
On Thu, 22 Jun 2023, "Paul E. McKenney" wrote:
I suggest C11 volatile atomic load/store. Load/store fusing is permitted
for non-volatile atomic loads and stores, and such fusing can ruin your
code's entire day. ;-)
Good catch. Seems like not a
On 6/22/23 14:32, Paul E. McKenney wrote:
On Thu, Jun 22, 2023 at 11:55:55AM -0400, Mathieu Desnoyers wrote:
On 6/21/23 19:19, Paul E. McKenney wrote:
[...]
diff --git a/include/urcu/uatomic/builtins-generic.h
b/include/urcu/uatomic/builtins-generic.h
new file mode 100644
index
On 6/21/23 19:19, Paul E. McKenney wrote:
[...]
diff --git a/include/urcu/uatomic/builtins-generic.h
b/include/urcu/uatomic/builtins-generic.h
new file mode 100644
index 000..8e6a9b5
--- /dev/null
+++ b/include/urcu/uatomic/builtins-generic.h
@@ -0,0 +1,85 @@
+/*
+ *
On 6/22/23 06:45, Ondřej Surý via lttng-dev wrote:
(Sorry, I missed closing brackets in both macros, so resending fixed patch...)
The cds_lfht_for_each_entry and cds_lfht_for_each_entry_duplicate macros
would call caa_container_of() macro on NULL pointer. This is not a
problem under normal
On 6/21/23 20:53, Olivier Dion wrote:
On Wed, 21 Jun 2023, "Paul E. McKenney" wrote:
On Mon, May 15, 2023 at 04:17:11PM -0400, Olivier Dion wrote:
#ifndef cmm_mb
#define cmm_mb()__sync_synchronize()
Just out of curiosity, why not also implement cmm_mb() in terms of
On 6/20/23 18:02, Brian Hutchinson wrote:
On Thu, May 11, 2023 at 2:14 PM Mathieu Desnoyers
wrote:
On 2023-05-11 14:13, Mathieu Desnoyers via lttng-dev wrote:
On 2023-05-11 12:36, Brian Hutchinson via lttng-dev wrote:
... more background. I've always used ltt in the kernel so I don't
have
On 6/21/23 01:39, Yitschak, Yehuda wrote:
On 6/20/23 10:20, Mathieu Desnoyers via lttng-dev wrote:
On 6/20/23 06:27, Mousa, Anas via lttng-dev wrote:
Hello,
Arethereanysuggestionstorootcausethehighlatencyandpotentiallyimproveito
n*platform1*?
Thanks and best regards,
Anas.
I
On 6/20/23 10:20, Mathieu Desnoyers via lttng-dev wrote:
On 6/20/23 06:27, Mousa, Anas via lttng-dev wrote:
Hello,
Arethereanysuggestionstorootcausethehighlatencyandpotentiallyimproveiton*platform1*?
Thanks and best regards,
Anas.
I recommend using "perf" wh
On 6/20/23 06:27, Mousa, Anas via lttng-dev wrote:
Hello,
Arethereanysuggestionstorootcausethehighlatencyandpotentiallyimproveiton*platform1*?
Thanks and best regards,
Anas.
I recommend using "perf" when tracing with the sample program in a loop
to figure out the hot spots. With
On 6/13/23 21:51, Li-Kuan Ou wrote:
Read-side critical section nesting is tracked in lower-order bits
and grace-period phase number use a single high-order bit
Merged, thanks!
Mathieu
Signed-off-by: Li-Kuan Ou
---
include/urcu/static/urcu-bp.h | 6 +++---
On 6/13/23 11:45, Li-Kuan Ou via lttng-dev wrote:
Read-side critical section nesting is tracked in lower-order bits
and grace-period phase number use a single high-order bit
Thanks for the fix. Here is a comment below,
Signed-off-by: Li-Kuan Ou
---
include/urcu/static/urcu-bp.h | 4
Hello all,
The recordings for last year’s 2022 Tracing Summit talks were just
posted to the DiaMon Workgroup channel!
2022 Tracing Summit Talks:
https://www.youtube.com/playlist?list=PLuo4E47p5_7YbvyBpSHh-wO3KUVQ81BQR
If you did not get the chance to attend last year, we invite you to take
a
Hi,
This is a stable release announcement for the LTTng UST and LTTng modules
tracer projects.
Those contain mainly bug fixes and add support for recent distributions and
upstream kernels.
What's new in both LTTng-UST 2.12.8 and 2.13.6:
- Fix: use unaligned pointer accesses for
On 2023-05-18 15:20, Brian Hutchinson wrote:
On Thu, May 18, 2023 at 3:07 PM Brian Hutchinson wrote:
On Thu, May 18, 2023 at 3:03 PM Mathieu Desnoyers
wrote:
On 2023-05-18 14:58, Brian Hutchinson wrote:
On Thu, May 18, 2023 at 11:00 AM Brian Hutchinson wrote:
On Thu, May 18, 2023 at
On 2023-05-18 15:07, Brian Hutchinson wrote:
[...]
If you attach to an ELF symbol (function), then there is no USDT in
play, so it should not be related to the issue you have.
That is what I was thinking which is why I wanted to try it.
But if your functions happen to be inlined, then
On 2023-05-18 14:58, Brian Hutchinson wrote:
On Thu, May 18, 2023 at 11:00 AM Brian Hutchinson wrote:
On Thu, May 18, 2023 at 10:45 AM Mathieu Desnoyers
wrote:
On 2023-05-18 10:10, Brian Hutchinson wrote:
[...]
I updated my hello world to have a function I'd like to use the
On 2023-05-18 10:10, Brian Hutchinson wrote:
[...]
I updated my hello world to have a function I'd like to use the
--userspace-probe method on with the very original name of
'probe_function':
#include
#include
void probe_function(int i);
int main(int argc, char *argv[])
{
unsigned int
On 2023-05-17 12:37, Brian Hutchinson wrote:
On Wed, May 17, 2023 at 12:08 PM Mathieu Desnoyers
wrote:
On 2023-05-16 22:11, Brian Hutchinson via lttng-dev wrote:
Hi,
I'm trying to figure out how to use uprobes with lttng.
I can't use a normal uprobe for a line number just using the address
On 2023-05-16 22:11, Brian Hutchinson via lttng-dev wrote:
Hi,
I'm trying to figure out how to use uprobes with lttng.
I can't use a normal uprobe for a line number just using the address I
want to probe obtained from objdump? As in:
echo 'p /usr/local/bin/my_app:0x2c3a8' >>
Hello all!
This is a Call for Proposals for the Tracing Summit 2023[0] which will be held
in Bilbao,
Spain on the 17th and 18th of September, 2023. This year, the event is
co-located with
Open Source Summit Europe 2023 [1].
- Event dates: Sunday, September 17th - Monday, September 18th
-
On 2023-05-12 10:52, Brian Hutchinson wrote:
Hi Mathieu,
On Fri, May 12, 2023 at 9:33 AM Mathieu Desnoyers
wrote:
On 2023-05-12 00:10, Brian Hutchinson wrote:
Hmm, I missed this earlier somehow.
So, I'm not the greatest at updating OE and Yocto recipes. I'm
currently using this recipe:
[adding back the mailing list]
On 2023-05-12 09:33, Mathieu Desnoyers wrote:
On 2023-05-12 00:10, Brian Hutchinson wrote:
Hmm, I missed this earlier somehow.
So, I'm not the greatest at updating OE and Yocto recipes. I'm
currently using this recipe:
On 2023-05-11 14:13, Mathieu Desnoyers via lttng-dev wrote:
On 2023-05-11 12:36, Brian Hutchinson via lttng-dev wrote:
... more background. I've always used ltt in the kernel so I don't
have much experience with the user side of it and especially
multi-threaded, multi-core so I'm probably
On 2023-05-11 12:36, Brian Hutchinson via lttng-dev wrote:
... more background. I've always used ltt in the kernel so I don't
have much experience with the user side of it and especially
multi-threaded, multi-core so I'm probably missing some fundamental
concepts that I need to understand.
On 2023-03-26 11:00, yashvardhan kukreti wrote:
Hi Mathew,
I have a question about this patch for lttng-modules and the use of
register_kprobe() to fetch the function ptr.
The question in this regard is especially from PPC64 ELF_ABI_v1
perspective.
The functions on
On 2023-03-22 07:01, Ondřej Surý via lttng-dev wrote:
On 22. 3. 2023, at 9:02, Ondřej Surý via lttng-dev
wrote:
That's pretty much weird because the "Write" happens on stack local variable,
while the "Previous write" happens after futex, which lead me to the fact that
ThreadSanitizer doesn't
On 2023-03-22 04:02, Ondřej Surý via lttng-dev wrote:
Hi,
this happens with all the patches fully applied and doesn't seem to be caused
by anything I am doing :)
WARNING: ThreadSanitizer: data race (pid=3995296)
Write of size 8 at 0x7fb51e5fd048 by thread T296:
#0 __tsan_memset
On 2023-03-22 07:08, Ondřej Surý via lttng-dev wrote:
Hi,
the documentation is pretty silent on this, and asking here is probably going
to be faster
than me trying to use the source to figure this out.
Is it legal to call_rcu() from within the call_rcu() callback?
Yes. call_rcu callbacks
On 2023-03-22 02:39, Yuan Bin via lttng-dev wrote:
Can I disable local-file-writing in lttng-relayd to avoid the disk
space overhead, only using it as a live viewer?
I am not sure why you bump this email thread. I already answered here.
Perhaps you did not receive my reply ?
On 2023-03-20 15:38, Duncan Sands via lttng-dev wrote:
Hi Mathieu,
While OK for the general case, I would recommend that we immediately
implement something more efficient on x86 32/64 which takes into
account that __ATOMIC_ACQ_REL atomic operations are implemented with
LOCK prefixed atomic
On 2023-03-21 10:51, Ondřej Surý via lttng-dev wrote:
When adding REMOVED_FLAG to the pointers in the rculfhash
implementation, retype the generic pointer to unsigned long to fix the
following compiler error:
You will need to update the patch subject as well.
Thanks,
Mathieu
On 2023-03-21 09:31, Ondřej Surý via lttng-dev wrote:
Instead of a custom code, use the __atomic_thread_fence() builtin to
implement the cmm_mb(), cmm_rmb(), cmm_wmb(), cmm_smp_mb(),
cmm_smp_rmb(), and cmm_smp_wmb() on all architectures, and
cmm_read_barrier_depends() on alpha (otherwise it's
On 2023-03-21 09:30, Ondřej Surý via lttng-dev wrote:
Replace the custom assembly code in include/urcu/uatomic/ with __atomic
builtins provided by C11-compatible compiler.
Signed-off-by: Ondřej Surý
---
include/Makefile.am| 16 -
include/urcu/uatomic.h | 84 +++--
On 2023-03-21 09:30, Ondřej Surý via lttng-dev wrote:
Add autoconf checks for all __atomic builtins that urcu require, and
adjust the gcc and clang versions in the README.md.
Signed-off-by: Ondřej Surý
---
README.md| 33 +
configure.ac | 15
On 2023-03-21 10:48, Ondřej Surý wrote:
On 21. 3. 2023, at 15:46, Mathieu Desnoyers
wrote:
On 2023-03-21 06:21, Ondřej Surý wrote:
On 20. 3. 2023, at 19:37, Mathieu Desnoyers
wrote:
On 2023-03-17 17:37, Ondřej Surý via lttng-dev wrote:
FIXME: This is experiment that adds explicit memory
On 2023-03-21 06:21, Ondřej Surý wrote:
On 20. 3. 2023, at 19:37, Mathieu Desnoyers
wrote:
On 2023-03-17 17:37, Ondřej Surý via lttng-dev wrote:
FIXME: This is experiment that adds explicit memory barrier in the
free_completion in the workqueue.c, so ThreadSanitizer knows it's ok to
free the
On 2023-03-21 10:44, Mathieu Desnoyers wrote:
On 2023-03-21 06:15, Ondřej Surý wrote:
On 20. 3. 2023, at 19:31, Mathieu Desnoyers
wrote:
On 2023-03-17 17:37, Ondřej Surý via lttng-dev wrote:
When adding REMOVED_FLAG to the pointers in the rculfhash
implementation, retype the generic
On 2023-03-21 06:15, Ondřej Surý wrote:
On 20. 3. 2023, at 19:31, Mathieu Desnoyers
wrote:
On 2023-03-17 17:37, Ondřej Surý via lttng-dev wrote:
When adding REMOVED_FLAG to the pointers in the rculfhash
implementation, retype the generic pointer to uintptr_t to fix the
compiler error.
On 2023-03-20 14:38, Mathieu Desnoyers via lttng-dev wrote:
On 2023-03-20 14:28, Ondřej Surý wrote:
On 20. 3. 2023, at 19:03, Mathieu Desnoyers
wrote:
In doc/uatomic-api.md, we document:
"```c
type uatomic_cmpxchg(type *addr, type old, type new);
```
An atomic read-modify-write oper
On 2023-03-20 14:28, Ondřej Surý wrote:
On 20. 3. 2023, at 19:03, Mathieu Desnoyers
wrote:
In doc/uatomic-api.md, we document:
"```c
type uatomic_cmpxchg(type *addr, type old, type new);
```
An atomic read-modify-write operation that performs this
sequence of operations atomically: check
On 2023-03-17 17:37, Ondřej Surý via lttng-dev wrote:
FIXME: This is experiment that adds explicit memory barrier in the
free_completion in the workqueue.c, so ThreadSanitizer knows it's ok to
free the resources.
Signed-off-by: Ondřej Surý
---
src/workqueue.c | 1 +
1 file changed, 1
On 2023-03-17 17:37, Ondřej Surý via lttng-dev wrote:
When adding REMOVED_FLAG to the pointers in the rculfhash
implementation, retype the generic pointer to uintptr_t to fix the
compiler error.
What is the compiler error ? I'm wondering whether the expected choice
to match the rest of this
On 2023-03-17 17:37, Ondřej Surý via lttng-dev wrote:
Instead of using CMM_ACCESS_ONCE() with memory barriers, use __atomic
builtins with relaxed memory ordering to implement CMM_LOAD_SHARED() and
CMM_STORE_SHARED().
Signed-off-by: Ondřej Surý
---
include/urcu/system.h | 7 +++
1 file
On 2023-03-17 17:37, Ondřej Surý via lttng-dev wrote:
Instead of custom code, use the __atomic builtins to implement the
rcu_dereference(), rcu_cmpxchg_pointer(), rcu_xchg_pointer() and
rcu_assign_pointer().
This also changes the cmm_mb() family of functions, but not everywhere.
This should
On 2023-03-20 14:06, Mathieu Desnoyers via lttng-dev wrote:
On 2023-03-17 17:37, Ondřej Surý via lttng-dev wrote:
Use __atomic_thread_fence(__ATOMIC_ACQ_REL) for cmm_barrier(), so
ThreadSanitizer can understand the memory synchronization.
You should update the patch subject and commit message
On 2023-03-20 14:03, Mathieu Desnoyers via lttng-dev wrote:
On 2023-03-17 17:37, Ondřej Surý via lttng-dev wrote:
Replace the custom assembly code in include/urcu/uatomic/ with __atomic
builtins provided by C11-compatible compiler.
[...]
+#define UATOMIC_HAS_ATOMIC_BYTE
+#define
On 2023-03-17 17:37, Ondřej Surý via lttng-dev wrote:
Use __atomic_thread_fence(__ATOMIC_ACQ_REL) for cmm_barrier(), so
ThreadSanitizer can understand the memory synchronization.
You should update the patch subject and commit message to replace
"thread" by "signal".
FIXME: What should be
On 2023-03-17 17:37, Ondřej Surý via lttng-dev wrote:
Replace the custom assembly code in include/urcu/uatomic/ with __atomic
builtins provided by C11-compatible compiler.
[...]
+#define UATOMIC_HAS_ATOMIC_BYTE
+#define UATOMIC_HAS_ATOMIC_SHORT
+
+#define uatomic_set(addr, v)
On 2023-03-17 13:02, Ondřej Surý wrote:
On 17. 3. 2023, at 14:44, Mathieu Desnoyers
wrote:
I would indeed like to remove all the custom atomics assembly code from liburcu
now that there are good atomics support in the major compilers (gcc and clang).
Here's very preliminary implementation:
On 2023-03-17 11:50, Ondřej Surý wrote:
On 17. 3. 2023, at 14:44, Mathieu Desnoyers
wrote:
Sure, can you please submit the patch as a separate email with subject/commit
message/signed-off-by tag ?
https://gitlab.isc.org/isc-projects/userspace-rcu/-/merge_requests/1.patch
Would this work
On 2023-03-14 08:26, Ondřej Surý via lttng-dev wrote:
Hey,
we use ThreadSanitizer in BIND 9 CI quite extensively and with userspace-rcu
it's lit like an American house on Saturnalia ;).
Haha, I have no doubt about it. Userspace RCU is all about concurrent
accesses, and so far possesses no
On 2023-03-13 11:30, Ondřej Surý wrote:
Hi Matthieu,
I spent some more time with the userspace-rcu on Friday and over weekend and
now I am in much better place.
On 13. 3. 2023, at 15:29, Mathieu Desnoyers
wrote:
On 2023-03-11 01:04, Ondřej Surý via lttng-dev wrote:
Hey,
so, we are
On 2023-03-11 01:04, Ondřej Surý via lttng-dev wrote:
Hey,
so, we are integrating userspace-rcu to BIND 9 (yay!) and as experiment,
I am rewriting the internal address database (keeps the infrastructure
information about names and addresses).
That's indeed very interesting !
There's a
On 2023-03-06 00:12, Yuan Bin via lttng-dev wrote:
Can I disable local-file-writing in lttng-relayd to avoid the disk
space overhead, only using it as a live viewer?
Not explicitly, but you can store your temporary files on a tmpfs file
system (see lttng-relayd(8) --output command line
This is a release announcement for the two currently maintained stable
branches of the LTTng-modules project.
* New in these releases
LTTng-modules v2.13.9 contains a fix required to build against Linux v6.2.
Both v2.12.13 and v2.13.9 contain a set of build fixes to follow
evolution of the
On 2023-02-15 04:09, Rengar Stinkt via lttng-dev wrote:
Dear community,
I only recently started working with lttng tracing due to work related
projects, so I am very new to this. I have done some research before
posting this but I can't seem to find an answer.
I am running several CPU load
Hi,
This is a release announcement for the Userspace RCU project.
This is a set of releases, including the new 0.14 branch with the 0.14.0
release, and bug fix releases for the 0.13 and 0.12 branches. The 0.12.5
release is the last of the 0.12 branch, which reaches end of life with
the
Hi Micke,
I did tweaks to make the code C++ compatible even though it's currently
only built in C. It makes it more future-proof.
I've merged the resulting patch into lttng-ust
master/stable-2.13/stable-2.12. Thanks for testing !
Mathieu
On 2023-02-06 11:15, Beckius, Mikael wrote:
Hello
Hi Mikael,
I just tried another approach to fix this issue, see:
https://review.lttng.org/c/lttng-ust/+/9413 Fix: use unaligned pointer accesses
for lttng_inline_memcpy
It is less intrusive than other approaches, and does not change the generated
code on the
most relevant architectures.
On 2023-01-31 11:18, Mathieu Desnoyers wrote:
On 2023-01-31 11:08, Mathieu Desnoyers wrote:
On 2023-01-30 01:50, Beckius, Mikael via lttng-dev wrote:
Hello Matthieu!
I have looked at this in place of Anders and as far as I can tell
this is not an arm64 issue but an arm issue. And even on arm
On 2023-01-31 11:08, Mathieu Desnoyers wrote:
On 2023-01-30 01:50, Beckius, Mikael via lttng-dev wrote:
Hello Matthieu!
I have looked at this in place of Anders and as far as I can tell this
is not an arm64 issue but an arm issue. And even on arm
__ARM_FEATURE_UNALIGNED is 1 so it seems the
On 2023-01-30 01:50, Beckius, Mikael via lttng-dev wrote:
Hello Matthieu!
I have looked at this in place of Anders and as far as I can tell this is not
an arm64 issue but an arm issue. And even on arm __ARM_FEATURE_UNALIGNED is 1
so it seems the problem only occurs if size equals 8.
So for
On 2023-01-26 14:32, Anders Wallin wrote:
Hi Matthieu,
I've retired and no longer have access to any arch64 target to test it on.
Thanks for your reply Anders,
I've talked to Henrik and Pär today and they are already testing it out.
Enjoy your retirement :)
Best regards,
Mathieu
--
Hi Anders,
Sorry for the long delay on this one, can you have a look at the following fix ?
https://review.lttng.org/c/lttng-ust/+/9319 Fix: aarch64: do not perform
unaligned stores
If it passes your testing, I'll merge this into lttng-ust.
Thanks,
Mathieu
On 2017-12-28 09:13, Anders
Hi,
Those are stable release updates of the LTTng modules project.
The most relevant change is that the 2.13.8 version introduces
support for the 6.1 Linux kernel, kernel version ranges updates
for the RHEL kernels, and a kallsyms wrapper fix on ppc64el.
The LTTng modules provide Linux kernel
On 2023-01-09 09:02, chafraysse--- via lttng-dev wrote:
Hi,
I'm looking for a CTF writer to serialize instrumentations in an
embedded Linux/Rust framework
LTTng UST looked like a very strong option, but I want to serialize
structures as CTF compound type structures and I did not see those
Hi Florian,
I'll pull your patch into the lttv master branch, but please be aware
that the LTTV project has not seen activity since 2013, is currently
unmaintained, and that we do not plan on doing further releases of this
project. Our efforts were diverted elsewhere on the trace analysis
front,
On 2022-11-02 03:24, Yongwei Wu via lttng-dev wrote:
I apologize if this is not the right place. I do not see an Issues page
on GitHub.
The README on GitHub now says MacOS is among "Tested on", so should we
remove Darwin from "Should also work on"?
Removed from README file in the master
On 2022-10-02 12:13, Eric Wong via lttng-dev wrote:
pthread_create may fail with EAGAIN (which is no fault of the
programmer), so don't allow the check to be compiled out.
Merged into master, stable-0.13, stable-0.12, thanks!
Mathieu
Signed-off-by: Eric Wong
---
src/urcu-defer-impl.h |
Hi,
These bug fix releases of the LTTng kernel and user-space tracers
contain security fixes which address memory disclosure and denial of
service issues. Those are of relatively low severity mainly because they
involve specific uses of the tracer by users that belong to the
`tracing` group.
When using the event notification capture API, empty strings are
represented by a NULL pointer with a size=0 in the msgpack object.
The NULL pointer is unexpected, which triggers an assertion in
lttng_event_field_value_string_create_with_size.
Fix this by duplicating an empty string ("") when a
On 2022-09-26 15:58, Eric Wong wrote:
Mathieu Desnoyers wrote:
Do you mind if I fold our 2 patches together with a Co-developed-by tag and
use your Signed-off-by ?
Looks good to me, thanks.
Then the question that will arise is whether this change is sufficiently
self-contained that we can
1 - 100 of 301 matches
Mail list logo
