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

[Google]

On Sun, 19 Jul 2026 12:04:20 +0200
Martin Kaiser <martin@xxxxxxxxx> wrote:

> Hi,
> 
> Thus wrote kernel test robot (oliver.sang@xxxxxxxxx):
> 
> > kernel test robot noticed "kselftests-bpf.ftrace.ftracetest-ktap.Generic_dynamic_event_-_add/remove_eprobe_events.fail" on:
> 
> > commit: 206b25c09080cc20fd4c2bea12d59df4b7ba2121 ("tracing: eprobe: read the complete FILTER_PTR_STRING pointer")
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> 
> > [test failed on linus/master      3b029c035b34bbc693405ddf759f0e9b920c27f1]
> > [test failed on linux-next/master 49362394dad7df66c274c867a271394c10ca2bb8]
> 
> > in testcase: kselftests-bpf
> > version: 
> > with following parameters:
> 
> > 	group: ftrace
> 
> > 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
> 
> > (please refer to attached dmesg/kmsg for entire log/backtrace)
> 
> [...]
> 
> > # # ++ 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"
> [...]
> > # # 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) <mhiramat@xxxxxxxxxx>