[PATCH] selftests/ftrace: allow relative paths in eprobe test

[PATCH] selftests/ftrace: allow relative paths in eprobe test

[Martin Kaiser]

The add/remove eprobe test installs an eprobe for the openat syscall,
runs ls and checks the filenames that were opened.

Commit 206b25c09080 ("tracing: eprobe: read the complete FILTER_PTR_STRING
pointer") fixed access to some string fields in eprobes. This allows for
dereferencing more filenames. In some cases, the log now shows a file
with a relative path instead of "(fault)". A relative path makes the
test fail.

Relax the filename checks to fix the test. Allow shared libraries and
locale configs that use a relative path.

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>
---
 .../selftests/ftrace/test.d/dynevent/add_remove_eprobe.tc      | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/testing/selftests/ftrace/test.d/dynevent/add_remove_eprobe.tc b/tools/testing/selftests/ftrace/test.d/dynevent/add_remove_eprobe.tc
index c300eb020262..baceeca7ccdf 100644
--- a/tools/testing/selftests/ftrace/test.d/dynevent/add_remove_eprobe.tc
+++ b/tools/testing/selftests/ftrace/test.d/dynevent/add_remove_eprobe.tc
@@ -22,7 +22,8 @@ ls
 echo 0 > events/eprobes/$EPROBE/enable
 
 content=`grep '^ *ls-' trace | grep 'file='`
-nocontent=`grep '^ *ls-' trace | grep 'file=' | grep -v -e '"/' -e '"."' -e '(fault)' ` || true
+nocontent=`grep '^ *ls-' trace | grep 'file=' | \
+	   grep -v -e '"/' -e '.so' -e 'locale' -e '"."' -e '(fault)'` || true
 
 if [ -z "$content" ]; then
 	exit_fail
-- 
2.43.7

Re: [PATCH] selftests/ftrace: allow relative paths in eprobe test

[Masami Hiramatsu]

On Tue, 21 Jul 2026 22:05:59 +0200
Martin Kaiser <martin@kaiser.cx> wrote:

> The add/remove eprobe test installs an eprobe for the openat syscall,
> runs ls and checks the filenames that were opened.
> 
> Commit 206b25c09080 ("tracing: eprobe: read the complete FILTER_PTR_STRING
> pointer") fixed access to some string fields in eprobes. This allows for
> dereferencing more filenames. In some cases, the log now shows a file
> with a relative path instead of "(fault)". A relative path makes the
> test fail.
> 
> Relax the filename checks to fix the test. Allow shared libraries and
> locale configs that use a relative path.

Hmm, should we check this "nocontent" ? This change seems a bit fragile.
I think we should use another syscall to make sure getting filename
correctly. At least this point, removing nocontent check will be better.

Thank you,

> 
> 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>
> ---
>  .../selftests/ftrace/test.d/dynevent/add_remove_eprobe.tc      | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/testing/selftests/ftrace/test.d/dynevent/add_remove_eprobe.tc b/tools/testing/selftests/ftrace/test.d/dynevent/add_remove_eprobe.tc
> index c300eb020262..baceeca7ccdf 100644
> --- a/tools/testing/selftests/ftrace/test.d/dynevent/add_remove_eprobe.tc
> +++ b/tools/testing/selftests/ftrace/test.d/dynevent/add_remove_eprobe.tc
> @@ -22,7 +22,8 @@ ls
>  echo 0 > events/eprobes/$EPROBE/enable
>  
>  content=`grep '^ *ls-' trace | grep 'file='`
> -nocontent=`grep '^ *ls-' trace | grep 'file=' | grep -v -e '"/' -e '"."' -e '(fault)' ` || true
> +nocontent=`grep '^ *ls-' trace | grep 'file=' | \
> +	   grep -v -e '"/' -e '.so' -e 'locale' -e '"."' -e '(fault)'` || true
>  
>  if [ -z "$content" ]; then
>  	exit_fail
> -- 
> 2.43.7
> 


-- 
Masami Hiramatsu (Google) <mhiramat@kernel.org>

Re: [PATCH] selftests/ftrace: allow relative paths in eprobe test

[Martin Kaiser]

Thus wrote Masami Hiramatsu (mhiramat@kernel.org):

> On Tue, 21 Jul 2026 22:05:59 +0200
> Martin Kaiser <martin@kaiser.cx> wrote:

> > The add/remove eprobe test installs an eprobe for the openat syscall,
> > runs ls and checks the filenames that were opened.

> > Commit 206b25c09080 ("tracing: eprobe: read the complete FILTER_PTR_STRING
> > pointer") fixed access to some string fields in eprobes. This allows for
> > dereferencing more filenames. In some cases, the log now shows a file
> > with a relative path instead of "(fault)". A relative path makes the
> > test fail.

> > Relax the filename checks to fix the test. Allow shared libraries and
> > locale configs that use a relative path.

> Hmm, should we check this "nocontent" ? This change seems a bit fragile.
> I think we should use another syscall to make sure getting filename
> correctly. At least this point, removing nocontent check will be better.

I've just sent another patch that uses chdir instead of openat. For chdir, we
know which filename we'll see in the logs and we can use a simpler filter.

Best regards,
Martin

Re: [PATCH] selftests/ftrace: allow relative paths in eprobe test

[Masami Hiramatsu]

On Tue, 4 Aug 2026 21:51:01 +0200
Martin Kaiser <martin@kaiser.cx> wrote:

> Thus wrote Masami Hiramatsu (mhiramat@kernel.org):
> 
> > On Tue, 21 Jul 2026 22:05:59 +0200
> > Martin Kaiser <martin@kaiser.cx> wrote:
> 
> > > The add/remove eprobe test installs an eprobe for the openat syscall,
> > > runs ls and checks the filenames that were opened.
> 
> > > Commit 206b25c09080 ("tracing: eprobe: read the complete FILTER_PTR_STRING
> > > pointer") fixed access to some string fields in eprobes. This allows for
> > > dereferencing more filenames. In some cases, the log now shows a file
> > > with a relative path instead of "(fault)". A relative path makes the
> > > test fail.
> 
> > > Relax the filename checks to fix the test. Allow shared libraries and
> > > locale configs that use a relative path.
> 
> > Hmm, should we check this "nocontent" ? This change seems a bit fragile.
> > I think we should use another syscall to make sure getting filename
> > correctly. At least this point, removing nocontent check will be better.
> 
> I've just sent another patch that uses chdir instead of openat. For chdir, we
> know which filename we'll see in the logs and we can use a simpler filter.
> 

Sounds nice, Thanks!

> Best regards,
> Martin


-- 
Masami Hiramatsu (Google) <mhiramat@kernel.org>