[PATCH ping2 linux-next] perf test: probe_vfs_getname add do_getname() probing fallback

[PATCH ping2 linux-next] perf test: probe_vfs_getname add do_getname() probing fallback

[Thomas Richter]

The following tests are skipped for some time now on platforms
s390 and x86_64:

 # perf test vfs_getname
 138: Add vfs_getname probe to get syscall args filenames    : Skip
 140: Use vfs_getname probe to get syscall args filenames    : Skip
 154: Check open filename arg using perf trace + vfs_getname : Skip
 #

This is caused by a change in kernel code of function
getname_flags(), see
  commit 9fa3ec84587c ("allow incomplete imports of filenames")
This commit changed the function getname_flags() implementation.

Now the perf probe 'vfs_getname parameter=xxx' does not match any
more. Extend the test logic to fall back to probing do_getname().
This reflects the updated kernel code.

Output after:
 # perf test vfs_getname
 138: Add vfs_getname probe to get syscall args filenames    : Ok
 140: Use vfs_getname probe to get syscall args filenames    : Ok
 154: Check open filename arg using perf trace + vfs_getname : Ok
 #

Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
Reviewed-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
---
 tools/perf/tests/shell/lib/probe_vfs_getname.sh | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/tools/perf/tests/shell/lib/probe_vfs_getname.sh b/tools/perf/tests/shell/lib/probe_vfs_getname.sh
