* Re: [PATCH] ring-buffer: Use a housekeeping CPU to wake up waiters
From: Steven Rostedt @ 2026-01-06 22:04 UTC (permalink / raw)
To: Petr Tesarik
Cc: Masami Hiramatsu, Mathieu Desnoyers, Sebastian Andrzej Siewior,
Clark Williams, linux-kernel, linux-trace-kernel, linux-rt-devel
In-Reply-To: <20260106091039.2012108-1-ptesarik@suse.com>
On Tue, 6 Jan 2026 10:10:39 +0100
Petr Tesarik <ptesarik@suse.com> wrote:
> Avoid running the wakeup irq_work on an isolated CPU. Since the wakeup can
> run on any CPU, let's pick a housekeeping CPU to do the job.
>
> This change reduces additional noise when tracing isolated CPUs. For
> example, the following ipi_send_cpu stack trace was captured with
> nohz_full=2 on the isolated CPU:
>
> <idle>-0 [002] d.h4. 1255.379293: ipi_send_cpu: cpu=2 callsite=irq_work_queue+0x2d/0x50 callback=rb_wake_up_waiters+0x0/0x80
> <idle>-0 [002] d.h4. 1255.379329: <stack trace>
> => trace_event_raw_event_ipi_send_cpu
> => __irq_work_queue_local
> => irq_work_queue
> => ring_buffer_unlock_commit
> => trace_buffer_unlock_commit_regs
> => trace_event_buffer_commit
> => trace_event_raw_event_x86_irq_vector
> => __sysvec_apic_timer_interrupt
> => sysvec_apic_timer_interrupt
> => asm_sysvec_apic_timer_interrupt
> => pv_native_safe_halt
> => default_idle
> => default_idle_call
> => do_idle
> => cpu_startup_entry
> => start_secondary
> => common_startup_64
I take it that even with this patch you would still get the above events.
The only difference would be the "cpu=" in the event info will not be the
same as the CPU it executed on, right?
>
> The IRQ work interrupt alone adds considerable noise, but the impact can
> get even worse with PREEMPT_RT, because the IRQ work interrupt is then
> handled by a separate kernel thread. This requires a task switch and makes
> tracing useless for analyzing latency on an isolated CPU.
>
> Signed-off-by: Petr Tesarik <ptesarik@suse.com>
LGTM,
I'll queue it up for the next merge window.
-- Steve
^ permalink raw reply
* Re: [PATCH] ftrace: Do not over-allocate ftrace memory
From: Steven Rostedt @ 2026-01-06 21:18 UTC (permalink / raw)
To: Guenter Roeck
Cc: Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, linux-kernel,
linux-trace-kernel
In-Reply-To: <20260106203533.2896197-1-linux@roeck-us.net>
On Tue, 6 Jan 2026 12:35:33 -0800
Guenter Roeck <linux@roeck-us.net> wrote:
> The pg_remaining calculation in ftrace_process_locs() assumes that
> ENTRIES_PER_PAGE multiplied by 2^order equals the actual capacity of the
> allocated page group. However, ENTRIES_PER_PAGE is PAGE_SIZE / ENTRY_SIZE
> (integer division). When PAGE_SIZE is not a multiple of ENTRY_SIZE (e.g.
> 4096 / 24 = 170 with remainder 16), high-order allocations (like 256 pages)
> have significantly more capacity than 256 * 170. This leads to pg_remaining
> being underestimated, which in turn makes skip (derived from skipped -
> pg_remaining) larger than expected, causing the WARN(skip != remaining)
> to trigger.
Nice catch! I guess you have a machine that allows much higher order
allocations than I do ;-)
>
> Extra allocated pages for ftrace: 2 with 654 skipped
> WARNING: CPU: 0 PID: 0 at kernel/trace/ftrace.c:7295 ftrace_process_locs+0x5bf/0x5e0
>
> A similar problem in ftrace_allocate_records() can result in allocating
> too many pages. This can trigger the second warning in
> ftrace_process_locs().
>
> Extra allocated pages for ftrace
> WARNING: CPU: 0 PID: 0 at kernel/trace/ftrace.c:7276 ftrace_process_locs+0x548/0x580
>
> Use the actual capacity of a page group to determine if too many pages
> have been allocated to solve the problem. Also use the actual capacity
> of a page group to determine the number of pages needed to avoid over-
> allocations in ftrace_allocate_records().
>
> Fixes: 4a3efc6baff93 ("ftrace: Update the mcount_loc check of skipped entries")
> Cc: Steven Rostedt <rostedt@goodmis.org>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> ---
> kernel/trace/ftrace.c | 25 +++++++++++++++++--------
> 1 file changed, 17 insertions(+), 8 deletions(-)
>
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index ef2d5dca6f70..211ec7a04f7e 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -3844,7 +3844,7 @@ static int ftrace_allocate_records(struct ftrace_page *pg, int count)
> return -EINVAL;
>
> /* We want to fill as much as possible, with no empty pages */
> - pages = DIV_ROUND_UP(count, ENTRIES_PER_PAGE);
> + pages = DIV_ROUND_UP(count * ENTRY_SIZE, PAGE_SIZE);
> order = fls(pages) - 1;
>
> again:
> @@ -7308,24 +7308,33 @@ static int ftrace_process_locs(struct module *mod,
> unsigned long skip;
>
> /* Count the number of entries unused and compare it to skipped. */
> - pg_remaining = (ENTRIES_PER_PAGE << pg->order) - pg->index;
> + pg_remaining = (PAGE_SIZE << pg->order) / ENTRY_SIZE - pg->index;
>
> if (!WARN(skipped < pg_remaining, "Extra allocated pages for ftrace")) {
> + unsigned long space = 0;
>
> skip = skipped - pg_remaining;
>
> - for (pg = pg_unuse; pg; pg = pg->next)
> + for (pg = pg_unuse; pg; pg = pg->next) {
> remaining += 1 << pg->order;
> + /*
> + * The capacity of a page group is
> + * (PAGE_SIZE << order) / ENTRY_SIZE
> + * Accumulate the total capacity of unused pages.
> + */
> + space += (PAGE_SIZE << pg->order) / ENTRY_SIZE;
> + }
>
> pages -= remaining;
I think pages is meaningless here, as it was set in the beginning with:
pages = DIV_ROUND_UP(count, ENTRIES_PER_PAGE);
Which is incorrect. I wonder if we should set it via:
/*
* Use ftrace_number_of_pages to determine how many pages were
* allocated
*/
pages = ftrace_number_of_pages;
start_pg = ftrace_allocate_pages(count);
if (!start_pg)
return -ENOMEM;
/* ftrace_allocate_pages() increments ftrace_number_of_pages */
pages = ftrace_number_of_pages - pages;
This will make pages equal the number of pages that were allocated. Then
I'm not sure we need this extra logic.
-- Steve
>
> - skip = DIV_ROUND_UP(skip, ENTRIES_PER_PAGE);
> -
> /*
> - * Check to see if the number of pages remaining would
> - * just fit the number of entries skipped.
> + * Check to see if extra pages have been allocated.
> + * Only warn if the number of unused entries is larger
> + * than the number of entries per page to avoid false
> + * positives due to rounding.
> */
> - WARN(skip != remaining, "Extra allocated pages for ftrace: %lu with %lu skipped",
> + WARN(space - skip > ENTRIES_PER_PAGE,
> + "Extra allocated pages for ftrace: %lu with %lu skipped",
> remaining, skipped);
> }
> /* Need to synchronize with ftrace_location_range() */
^ permalink raw reply
* [PATCH] ftrace: Do not over-allocate ftrace memory
From: Guenter Roeck @ 2026-01-06 20:35 UTC (permalink / raw)
To: Steven Rostedt
Cc: Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, linux-kernel,
linux-trace-kernel, Guenter Roeck
The pg_remaining calculation in ftrace_process_locs() assumes that
ENTRIES_PER_PAGE multiplied by 2^order equals the actual capacity of the
allocated page group. However, ENTRIES_PER_PAGE is PAGE_SIZE / ENTRY_SIZE
(integer division). When PAGE_SIZE is not a multiple of ENTRY_SIZE (e.g.
4096 / 24 = 170 with remainder 16), high-order allocations (like 256 pages)
have significantly more capacity than 256 * 170. This leads to pg_remaining
being underestimated, which in turn makes skip (derived from skipped -
pg_remaining) larger than expected, causing the WARN(skip != remaining)
to trigger.
Extra allocated pages for ftrace: 2 with 654 skipped
WARNING: CPU: 0 PID: 0 at kernel/trace/ftrace.c:7295 ftrace_process_locs+0x5bf/0x5e0
A similar problem in ftrace_allocate_records() can result in allocating
too many pages. This can trigger the second warning in
ftrace_process_locs().
Extra allocated pages for ftrace
WARNING: CPU: 0 PID: 0 at kernel/trace/ftrace.c:7276 ftrace_process_locs+0x548/0x580
Use the actual capacity of a page group to determine if too many pages
have been allocated to solve the problem. Also use the actual capacity
of a page group to determine the number of pages needed to avoid over-
allocations in ftrace_allocate_records().
Fixes: 4a3efc6baff93 ("ftrace: Update the mcount_loc check of skipped entries")
Cc: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
kernel/trace/ftrace.c | 25 +++++++++++++++++--------
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index ef2d5dca6f70..211ec7a04f7e 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -3844,7 +3844,7 @@ static int ftrace_allocate_records(struct ftrace_page *pg, int count)
return -EINVAL;
/* We want to fill as much as possible, with no empty pages */
- pages = DIV_ROUND_UP(count, ENTRIES_PER_PAGE);
+ pages = DIV_ROUND_UP(count * ENTRY_SIZE, PAGE_SIZE);
order = fls(pages) - 1;
again:
@@ -7308,24 +7308,33 @@ static int ftrace_process_locs(struct module *mod,
unsigned long skip;
/* Count the number of entries unused and compare it to skipped. */
- pg_remaining = (ENTRIES_PER_PAGE << pg->order) - pg->index;
+ pg_remaining = (PAGE_SIZE << pg->order) / ENTRY_SIZE - pg->index;
if (!WARN(skipped < pg_remaining, "Extra allocated pages for ftrace")) {
+ unsigned long space = 0;
skip = skipped - pg_remaining;
- for (pg = pg_unuse; pg; pg = pg->next)
+ for (pg = pg_unuse; pg; pg = pg->next) {
remaining += 1 << pg->order;
+ /*
+ * The capacity of a page group is
+ * (PAGE_SIZE << order) / ENTRY_SIZE
+ * Accumulate the total capacity of unused pages.
+ */
+ space += (PAGE_SIZE << pg->order) / ENTRY_SIZE;
+ }
pages -= remaining;
- skip = DIV_ROUND_UP(skip, ENTRIES_PER_PAGE);
-
/*
- * Check to see if the number of pages remaining would
- * just fit the number of entries skipped.
+ * Check to see if extra pages have been allocated.
+ * Only warn if the number of unused entries is larger
+ * than the number of entries per page to avoid false
+ * positives due to rounding.
*/
- WARN(skip != remaining, "Extra allocated pages for ftrace: %lu with %lu skipped",
+ WARN(space - skip > ENTRIES_PER_PAGE,
+ "Extra allocated pages for ftrace: %lu with %lu skipped",
remaining, skipped);
}
/* Need to synchronize with ftrace_location_range() */
--
2.45.2
^ permalink raw reply related
* Re: [PATCH v3 08/13] sched: Export hidden tracepoints to modules
From: Phil Auld @ 2026-01-06 20:21 UTC (permalink / raw)
To: Gabriele Monaco
Cc: linux-kernel, Steven Rostedt, Nam Cao, Ingo Molnar,
Peter Zijlstra, Tomas Glozar, Juri Lelli, Clark Williams,
John Kacur, linux-trace-kernel
In-Reply-To: <20251211223643.GA557546@pauld.westford.csb>
Ping...
On Fri, Dec 12, 2025 at 07:36:43AM +0900 Phil Auld wrote:
>
> Hi Peter,
>
> On Fri, Dec 05, 2025 at 08:35:52AM -0500 Phil Auld wrote:
> > On Fri, Dec 05, 2025 at 02:16:16PM +0100 Gabriele Monaco wrote:
> > > The tracepoints sched_entry, sched_exit and sched_set_need_resched
> > > are not exported to tracefs as trace events, this allows only kernel
> > > code to access them. Helper modules like [1] can be used to still have
> > > the tracepoints available to ftrace for debugging purposes, but they do
> > > rely on the tracepoints being exported.
> > >
> > > Export the 3 not exported tracepoints.
> > > Note that sched_set_state is already exported as the macro is called
> > > from modules.
> > >
> > > [1] - https://github.com/qais-yousef/sched_tp.git
> > >
> > > Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
> >
> > This makes sense.
> >
> > Reviewed-by: Phil Auld <pauld@redhat.com>
> >
>
> Any chance we can get this one in even if the rest of the series
> needs more time?
>
> Without this, out of tree modules fail to link.
Any thoughts on this? Please?
Anything including linux/sched.h fails to link due to
these:
__trace_set_need_resched
__tracepoint_sched_set_need_resched_tp
Thanks,
Phil
>
> I don't know if it's worth adding:
>
> Fixes: adcc3bfa8806 ("sched: Adapt sched tracepoints for RV task model")
>
>
> Cheers,
> Phil
>
> >
> > Cheers,
> > Phil
> >
> > > ---
> > > kernel/sched/core.c | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > > index 41ba0be16911..5516778c19eb 100644
> > > --- a/kernel/sched/core.c
> > > +++ b/kernel/sched/core.c
> > > @@ -119,6 +119,9 @@ EXPORT_TRACEPOINT_SYMBOL_GPL(sched_util_est_cfs_tp);
> > > EXPORT_TRACEPOINT_SYMBOL_GPL(sched_util_est_se_tp);
> > > EXPORT_TRACEPOINT_SYMBOL_GPL(sched_update_nr_running_tp);
> > > EXPORT_TRACEPOINT_SYMBOL_GPL(sched_compute_energy_tp);
> > > +EXPORT_TRACEPOINT_SYMBOL_GPL(sched_entry_tp);
> > > +EXPORT_TRACEPOINT_SYMBOL_GPL(sched_exit_tp);
> > > +EXPORT_TRACEPOINT_SYMBOL_GPL(sched_set_need_resched_tp);
> > >
> > > DEFINE_PER_CPU_SHARED_ALIGNED(struct rq, runqueues);
> > > DEFINE_PER_CPU(struct rnd_state, sched_rnd_state);
> > > --
> > > 2.52.0
> > >
> > >
> >
> > --
> >
>
> --
>
>
--
^ permalink raw reply
* Re: [RFC PATCH 1/2] rcu: Add rcu_read_lock_notrace()
From: Mathieu Desnoyers @ 2026-01-06 18:43 UTC (permalink / raw)
To: paulmck
Cc: Steven Rostedt, Sebastian Andrzej Siewior, Boqun Feng,
linux-rt-devel, rcu, linux-trace-kernel, Frederic Weisbecker,
Joel Fernandes, Josh Triplett, Lai Jiangshan, Masami Hiramatsu,
Neeraj Upadhyay, Thomas Gleixner, Uladzislau Rezki, Zqiang, bpf
In-Reply-To: <24a769a9-274c-452f-904f-fa1cc8271183@paulmck-laptop>
On 2026-01-06 13:30, Paul E. McKenney wrote:
> On Tue, Jan 06, 2026 at 10:08:44AM -0500, Mathieu Desnoyers wrote:
[...]
>> Re-reading the comment and your explanation, I think the comments are
>> clear enough. One nit I found while reading though:
>>
>> include/linux/srcutree.h:
>>
>> * Note that both this_cpu_inc() and atomic_long_inc() are RCU read-side
>> * critical sections either because they disables interrupts, because
>>
>> disables -> disable
>
> Like this?
Looks good !
Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Thanks,
Mathieu
>
> Thanx, Paul
>
> ------------------------------------------------------------------------
>
> commit b3fc7ac622a19fcf921871be097e3536847406cd
> Author: Paul E. McKenney <paulmck@kernel.org>
> Date: Tue Jan 6 10:28:10 2026 -0800
>
> srcu: Fix s/they disables/they disable/ typo in srcu_read_unlock_fast()
>
> Typo fix in srcu_read_unlock_fast() header comment.
>
> Reported-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
>
> diff --git a/include/linux/srcutree.h b/include/linux/srcutree.h
> index d6f978b50472d..727719a3cbeb9 100644
> --- a/include/linux/srcutree.h
> +++ b/include/linux/srcutree.h
> @@ -259,7 +259,7 @@ static inline struct srcu_ctr __percpu *__srcu_ctr_to_ptr(struct srcu_struct *ss
> * srcu_read_unlock_fast().
> *
> * Note that both this_cpu_inc() and atomic_long_inc() are RCU read-side
> - * critical sections either because they disables interrupts, because
> + * critical sections either because they disable interrupts, because
> * they are a single instruction, or because they are read-modify-write
> * atomic operations, depending on the whims of the architecture.
> * This matters because the SRCU-fast grace-period mechanism uses either
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
^ permalink raw reply
* Re: [RFC PATCH 1/2] rcu: Add rcu_read_lock_notrace()
From: Paul E. McKenney @ 2026-01-06 18:30 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: Steven Rostedt, Sebastian Andrzej Siewior, Boqun Feng,
linux-rt-devel, rcu, linux-trace-kernel, Frederic Weisbecker,
Joel Fernandes, Josh Triplett, Lai Jiangshan, Masami Hiramatsu,
Neeraj Upadhyay, Thomas Gleixner, Uladzislau Rezki, Zqiang, bpf
In-Reply-To: <42ec09a2-ba39-4277-94ee-faca1540a4c8@efficios.com>
On Tue, Jan 06, 2026 at 10:08:44AM -0500, Mathieu Desnoyers wrote:
> On 2025-07-17 11:18, Paul E. McKenney wrote:
> > On Thu, Jul 17, 2025 at 10:46:46AM -0400, Mathieu Desnoyers wrote:
> > > On 2025-07-17 09:14, Mathieu Desnoyers wrote:
> > > > On 2025-07-16 18:54, Paul E. McKenney wrote:
> > > [...]
> > > >
> > > > 2) I think I'm late to the party in reviewing srcu-fast, I'll
> > > > go have a look :)
> > >
> > > OK, I'll bite. :) Please let me know where I'm missing something:
> > >
> > > Looking at srcu-lite and srcu-fast, I understand that they fundamentally
> > > depend on a trick we published here https://lwn.net/Articles/573497/
> > > "The RCU-barrier menagerie" that allows turning, e.g. this Dekker:
> > >
> > > volatile int x = 0, y = 0
> > >
> > > CPU 0 CPU 1
> > >
> > > x = 1 y = 1
> > > smp_mb smp_mb
> > > r2 = y r4 = x
> > >
> > > BUG_ON(r2 == 0 && r4 == 0)
> > >
> > > into
> > >
> > > volatile int x = 0, y = 0
> > >
> > > CPU 0 CPU 1
> > >
> > > rcu_read_lock()
> > > x = 1 y = 1
> > > synchronize_rcu()
> > > r2 = y r4 = x
> > > rcu_read_unlock()
> > >
> > > BUG_ON(r2 == 0 && r4 == 0)
> > >
> > > So looking at srcu-fast, we have:
> > >
> > > * Note that both this_cpu_inc() and atomic_long_inc() are RCU read-side
> > > * critical sections either because they disables interrupts, because they
> > > * are a single instruction, or because they are a read-modify-write atomic
> > > * operation, depending on the whims of the architecture.
> > >
> > > It appears to be pairing, as RCU read-side:
> > >
> > > - irq off/on implied by this_cpu_inc
> > > - atomic
> > > - single instruction
> > >
> > > with synchronize_rcu within the grace period, and hope that this behaves as a
> > > smp_mb pairing preventing the srcu read-side critical section from leaking
> > > out of the srcu read lock/unlock.
> > >
> > > I note that there is a validation that rcu_is_watching() within
> > > __srcu_read_lock_fast, but it's one thing to have rcu watching, but
> > > another to have an actual read-side critical section. Note that
> > > preemption, irqs, softirqs can very well be enabled when calling
> > > __srcu_read_lock_fast.
> > >
> > > My understanding of the how memory barriers implemented with RCU
> > > work is that we need to surround the memory accesses on the fast-path
> > > (where we turn smp_mb into barrier) with an RCU read-side critical
> > > section to make sure it does not spawn across a synchronize_rcu.
> > >
> > > What I am missing here is how can a RCU side-side that only consist
> > > of the irq off/on or atomic or single instruction cover all memory
> > > accesses we are trying to order, namely those within the srcu
> > > critical section after the compiler barrier() ? Is having RCU
> > > watching sufficient to guarantee this ?
> >
> > Good eyes!!!
> >
> > The trick is that this "RCU read-side critical section" consists only of
> > either this_cpu_inc() or atomic_long_inc(), with the latter only happening
> > in systems that have NMIs, but don't have NMI-safe per-CPU operations.
> > Neither this_cpu_inc() nor atomic_long_inc() can be interrupted, and
> > thus both act as an interrupts-disabled RCU read-side critical section.
> >
> > Therefore, if the SRCU grace-period computation fails to see an
> > srcu_read_lock_fast() increment, its earlier code is guaranteed to
> > happen before the corresponding critical section. Similarly, if the SRCU
> > grace-period computation sees an srcu_read_unlock_fast(), its subsequent
> > code is guaranteed to happen after the corresponding critical section.
> >
> > Does that help? If so, would you be interested and nominating a comment?
> >
> > Or am I missing something subtle here?
> >
> > Either way, many thanks for digging into this!!!
> Re-reading the comment and your explanation, I think the comments are
> clear enough. One nit I found while reading though:
>
> include/linux/srcutree.h:
>
> * Note that both this_cpu_inc() and atomic_long_inc() are RCU read-side
> * critical sections either because they disables interrupts, because
>
> disables -> disable
Like this?
Thanx, Paul
------------------------------------------------------------------------
commit b3fc7ac622a19fcf921871be097e3536847406cd
Author: Paul E. McKenney <paulmck@kernel.org>
Date: Tue Jan 6 10:28:10 2026 -0800
srcu: Fix s/they disables/they disable/ typo in srcu_read_unlock_fast()
Typo fix in srcu_read_unlock_fast() header comment.
Reported-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
diff --git a/include/linux/srcutree.h b/include/linux/srcutree.h
index d6f978b50472d..727719a3cbeb9 100644
--- a/include/linux/srcutree.h
+++ b/include/linux/srcutree.h
@@ -259,7 +259,7 @@ static inline struct srcu_ctr __percpu *__srcu_ctr_to_ptr(struct srcu_struct *ss
* srcu_read_unlock_fast().
*
* Note that both this_cpu_inc() and atomic_long_inc() are RCU read-side
- * critical sections either because they disables interrupts, because
+ * critical sections either because they disable interrupts, because
* they are a single instruction, or because they are read-modify-write
* atomic operations, depending on the whims of the architecture.
* This matters because the SRCU-fast grace-period mechanism uses either
^ permalink raw reply related
* Re: [PATCH v2 15/18] rtla: Make stop_tracing variable volatile
From: Crystal Wood @ 2026-01-06 17:47 UTC (permalink / raw)
To: Steven Rostedt, Wander Lairson Costa
Cc: Tomas Glozar, Ivan Pravdin, Costa Shulyupin, John Kacur,
Tiezhu Yang, open list:Real-time Linux Analysis (RTLA) tools,
open list:Real-time Linux Analysis (RTLA) tools,
open list:BPF [MISC]:Keyword:(?:\b|_)bpf(?:\b|_)
In-Reply-To: <20260106110519.40c97efe@gandalf.local.home>
On Tue, 2026-01-06 at 11:05 -0500, Steven Rostedt wrote:
> On Tue, 6 Jan 2026 08:49:51 -0300
> Wander Lairson Costa <wander@redhat.com> wrote:
>
> > Add the volatile qualifier to stop_tracing in both common.c and
> > common.h to ensure all accesses to this variable bypass compiler
> > optimizations and read directly from memory. This guarantees that
> > when the signal handler sets stop_tracing, the change is immediately
> > visible to the main program loop, preventing potential hangs or
> > delayed shutdown when termination signals are received.
>
> In the kernel, this is handled via the READ_ONCE() macro. Perhaps rtla
> should implement that too.
Or just get it from tools/include/linux/compiler.h. No need to reinvent
the wheel (even though several other tools do).
That said, signal safety is a pretty routine use for volatile.
-Crystal
^ permalink raw reply
* Re: ftrace: sorttable unable to sort ELF64 on 32-bit host
From: Sahil Gupta @ 2026-01-06 17:39 UTC (permalink / raw)
To: Steven Rostedt; +Cc: linux-trace-kernel, Dmitry Safonov, Kevin Mitchell, stable
In-Reply-To: <20260106122145.42e4ec09@gandalf.local.home>
Sounds good, many thanks.
Sahil
^ permalink raw reply
* Re: ftrace: sorttable unable to sort ELF64 on 32-bit host
From: Steven Rostedt @ 2026-01-06 17:21 UTC (permalink / raw)
To: Sahil Gupta; +Cc: linux-trace-kernel, Dmitry Safonov, Kevin Mitchell, stable
In-Reply-To: <CABEuK16m+msavH79AZxTRSqOsS5MQmOnsZZ8tZuKY5WWwz3bFw@mail.gmail.com>
On Thu, 20 Mar 2025 17:02:06 -0500
Sahil Gupta <s.gupta@arista.com> wrote:
> Hi Steven,
Hi,
Sorry for the really late reply. I'm cleaning out my inbox and just noticed
this email.
>
> On 6.12.0, sorttable is unable to sort 64-bit ELFs on 32-bit hosts
> because of the parsing of the start_mcount_loc and stop_mcount_loc
> values in get_mcount_loc():
>
> *_start = strtoul(start_buff, NULL, 16);
>
> and
>
> *_stop = strtoul(stop_buff, NULL, 16);
>
> This code makes the (often correct) assumption that the host and the
> target have the same architecture, however it runs into issues when
> compiling for a 64-bit target on a 32-bit host, as unsigned long is
> shorter than the pointer width. As a result, I've noticed that both
> start and stop max out at 2^32 - 1.
>
> It seems that commit 4acda8ed fixes this issue inadvertently by
> directly extracting them from the ELF using the correct width. I'm
> wondering if it is possible to backport this as well as the other
> sorttable refactors to 6.12.0 since they fix this issue.
I think this is a good reason to mark that commit as stable and backport it
to 6.12.
-- Steve
^ permalink raw reply
* Re: [PATCH v2] arm64: Disable branch profiling for all arm64 code
From: Steven Rostedt @ 2026-01-06 16:11 UTC (permalink / raw)
To: Mark Rutland
Cc: Breno Leitao, Catalin Marinas, Will Deacon, Laura Abbott,
linux-arm-kernel, linux-kernel, linux-trace-kernel,
Masami Hiramatsu, kernel-team, puranjay, stable
In-Reply-To: <aVz-6WozGIxGiTUR@J2N7QTR9R3>
On Tue, 6 Jan 2026 12:24:09 +0000
Mark Rutland <mark.rutland@arm.com> wrote:
> Whoops; s/CONFIG_DEBUG_VIRTUAL/PROFILE_ANNOTATED_BRANCHES/ in both
> places in my reply.
Note, it could still be useful ;-)
I've been running my yearly branch profiling build on both my main
workstation and my server. I post the results from my server publicly (this
is updated every night):
https://rostedt.org/branches/current
If you check out the branch_annotated file, you can see there's still quite
a bit that gets it wrong. Some of these is because of bad assumptions by
the developer, others is because the code moved around causing new branches
to make later annotated branches go the opposite way.
Note, its still slow to download, not only because my internet is 20mbs up,
but also because that web server is running on a machine with this
profiling still enabled. I'll rebuild the kernel and disable it this weekend.
-- Steve
^ permalink raw reply
* Re: [v2 PATCH 2/2] tracing: Add show_event_triggers to expose active event triggers
From: Randy Dunlap @ 2026-01-06 16:08 UTC (permalink / raw)
To: Steven Rostedt
Cc: Aaron Tomlin, mhiramat, mark.rutland, mathieu.desnoyers, corbet,
neelx, sean, linux-kernel, linux-trace-kernel, linux-doc
In-Reply-To: <20260106101701.7dd20845@gandalf.local.home>
On 1/6/26 7:17 AM, Steven Rostedt wrote:
> On Mon, 5 Jan 2026 22:10:39 -0800
> Randy Dunlap <rdunlap@infradead.org> wrote:
>
>> Hi,
>>
>> On 1/5/26 6:29 AM, Aaron Tomlin wrote:
>>> diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst
>>> index 4ce01e726b09..b9efb148a5c2 100644
>>> --- a/Documentation/trace/ftrace.rst
>>> +++ b/Documentation/trace/ftrace.rst
>>> @@ -692,6 +692,14 @@ of ftrace. Here is a list of some of the key files:
>>>
>>> See events.rst for more information.
>>>
>>> + show_event_triggers:
>>> +
>>> + A list of events that have triggers. This shows the
>>> + system/event pair along with the trigger that is attached to
>>> + the event.
>>> +
>>> + See events.rst for more information.
>>> +
>>
>> Isn't this the same chunk that was in patch 1/2?
>
> No, patch 1/2 has:
>
> @@ -684,6 +684,14 @@ of ftrace. Here is a list of some of the key files:
>
> See events.rst for more information.
>
> + show_event_filters:
> +
> + A list of events that have filters. This shows the
> + system/event pair along with the filter that is attached to
> + the event.
> +
> + See events.rst for more information.
> +
> available_events:
>
>
> It is simply a s/filter/trigger/g difference though.
Ack. Thanks.
--
~Randy
^ permalink raw reply
* Re: [PATCH v2 15/18] rtla: Make stop_tracing variable volatile
From: Steven Rostedt @ 2026-01-06 16:05 UTC (permalink / raw)
To: Wander Lairson Costa
Cc: Tomas Glozar, Crystal Wood, Ivan Pravdin, Costa Shulyupin,
John Kacur, Tiezhu Yang,
open list:Real-time Linux Analysis (RTLA) tools,
open list:Real-time Linux Analysis (RTLA) tools,
open list:BPF [MISC]:Keyword:(?:b|_)bpf(?:b|_)
In-Reply-To: <20260106133655.249887-16-wander@redhat.com>
On Tue, 6 Jan 2026 08:49:51 -0300
Wander Lairson Costa <wander@redhat.com> wrote:
> Add the volatile qualifier to stop_tracing in both common.c and
> common.h to ensure all accesses to this variable bypass compiler
> optimizations and read directly from memory. This guarantees that
> when the signal handler sets stop_tracing, the change is immediately
> visible to the main program loop, preventing potential hangs or
> delayed shutdown when termination signals are received.
In the kernel, this is handled via the READ_ONCE() macro. Perhaps rtla
should implement that too.
-- Steve
^ permalink raw reply
* Re: [PATCH v2 13/18] rtla: Fix buffer size for strncpy in timerlat_aa
From: Steven Rostedt @ 2026-01-06 16:03 UTC (permalink / raw)
To: Wander Lairson Costa
Cc: Tomas Glozar, Crystal Wood, Ivan Pravdin, Costa Shulyupin,
John Kacur, Tiezhu Yang,
open list:Real-time Linux Analysis (RTLA) tools,
open list:Real-time Linux Analysis (RTLA) tools,
open list:BPF [MISC]:Keyword:(?:b|_)bpf(?:b|_)
In-Reply-To: <20260106133655.249887-14-wander@redhat.com>
On Tue, 6 Jan 2026 08:49:49 -0300
Wander Lairson Costa <wander@redhat.com> wrote:
> The run_thread_comm and current_comm character arrays in struct
> timerlat_aa_data are defined with size MAX_COMM (24 bytes), but
> strncpy() is called with MAX_COMM as the size parameter. If the
> source string is exactly MAX_COMM bytes or longer, strncpy() will
> copy exactly MAX_COMM bytes without null termination, potentially
> causing buffer overruns when these strings are later used.
We should implement something like the kernel has of "strscpy()" which not
only truncates but also adds a null terminating byte.
>
> Increase the buffer sizes to MAX_COMM+1 to ensure there is always
> room for the null terminator. This guarantees that even when strncpy()
> copies the maximum number of characters, the buffer remains properly
> null-terminated and safe to use in subsequent string operations.
>
> Signed-off-by: Wander Lairson Costa <wander@redhat.com>
> ---
> tools/tracing/rtla/src/timerlat_aa.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tools/tracing/rtla/src/timerlat_aa.c b/tools/tracing/rtla/src/timerlat_aa.c
> index 31e66ea2b144c..d310fe65abace 100644
> --- a/tools/tracing/rtla/src/timerlat_aa.c
> +++ b/tools/tracing/rtla/src/timerlat_aa.c
> @@ -47,7 +47,7 @@ struct timerlat_aa_data {
> * note: "unsigned long long" because they are fetch using tep_get_field_val();
> */
> unsigned long long run_thread_pid;
> - char run_thread_comm[MAX_COMM];
> + char run_thread_comm[MAX_COMM+1];
The reason why I suggest strscpy() is because now you just made every this
unaligned in the struct. 24 bytes fits nicely as 3 8 byte words. Now by
adding another byte, you just added 7 bytes of useless padding between this
and the next field.
-- Steve
> unsigned long long thread_blocking_duration;
> unsigned long long max_exit_idle_latency;
>
> @@ -88,7 +88,7 @@ struct timerlat_aa_data {
> /*
> * Current thread.
> */
> - char current_comm[MAX_COMM];
> + char current_comm[MAX_COMM+1];
> unsigned long long current_pid;
>
> /*
^ permalink raw reply
* Re: [PATCH v2] arm64: Disable branch profiling for all arm64 code
From: Breno Leitao @ 2026-01-06 15:46 UTC (permalink / raw)
To: Mark Rutland
Cc: Catalin Marinas, Will Deacon, Laura Abbott, linux-arm-kernel,
linux-kernel, linux-trace-kernel, Steven Rostedt,
Masami Hiramatsu, kernel-team, puranjay, stable
In-Reply-To: <aV0qxGioAXxkh6QD@J2N7QTR9R3>
On Tue, Jan 06, 2026 at 03:31:16PM +0000, Mark Rutland wrote:
> On Tue, Jan 06, 2026 at 06:05:37AM -0800, Breno Leitao wrote:
> > On Tue, Jan 06, 2026 at 12:21:47PM +0000, Mark Rutland wrote:
> > > On Tue, Jan 06, 2026 at 02:16:35AM -0800, Breno Leitao wrote:
> > > > The arm64 kernel doesn't boot with annotated branches
> > > > (PROFILE_ANNOTATED_BRANCHES) enabled and CONFIG_DEBUG_VIRTUAL together.
> > > >
> > > > Bisecting it, I found that disabling branch profiling in arch/arm64/mm
> > > > solved the problem. Narrowing down a bit further, I found that
> > > > physaddr.c is the file that needs to have branch profiling disabled to
> > > > get the machine to boot.
> > > >
> > > > I suspect that it might invoke some ftrace helper very early in the boot
> > > > process and ftrace is still not enabled(!?).
> > > >
> > > > Rather than playing whack-a-mole with individual files, disable branch
> > > > profiling for the entire arch/arm64 tree, similar to what x86 already
> > > > does in arch/x86/Kbuild.
> > > >
> > > > Cc: stable@vger.kernel.org
> > > > Fixes: ec6d06efb0bac ("arm64: Add support for CONFIG_DEBUG_VIRTUAL")
> > > > Signed-off-by: Breno Leitao <leitao@debian.org>
> > >
> > > I don't think ec6d06efb0bac is to blame here, and CONFIG_DEBUG_VIRTUAL
> > > is unsound in a number of places, so I'd prefer to remove that Fixes tag
> > > and backport this for all stable trees.
> >
> > That is fair, thanks for the review.
> >
> > Should I submit a new version without the fixes tag, or, do you guys do
> > it while merging the patch?
>
> I assume that Catalin or Will can handle that when applying (if they
> agree with me); no need to respin.
Thanks Mark.
^ permalink raw reply
* Re: [PATCH v2] arm64: Disable branch profiling for all arm64 code
From: Mark Rutland @ 2026-01-06 15:31 UTC (permalink / raw)
To: Breno Leitao
Cc: Catalin Marinas, Will Deacon, Laura Abbott, linux-arm-kernel,
linux-kernel, linux-trace-kernel, Steven Rostedt,
Masami Hiramatsu, kernel-team, puranjay, stable
In-Reply-To: <tj43kozcibuidfzoqzrvk6gsxylddfpyftkdiy7xb2zm7yncx5@z33xu7tavuts>
On Tue, Jan 06, 2026 at 06:05:37AM -0800, Breno Leitao wrote:
> On Tue, Jan 06, 2026 at 12:21:47PM +0000, Mark Rutland wrote:
> > On Tue, Jan 06, 2026 at 02:16:35AM -0800, Breno Leitao wrote:
> > > The arm64 kernel doesn't boot with annotated branches
> > > (PROFILE_ANNOTATED_BRANCHES) enabled and CONFIG_DEBUG_VIRTUAL together.
> > >
> > > Bisecting it, I found that disabling branch profiling in arch/arm64/mm
> > > solved the problem. Narrowing down a bit further, I found that
> > > physaddr.c is the file that needs to have branch profiling disabled to
> > > get the machine to boot.
> > >
> > > I suspect that it might invoke some ftrace helper very early in the boot
> > > process and ftrace is still not enabled(!?).
> > >
> > > Rather than playing whack-a-mole with individual files, disable branch
> > > profiling for the entire arch/arm64 tree, similar to what x86 already
> > > does in arch/x86/Kbuild.
> > >
> > > Cc: stable@vger.kernel.org
> > > Fixes: ec6d06efb0bac ("arm64: Add support for CONFIG_DEBUG_VIRTUAL")
> > > Signed-off-by: Breno Leitao <leitao@debian.org>
> >
> > I don't think ec6d06efb0bac is to blame here, and CONFIG_DEBUG_VIRTUAL
> > is unsound in a number of places, so I'd prefer to remove that Fixes tag
> > and backport this for all stable trees.
>
> That is fair, thanks for the review.
>
> Should I submit a new version without the fixes tag, or, do you guys do
> it while merging the patch?
I assume that Catalin or Will can handle that when applying (if they
agree with me); no need to respin.
Mark.
^ permalink raw reply
* Re: [PATCH 0/5] uprobes: transition from kmap_atomic to kmap_local_page
From: Peter Zijlstra @ 2026-01-06 15:25 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Keke Ming, mhiramat, linux, catalin.marinas, will, tsbogend, pjw,
palmer, aou, akpm, linux-kernel, linux-trace-kernel, linux-mm,
linux-arm-kernel, linux-mips, linux-riscv
In-Reply-To: <aVj146EunyaOQzxO@redhat.com>
On Sat, Jan 03, 2026 at 11:56:35AM +0100, Oleg Nesterov wrote:
> On 01/03, Keke Ming wrote:
> >
> > Keke Ming (5):
> > riscv/uprobes: use kmap_local_page() in arch_uprobe_copy_ixol()
> > arm64/uprobes: use kmap_local_page() in arch_uprobe_copy_ixol()
> > mips/uprobes: use kmap_local_page() in arch_uprobe_copy_ixol()
> > arm/uprobes: use kmap_local_page() in arch_uprobe_copy_ixol()
> > uprobes: use kmap_local_page() for temporary page mappings
> >
> > arch/arm/probes/uprobes/core.c | 4 ++--
> > arch/arm64/kernel/probes/uprobes.c | 4 ++--
> > arch/mips/kernel/uprobes.c | 4 ++--
> > arch/riscv/kernel/probes/uprobes.c | 4 ++--
> > kernel/events/uprobes.c | 12 ++++++------
> > 5 files changed, 14 insertions(+), 14 deletions(-)
>
> Thanks,
>
> Acked-by: Oleg Nesterov <oleg@redhat.com>
Let me go stick them in tip/perf/core
^ permalink raw reply
* Re: [v2 PATCH 2/2] tracing: Add show_event_triggers to expose active event triggers
From: Steven Rostedt @ 2026-01-06 15:17 UTC (permalink / raw)
To: Randy Dunlap
Cc: Aaron Tomlin, mhiramat, mark.rutland, mathieu.desnoyers, corbet,
neelx, sean, linux-kernel, linux-trace-kernel, linux-doc
In-Reply-To: <95feb439-2298-4539-8833-e05ed06f273b@infradead.org>
On Mon, 5 Jan 2026 22:10:39 -0800
Randy Dunlap <rdunlap@infradead.org> wrote:
> Hi,
>
> On 1/5/26 6:29 AM, Aaron Tomlin wrote:
> > diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst
> > index 4ce01e726b09..b9efb148a5c2 100644
> > --- a/Documentation/trace/ftrace.rst
> > +++ b/Documentation/trace/ftrace.rst
> > @@ -692,6 +692,14 @@ of ftrace. Here is a list of some of the key files:
> >
> > See events.rst for more information.
> >
> > + show_event_triggers:
> > +
> > + A list of events that have triggers. This shows the
> > + system/event pair along with the trigger that is attached to
> > + the event.
> > +
> > + See events.rst for more information.
> > +
>
> Isn't this the same chunk that was in patch 1/2?
No, patch 1/2 has:
@@ -684,6 +684,14 @@ of ftrace. Here is a list of some of the key files:
See events.rst for more information.
+ show_event_filters:
+
+ A list of events that have filters. This shows the
+ system/event pair along with the filter that is attached to
+ the event.
+
+ See events.rst for more information.
+
available_events:
It is simply a s/filter/trigger/g difference though.
-- Steve
^ permalink raw reply
* Re: [RFC PATCH 1/2] rcu: Add rcu_read_lock_notrace()
From: Mathieu Desnoyers @ 2026-01-06 15:08 UTC (permalink / raw)
To: paulmck
Cc: Steven Rostedt, Sebastian Andrzej Siewior, Boqun Feng,
linux-rt-devel, rcu, linux-trace-kernel, Frederic Weisbecker,
Joel Fernandes, Josh Triplett, Lai Jiangshan, Masami Hiramatsu,
Neeraj Upadhyay, Thomas Gleixner, Uladzislau Rezki, Zqiang, bpf
In-Reply-To: <2f8bb8bb-320e-480f-9a56-8eb5cbd4438a@paulmck-laptop>
On 2025-07-17 11:18, Paul E. McKenney wrote:
> On Thu, Jul 17, 2025 at 10:46:46AM -0400, Mathieu Desnoyers wrote:
>> On 2025-07-17 09:14, Mathieu Desnoyers wrote:
>>> On 2025-07-16 18:54, Paul E. McKenney wrote:
>> [...]
>>>
>>> 2) I think I'm late to the party in reviewing srcu-fast, I'll
>>> go have a look :)
>>
>> OK, I'll bite. :) Please let me know where I'm missing something:
>>
>> Looking at srcu-lite and srcu-fast, I understand that they fundamentally
>> depend on a trick we published here https://lwn.net/Articles/573497/
>> "The RCU-barrier menagerie" that allows turning, e.g. this Dekker:
>>
>> volatile int x = 0, y = 0
>>
>> CPU 0 CPU 1
>>
>> x = 1 y = 1
>> smp_mb smp_mb
>> r2 = y r4 = x
>>
>> BUG_ON(r2 == 0 && r4 == 0)
>>
>> into
>>
>> volatile int x = 0, y = 0
>>
>> CPU 0 CPU 1
>>
>> rcu_read_lock()
>> x = 1 y = 1
>> synchronize_rcu()
>> r2 = y r4 = x
>> rcu_read_unlock()
>>
>> BUG_ON(r2 == 0 && r4 == 0)
>>
>> So looking at srcu-fast, we have:
>>
>> * Note that both this_cpu_inc() and atomic_long_inc() are RCU read-side
>> * critical sections either because they disables interrupts, because they
>> * are a single instruction, or because they are a read-modify-write atomic
>> * operation, depending on the whims of the architecture.
>>
>> It appears to be pairing, as RCU read-side:
>>
>> - irq off/on implied by this_cpu_inc
>> - atomic
>> - single instruction
>>
>> with synchronize_rcu within the grace period, and hope that this behaves as a
>> smp_mb pairing preventing the srcu read-side critical section from leaking
>> out of the srcu read lock/unlock.
>>
>> I note that there is a validation that rcu_is_watching() within
>> __srcu_read_lock_fast, but it's one thing to have rcu watching, but
>> another to have an actual read-side critical section. Note that
>> preemption, irqs, softirqs can very well be enabled when calling
>> __srcu_read_lock_fast.
>>
>> My understanding of the how memory barriers implemented with RCU
>> work is that we need to surround the memory accesses on the fast-path
>> (where we turn smp_mb into barrier) with an RCU read-side critical
>> section to make sure it does not spawn across a synchronize_rcu.
>>
>> What I am missing here is how can a RCU side-side that only consist
>> of the irq off/on or atomic or single instruction cover all memory
>> accesses we are trying to order, namely those within the srcu
>> critical section after the compiler barrier() ? Is having RCU
>> watching sufficient to guarantee this ?
>
> Good eyes!!!
>
> The trick is that this "RCU read-side critical section" consists only of
> either this_cpu_inc() or atomic_long_inc(), with the latter only happening
> in systems that have NMIs, but don't have NMI-safe per-CPU operations.
> Neither this_cpu_inc() nor atomic_long_inc() can be interrupted, and
> thus both act as an interrupts-disabled RCU read-side critical section.
>
> Therefore, if the SRCU grace-period computation fails to see an
> srcu_read_lock_fast() increment, its earlier code is guaranteed to
> happen before the corresponding critical section. Similarly, if the SRCU
> grace-period computation sees an srcu_read_unlock_fast(), its subsequent
> code is guaranteed to happen after the corresponding critical section.
>
> Does that help? If so, would you be interested and nominating a comment?
>
> Or am I missing something subtle here?
>
> Either way, many thanks for digging into this!!!
Re-reading the comment and your explanation, I think the comments are
clear enough. One nit I found while reading though:
include/linux/srcutree.h:
* Note that both this_cpu_inc() and atomic_long_inc() are RCU read-side
* critical sections either because they disables interrupts, because
disables -> disable
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
^ permalink raw reply
* Re: [PATCH v2] arm64: Disable branch profiling for all arm64 code
From: Breno Leitao @ 2026-01-06 14:05 UTC (permalink / raw)
To: Mark Rutland
Cc: Catalin Marinas, Will Deacon, Laura Abbott, linux-arm-kernel,
linux-kernel, linux-trace-kernel, Steven Rostedt,
Masami Hiramatsu, kernel-team, puranjay, stable
In-Reply-To: <aVz-NHMG7rSJ9u1N@J2N7QTR9R3>
On Tue, Jan 06, 2026 at 12:21:47PM +0000, Mark Rutland wrote:
> On Tue, Jan 06, 2026 at 02:16:35AM -0800, Breno Leitao wrote:
> > The arm64 kernel doesn't boot with annotated branches
> > (PROFILE_ANNOTATED_BRANCHES) enabled and CONFIG_DEBUG_VIRTUAL together.
> >
> > Bisecting it, I found that disabling branch profiling in arch/arm64/mm
> > solved the problem. Narrowing down a bit further, I found that
> > physaddr.c is the file that needs to have branch profiling disabled to
> > get the machine to boot.
> >
> > I suspect that it might invoke some ftrace helper very early in the boot
> > process and ftrace is still not enabled(!?).
> >
> > Rather than playing whack-a-mole with individual files, disable branch
> > profiling for the entire arch/arm64 tree, similar to what x86 already
> > does in arch/x86/Kbuild.
> >
> > Cc: stable@vger.kernel.org
> > Fixes: ec6d06efb0bac ("arm64: Add support for CONFIG_DEBUG_VIRTUAL")
> > Signed-off-by: Breno Leitao <leitao@debian.org>
>
> I don't think ec6d06efb0bac is to blame here, and CONFIG_DEBUG_VIRTUAL
> is unsound in a number of places, so I'd prefer to remove that Fixes tag
> and backport this for all stable trees.
That is fair, thanks for the review.
Should I submit a new version without the fixes tag, or, do you guys do
it while merging the patch?
thanks
--breno
^ permalink raw reply
* [PATCH v2 18/18] rtla: Simplify code by caching string lengths
From: Wander Lairson Costa @ 2026-01-06 11:49 UTC (permalink / raw)
To: Steven Rostedt, Tomas Glozar, Wander Lairson Costa, Crystal Wood,
Ivan Pravdin, Costa Shulyupin, John Kacur, Tiezhu Yang,
open list:Real-time Linux Analysis (RTLA) tools,
open list:Real-time Linux Analysis (RTLA) tools,
open list:BPF [MISC]:Keyword:(?:b|_)bpf(?:b|_)
In-Reply-To: <20260106133655.249887-1-wander@redhat.com>
Simplify trace_event_save_hist() and set_comm_cgroup() by computing
string lengths once and storing them in local variables, rather than
calling strlen() multiple times on the same unchanged strings. This
makes the code clearer by eliminating redundant function calls and
improving readability.
In trace_event_save_hist(), the write loop previously called strlen()
on the hist buffer twice per iteration for both the size calculation
and loop condition. Store the length in hist_len before entering the
loop. In set_comm_cgroup(), strlen() was called on cgroup_path up to
three times in succession. Store the result in cg_path_len to use in
both the offset calculation and size parameter for subsequent append
operations.
This simplification makes the code easier to read and maintain without
changing program behavior.
Signed-off-by: Wander Lairson Costa <wander@redhat.com>
---
tools/tracing/rtla/src/trace.c | 6 ++++--
tools/tracing/rtla/src/utils.c | 11 +++++++----
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/tools/tracing/rtla/src/trace.c b/tools/tracing/rtla/src/trace.c
index 092fcab77dc4c..223ab97e50aed 100644
--- a/tools/tracing/rtla/src/trace.c
+++ b/tools/tracing/rtla/src/trace.c
@@ -346,6 +346,7 @@ static void trace_event_save_hist(struct trace_instance *instance,
mode_t mode = 0644;
char path[MAX_PATH];
char *hist;
+ size_t hist_len;
if (!tevent)
return;
@@ -376,9 +377,10 @@ static void trace_event_save_hist(struct trace_instance *instance,
}
index = 0;
+ hist_len = strlen(hist);
do {
- index += write(out_fd, &hist[index], strlen(hist) - index);
- } while (index < strlen(hist));
+ index += write(out_fd, &hist[index], hist_len - index);
+ } while (index < hist_len);
free(hist);
out_close:
diff --git a/tools/tracing/rtla/src/utils.c b/tools/tracing/rtla/src/utils.c
index 4093030e446ab..aee7f02b1e9b4 100644
--- a/tools/tracing/rtla/src/utils.c
+++ b/tools/tracing/rtla/src/utils.c
@@ -870,6 +870,7 @@ int set_comm_cgroup(const char *comm_prefix, const char *cgroup)
DIR *procfs;
int retval;
int cg_fd;
+ size_t cg_path_len;
if (strlen(comm_prefix) >= MAX_PATH) {
err_msg("Command prefix is too long: %d < strlen(%s)\n",
@@ -883,16 +884,18 @@ int set_comm_cgroup(const char *comm_prefix, const char *cgroup)
return 0;
}
+ cg_path_len = strlen(cgroup_path);
+
if (!cgroup) {
- retval = get_self_cgroup(&cgroup_path[strlen(cgroup_path)],
- sizeof(cgroup_path) - strlen(cgroup_path));
+ retval = get_self_cgroup(&cgroup_path[cg_path_len],
+ sizeof(cgroup_path) - cg_path_len);
if (!retval) {
err_msg("Did not find self cgroup\n");
return 0;
}
} else {
- snprintf(&cgroup_path[strlen(cgroup_path)],
- sizeof(cgroup_path) - strlen(cgroup_path), "%s/", cgroup);
+ snprintf(&cgroup_path[cg_path_len],
+ sizeof(cgroup_path) - cg_path_len, "%s/", cgroup);
}
snprintf(cgroup_procs, MAX_PATH, "%s/cgroup.procs", cgroup_path);
--
2.52.0
^ permalink raw reply related
* [PATCH v2 17/18] rtla: Fix parse_cpu_set() return value documentation
From: Wander Lairson Costa @ 2026-01-06 11:49 UTC (permalink / raw)
To: Steven Rostedt, Tomas Glozar, Wander Lairson Costa, Ivan Pravdin,
Crystal Wood, Costa Shulyupin, John Kacur, Tiezhu Yang,
open list:Real-time Linux Analysis (RTLA) tools,
open list:Real-time Linux Analysis (RTLA) tools,
open list:BPF [MISC]:Keyword:(?:b|_)bpf(?:b|_)
In-Reply-To: <20260106133655.249887-1-wander@redhat.com>
Correct the return value documentation for parse_cpu_set() function
in utils.c. The comment incorrectly stated that the function returns
1 on success and 0 on failure, but the actual implementation returns
0 on success and 1 on failure, following the common error-on-nonzero
convention used throughout the codebase.
This documentation fix ensures that developers reading the code
understand the correct return value semantics and prevents potential
misuse of the function's return value in conditional checks.
Signed-off-by: Wander Lairson Costa <wander@redhat.com>
---
tools/tracing/rtla/src/utils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/tracing/rtla/src/utils.c b/tools/tracing/rtla/src/utils.c
index 508b8891acd86..4093030e446ab 100644
--- a/tools/tracing/rtla/src/utils.c
+++ b/tools/tracing/rtla/src/utils.c
@@ -113,7 +113,7 @@ void get_duration(time_t start_time, char *output, int output_size)
* Receives a cpu list, like 1-3,5 (cpus 1, 2, 3, 5), and then set
* filling cpu_set_t argument.
*
- * Returns 1 on success, 0 otherwise.
+ * Returns 0 on success, 1 otherwise.
*/
int parse_cpu_set(char *cpu_list, cpu_set_t *set)
{
--
2.52.0
^ permalink raw reply related
* [PATCH v2 16/18] rtla: Ensure null termination after read operations in utils.c
From: Wander Lairson Costa @ 2026-01-06 11:49 UTC (permalink / raw)
To: Steven Rostedt, Tomas Glozar, Wander Lairson Costa, Ivan Pravdin,
Crystal Wood, Costa Shulyupin, John Kacur, Tiezhu Yang,
open list:Real-time Linux Analysis (RTLA) tools,
open list:Real-time Linux Analysis (RTLA) tools,
open list:BPF [MISC]:Keyword:(?:b|_)bpf(?:b|_)
In-Reply-To: <20260106133655.249887-1-wander@redhat.com>
Add explicit null termination and buffer initialization for read()
operations in procfs_is_workload_pid() and get_self_cgroup() functions.
The read() system call does not null-terminate the data it reads, and
when the buffer is filled to capacity, subsequent string operations
will read past the buffer boundary searching for a null terminator.
In procfs_is_workload_pid(), explicitly set buffer[MAX_PATH-1] to '\0'
to ensure the buffer is always null-terminated before passing it to
strncmp(). In get_self_cgroup(), use memset() to zero the path buffer
before reading, which ensures null termination when retval is less than
MAX_PATH. Additionally, set path[MAX_PATH-1] to '\0' after the read to
handle the case where the buffer is filled completely.
These defensive buffer handling practices prevent potential buffer
overruns and align with the ongoing buffer safety improvements across
the rtla codebase.
Signed-off-by: Wander Lairson Costa <wander@redhat.com>
---
tools/tracing/rtla/src/utils.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/tracing/rtla/src/utils.c b/tools/tracing/rtla/src/utils.c
index e0f31e5cae844..508b8891acd86 100644
--- a/tools/tracing/rtla/src/utils.c
+++ b/tools/tracing/rtla/src/utils.c
@@ -317,6 +317,7 @@ static int procfs_is_workload_pid(const char *comm_prefix, struct dirent *proc_e
if (retval <= 0)
return 0;
+ buffer[MAX_PATH-1] = '\0';
retval = strncmp(comm_prefix, buffer, strlen(comm_prefix));
if (retval)
return 0;
@@ -750,6 +751,7 @@ static int get_self_cgroup(char *self_cg, int sizeof_self_cg)
if (fd < 0)
return 0;
+ memset(path, 0, sizeof(path));
retval = read(fd, path, MAX_PATH);
close(fd);
@@ -757,6 +759,7 @@ static int get_self_cgroup(char *self_cg, int sizeof_self_cg)
if (retval <= 0)
return 0;
+ path[MAX_PATH-1] = '\0';
start = path;
start = strstr(start, ":");
--
2.52.0
^ permalink raw reply related
* [PATCH v2 15/18] rtla: Make stop_tracing variable volatile
From: Wander Lairson Costa @ 2026-01-06 11:49 UTC (permalink / raw)
To: Steven Rostedt, Tomas Glozar, Wander Lairson Costa, Crystal Wood,
Ivan Pravdin, Costa Shulyupin, John Kacur, Tiezhu Yang,
open list:Real-time Linux Analysis (RTLA) tools,
open list:Real-time Linux Analysis (RTLA) tools,
open list:BPF [MISC]:Keyword:(?:b|_)bpf(?:b|_)
In-Reply-To: <20260106133655.249887-1-wander@redhat.com>
The stop_tracing global variable is accessed from both the signal
handler context and the main program flow without synchronization.
This creates a potential race condition where compiler optimizations
could cache the variable value in registers, preventing the signal
handler's updates from being visible to other parts of the program.
Add the volatile qualifier to stop_tracing in both common.c and
common.h to ensure all accesses to this variable bypass compiler
optimizations and read directly from memory. This guarantees that
when the signal handler sets stop_tracing, the change is immediately
visible to the main program loop, preventing potential hangs or
delayed shutdown when termination signals are received.
Signed-off-by: Wander Lairson Costa <wander@redhat.com>
---
tools/tracing/rtla/src/common.c | 2 +-
tools/tracing/rtla/src/common.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/tracing/rtla/src/common.c b/tools/tracing/rtla/src/common.c
index d608ffe12e7b0..1e6542a1e9630 100644
--- a/tools/tracing/rtla/src/common.c
+++ b/tools/tracing/rtla/src/common.c
@@ -8,7 +8,7 @@
#include "common.h"
struct trace_instance *trace_inst;
-int stop_tracing;
+volatile int stop_tracing;
static void stop_trace(int sig)
{
diff --git a/tools/tracing/rtla/src/common.h b/tools/tracing/rtla/src/common.h
index f2c9e21c03651..283641f3e7c9b 100644
--- a/tools/tracing/rtla/src/common.h
+++ b/tools/tracing/rtla/src/common.h
@@ -54,7 +54,7 @@ struct osnoise_context {
};
extern struct trace_instance *trace_inst;
-extern int stop_tracing;
+extern volatile int stop_tracing;
struct hist_params {
char no_irq;
--
2.52.0
^ permalink raw reply related
* [PATCH v2 14/18] rtla: Add generated output files to gitignore
From: Wander Lairson Costa @ 2026-01-06 11:49 UTC (permalink / raw)
To: Steven Rostedt, Tomas Glozar, Wander Lairson Costa, Crystal Wood,
Ivan Pravdin, Costa Shulyupin, John Kacur, Tiezhu Yang,
open list:Real-time Linux Analysis (RTLA) tools,
open list:Real-time Linux Analysis (RTLA) tools,
open list:BPF [MISC]:Keyword:(?:b|_)bpf(?:b|_)
In-Reply-To: <20260106133655.249887-1-wander@redhat.com>
The rtla tool generates various output files during testing and
execution, including custom trace outputs and histogram data. These
files are artifacts of running the tool with different options and
should not be tracked in version control.
Add gitignore entries for custom_filename.txt, osnoise_irq_noise_hist.txt,
osnoise_trace.txt, and timerlat_trace.txt to prevent accidentally
committing these generated files. This aligns with the existing pattern
of ignoring build artifacts and generated headers like *.skel.h.
Signed-off-by: Wander Lairson Costa <wander@redhat.com>
---
tools/tracing/rtla/.gitignore | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/tools/tracing/rtla/.gitignore b/tools/tracing/rtla/.gitignore
index 1a394ad26cc1e..4d39d64ac08c0 100644
--- a/tools/tracing/rtla/.gitignore
+++ b/tools/tracing/rtla/.gitignore
@@ -5,3 +5,7 @@ fixdep
feature
FEATURE-DUMP
*.skel.h
+custom_filename.txt
+osnoise_irq_noise_hist.txt
+osnoise_trace.txt
+timerlat_trace.txt
--
2.52.0
^ permalink raw reply related
* [PATCH v2 13/18] rtla: Fix buffer size for strncpy in timerlat_aa
From: Wander Lairson Costa @ 2026-01-06 11:49 UTC (permalink / raw)
To: Steven Rostedt, Tomas Glozar, Wander Lairson Costa, Crystal Wood,
Ivan Pravdin, Costa Shulyupin, John Kacur, Tiezhu Yang,
open list:Real-time Linux Analysis (RTLA) tools,
open list:Real-time Linux Analysis (RTLA) tools,
open list:BPF [MISC]:Keyword:(?:b|_)bpf(?:b|_)
In-Reply-To: <20260106133655.249887-1-wander@redhat.com>
The run_thread_comm and current_comm character arrays in struct
timerlat_aa_data are defined with size MAX_COMM (24 bytes), but
strncpy() is called with MAX_COMM as the size parameter. If the
source string is exactly MAX_COMM bytes or longer, strncpy() will
copy exactly MAX_COMM bytes without null termination, potentially
causing buffer overruns when these strings are later used.
Increase the buffer sizes to MAX_COMM+1 to ensure there is always
room for the null terminator. This guarantees that even when strncpy()
copies the maximum number of characters, the buffer remains properly
null-terminated and safe to use in subsequent string operations.
Signed-off-by: Wander Lairson Costa <wander@redhat.com>
---
tools/tracing/rtla/src/timerlat_aa.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/tracing/rtla/src/timerlat_aa.c b/tools/tracing/rtla/src/timerlat_aa.c
index 31e66ea2b144c..d310fe65abace 100644
--- a/tools/tracing/rtla/src/timerlat_aa.c
+++ b/tools/tracing/rtla/src/timerlat_aa.c
@@ -47,7 +47,7 @@ struct timerlat_aa_data {
* note: "unsigned long long" because they are fetch using tep_get_field_val();
*/
unsigned long long run_thread_pid;
- char run_thread_comm[MAX_COMM];
+ char run_thread_comm[MAX_COMM+1];
unsigned long long thread_blocking_duration;
unsigned long long max_exit_idle_latency;
@@ -88,7 +88,7 @@ struct timerlat_aa_data {
/*
* Current thread.
*/
- char current_comm[MAX_COMM];
+ char current_comm[MAX_COMM+1];
unsigned long long current_pid;
/*
--
2.52.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox