Re: [linus:master] [tracing] 206b25c090: kselftests-bpf.ftrace.ftracetest-ktap.Generic_dynamic_event_-_add/remove_eprobe_events.fail

On Sun, 19 Jul 2026 12:04:20 +0200
Martin Kaiser [off-list ref] wrote:

Hi,

Thus wrote kernel test robot (oliver.sang@intel.com):

quoted

kernel test robot noticed "kselftests-bpf.ftrace.ftracetest-ktap.Generic_dynamic_event_-_add/remove_eprobe_events.fail" on:

quoted

commit: 206b25c09080cc20fd4c2bea12d59df4b7ba2121 ("tracing: eprobe: read the complete FILTER_PTR_STRING pointer")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master

quoted

[test failed on linus/master      3b029c035b34bbc693405ddf759f0e9b920c27f1]
[test failed on linux-next/master 49362394dad7df66c274c867a271394c10ca2bb8]

quoted

in testcase: kselftests-bpf
version: 
with following parameters:

quoted

	group: ftrace

quoted

config: x86_64-rhel-9.4-bpf
compiler: gcc-14
test machine: 16 threads Intel(R) Core(TM) i7-13620H (Raptor Lake) with 32G memory

quoted

(please refer to attached dmesg/kmsg for entire log/backtrace)

[...]

quoted

# # ++ echo 0
# # +++ grep '^ *ls-' trace
# # +++ grep file=
# # ++ content='              ls-5520    [006] ...1.   335.361454: eprobe_open: (syscalls.sys_enter_openat) file="/usr/libexec/coreutils/libstdbuf.so"
# # ls-5520    [006] ...1.   335.361620: eprobe_open: (syscalls.sys_enter_openat) file="glibc-hwcaps/x86-64-v3/libselinux.so.1"
# # ls-5520    [006] ...1.   335.361649: eprobe_open: (syscalls.sys_enter_openat) file="glibc-hwcaps/x86-64-v2/libselinux.so.1"

[...]

quoted

# # ls-5520    [006] ...1.   335.364212: eprobe_open: (syscalls.sys_enter_openat) file="/usr/lib/locale/C.UTF-8/LC_NUMERIC"
# # ls-5520    [006] ...1.   335.364239: eprobe_open: (syscalls.sys_enter_openat) file="/usr/lib/locale/C.utf8/LC_NUMERIC"
# # ls-5520    [006] ...1.   335.364265: eprobe_open: (syscalls.sys_enter_openat) file="/usr/lib/locale/C.UTF-8/LC_CTYPE"
# # ls-5520    [006] ...1.   335.364292: eprobe_open: (syscalls.sys_enter_openat) file="/usr/lib/locale/C.utf8/LC_CTYPE"
# # ls-5520    [006] ...1.   335.364341: eprobe_open: (syscalls.sys_enter_openat) file="."'
# # +++ grep '^ *ls-' trace
# # +++ grep file=
# # +++ grep -v -e '"/' -e '"."' -e '(fault)'
# # ++ nocontent='              ls-5520    [006] ...1.   335.361620: eprobe_open: (syscalls.sys_enter_openat) file="glibc-hwcaps/x86-64-v3/libselinux.so.1"
# # ls-5520    [006] ...1.   335.361649: eprobe_open: (syscalls.sys_enter_openat) file="glibc-hwcaps/x86-64-v2/libselinux.so.1"
# # ls-5520    [006] ...1.   335.361676: eprobe_open: (syscalls.sys_enter_openat) file="libselinux.so.1"
# # ls-5520    [006] ...1.   335.362051: eprobe_open: (syscalls.sys_enter_openat) file="glibc-hwcaps/x86-64-v3/libcap.so.2"
# # ls-5520    [006] ...1.   335.362080: eprobe_open: (syscalls.sys_enter_openat) file="glibc-hwcaps/x86-64-v2/libcap.so.2"
# # ls-5520    [006] ...1.   335.362107: eprobe_open: (syscalls.sys_enter_openat) file="libcap.so.2"
# # ls-5520    [006] ...1.   335.362288: eprobe_open: (syscalls.sys_enter_openat) file="glibc-hwcaps/x86-64-v3/libc.so.6"
# # ls-5520    [006] ...1.   335.362314: eprobe_open: (syscalls.sys_enter_openat) file="glibc-hwcaps/x86-64-v2/libc.so.6"
# # ls-5520    [006] ...1.   335.362340: eprobe_open: (syscalls.sys_enter_openat) file="libc.so.6"
# # ls-5520    [006] ...1.   335.362552: eprobe_open: (syscalls.sys_enter_openat) file="glibc-hwcaps/x86-64-v3/libpcre2-8.so.0"
# # ls-5520    [006] ...1.   335.362581: eprobe_open: (syscalls.sys_enter_openat) file="glibc-hwcaps/x86-64-v2/libpcre2-8.so.0"
# # ls-5520    [006] ...1.   335.362607: eprobe_open: (syscalls.sys_enter_openat) file="libpcre2-8.so.0"'

This list must be empty for the test to pass. Files with absolute paths and
pointers that can't be dereferenced "(fault)" are filtered.

Yeah, it seems like a test bug.

My patch fixed the dereferencing, some of the faults are now readable
filenames. And for some of those, openat used a relative path.

Hm, in this case, we need to fix the test too.

IMHO, the test is not correct, relative paths should be allowed. (In fact, any
name of an existing file should be ok.)

I'll think about this a bit more and submit a patch to fix the test.

Thanks for you help!

Thank you,

-- 
Masami Hiramatsu (Google) [off-list ref]