index 88cd0e26d5f6..9156a79212b9 100644
--- a/tools/perf/tests/shell/lib/probe_vfs_getname.sh
+++ b/tools/perf/tests/shell/lib/probe_vfs_getname.sh
@@ -12,6 +12,8 @@ cleanup_probe_vfs_getname() {
 
 add_probe_vfs_getname() {
 	add_probe_verbose=$1
+	do_getname=0
+
 	if [ $had_vfs_getname -eq 1 ] ; then
 		result_initname_re="[[:space:]]+([[:digit:]]+)[[:space:]]+initname.*"
 		line=$(perf probe -L getname_flags 2>&1 | grep -E "$result_initname_re" | sed -r "s/$result_initname_re/\1/")
@@ -28,12 +30,24 @@ add_probe_vfs_getname() {
 			line=$(perf probe -L getname_flags 2>&1 | grep -E "$result_aname_re" | sed -r "s/$result_aname_re/\1/")
 		fi
 
+		if [ -z "$line" ] ; then
+			do_getname=1
+			result_iname_re="[[:space:]]+([[:digit:]]+)[[:space:]]+initname\(result\);"
+			line=$(perf probe -L do_getname 2>&1 | grep -E "$result_iname_re" | sed -r "s/$result_iname_re/\1/")
+		fi
+
 		if [ -z "$line" ] ; then
 			echo "Could not find probeable line"
 			return 2
 		fi
 
-		perf probe -q       "vfs_getname=getname_flags:${line} pathname=result->name:string" || \
+		if [ "$do_getname" -eq 1 ]
+		then
+			param="vfs_getname=do_getname:${line} pathname=result->iname:string"
+			perf probe -q "$param" || perf probe $add_probe_verbose "$param" || return 1
+			return 0
+		fi
+		perf probe -q "vfs_getname=getname_flags:${line} pathname=result->name:string" || \
 		perf probe $add_probe_verbose "vfs_getname=getname_flags:${line} pathname=filename:ustring" || return 1
 	fi
 }
-- 
2.53.0

Re: [PATCH ping2 linux-next] perf test: probe_vfs_getname add do_getname() probing fallback

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The fallback perf probe uses `result->iname:string` instead of `result->name:string`, causing out-of-bounds kernel memory reads for long paths.
- [Medium] The `do_getname` probe registration drops the reliable userspace string fallback (`pathname=filename:ustring`).
--

commit eda643d967c95ab86fa0ef1c44c37f4ff13cc45a
Author: Thomas Richter <tmricht@linux.ibm.com>

perf test: probe_vfs_getname add do_getname() probing fallback

The perf vfs_getname test skips on some platforms because getname_flags()
no longer matches the expected perf probe format after kernel changes. This
commit falls back to probing do_getname() if the initial getname_flags()
lookup fails.

> diff --git a/tools/perf/tests/shell/lib/probe_vfs_getname.sh b/tools/perf/tests/shell/lib/probe_vfs_getname.sh
> index 88cd0e26d5f67..9156a79212b9e 100644
> --- a/tools/perf/tests/shell/lib/probe_vfs_getname.sh
> +++ b/tools/perf/tests/shell/lib/probe_vfs_getname.sh

[ ... ]

> @@ -28,12 +30,24 @@ add_probe_vfs_getname() {
>  			line=$(perf probe -L getname_flags 2>&1 | grep -E "$result_aname_re" | sed -r "s/$result_aname_re/\1/")
>  		fi
>  
> +		if [ -z "$line" ] ; then
> +			do_getname=1
> +			result_iname_re="[[:space:]]+([[:digit:]]+)[[:space:]]+initname\(result\);"
> +			line=$(perf probe -L do_getname 2>&1 | grep -E "$result_iname_re" | sed -r "s/$result_iname_re/\1/")
> +		fi
> +
>  		if [ -z "$line" ] ; then
>  			echo "Could not find probeable line"
>  			return 2
>  		fi
>  
> -		perf probe -q       "vfs_getname=getname_flags:${line} pathname=result->name:string" || \
> +		if [ "$do_getname" -eq 1 ]
> +		then
> +			param="vfs_getname=do_getname:${line} pathname=result->iname:string"

Does probing result->iname:string read out-of-bounds kernel memory when paths
are longer than EMBEDDED_NAME_MAX (192 bytes)?

In fs/namei.c, struct filename uses the flexible array iname for short paths,
but dynamically allocates a separate buffer for longer ones. When paths are
long, iname is filled without a null terminator, and result->name points to
the newly allocated buffer.

Reading iname as a string might record garbage data or cause a kprobe fault if
it reads past the end of the slab allocation.

Would it be better to use pathname=result->name:string here, mirroring the
getname_flags behavior?

> +			perf probe -q "$param" || perf probe $add_probe_verbose "$param" || return 1

Does this logic inadvertently drop the userspace string fallback
pathname=filename:ustring?

The original probe logic gracefully falls back to probing the userspace
pointer directly if the compiler optimizes out the result pointer at the
probed line.

Since do_getname() receives const char __user *filename as its first argument
exactly like getname_flags(), could we retain the pathname=filename:ustring
fallback here to improve test reliability across different compiler
environments?

> +			return 0
> +		fi
> +		perf probe -q "vfs_getname=getname_flags:${line} pathname=result->name:string" || \
>  		perf probe $add_probe_verbose "vfs_getname=getname_flags:${line} pathname=filename:ustring" || return 1
>  	fi
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260519110643.1424411-1-tmricht@linux.ibm.com?part=1

[PATCH ping2 linux-next] perf test: probe_vfs_getname add do_getname() probing fallback

[Thomas Richter]

The following tests are skipped for some time now on platforms
s390 and x86_64:

 # perf test vfs_getname
 138: Add vfs_getname probe to get syscall args filenames    : Skip
 140: Use vfs_getname probe to get syscall args filenames    : Skip
 154: Check open filename arg using perf trace + vfs_getname : Skip
 #

This is caused by a change in kernel code of function
getname_flags(), see
  commit 9fa3ec84587c ("allow incomplete imports of filenames")
This commit changed the function getname_flags() implementation.

Now the perf probe 'vfs_getname parameter=xxx' does not match any
more. Extend the test logic to fall back to probing do_getname().
This reflects the updated kernel code.

Output after:
 # perf test vfs_getname
 138: Add vfs_getname probe to get syscall args filenames    : Ok
 140: Use vfs_getname probe to get syscall args filenames    : Ok
 154: Check open filename arg using perf trace + vfs_getname : Ok
 #

Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
Reviewed-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
---
 tools/perf/tests/shell/lib/probe_vfs_getname.sh | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/tools/perf/tests/shell/lib/probe_vfs_getname.sh b/tools/perf/tests/shell/lib/probe_vfs_getname.sh
index 88cd0e26d5f6..9156a79212b9 100644
--- a/tools/perf/tests/shell/lib/probe_vfs_getname.sh
+++ b/tools/perf/tests/shell/lib/probe_vfs_getname.sh
@@ -12,6 +12,8 @@ cleanup_probe_vfs_getname() {
 
 add_probe_vfs_getname() {
 	add_probe_verbose=$1
+	do_getname=0
+
 	if [ $had_vfs_getname -eq 1 ] ; then
 		result_initname_re="[[:space:]]+([[:digit:]]+)[[:space:]]+initname.*"
 		line=$(perf probe -L getname_flags 2>&1 | grep -E "$result_initname_re" | sed -r "s/$result_initname_re/\1/")
@@ -28,12 +30,24 @@ add_probe_vfs_getname() {
 			line=$(perf probe -L getname_flags 2>&1 | grep -E "$result_aname_re" | sed -r "s/$result_aname_re/\1/")
 		fi
 
+		if [ -z "$line" ] ; then
+			do_getname=1
+			result_iname_re="[[:space:]]+([[:digit:]]+)[[:space:]]+initname\(result\);"
+			line=$(perf probe -L do_getname 2>&1 | grep -E "$result_iname_re" | sed -r "s/$result_iname_re/\1/")
+		fi
+
 		if [ -z "$line" ] ; then
 			echo "Could not find probeable line"
 			return 2
 		fi
 
-		perf probe -q       "vfs_getname=getname_flags:${line} pathname=result->name:string" || \
+		if [ "$do_getname" -eq 1 ]
+		then
+			param="vfs_getname=do_getname:${line} pathname=result->iname:string"
+			perf probe -q "$param" || perf probe $add_probe_verbose "$param" || return 1
+			return 0
+		fi
+		perf probe -q "vfs_getname=getname_flags:${line} pathname=result->name:string" || \
 		perf probe $add_probe_verbose "vfs_getname=getname_flags:${line} pathname=filename:ustring" || return 1
 	fi
 }
-- 
2.53.0

Re: [PATCH ping2 linux-next] perf test: probe_vfs_getname add do_getname() probing fallback

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The fallback probe for `do_getname` incorrectly uses `result->iname:string` instead of `result->name:string`, leading to string truncation or out-of-bounds reads for long filenames.
- [Medium] The new `do_getname` probe logic omits the fallback to reading the user-space pointer (`filename:ustring`) if the `result` struct is optimized out by the compiler, reducing test robustness.
--

commit ad303146f8b0a504f7736915a5ea288cabae2ca8
Author: Thomas Richter <tmricht@linux.ibm.com>

perf test: probe_vfs_getname add do_getname() probing fallback

This commit extends the vfs_getname perf test to fall back to probing
do_getname() if getname_flags() cannot be probed. This accounts for
recent kernel changes that altered the getname_flags() implementation.

> diff --git a/tools/perf/tests/shell/lib/probe_vfs_getname.sh b/tools/perf/tests/shell/lib/probe_vfs_getname.sh
> index 88cd0e26d5f67..9156a79212b9e 100644
> --- a/tools/perf/tests/shell/lib/probe_vfs_getname.sh
> +++ b/tools/perf/tests/shell/lib/probe_vfs_getname.sh

[ ... ]

> @@ -28,12 +30,24 @@ add_probe_vfs_getname() {
>  			line=$(perf probe -L getname_flags 2>&1 | grep -E "$result_aname_re" | sed -r "s/$result_aname_re/\1/")
>  		fi
>  
> +		if [ -z "$line" ] ; then
> +			do_getname=1
> +			result_iname_re="[[:space:]]+([[:digit:]]+)[[:space:]]+initname\(result\);"
> +			line=$(perf probe -L do_getname 2>&1 | grep -E "$result_iname_re" | sed -r "s/$result_iname_re/\1/")
> +		fi
> +
>  		if [ -z "$line" ] ; then
>  			echo "Could not find probeable line"
>  			return 2
>  		fi
>  
> -		perf probe -q       "vfs_getname=getname_flags:${line} pathname=result->name:string" || \
> +		if [ "$do_getname" -eq 1 ]
> +		then
> +			param="vfs_getname=do_getname:${line} pathname=result->iname:string"

[Severity: Medium]
Will tracing result->iname as a string cause out-of-bounds reads or
truncated output for long filenames?

Looking at getname_long() in fs/namei.c, when a filename >=
EMBEDDED_NAME_MAX is processed, a separate buffer is allocated for
name->name:

	memcpy(p, &name->iname, EMBEDDED_NAME_MAX);
	len = strncpy_from_user(p + EMBEDDED_NAME_MAX,
				filename + EMBEDDED_NAME_MAX,
				PATH_MAX - EMBEDDED_NAME_MAX);
	if (unlikely(len < 0))
		return len;
	if (unlikely(len == PATH_MAX - EMBEDDED_NAME_MAX))
		return -ENAMETOOLONG;
	name->name = no_free_ptr(p);

This leaves name->iname completely filled without a null terminator. Should
this probe use pathname=result->name:string instead to safely handle both
short and long filenames?

> +			perf probe -q "$param" || perf probe $add_probe_verbose "$param" || return 1

[Severity: Medium]
Does this fallback logic miss the user-space pointer retry?

The original code for getname_flags falls back to tracing the user-space
pointer (filename:ustring) if probing the result struct fails (which can
happen if the compiler optimizes the struct out).

In this new do_getname block, if the first probe fails, it retries the
exact same parameter with $add_probe_verbose rather than falling back to
pathname=filename:ustring. Can this cause spurious test failures on
environments where debug info for the result pointer is optimized out?

> +			return 0
> +		fi
> +		perf probe -q "vfs_getname=getname_flags:${line} pathname=result->name:string" || \
>  		perf probe $add_probe_verbose "vfs_getname=getname_flags:${line} pathname=filename:ustring" || return 1
>  	fi
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260911100455.2131629-1-tmricht@linux.ibm.com?part=1