* Re: [PATCH v3 1/2] mm: vmscan: add cgroup IDs to vmscan tracepoints
From: Andrew Morton @ 2026-01-07 18:32 UTC (permalink / raw)
To: Shakeel Butt
Cc: Thomas Ballasi, linux-mm, linux-trace-kernel, mhiramat, rostedt
In-Reply-To: <ovqxo2mmjiuymqk36t2xydcyzvtppcqsog62yx3qtwsknbkgzq@3phadh5gfyjd>
On Wed, 7 Jan 2026 10:14:53 -0800 Shakeel Butt <shakeel.butt@linux.dev> wrote:
> On Mon, Jan 05, 2026 at 02:46:39PM -0800, Shakeel Butt wrote:
> [...]
> >
> > Orthogonally I am cleaning up memcg id usage and after that cleanup,
> > mem_cgroup_id() would be preferred way to get the ID. No need to do
> > anything now as I will cleanup this usage later as well.
>
> The series has been landed in mm-new. Please use mem_cgroup_id() instead
> of cgroup_id(memcg->css.cgroup).
fyi, I removed this series yesterday due to a CONFIG_MEMCG=n build failure.
^ permalink raw reply
* Re: [PATCH v1] tracing: Avoid possible signed 64-bit truncation
From: Steven Rostedt @ 2026-01-07 19:26 UTC (permalink / raw)
To: Ian Rogers
Cc: Masami Hiramatsu, Mathieu Desnoyers, linux-kernel,
linux-trace-kernel
In-Reply-To: <20251209213135.13eb68f4@fedora>
On Tue, 9 Dec 2025 21:31:35 -0500
Steven Rostedt <rostedt@goodmis.org> wrote:
> > ---
> > kernel/trace/trace.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> > index d1e527cf2aae..e6a80cbe9326 100644
> > --- a/kernel/trace/trace.c
> > +++ b/kernel/trace/trace.c
> > @@ -6057,8 +6057,10 @@ static int cmp_mod_entry(const void *key, const void *pivot)
> >
> > if (addr >= ent[0].mod_addr && addr < ent[1].mod_addr)
> > return 0;
> > + else if (addr > ent->mod_addr)
> > + return 1;
> > else
> > - return addr - ent->mod_addr;
> > + return -1;
>
> Could we still keep this down to a single if check?
>
> if (addr < ent->mod_addr)
> return -1;
>
> return addr >= ent[1].mod_addr;
Care to send a v2?
-- Steve
^ permalink raw reply
* Re: [PATCH v1] tracing: Avoid possible signed 64-bit truncation
From: Ian Rogers @ 2026-01-07 19:40 UTC (permalink / raw)
To: Steven Rostedt
Cc: Masami Hiramatsu, Mathieu Desnoyers, linux-kernel,
linux-trace-kernel
In-Reply-To: <20260107142632.0dec5b10@gandalf.local.home>
On Wed, Jan 7, 2026 at 11:26 AM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Tue, 9 Dec 2025 21:31:35 -0500
> Steven Rostedt <rostedt@goodmis.org> wrote:
>
> > > ---
> > > kernel/trace/trace.c | 4 +++-
> > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> > > index d1e527cf2aae..e6a80cbe9326 100644
> > > --- a/kernel/trace/trace.c
> > > +++ b/kernel/trace/trace.c
> > > @@ -6057,8 +6057,10 @@ static int cmp_mod_entry(const void *key, const void *pivot)
> > >
> > > if (addr >= ent[0].mod_addr && addr < ent[1].mod_addr)
> > > return 0;
> > > + else if (addr > ent->mod_addr)
> > > + return 1;
> > > else
> > > - return addr - ent->mod_addr;
> > > + return -1;
> >
> > Could we still keep this down to a single if check?
> >
> > if (addr < ent->mod_addr)
> > return -1;
> >
> > return addr >= ent[1].mod_addr;
>
> Care to send a v2?
Will do, sorry for the delay.
Ian
> -- Steve
^ permalink raw reply
* Re: [PATCH v4 1/2] kallsyms: Always initialize modbuildid on ftrace address
From: Steven Rostedt @ 2026-01-07 19:44 UTC (permalink / raw)
To: Maurice Hieronymus
Cc: ast, daniel, john.fastabend, andrii, martin.lau, eddyz87, song,
yonghong.song, kpsingh, sdf, haoluo, jolsa, mhiramat,
mark.rutland, mathieu.desnoyers, georges.aureau, bpf,
linux-kernel, linux-trace-kernel
In-Reply-To: <20251220181838.63242-2-mhi@mailbox.org>
On Sat, 20 Dec 2025 19:18:37 +0100
Maurice Hieronymus <mhi@mailbox.org> wrote:
> modbuildid is never set when kallsyms_lookup_buildid is returning via
> successful ftrace_mod_address_lookup.
>
> This leads to an uninitialized pointer dereference on x86 when
> CONFIG_STACKTRACE_BUILD_ID=y inside __sprint_symbol.
>
Nothing should be getting a buildid from the ftrace kallsyms lookup.
This code is used to find the names of init functions of modules after
those init functions have been freed. Nothing but ftrace should be looking
for these addresses, and ftrace doesn't care about buildids.
-- Steve
^ permalink raw reply
* Re: [PATCH v3 1/2] mm: vmscan: add cgroup IDs to vmscan tracepoints
From: Shakeel Butt @ 2026-01-07 20:35 UTC (permalink / raw)
To: Andrew Morton
Cc: Thomas Ballasi, linux-mm, linux-trace-kernel, mhiramat, rostedt
In-Reply-To: <20260107103208.e64fe3c26d02bfcb21404dd9@linux-foundation.org>
On Wed, Jan 07, 2026 at 10:32:08AM -0800, Andrew Morton wrote:
> On Wed, 7 Jan 2026 10:14:53 -0800 Shakeel Butt <shakeel.butt@linux.dev> wrote:
>
> > On Mon, Jan 05, 2026 at 02:46:39PM -0800, Shakeel Butt wrote:
> > [...]
> > >
> > > Orthogonally I am cleaning up memcg id usage and after that cleanup,
> > > mem_cgroup_id() would be preferred way to get the ID. No need to do
> > > anything now as I will cleanup this usage later as well.
> >
> > The series has been landed in mm-new. Please use mem_cgroup_id() instead
> > of cgroup_id(memcg->css.cgroup).
>
> fyi, I removed this series yesterday due to a CONFIG_MEMCG=n build failure.
Oh sorry, I meant my series [1] landed in mm-new and with that Thomas
can directly use mem_cgroup_id() without worrying about CONFIG_MEMCG=n.
[1] https://lkml.kernel.org/r/20251225232116.294540-1-shakeel.butt@linux.dev
^ permalink raw reply
* [syzbot ci] Re: bpf: Fix memory access flags in helper prototypes
From: syzbot ci @ 2026-01-07 21:01 UTC (permalink / raw)
To: andrii, ast, bpf, daniel, davem, dxu, eddyz87, edumazet,
electronlsr, ftyghome, gplhust955, haoluo, haoran.ni.cs, horms,
john.fastabend, jolsa, kpsingh, kuba, linux-kernel,
linux-trace-kernel, martin.lau, mathieu.desnoyers, mattbobrowski,
mhiramat, netdev, pabeni, rostedt, sdf, song, yonghong.song
Cc: syzbot, syzkaller-bugs
In-Reply-To: <20260107-helper_proto-v1-0-e387e08271cc@gmail.com>
syzbot ci has tested the following series
[v1] bpf: Fix memory access flags in helper prototypes
https://lore.kernel.org/all/20260107-helper_proto-v1-0-e387e08271cc@gmail.com
* [PATCH bpf 1/2] bpf: Fix memory access flags in helper prototypes
* [PATCH bpf 2/2] bpf: Require ARG_PTR_TO_MEM with memory flag
and found the following issue:
WARNING in check_helper_call
Full report is available here:
https://ci.syzbot.org/series/020c2fa8-b95d-4273-9bc0-2f82fa714a8e
***
WARNING in check_helper_call
tree: bpf
URL: https://kernel.googlesource.com/pub/scm/linux/kernel/git/bpf/bpf.git
base: ab86d0bf01f6d0e37fd67761bb62918321b64efc
arch: amd64
compiler: Debian clang version 21.1.8 (++20251202083448+f68f64eb8130-1~exp1~20251202083504.46), Debian LLD 21.1.8
config: https://ci.syzbot.org/builds/9a24b0e7-35e4-4718-b939-3b210b6b5126/config
C repro: https://ci.syzbot.org/findings/8fcbdcf8-4480-46d8-b7a8-f1de9401a8ac/c_repro
syz repro: https://ci.syzbot.org/findings/8fcbdcf8-4480-46d8-b7a8-f1de9401a8ac/syz_repro
------------[ cut here ]------------
verifier bug: incorrect func proto bpf_tcp_raw_check_syncookie_ipv6#207
WARNING: kernel/bpf/verifier.c:11546 at check_helper_call+0xc00/0x6e10 kernel/bpf/verifier.c:11546, CPU#0: syz.0.17/5981
Modules linked in:
CPU: 0 UID: 0 PID: 5981 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
RIP: 0010:check_helper_call+0xc16/0x6e10 kernel/bpf/verifier.c:11546
Code: ef e6 ff 49 bf 00 00 00 00 00 fc ff df 48 8d 1d a0 c2 ea 0d 44 8b 64 24 24 44 89 e7 e8 d3 32 0c 00 48 89 df 48 89 c6 44 89 e2 <67> 48 0f b9 3a 49 81 c6 80 08 00 00 44 89 e7 e8 b6 32 0c 00 4c 89
RSP: 0018:ffffc90007116fa0 EFLAGS: 00010246
RAX: ffffffff8b934740 RBX: ffffffff8fc645d0 RCX: dffffc0000000000
RDX: 00000000000000cf RSI: ffffffff8b934740 RDI: ffffffff8fc645d0
RBP: ffffc900071171b0 R08: ffff88816b42ba80 R09: 0000000000000002
R10: 0000000000000004 R11: 0000000000000000 R12: 00000000000000cf
R13: f8f8f8f8f8f8f8f8 R14: ffff888112440000 R15: dffffc0000000000
FS: 000055557af7b500(0000) GS:ffff88818e40e000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fd892207dac CR3: 0000000161682000 CR4: 00000000000006f0
Call Trace:
<TASK>
do_check_insn kernel/bpf/verifier.c:20417 [inline]
do_check+0x99eb/0xec30 kernel/bpf/verifier.c:20598
do_check_common+0x19cc/0x25b0 kernel/bpf/verifier.c:23882
do_check_main kernel/bpf/verifier.c:23965 [inline]
bpf_check+0x5f0d/0x1c4a0 kernel/bpf/verifier.c:25272
bpf_prog_load+0x1484/0x1ae0 kernel/bpf/syscall.c:3088
__sys_bpf+0x570/0x920 kernel/bpf/syscall.c:6164
__do_sys_bpf kernel/bpf/syscall.c:6274 [inline]
__se_sys_bpf kernel/bpf/syscall.c:6272 [inline]
__x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:6272
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fd891f9acb9
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffee24b6bb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000141
RAX: ffffffffffffffda RBX: 00007fd892205fa0 RCX: 00007fd891f9acb9
RDX: 0000000000000094 RSI: 0000200000000300 RDI: 0000000000000005
RBP: 00007fd892008bf7 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fd892205fac R14: 00007fd892205fa0 R15: 00007fd892205fa0
</TASK>
----------------
Code disassembly (best guess):
0: ef out %eax,(%dx)
1: e6 ff out %al,$0xff
3: 49 bf 00 00 00 00 00 movabs $0xdffffc0000000000,%r15
a: fc ff df
d: 48 8d 1d a0 c2 ea 0d lea 0xdeac2a0(%rip),%rbx # 0xdeac2b4
14: 44 8b 64 24 24 mov 0x24(%rsp),%r12d
19: 44 89 e7 mov %r12d,%edi
1c: e8 d3 32 0c 00 call 0xc32f4
21: 48 89 df mov %rbx,%rdi
24: 48 89 c6 mov %rax,%rsi
27: 44 89 e2 mov %r12d,%edx
* 2a: 67 48 0f b9 3a ud1 (%edx),%rdi <-- trapping instruction
2f: 49 81 c6 80 08 00 00 add $0x880,%r14
36: 44 89 e7 mov %r12d,%edi
39: e8 b6 32 0c 00 call 0xc32f4
3e: 4c rex.WR
3f: 89 .byte 0x89
***
If these findings have caused you to resend the series or submit a
separate fix, please add the following tag to your commit message:
Tested-by: syzbot@syzkaller.appspotmail.com
---
This report is generated by a bot. It may contain errors.
syzbot ci engineers can be reached at syzkaller@googlegroups.com.
^ permalink raw reply
* [PATCH] tracing: Check the return value of tracing_update_buffers()
From: Steven Rostedt @ 2026-01-07 21:15 UTC (permalink / raw)
To: LKML, Linux Trace Kernel; +Cc: Masami Hiramatsu, Mathieu Desnoyers, Li Zhong
From: Steven Rostedt <rostedt@goodmis.org>
In the very unlikely event that tracing_update_buffers() fails in
trace_printk_init_buffers(), report the failure so that it is known.
Link: https://lore.kernel.org/all/20220917020353.3836285-1-floridsleeves@gmail.com/
Suggested-by: Li Zhong <floridsleeves@gmail.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
---
kernel/trace/trace.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 2d387d56dcd4..1722e01e2238 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -3418,9 +3418,10 @@ void trace_printk_init_buffers(void)
pr_warn("**********************************************************\n");
/* Expand the buffers to set size */
- tracing_update_buffers(&global_trace);
-
- buffers_allocated = 1;
+ if (tracing_update_buffers(&global_trace) < 0)
+ pr_err("Failed to expand tracing buffers for trace_printk() calls\n");
+ else
+ buffers_allocated = 1;
/*
* trace_printk_init_buffers() can be called by modules.
--
2.51.0
^ permalink raw reply related
* Re: [PATCH] riscv: trace: fix snapshot deadlock with sbi ecall
From: Paul Walmsley @ 2026-01-07 22:36 UTC (permalink / raw)
To: Martin Kaiser
Cc: Paul Walmsley, Palmer Dabbelt, linux-riscv, linux-trace-kernel,
linux-kernel
In-Reply-To: <20251223135043.1336524-1-martin@kaiser.cx>
On Tue, 23 Dec 2025, Martin Kaiser wrote:
> If sbi_ecall.c's functions are traceable,
>
> echo "__sbi_ecall:snapshot" > /sys/kernel/tracing/set_ftrace_filter
>
> may get the kernel into a deadlock.
>
> (Functions in sbi_ecall.c are excluded from tracing if
> CONFIG_RISCV_ALTERNATIVE_EARLY is set.)
>
> __sbi_ecall triggers a snapshot of the ringbuffer. The snapshot code
> raises an IPI interrupt, which results in another call to __sbi_ecall
> and another snapshot...
>
> All it takes to get into this endless loop is one initial __sbi_ecall.
> On RISC-V systems without SSTC extension, the clock events in
> timer-riscv.c issue periodic sbi ecalls, making the problem easy to
> trigger.
>
> Always exclude the sbi_ecall.c functions from tracing to fix the
> potential deadlock.
>
> sbi ecalls can easiliy be logged via trace events, excluding ecall
> functions from function tracing is not a big limitation.
>
> Signed-off-by: Martin Kaiser <martin@kaiser.cx>
Thanks, queued for v6.19-rc.
- Paul
^ permalink raw reply
* [PATCH v2] tracing: Avoid possible signed 64-bit truncation
From: Ian Rogers @ 2026-01-08 0:26 UTC (permalink / raw)
To: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers, linux-kernel,
linux-trace-kernel
Cc: Ian Rogers
64-bit truncation to 32-bit can result in the sign of the truncated
value changing. The cmp_mod_entry is used in bsearch and so the
truncation could result in an invalid search order. This would only
happen were the addresses more than 2GB apart and so unlikely, but
let's fix the potentially broken compare anyway.
Signed-off-by: Ian Rogers <irogers@google.com>
---
Reduce the number of checks as suggested-by Steven Rostedt
<rostedt@goodmis.org>.
v1: https://lore.kernel.org/lkml/20251209224024.2322124-1-irogers@google.com/
---
kernel/trace/trace.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 6f2148df14d9..5e2d597b4377 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -6109,10 +6109,10 @@ static int cmp_mod_entry(const void *key, const void *pivot)
unsigned long addr = (unsigned long)key;
const struct trace_mod_entry *ent = pivot;
- if (addr >= ent[0].mod_addr && addr < ent[1].mod_addr)
- return 0;
- else
- return addr - ent->mod_addr;
+ if (addr < ent[0].mod_addr)
+ return -1;
+
+ return addr >= ent[1].mod_addr;
}
/**
--
2.52.0.351.gbe84eed79e-goog
^ permalink raw reply related
* [PATCH 2/2] Documentation: tracing: Wrap PCI tracepoint examples
From: Bagas Sanjaya @ 2026-01-08 1:39 UTC (permalink / raw)
To: Linux Kernel Mailing List, Linux Documentation,
Linux Kernel Tracing
Cc: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Jonathan Corbet, Shuai Xue, Bjorn Helgaas, Ilpo Järvinen,
Swaraj Gaikwad, Bagas Sanjaya, Stephen Rothwell
In-Reply-To: <20260108013956.14351-1-bagasdotme@gmail.com>
Sphinx reports htmldocs warnings:
Documentation/trace/events-pci.rst:43: ERROR: Unexpected indentation. [docutils]
Documentation/trace/events-pci.rst:74: ERROR: Unexpected indentation. [docutils]
Fix them by wrapping example shell snippets in PCI tracepoint
documentation in literal code blocks.
Fixes: d0eb853678a21b ("Documentation: tracing: Add PCI tracepoint documentation")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Closes: https://lore.kernel.org/linux-next/20260105160000.0368ec8d@canb.auug.org.au/
Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
---
Documentation/trace/events-pci.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/trace/events-pci.rst b/Documentation/trace/events-pci.rst
index c1ad0fc54777e0..03ff4ad30ddfa1 100644
--- a/Documentation/trace/events-pci.rst
+++ b/Documentation/trace/events-pci.rst
@@ -33,7 +33,7 @@ state changes.
* ``CARD_PRESENT`` - Card detected in slot
* ``CARD_NOT_PRESENT`` - Card removed from slot
-**Example Usage**:
+**Example Usage**::
# Enable the tracepoint
echo 1 > /sys/kernel/debug/tracing/events/pci/pci_hp_event/enable
@@ -64,7 +64,7 @@ Monitors PCIe link speed changes and provides detailed link status information.
- ``4`` - Hotplug event
-**Example Usage**:
+**Example Usage**::
# Enable the tracepoint
echo 1 > /sys/kernel/debug/tracing/events/pci/pcie_link_event/enable
--
An old man doll... just what I always wanted! - Clara
^ permalink raw reply related
* [PATCH 1/2] Documentation: tracing: Add toctree entry for PCI tracepoint
From: Bagas Sanjaya @ 2026-01-08 1:39 UTC (permalink / raw)
To: Linux Kernel Mailing List, Linux Documentation,
Linux Kernel Tracing
Cc: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Jonathan Corbet, Shuai Xue, Bjorn Helgaas, Ilpo Järvinen,
Swaraj Gaikwad, Bagas Sanjaya, Stephen Rothwell
In-Reply-To: <20260108013956.14351-1-bagasdotme@gmail.com>
Sphinx reports missing toctree entry htmldocs warning:
Documentation/trace/events-pci.rst: WARNING: document isn't included in any toctree [toc.not_included]
Fix it by adding the entry for PCI tracepoint documentation.
Fixes: d0eb853678a21b ("Documentation: tracing: Add PCI tracepoint documentation")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Closes: https://lore.kernel.org/linux-next/20260105160000.0368ec8d@canb.auug.org.au/
Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
---
Documentation/trace/index.rst | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/trace/index.rst b/Documentation/trace/index.rst
index b4a429dc4f7ad6..0a40bfabcf19bf 100644
--- a/Documentation/trace/index.rst
+++ b/Documentation/trace/index.rst
@@ -54,6 +54,7 @@ applications.
events-power
events-nmi
events-msr
+ events-pci
boottime-trace
histogram
histogram-design
--
An old man doll... just what I always wanted! - Clara
^ permalink raw reply related
* [PATCH 0/2] PCI tracepoint documentation fixes
From: Bagas Sanjaya @ 2026-01-08 1:39 UTC (permalink / raw)
To: Linux Kernel Mailing List, Linux Documentation,
Linux Kernel Tracing
Cc: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Jonathan Corbet, Shuai Xue, Bjorn Helgaas, Ilpo Järvinen,
Swaraj Gaikwad, Bagas Sanjaya
Hi,
Here are two fixes for htmldocs warnings on PCI tracepoint docs as reported in
linux-next [1]. The shortlog below should be self-explanatory.
Enjoy!
[1]: https://lore.kernel.org/linux-next/20260105160000.0368ec8d@canb.auug.org.au/
Bagas Sanjaya (2):
Documentation: tracing: Add toctree entry for PCI tracepoint
Documentation: tracing: Wrap PCI tracepoint examples
Documentation/trace/events-pci.rst | 4 ++--
Documentation/trace/index.rst | 1 +
2 files changed, 3 insertions(+), 2 deletions(-)
base-commit: 29a77b4897f1a0f40209bee929129d4c3f9c7a4b
--
An old man doll... just what I always wanted! - Clara
^ permalink raw reply
* Re: [PATCH v2] tracing: Avoid possible signed 64-bit truncation
From: Masami Hiramatsu @ 2026-01-08 2:35 UTC (permalink / raw)
To: Ian Rogers
Cc: Steven Rostedt, Mathieu Desnoyers, linux-kernel,
linux-trace-kernel
In-Reply-To: <20260108002625.333331-1-irogers@google.com>
On Wed, 7 Jan 2026 16:26:25 -0800
Ian Rogers <irogers@google.com> wrote:
> 64-bit truncation to 32-bit can result in the sign of the truncated
> value changing. The cmp_mod_entry is used in bsearch and so the
> truncation could result in an invalid search order. This would only
> happen were the addresses more than 2GB apart and so unlikely, but
> let's fix the potentially broken compare anyway.
>
> Signed-off-by: Ian Rogers <irogers@google.com>
> ---
> Reduce the number of checks as suggested-by Steven Rostedt
> <rostedt@goodmis.org>.
> v1: https://lore.kernel.org/lkml/20251209224024.2322124-1-irogers@google.com/
Look good to me.
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Thanks!
> ---
> kernel/trace/trace.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 6f2148df14d9..5e2d597b4377 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -6109,10 +6109,10 @@ static int cmp_mod_entry(const void *key, const void *pivot)
> unsigned long addr = (unsigned long)key;
> const struct trace_mod_entry *ent = pivot;
>
> - if (addr >= ent[0].mod_addr && addr < ent[1].mod_addr)
> - return 0;
> - else
> - return addr - ent->mod_addr;
> + if (addr < ent[0].mod_addr)
> + return -1;
> +
> + return addr >= ent[1].mod_addr;
> }
>
> /**
> --
> 2.52.0.351.gbe84eed79e-goog
>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/2] tracing: Make the backup instance readonly
From: Masami Hiramatsu @ 2026-01-08 2:51 UTC (permalink / raw)
To: Steven Rostedt; +Cc: Mathieu Desnoyers, linux-kernel, linux-trace-kernel
In-Reply-To: <20260107114133.7f14dac2@gandalf.local.home>
On Wed, 7 Jan 2026 11:41:33 -0500
Steven Rostedt <rostedt@goodmis.org> wrote:
> On Wed, 7 Jan 2026 23:45:59 +0900
> "Masami Hiramatsu (Google)" <mhiramat@kernel.org> wrote:
>
> > From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
> >
> > Since there is no reason to reuse the backup instance, make it
> > readonly. Note that only backup instances are readonly, because
> > other trace instances will be empty unless it is writable.
> > Only backup instances have copy entries from the original.
> >
> > Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
> > ---
> > kernel/trace/trace.c | 91 ++++++++++++++++++++++++++++++++-----------
> > kernel/trace/trace.h | 6 +++
> > kernel/trace/trace_events.c | 14 +++++--
> > 3 files changed, 84 insertions(+), 27 deletions(-)
> >
> > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> > index 38f7a7a55c23..725930f5980e 100644
> > --- a/kernel/trace/trace.c
> > +++ b/kernel/trace/trace.c
> > @@ -4888,6 +4888,9 @@ static int tracing_open(struct inode *inode, struct file *file)
> > int cpu = tracing_get_cpu(inode);
> > struct array_buffer *trace_buf = &tr->array_buffer;
> >
> > + if (trace_array_is_readonly(tr))
> > + return -EPERM;
>
> So this fails if someone opens a file in RDONLY mode?
>
> Why?
Ah, that's a bug. Let me fix it.
>
>
> > +
> > #ifdef CONFIG_TRACER_MAX_TRACE
> > if (tr->current_trace->print_max)
> > trace_buf = &tr->max_buffer;
> > @@ -6077,6 +6080,9 @@ static int __tracing_resize_ring_buffer(struct trace_array *tr,
> > ssize_t tracing_resize_ring_buffer(struct trace_array *tr,
> > unsigned long size, int cpu_id)
> > {
> > + if (trace_array_is_readonly(tr))
> > + return -EPERM;
>
> In fact, I don't think we need any of these.
Would you mean we should check readonly
>
> > +
> > guard(mutex)(&trace_types_lock);
> >
> > if (cpu_id != RING_BUFFER_ALL_CPUS) {
>
>
>
> > @@ -9353,12 +9381,16 @@ static void
> > tracing_init_tracefs_percpu(struct trace_array *tr, long cpu)
> > {
> > struct dentry *d_percpu = tracing_dentry_percpu(tr, cpu);
> > + umode_t writable_mode = TRACE_MODE_WRITE;
> > struct dentry *d_cpu;
> > char cpu_dir[30]; /* 30 characters should be more than enough */
> >
> > if (!d_percpu)
> > return;
> >
> > + if (trace_array_is_readonly(tr))
> > + writable_mode = TRACE_MODE_READ;
>
> This is more like what we should do with all the files in a read-only
> instance. Just make all files not allow writes.
Actually, that's my first prototype but it did not work (at least on
tracefs).
Superuser can write anything unless the file does not have .write
operation.
>
> We may need to make sure they can't be changed to write as well. But that
> will require a change to tracefs (and eventfs).
Ah, you mean the permission check is not correctly done in tracefs/eventfs yet?
Thank you,
>
> -- Steve
>
>
> > +
> > snprintf(cpu_dir, 30, "cpu%ld", cpu);
> > d_cpu = tracefs_create_dir(cpu_dir, d_percpu);
> > if (!d_cpu) {
> > @@ -9371,7 +9403,7 @@ tracing_init_tracefs_percpu(struct trace_array *tr, long cpu)
> > tr, cpu, &tracing_pipe_fops);
> >
> > /* per cpu trace */
> > - trace_create_cpu_file("trace", TRACE_MODE_WRITE, d_cpu,
> > + trace_create_cpu_file("trace", writable_mode, d_cpu,
> > tr, cpu, &tracing_fops);
> >
> > trace_create_cpu_file("trace_pipe_raw", TRACE_MODE_READ, d_cpu,
>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/2] tracing: Make the backup instance readonly
From: Steven Rostedt @ 2026-01-08 3:05 UTC (permalink / raw)
To: Masami Hiramatsu (Google)
Cc: Mathieu Desnoyers, linux-kernel, linux-trace-kernel
In-Reply-To: <20260108115125.b832464d94ebcfd0ea3b5af4@kernel.org>
On Thu, 8 Jan 2026 11:51:25 +0900
Masami Hiramatsu (Google) <mhiramat@kernel.org> wrote:
> > We may need to make sure they can't be changed to write as well. But that
> > will require a change to tracefs (and eventfs).
>
> Ah, you mean the permission check is not correctly done in tracefs/eventfs yet?
Actually, i think we could use a different fops for read only instances
that do not have a write callback. And for eventfs we could have it for
read only instances to only create the id and format files.
-- Steve
^ permalink raw reply
* Re: [PATCH 1/2] tracing: Make the backup instance readonly
From: Masami Hiramatsu @ 2026-01-08 3:07 UTC (permalink / raw)
To: Steven Rostedt; +Cc: Mathieu Desnoyers, linux-kernel, linux-trace-kernel
In-Reply-To: <20260107114133.7f14dac2@gandalf.local.home>
On Wed, 7 Jan 2026 11:41:33 -0500
Steven Rostedt <rostedt@goodmis.org> wrote:
> > @@ -4888,6 +4888,9 @@ static int tracing_open(struct inode *inode, struct file *file)
> > int cpu = tracing_get_cpu(inode);
> > struct array_buffer *trace_buf = &tr->array_buffer;
> >
> > + if (trace_array_is_readonly(tr))
> > + return -EPERM;
>
> So this fails if someone opens a file in RDONLY mode?
>
> Why?
This is for `trace` file and this block is to erase the buffer.
-----
/* If this file was open for write, then erase contents */
if ((file->f_mode & FMODE_WRITE) && (file->f_flags & O_TRUNC)) {
int cpu = tracing_get_cpu(inode);
struct array_buffer *trace_buf = &tr->array_buffer;
if (trace_array_is_readonly(tr))
return -EPERM;
-----
Thus, if user opens it RDONLY mode to read the buffer, we don't care
because it is readonly (readable).
Thank you,
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/2] Documentation: tracing: Wrap PCI tracepoint examples
From: Randy Dunlap @ 2026-01-08 4:30 UTC (permalink / raw)
To: Bagas Sanjaya, Linux Kernel Mailing List, Linux Documentation,
Linux Kernel Tracing
Cc: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Jonathan Corbet, Shuai Xue, Bjorn Helgaas, Ilpo Järvinen,
Swaraj Gaikwad, Stephen Rothwell
In-Reply-To: <20260108013956.14351-3-bagasdotme@gmail.com>
On 1/7/26 5:39 PM, Bagas Sanjaya wrote:
> Sphinx reports htmldocs warnings:
>
> Documentation/trace/events-pci.rst:43: ERROR: Unexpected indentation. [docutils]
> Documentation/trace/events-pci.rst:74: ERROR: Unexpected indentation. [docutils]
>
> Fix them by wrapping example shell snippets in PCI tracepoint
> documentation in literal code blocks.
>
> Fixes: d0eb853678a21b ("Documentation: tracing: Add PCI tracepoint documentation")
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Closes: https://lore.kernel.org/linux-next/20260105160000.0368ec8d@canb.auug.org.au/
> Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Thanks.
> ---
> Documentation/trace/events-pci.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/trace/events-pci.rst b/Documentation/trace/events-pci.rst
> index c1ad0fc54777e0..03ff4ad30ddfa1 100644
> --- a/Documentation/trace/events-pci.rst
> +++ b/Documentation/trace/events-pci.rst
> @@ -33,7 +33,7 @@ state changes.
> * ``CARD_PRESENT`` - Card detected in slot
> * ``CARD_NOT_PRESENT`` - Card removed from slot
>
> -**Example Usage**:
> +**Example Usage**::
>
> # Enable the tracepoint
> echo 1 > /sys/kernel/debug/tracing/events/pci/pci_hp_event/enable
> @@ -64,7 +64,7 @@ Monitors PCIe link speed changes and provides detailed link status information.
> - ``4`` - Hotplug event
>
>
> -**Example Usage**:
> +**Example Usage**::
>
> # Enable the tracepoint
> echo 1 > /sys/kernel/debug/tracing/events/pci/pcie_link_event/enable
--
~Randy
^ permalink raw reply
* Re: [PATCH 1/2] Documentation: tracing: Add toctree entry for PCI tracepoint
From: Randy Dunlap @ 2026-01-08 4:30 UTC (permalink / raw)
To: Bagas Sanjaya, Linux Kernel Mailing List, Linux Documentation,
Linux Kernel Tracing
Cc: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Jonathan Corbet, Shuai Xue, Bjorn Helgaas, Ilpo Järvinen,
Swaraj Gaikwad, Stephen Rothwell
In-Reply-To: <20260108013956.14351-2-bagasdotme@gmail.com>
On 1/7/26 5:39 PM, Bagas Sanjaya wrote:
> Sphinx reports missing toctree entry htmldocs warning:
>
> Documentation/trace/events-pci.rst: WARNING: document isn't included in any toctree [toc.not_included]
>
> Fix it by adding the entry for PCI tracepoint documentation.
>
> Fixes: d0eb853678a21b ("Documentation: tracing: Add PCI tracepoint documentation")
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Closes: https://lore.kernel.org/linux-next/20260105160000.0368ec8d@canb.auug.org.au/
> Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Thanks.
> ---
> Documentation/trace/index.rst | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/trace/index.rst b/Documentation/trace/index.rst
> index b4a429dc4f7ad6..0a40bfabcf19bf 100644
> --- a/Documentation/trace/index.rst
> +++ b/Documentation/trace/index.rst
> @@ -54,6 +54,7 @@ applications.
> events-power
> events-nmi
> events-msr
> + events-pci
> boottime-trace
> histogram
> histogram-design
--
~Randy
^ permalink raw reply
* Re: [PATCH 1/2] tracing: Make the backup instance readonly
From: Masami Hiramatsu @ 2026-01-08 5:30 UTC (permalink / raw)
To: Steven Rostedt; +Cc: Mathieu Desnoyers, linux-kernel, linux-trace-kernel
In-Reply-To: <20260107220542.0128abf1@fedora>
On Wed, 7 Jan 2026 22:05:42 -0500
Steven Rostedt <rostedt@goodmis.org> wrote:
> On Thu, 8 Jan 2026 11:51:25 +0900
> Masami Hiramatsu (Google) <mhiramat@kernel.org> wrote:
>
> > > We may need to make sure they can't be changed to write as well. But that
> > > will require a change to tracefs (and eventfs).
> >
> > Ah, you mean the permission check is not correctly done in tracefs/eventfs yet?
>
> Actually, i think we could use a different fops for read only instances
> that do not have a write callback. And for eventfs we could have it for
> read only instances to only create the id and format files.
Ah, OK. Let me update it.
Thanks,
>
> -- Steve
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH] ring-buffer: Use a housekeeping CPU to wake up waiters
From: Petr Tesarik @ 2026-01-08 8:39 UTC (permalink / raw)
To: Steven Rostedt
Cc: Masami Hiramatsu, Mathieu Desnoyers, Sebastian Andrzej Siewior,
Clark Williams, linux-kernel, linux-trace-kernel, linux-rt-devel
In-Reply-To: <20260107111935.3befc296@gandalf.local.home>
On Wed, 7 Jan 2026 11:19:35 -0500
Steven Rostedt <rostedt@goodmis.org> wrote:
> On Wed, 7 Jan 2026 11:17:09 -0500
> Steven Rostedt <rostedt@goodmis.org> wrote:
>
> > Or we simply change it to:
> >
> > static inline void
>
> Actually, the above should be noinline, as it's in a slower path, and
> should not be adding logic into the cache of the fast path.
However, to be honest, I'm surprized this is considered slow path. My
use case is to record a few selected trace events with "trace-cmd
record", which spends most time polling trace_pipe_raw. Consequently,
there is almost always a pending waiter that requires a wakeup.
In short, irq_work_queue() is the hot path for me.
OTOH I don't mind making it noinline, because on recent Intel and AMD
systems, a function call (noinline) is often cheaper than an increase
in L1 cache footprint (caused by inlining). But I'm confused. I have
always thought most people use tracing same way as I do.
> > rb_irq_work_queue(struct rb_irq_work *irq_work)
> > {
> > int cpu;
> >
> > /* irq_work_queue_on() is not allowed in NMI context */
> > if (in_nmi()) {
> > irq_work_queue(&irq_work->work, cpu);
> > return;
> > }
Thanks for the idea. There are some downsides. IIUC there is no
fundamental reason IPIs to other CPUs cannot be sent from NMI context.
It's just a limitation of the current Linux kernel code. As such, it
may be lifted in the future, and at that point nobody will remember to
remove this condition.
My current plan is it to keep the patch on hold and have a look why IPI
backends are not NMI-safe. In fact, I'm not even 100% sure the comment
is correct. The issue may have fixed itself e.g. by removing the last
affected architecture. ;-)
Petr T
^ permalink raw reply
* Re: [PATCH bpf-next 1/2] arm64/ftrace,bpf: Fix partial regs after bpf_prog_run
From: Jiri Olsa @ 2026-01-08 9:20 UTC (permalink / raw)
To: Steven Rostedt
Cc: Will Deacon, Masami Hiramatsu, Mahe Tardy, Peter Zijlstra, bpf,
linux-trace-kernel, linux-arm-kernel, x86, Yonghong Song,
Song Liu, Andrii Nakryiko, Mark Rutland
In-Reply-To: <20260107121432.73fccf84@gandalf.local.home>
On Wed, Jan 07, 2026 at 12:14:32PM -0500, Steven Rostedt wrote:
> On Wed, 7 Jan 2026 16:52:52 +0000
> Will Deacon <will@kernel.org> wrote:
>
> > diff --git a/include/linux/ftrace_regs.h b/include/linux/ftrace_regs.h
> > index 15627ceea9bc..3ebd8cdac7c6 100644
> > --- a/include/linux/ftrace_regs.h
> > +++ b/include/linux/ftrace_regs.h
> > @@ -33,6 +33,15 @@ struct ftrace_regs;
> > #define ftrace_regs_get_frame_pointer(fregs) \
> > frame_pointer(&arch_ftrace_regs(fregs)->regs)
> >
> > +#else
> > +
> > +static __always_inline void
> > +ftrace_partial_regs_update(const struct ftrace_regs *fregs, struct pt_regs *regs)
> > +{
> > + ftrace_regs_set_instruction_pointer(fregs, instruction_pointer(regs));
> > + ftrace_regs_set_return_value(fregs, regs_return_value(regs));
> > +}
> > +
> > #endif /* HAVE_ARCH_FTRACE_REGS */
> >
> > /* This can be overridden by the architectures */
>
> Hmm, maybe that would work. Of course you forgot to add the helper for the
> !HAVE_ARCH_FTRACE_REGS case ;-)
seems to work, will send new version with that
thanks,
jirka
---
diff --git a/include/linux/ftrace_regs.h b/include/linux/ftrace_regs.h
index 15627ceea9bc..4b053eb4c9d5 100644
--- a/include/linux/ftrace_regs.h
+++ b/include/linux/ftrace_regs.h
@@ -33,6 +33,18 @@ struct ftrace_regs;
#define ftrace_regs_get_frame_pointer(fregs) \
frame_pointer(&arch_ftrace_regs(fregs)->regs)
+static __always_inline void
+ftrace_partial_regs_update(const struct ftrace_regs *fregs, struct pt_regs *regs) { }
+
+#else
+
+static __always_inline void
+ftrace_partial_regs_update(const struct ftrace_regs *fregs, struct pt_regs *regs)
+{
+ ftrace_regs_set_instruction_pointer(fregs, instruction_pointer(regs));
+ ftrace_regs_set_return_value(fregs, regs_return_value(regs));
+}
+
#endif /* HAVE_ARCH_FTRACE_REGS */
/* This can be overridden by the architectures */
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index 6e076485bf70..3a17f79b20c2 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -2564,6 +2564,7 @@ kprobe_multi_link_prog_run(struct bpf_kprobe_multi_link *link,
old_run_ctx = bpf_set_run_ctx(&run_ctx.session_ctx.run_ctx);
err = bpf_prog_run(link->link.prog, regs);
bpf_reset_run_ctx(old_run_ctx);
+ ftrace_partial_regs_update(fregs, bpf_kprobe_multi_pt_regs_ptr());
rcu_read_unlock();
out:
^ permalink raw reply related
* [PATCH v1] tools/rtla: Generate optstring from long options
From: Costa Shulyupin @ 2026-01-08 9:49 UTC (permalink / raw)
To: Steven Rostedt, Tomas Glozar, Costa Shulyupin, Crystal Wood,
Wander Lairson Costa, John Kacur, Ivan Pravdin,
linux-trace-kernel, linux-kernel
getopt_long() processes short and long options independently.
RTLA, like the majority of applications, uses both short and long
variants for each logical option.
Since the val member of struct option holds the letter of the short
variant, the string of short options can be reconstructed from the
array of long options.
Add getopt_auto() to generate optstring from an array of long options,
eliminating the need to maintain separate short option strings.
Signed-off-by: Costa Shulyupin <costa.shul@redhat.com>
---
tools/tracing/rtla/src/common.c | 32 +++++++++++++++++++++++++-
tools/tracing/rtla/src/common.h | 2 ++
tools/tracing/rtla/src/osnoise_hist.c | 3 +--
tools/tracing/rtla/src/osnoise_top.c | 3 +--
tools/tracing/rtla/src/timerlat_hist.c | 3 +--
tools/tracing/rtla/src/timerlat_top.c | 3 +--
6 files changed, 37 insertions(+), 9 deletions(-)
diff --git a/tools/tracing/rtla/src/common.c b/tools/tracing/rtla/src/common.c
index ceff76a62a30..f310b0d59ad3 100644
--- a/tools/tracing/rtla/src/common.c
+++ b/tools/tracing/rtla/src/common.c
@@ -39,6 +39,36 @@ static void set_signals(struct common_params *params)
}
}
+/*
+ * getopt_auto - auto-generates optstring from long_options
+ */
+int getopt_auto(int argc, char **argv, const struct option *long_opts)
+{
+ char opts[256];
+ int n = 0;
+
+ for (int i = 0; long_opts[i].name; i++) {
+ if (long_opts[i].val < 32 || long_opts[i].val > 127)
+ continue;
+
+ if (n + 4 >= sizeof(opts))
+ fatal("optstring buffer overflow");
+
+ opts[n++] = long_opts[i].val;
+
+ if (long_opts[i].has_arg == required_argument)
+ opts[n++] = ':';
+ else if (long_opts[i].has_arg == optional_argument) {
+ opts[n++] = ':';
+ opts[n++] = ':';
+ }
+ }
+
+ opts[n] = '\0';
+
+ return getopt_long(argc, argv, opts, long_opts, NULL);
+}
+
/*
* common_parse_options - parse common command line options
*
@@ -69,7 +99,7 @@ int common_parse_options(int argc, char **argv, struct common_params *common)
};
opterr = 0;
- c = getopt_long(argc, argv, "c:C::Dd:e:H:P:", long_options, NULL);
+ c = getopt_auto(argc, argv, long_options);
opterr = 1;
switch (c) {
diff --git a/tools/tracing/rtla/src/common.h b/tools/tracing/rtla/src/common.h
index 7602c5593ef5..d4b3715700be 100644
--- a/tools/tracing/rtla/src/common.h
+++ b/tools/tracing/rtla/src/common.h
@@ -1,6 +1,7 @@
/* SPDX-License-Identifier: GPL-2.0 */
#pragma once
+#include <getopt.h>
#include "actions.h"
#include "timerlat_u.h"
#include "trace.h"
@@ -156,6 +157,7 @@ int osnoise_set_stop_us(struct osnoise_context *context, long long stop_us);
int osnoise_set_stop_total_us(struct osnoise_context *context,
long long stop_total_us);
+int getopt_auto(int argc, char **argv, const struct option *long_opts);
int common_parse_options(int argc, char **argv, struct common_params *common);
int common_apply_config(struct osnoise_tool *tool, struct common_params *params);
int top_main_loop(struct osnoise_tool *tool);
diff --git a/tools/tracing/rtla/src/osnoise_hist.c b/tools/tracing/rtla/src/osnoise_hist.c
index 9d70ea34807f..5c863e7aad28 100644
--- a/tools/tracing/rtla/src/osnoise_hist.c
+++ b/tools/tracing/rtla/src/osnoise_hist.c
@@ -506,8 +506,7 @@ static struct common_params
if (common_parse_options(argc, argv, ¶ms->common))
continue;
- c = getopt_long(argc, argv, "a:b:E:hp:r:s:S:t::T:01234:5:6:7:",
- long_options, NULL);
+ c = getopt_auto(argc, argv, long_options);
/* detect the end of the options. */
if (c == -1)
diff --git a/tools/tracing/rtla/src/osnoise_top.c b/tools/tracing/rtla/src/osnoise_top.c
index d54d47947fb4..b7aed40fd216 100644
--- a/tools/tracing/rtla/src/osnoise_top.c
+++ b/tools/tracing/rtla/src/osnoise_top.c
@@ -358,8 +358,7 @@ struct common_params *osnoise_top_parse_args(int argc, char **argv)
if (common_parse_options(argc, argv, ¶ms->common))
continue;
- c = getopt_long(argc, argv, "a:hp:qr:s:S:t::T:0:1:2:3:",
- long_options, NULL);
+ c = getopt_auto(argc, argv, long_options);
/* Detect the end of the options. */
if (c == -1)
diff --git a/tools/tracing/rtla/src/timerlat_hist.c b/tools/tracing/rtla/src/timerlat_hist.c
index 4e8c38a61197..096de8ba3efb 100644
--- a/tools/tracing/rtla/src/timerlat_hist.c
+++ b/tools/tracing/rtla/src/timerlat_hist.c
@@ -825,8 +825,7 @@ static struct common_params
if (common_parse_options(argc, argv, ¶ms->common))
continue;
- c = getopt_long(argc, argv, "a:b:E:hi:knp:s:t::T:uU0123456:7:8:9\1\2:\3:",
- long_options, NULL);
+ c = getopt_auto(argc, argv, long_options);
/* detect the end of the options. */
if (c == -1)
diff --git a/tools/tracing/rtla/src/timerlat_top.c b/tools/tracing/rtla/src/timerlat_top.c
index 284b74773c2b..27c14aa71a8b 100644
--- a/tools/tracing/rtla/src/timerlat_top.c
+++ b/tools/tracing/rtla/src/timerlat_top.c
@@ -588,8 +588,7 @@ static struct common_params
if (common_parse_options(argc, argv, ¶ms->common))
continue;
- c = getopt_long(argc, argv, "a:hi:knp:qs:t::T:uU0:1:2:345:6:7:",
- long_options, NULL);
+ c = getopt_auto(argc, argv, long_options);
/* detect the end of the options. */
if (c == -1)
--
2.52.0
^ permalink raw reply related
* Re: [PATCH] ring-buffer: Use a housekeeping CPU to wake up waiters
From: Petr Tesarik @ 2026-01-08 10:46 UTC (permalink / raw)
To: Steven Rostedt
Cc: Masami Hiramatsu, Mathieu Desnoyers, Sebastian Andrzej Siewior,
Clark Williams, linux-kernel, linux-trace-kernel, linux-rt-devel,
Frederic Weisbecker
In-Reply-To: <20260108093932.252f6bc7@mordecai>
On Thu, 8 Jan 2026 09:39:32 +0100
Petr Tesarik <ptesarik@suse.com> wrote:
> On Wed, 7 Jan 2026 11:19:35 -0500
> Steven Rostedt <rostedt@goodmis.org> wrote:
>
> > On Wed, 7 Jan 2026 11:17:09 -0500
> > Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > > Or we simply change it to:
> > >
> > > static inline void
> >
> > Actually, the above should be noinline, as it's in a slower path, and
> > should not be adding logic into the cache of the fast path.
>
> However, to be honest, I'm surprized this is considered slow path. My
> use case is to record a few selected trace events with "trace-cmd
> record", which spends most time polling trace_pipe_raw. Consequently,
> there is almost always a pending waiter that requires a wakeup.
>
> In short, irq_work_queue() is the hot path for me.
>
> OTOH I don't mind making it noinline, because on recent Intel and AMD
> systems, a function call (noinline) is often cheaper than an increase
> in L1 cache footprint (caused by inlining). But I'm confused. I have
> always thought most people use tracing same way as I do.
>
> > > rb_irq_work_queue(struct rb_irq_work *irq_work)
> > > {
> > > int cpu;
> > >
> > > /* irq_work_queue_on() is not allowed in NMI context */
> > > if (in_nmi()) {
> > > irq_work_queue(&irq_work->work, cpu);
> > > return;
> > > }
>
> Thanks for the idea. There are some downsides. IIUC there is no
> fundamental reason IPIs to other CPUs cannot be sent from NMI context.
> It's just a limitation of the current Linux kernel code. As such, it
> may be lifted in the future, and at that point nobody will remember to
> remove this condition.
>
> My current plan is it to keep the patch on hold and have a look why IPI
> backends are not NMI-safe. In fact, I'm not even 100% sure the comment
> is correct. The issue may have fixed itself e.g. by removing the last
> affected architecture. ;-)
This turned to be an interesting digression. Since we still support
old xAPIC (not x2APIC) systems, there is a reason in hardware. The xAPIC
ICR is programmed by writing to two 32-bit registers. If an NMI occurs
between those two writes, we'd have to restore the upper 32 bits of
ICR. Alternatively, we could queue the request if ICR write is in
progress and flush the queue after finishing the write to the ICR (out
of NMI context). The code could even be arch-independent...
However, it's not worth the effort just for this one corner case.
Besides, it seems that other people have always been aware that
irq_work_queue_on() is NMI-unsafe, so in case the future brings a
better reason to make it NMI-safe, there's a fair chance that all
the extra code in rb_irq_work_queue() gets reviewed.
Petr T
^ permalink raw reply
* [PATCH v2 1/1] ring-buffer: Use a housekeeping CPU to wake up waiters
From: Petr Tesarik @ 2026-01-08 13:21 UTC (permalink / raw)
To: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Sebastian Andrzej Siewior, Clark Williams
Cc: Frederic Weisbecker, linux-kernel, linux-trace-kernel,
linux-rt-devel, Petr Tesarik
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
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.
After applying the patch, the trace is similar, but ipi_send_cpu always
targets a non-isolated CPU.
Unfortunately, irq_work_queue_on() is not NMI-safe. When running in NMI
context, fall back to queuing the irq work on the local CPU.
Signed-off-by: Petr Tesarik <ptesarik@suse.com>
---
kernel/trace/ring_buffer.c | 24 +++++++++++++++++++++---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index 41c9f5d079beb..5cf4c6baa2771 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -4,6 +4,7 @@
*
* Copyright (C) 2008 Steven Rostedt <srostedt@redhat.com>
*/
+#include <linux/sched/isolation.h>
#include <linux/trace_recursion.h>
#include <linux/trace_events.h>
#include <linux/ring_buffer.h>
@@ -4011,19 +4012,36 @@ static void rb_commit(struct ring_buffer_per_cpu *cpu_buffer)
rb_end_commit(cpu_buffer);
}
+static bool
+rb_irq_work_queue(struct rb_irq_work *irq_work)
+{
+ int cpu;
+
+ /* irq_work_queue_on() is not NMI-safe */
+ if (unlikely(in_nmi()))
+ return irq_work_queue(&irq_work->work);
+
+ /*
+ * If CPU isolation is not active, cpu is always the current
+ * CPU, and the following is equivallent to irq_work_queue().
+ */
+ cpu = housekeeping_any_cpu(HK_TYPE_KERNEL_NOISE);
+ return irq_work_queue_on(&irq_work->work, cpu);
+}
+
static __always_inline void
rb_wakeups(struct trace_buffer *buffer, struct ring_buffer_per_cpu *cpu_buffer)
{
if (buffer->irq_work.waiters_pending) {
buffer->irq_work.waiters_pending = false;
/* irq_work_queue() supplies it's own memory barriers */
- irq_work_queue(&buffer->irq_work.work);
+ rb_irq_work_queue(&buffer->irq_work);
}
if (cpu_buffer->irq_work.waiters_pending) {
cpu_buffer->irq_work.waiters_pending = false;
/* irq_work_queue() supplies it's own memory barriers */
- irq_work_queue(&cpu_buffer->irq_work.work);
+ rb_irq_work_queue(&cpu_buffer->irq_work);
}
if (cpu_buffer->last_pages_touch == local_read(&cpu_buffer->pages_touched))
@@ -4043,7 +4061,7 @@ rb_wakeups(struct trace_buffer *buffer, struct ring_buffer_per_cpu *cpu_buffer)
cpu_buffer->irq_work.wakeup_full = true;
cpu_buffer->irq_work.full_waiters_pending = false;
/* irq_work_queue() supplies it's own memory barriers */
- irq_work_queue(&cpu_buffer->irq_work.work);
+ rb_irq_work_queue(&cpu_buffer->irq_work);
}
#ifdef CONFIG_RING_BUFFER_RECORD_RECURSION
--
2.52.0
^ permalink raw reply related
* [PATCH v2 0/2] tracing: Remove backup instance after read all
From: Masami Hiramatsu (Google) @ 2026-01-08 14:22 UTC (permalink / raw)
To: Steven Rostedt
Cc: Masami Hiramatsu, Mathieu Desnoyers, linux-kernel,
linux-trace-kernel
Hi,
Here is the 2nd version of the series to improve backup instances of
the persistent ring buffer. The previous version is here:
https://lore.kernel.org/all/176779714767.4193242.1978666866487010024.stgit@mhiramat.tok.corp.google.com/
In this version, I updated [1/2] to use dedicated file operations
for read only instance instead of checking on each write function.
Also use dedicated entries files for eventfs to remove writable
control files from it. So it has only 'format' and 'id' files in
readonly backup instance.
Since backup instances are a kind of snapshot of the persistent
ring buffer, it should be readonly. And if it is readonly
there is no reason to keep it after reading all data via trace_pipe
because the data has been consumed.
Thus, [1/2] makes backup instances readonly (not able to write any
events, cleanup trace, change buffer size). Also, [2/2] removes the
backup instance after consuming all data via trace_pipe.
With this improvements, even if we makes a backup instance (using
the same amount of memory of the persistent ring buffer), it will
be removed after reading the data automatically.
---
Masami Hiramatsu (Google) (2):
tracing: Make the backup instance readonly
tracing: Add autoremove feature to the backup instance
kernel/trace/trace.c | 227 +++++++++++++++++++++++++++++++++++--------
kernel/trace/trace.h | 20 ++++
kernel/trace/trace_boot.c | 5 +
kernel/trace/trace_events.c | 75 ++++++++++----
4 files changed, 261 insertions(+), 66 deletions(-)
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
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