linux.git/tools/testing/selftests/ftrace, branch v7.2 Linux kernel source tree selftests/ftrace: Convert ELF entry point to file offset in uprobe test 2026-08-07T16:02:21+00:00 Rui Qi qirui.001@bytedance.com 2026-08-07T08:15:12+00:00 24aa630f6259e6a2107936c06fed72063f712b64 The add_remove_uprobe test uses readelf -h to obtain the ELF entry point (e_entry) and passes it directly as the offset to uprobe_events. However, uprobe_events expects a file offset, not a virtual address. For PIE binaries, the virtual address happens to equal the file offset because the first LOAD segment has p_vaddr == p_offset, so the test works by coincidence. But for non-PIE executables, e_entry is an absolute virtual address that can far exceed the file size. When the probe is enabled, uprobe_register() checks offset > i_size_read(inode) and rejects it with -EINVAL. Fix this by converting the virtual address to a file offset using the ELF program headers: scan readelf -lW output for the LOAD segment containing the entry point, then compute file_offset = e_entry - p_vaddr + p_offset. For PIE binaries the result is unchanged; for non-PIE binaries the offset is correctly translated. The conversion uses only POSIX shell primitives, with no dependency on gawk or perl. Link: https://lore.kernel.org/all/20260807081512.2974757-3-qirui.001@bytedance.com/ Fixes: dc4b165855f2 ("selftests/ftrace: Use readelf to find entry point in uprobe test") Cc: stable@vger.kernel.org Signed-off-by: Rui Qi <qirui.001@bytedance.com> Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> 
The add_remove_uprobe test uses readelf -h to obtain the ELF entry
point (e_entry) and passes it directly as the offset to uprobe_events.
However, uprobe_events expects a file offset, not a virtual address.

For PIE binaries, the virtual address happens to equal the file offset
because the first LOAD segment has p_vaddr == p_offset, so the test
works by coincidence. But for non-PIE executables, e_entry is an
absolute virtual address that can far exceed the file size. When the
probe is enabled, uprobe_register() checks offset > i_size_read(inode)
and rejects it with -EINVAL.

Fix this by converting the virtual address to a file offset using the
ELF program headers: scan readelf -lW output for the LOAD segment
containing the entry point, then compute file_offset = e_entry -
p_vaddr + p_offset. For PIE binaries the result is unchanged; for
non-PIE binaries the offset is correctly translated.

The conversion uses only POSIX shell primitives, with no dependency on
gawk or perl.

Link: https://lore.kernel.org/all/20260807081512.2974757-3-qirui.001@bytedance.com/

Fixes: dc4b165855f2 ("selftests/ftrace: Use readelf to find entry point in uprobe test")
Cc: stable@vger.kernel.org
Signed-off-by: Rui Qi <qirui.001@bytedance.com>
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
selftests/ftrace: refactor eprobes test to fix argument checks 2026-08-05T00:01:48+00:00 Martin Kaiser martin@kaiser.cx 2026-08-04T19:46:35+00:00 6e3abef2a27e7402a94111c9eff85d887e64a309 The add/remove eprobe test installs an eprobe for the openat syscall and runs ls. It checks the filenames that were opened by ls against a whitelist and a blacklist. Commit 206b25c09080 ("tracing: eprobe: read the complete FILTER_PTR_STRING pointer") fixed access to some string fields in eprobes. This triggers test failures as the blacklist does not allow relative paths for the openat parameters. What makes this test unstable is the fact that the openat calls vary a lot between different systems. Refactor the test to make it more robust. "cd <directory>" will issue a chdir syscall with the target directory as parameter. Set an eprobe on the sys_enter_chdir event and filter for the exact directory name. Allow (fault) as fallback. Link: https://lore.kernel.org/all/20260804194705.760893-1-martin@kaiser.cx/ Fixes: 206b25c09080 ("tracing: eprobe: read the complete FILTER_PTR_STRING pointer") Reported-by: kernel test robot <oliver.sang@intel.com> Closes: https://lore.kernel.org/oe-lkp/202607151010.b68428e1-lkp@intel.com Signed-off-by: Martin Kaiser <martin@kaiser.cx> Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> 
The add/remove eprobe test installs an eprobe for the openat syscall and
runs ls. It checks the filenames that were opened by ls against a
whitelist and a blacklist.

Commit 206b25c09080 ("tracing: eprobe: read the complete FILTER_PTR_STRING
pointer") fixed access to some string fields in eprobes. This triggers
test failures as the blacklist does not allow relative paths for the
openat parameters.

What makes this test unstable is the fact that the openat calls vary a
lot between different systems.

Refactor the test to make it more robust. "cd <directory>" will issue a
chdir syscall with the target directory as parameter. Set an eprobe on
the sys_enter_chdir event and filter for the exact directory name. Allow
(fault) as fallback.

Link: https://lore.kernel.org/all/20260804194705.760893-1-martin@kaiser.cx/

Fixes: 206b25c09080 ("tracing: eprobe: read the complete FILTER_PTR_STRING pointer")
Reported-by: kernel test robot <oliver.sang@intel.com>
Closes: https://lore.kernel.org/oe-lkp/202607151010.b68428e1-lkp@intel.com
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
selftests/ftrace: Reset triggers at top level before instance loop 2026-07-24T17:43:18+00:00 Masami Hiramatsu (Google) mhiramat@kernel.org 2026-07-17T02:51:59+00:00 1a087033a6bad73b4140020b40e819b0933aafc3 When running instance tests, 'ftracetest' creates a new ftrace instance and runs the tests inside it. Before starting each test, it executes 'initialize_system()' to reset the ftrace state to initial-state. However, since 'initialize_system()' is executed in the context of the instance directory, it only cleans up triggers and filters of that instance. Any triggers or dynamic events left behind in the top-level instance by previous failed top-level tests, are left completely untouched. These top-level leftovers can cause subsequent instance-based tests to fail or even crash the kernel. Fix this by executing 'initialize_system()' in the top-level tracing directory once before entering the instance loop. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/178425671889.84440.9477850701738666404.stgit@devnote2 Fixes: b5b77be812de ("selftests: ftrace: Allow some tests to be run in a tracing instance") Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Steven Rostedt <rostedt@goodmis.org> 
When running instance tests, 'ftracetest' creates a new ftrace instance
and runs the tests inside it. Before starting each test, it executes
'initialize_system()' to reset the ftrace state to initial-state.

However, since 'initialize_system()' is executed in the context of the
instance directory, it only cleans up triggers and filters of that
instance.
Any triggers or dynamic events left behind in the top-level instance by
previous failed top-level tests, are left completely untouched. These
top-level leftovers can cause subsequent instance-based tests to fail
or even crash the kernel.

Fix this by executing 'initialize_system()' in the top-level tracing
directory once before entering the instance loop.

Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/178425671889.84440.9477850701738666404.stgit@devnote2
Fixes: b5b77be812de ("selftests: ftrace: Allow some tests to be run in a tracing instance")
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
selftests/tracing: Have trigger-hist-poll.tc use sched_process_exit 2026-07-10T16:14:42+00:00 Steven Rostedt rostedt@goodmis.org 2026-07-08T20:34:36+00:00 c5c413534d40eb4c982f1794e62813f926aba747 Currently trigger-hist-poll.tc uses sched_process_free to test the polling of the histogram file. The way it does that is to run sleep, then execute the poll.c code that polls on the sched_process_free for up to 4 seconds to test that when sleep triggers the sched_process_free trace event, it will update the histogram and wake the poll.c code up. The issue is that sched_process_free trace event is called by delayed_put_task_struct() which is called after a RCU grace period has ended. If CONFIG_RCU_LAZY is enabled, RCU callbacks are batched together and do not execute right away. This causes the delayed_put_task_struct() to be called after the poll.c function finishes and it will report an error that it did not wake up on the event. That's because the event didn't trigger during its wait time. Use sched_process_exit instead, which is called when a process exits and doesn't depend on RCU callbacks that may be delayed. Link: https://lore.kernel.org/r/20260708163436.058cc3df@gandalf.local.home Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> 
Currently trigger-hist-poll.tc uses sched_process_free to test the polling
of the histogram file. The way it does that is to run sleep, then execute
the poll.c code that polls on the sched_process_free for up to 4 seconds
to test that when sleep triggers the sched_process_free trace event, it
will update the histogram and wake the poll.c code up.

The issue is that sched_process_free trace event is called by
delayed_put_task_struct() which is called after a RCU grace period has
ended. If CONFIG_RCU_LAZY is enabled, RCU callbacks are batched together
and do not execute right away. This causes the delayed_put_task_struct()
to be called after the poll.c function finishes and it will report an
error that it did not wake up on the event. That's because the event
didn't trigger during its wait time.

Use sched_process_exit instead, which is called when a process exits and
doesn't depend on RCU callbacks that may be delayed.

Link: https://lore.kernel.org/r/20260708163436.058cc3df@gandalf.local.home
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
selftests/ftrace: Fix reading enabled_functions in add_remove_fprobe_module test 2026-07-10T16:14:42+00:00 Steven Rostedt rostedt@goodmis.org 2026-07-08T19:32:39+00:00 22a78be4123dce81d72c963a98b774b7d5e1f8e5 The add_remove_fprobe_module test checks the number of functions added to the enabled_functions file to make sure that the functions added or removed is as expected. The issue is that it expects this file to be empty on start up. Now that systemd uses BPF that attaches to functions via ftrace, this file is not empty in several systems: # cat /sys/kernel/tracing/enabled_functions bpf_lsm_file_open (1) R D M tramp: ftrace_regs_caller+0x0/0x61 (call_direct_funcs+0x0/0x50) direct(jmp)-->bpf_trampoline_6442529439+0x0/0xe9 Change the test to read the number of lines in enabled_functions at the start of the test and subtract that from the value of the count for the checks within the test. Link: https://lore.kernel.org/r/20260708153239.055d56dd@gandalf.local.home Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> 
The add_remove_fprobe_module test checks the number of functions added to
the enabled_functions file to make sure that the functions added or
removed is as expected. The issue is that it expects this file to be empty
on start up.

Now that systemd uses BPF that attaches to functions via ftrace, this file
is not empty in several systems:

 # cat /sys/kernel/tracing/enabled_functions
 bpf_lsm_file_open (1) R   D   M 	tramp: ftrace_regs_caller+0x0/0x61 (call_direct_funcs+0x0/0x50)
	direct(jmp)-->bpf_trampoline_6442529439+0x0/0xe9

Change the test to read the number of lines in enabled_functions at the
start of the test and subtract that from the value of the count for the
checks within the test.

Link: https://lore.kernel.org/r/20260708153239.055d56dd@gandalf.local.home
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Merge tag 'linux_kselftest-next-7.2-rc1-second' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest 2026-06-23T14:35:37+00:00 Linus Torvalds torvalds@linux-foundation.org 2026-06-23T14:35:37+00:00 3eb20a97b315a9fd5fea33c207c51823f22c2b4d Pull more kselftest updates from Shuah Khan: "Docs: -remove obsolete wiki link from kselftest.rst ftrace: - drop invalid top-level local in test_ownership - Fix trace_marker_raw test on 64K page kernels" * tag 'linux_kselftest-next-7.2-rc1-second' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest: docs: kselftest: remove link to obsolete wiki selftests/ftrace: Fix trace_marker_raw test on 64K page kernels selftests/ftrace: Drop invalid top-level local in test_ownership 
Pull more kselftest updates from Shuah Khan:
 "Docs:
    -remove obsolete wiki link from kselftest.rst

  ftrace:
    - drop invalid top-level local in test_ownership
    - Fix trace_marker_raw test on 64K page kernels"

* tag 'linux_kselftest-next-7.2-rc1-second' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest:
  docs: kselftest: remove link to obsolete wiki
  selftests/ftrace: Fix trace_marker_raw test on 64K page kernels
  selftests/ftrace: Drop invalid top-level local in test_ownership
selftests/ftrace: Fix trace_marker_raw test on 64K page kernels 2026-06-17T23:17:26+00:00 Tianchen Ding dtcccc@linux.alibaba.com 2026-06-01T02:32:51+00:00 65f26d15f7db80b0a3f995c518cdddb50e6dea99 On ARM64 kernels with 64K pages, the trace_marker_raw test fails because bash's printf builtin uses stdio buffering which splits output into multiple small write() calls to the tracefs file. Since each individual write is within TRACE_MARKER_MAX_SIZE (4096), they all succeed, causing the "too big" write test to incorrectly pass. Fix by writing through dd with iflag=fullblock to guarantee a single atomic write() syscall to trace_marker_raw. Link: https://lore.kernel.org/r/20260601023251.1916483-1-dtcccc@linux.alibaba.com Fixes: 37f46601383a ("selftests/tracing: Add basic test for trace_marker_raw file") Signed-off-by: Tianchen Ding <dtcccc@linux.alibaba.com> Reviewed-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> 
On ARM64 kernels with 64K pages, the trace_marker_raw test fails because
bash's printf builtin uses stdio buffering which splits output into
multiple small write() calls to the tracefs file. Since each individual
write is within TRACE_MARKER_MAX_SIZE (4096), they all succeed, causing
the "too big" write test to incorrectly pass.

Fix by writing through dd with iflag=fullblock to guarantee a single
atomic write() syscall to trace_marker_raw.

Link: https://lore.kernel.org/r/20260601023251.1916483-1-dtcccc@linux.alibaba.com
Fixes: 37f46601383a ("selftests/tracing: Add basic test for trace_marker_raw file")
Signed-off-by: Tianchen Ding <dtcccc@linux.alibaba.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
selftests/ftrace: Drop invalid top-level local in test_ownership 2026-06-17T22:27:17+00:00 Cao Ruichuang create0818@163.com 2026-04-07T10:26:13+00:00 808c447df2fe234eb7d9e08ecf53159d291c104c test_ownership.tc is sourced by ftracetest under /bin/sh. The script currently declares mount_point with local at file scope, which makes /bin/sh abort with "local: not in a function" before the test can reach the eventfs ownership checks. Replace the top-level local declaration with a normal shell variable so kernels that support the gid= tracefs mount option can run the test at all. Link: https://lore.kernel.org/r/20260407102613.81419-1-create0818@163.com Fixes: 8b55572e51805 ("tracing/selftests: Add tracefs mount options test") Signed-off-by: Cao Ruichuang <create0818@163.com> Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> 
test_ownership.tc is sourced by ftracetest under /bin/sh.

The script currently declares mount_point with local at file scope,
which makes /bin/sh abort with "local: not in a function" before the
test can reach the eventfs ownership checks.

Replace the top-level local declaration with a normal shell variable so
kernels that support the gid= tracefs mount option can run the test at
all.

Link: https://lore.kernel.org/r/20260407102613.81419-1-create0818@163.com
Fixes: 8b55572e51805 ("tracing/selftests: Add tracefs mount options test")
Signed-off-by: Cao Ruichuang <create0818@163.com>
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
tracing/probes: Point the error offset correctly for eprobe argument error 2026-05-30T13:45:50+00:00 Masami Hiramatsu (Google) mhiramat@kernel.org 2026-05-25T02:21:14+00:00 85e0f27dd1396307913ffc5745b0c05137e9beac Fix to point the error offset correctly for eprobe argument error. In the cleanup commit 1b8b0cd754cd ("tracing/probes: Move event parameter fetching code to common parser"), due to incorrect backward compatibility aimed at conforming to the test specifications, the error location was set to 0 when a non-existent formal parameter was specified for Eprobe. However, this should be corrected in both the test and the implementation to point correct error position. Link: https://lore.kernel.org/all/177967567399.209006.1451571244515632097.stgit@devnote2/ Fixes: 1b8b0cd754cd ("tracing/probes: Move event parameter fetching code to common parser") Cc: stable@vger.kernel.org Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Reviewed-by: Steven Rostedt <rostedt@goodmis.org> 
Fix to point the error offset correctly for eprobe argument error.
In the cleanup commit 1b8b0cd754cd ("tracing/probes: Move event parameter
fetching code to common parser"), due to incorrect backward compatibility
aimed at conforming to the test specifications, the error location was set
to 0 when a non-existent formal parameter was specified for Eprobe.
However, this should be corrected in both the test and the implementation
to point correct error position.

Link: https://lore.kernel.org/all/177967567399.209006.1451571244515632097.stgit@devnote2/

Fixes: 1b8b0cd754cd ("tracing/probes: Move event parameter fetching code to common parser")
Cc: stable@vger.kernel.org
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
selftests/ftrace: Add a testcase for multiple fprobe events 2026-04-22T00:26:46+00:00 Masami Hiramatsu (Google) mhiramat@kernel.org 2026-04-20T14:01:43+00:00 453553e1ed53ca364454e155ba33e110d02c75cd Add a testcase for multiple fprobe events on the same function so that it clears ftrace hash map correctly when removing the events. Link: https://lore.kernel.org/all/177669370353.132053.16801520791509406141.stgit@mhiramat.tok.corp.google.com/ Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> 
Add a testcase for multiple fprobe events on the same function
so that it clears ftrace hash map correctly when removing the
events.

Link: https://lore.kernel.org/all/177669370353.132053.16801520791509406141.stgit@mhiramat.tok.corp.google.com/

Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>