* [PATCH v4] perf test: Fix test trace+probe_vfs_getname.sh on s390
@ 2020-02-17 10:21 Thomas Richter
2020-02-17 12:10 ` Masami Hiramatsu
0 siblings, 1 reply; 3+ messages in thread
From: Thomas Richter @ 2020-02-17 10:21 UTC (permalink / raw)
To: linux-kernel, linux-perf-users, acme, mhiramat
Cc: gor, sumanthk, heiko.carstens, Thomas Richter
This test places a kprobe to function getname_flags() in the kernel
which has the following prototype:
struct filename *
getname_flags(const char __user *filename, int flags, int *empty)
Variable filename points to a filename located in user space memory.
Looking at
commit 88903c464321c ("tracing/probe: Add ustring type for user-space string")
the kprobe should indicate that user space memory is accessed.
Output before:
[root@m35lp76 perf]# ./perf test 66 67
66: Use vfs_getname probe to get syscall args filenames : FAILED!
67: Check open filename arg using perf trace + vfs_getname: FAILED!
[root@m35lp76 perf]#
Output after:
[root@m35lp76 perf]# ./perf test 66 67
66: Use vfs_getname probe to get syscall args filenames : Ok
67: Check open filename arg using perf trace + vfs_getname: Ok
[root@m35lp76 perf]#
Comments from Masami Hiramatsu:
This bug doesn't happen on x86 or other archs on which user-address
space and kernel address space is same. On some arch (ppc64 in this case?)
user-address space is partially or completely same as kernel address space.
(Yes, they switch the world when running into the kernel) In this case,
we need to use different data access functions for each spaces.
That is why I introduced "ustring" type for kprobe event.
As far as I can see, Thomas's patch is sane. Thomas, could you show us
your result on your test environment?
Thank you
Comments from Thomas Richter:
Test results included above.
Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
---
tools/perf/tests/shell/lib/probe_vfs_getname.sh | 2 +-
1 file changed, 1 insertion(+), 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 7cb99b433888..c2cc42daf924 100644
--- a/tools/perf/tests/shell/lib/probe_vfs_getname.sh
+++ b/tools/perf/tests/shell/lib/probe_vfs_getname.sh
@@ -14,7 +14,7 @@ add_probe_vfs_getname() {
if [ $had_vfs_getname -eq 1 ] ; then
line=$(perf probe -L getname_flags 2>&1 | egrep 'result.*=.*filename;' | sed -r 's/[[:space:]]+([[:digit:]]+)[[:space:]]+result->uptr.*/\1/')
perf probe -q "vfs_getname=getname_flags:${line} pathname=result->name:string" || \
- perf probe $verbose "vfs_getname=getname_flags:${line} pathname=filename:string"
+ perf probe $verbose "vfs_getname=getname_flags:${line} pathname=filename:ustring"
fi
}
--
2.21.0
^ permalink raw reply related [flat|nested] 3+ messages in thread* Re: [PATCH v4] perf test: Fix test trace+probe_vfs_getname.sh on s390
2020-02-17 10:21 [PATCH v4] perf test: Fix test trace+probe_vfs_getname.sh on s390 Thomas Richter
@ 2020-02-17 12:10 ` Masami Hiramatsu
2020-02-17 14:29 ` Arnaldo Carvalho de Melo
0 siblings, 1 reply; 3+ messages in thread
From: Masami Hiramatsu @ 2020-02-17 12:10 UTC (permalink / raw)
To: Thomas Richter
Cc: linux-kernel, linux-perf-users, acme, gor, sumanthk,
heiko.carstens
On Mon, 17 Feb 2020 11:21:11 +0100
Thomas Richter <tmricht@linux.ibm.com> wrote:
> This test places a kprobe to function getname_flags() in the kernel
> which has the following prototype:
>
> struct filename *
> getname_flags(const char __user *filename, int flags, int *empty)
>
> Variable filename points to a filename located in user space memory.
> Looking at
> commit 88903c464321c ("tracing/probe: Add ustring type for user-space string")
> the kprobe should indicate that user space memory is accessed.
>
> Output before:
> [root@m35lp76 perf]# ./perf test 66 67
> 66: Use vfs_getname probe to get syscall args filenames : FAILED!
> 67: Check open filename arg using perf trace + vfs_getname: FAILED!
> [root@m35lp76 perf]#
>
> Output after:
> [root@m35lp76 perf]# ./perf test 66 67
> 66: Use vfs_getname probe to get syscall args filenames : Ok
> 67: Check open filename arg using perf trace + vfs_getname: Ok
> [root@m35lp76 perf]#
>
> Comments from Masami Hiramatsu:
> This bug doesn't happen on x86 or other archs on which user-address
> space and kernel address space is same. On some arch (ppc64 in this case?)
> user-address space is partially or completely same as kernel address space.
> (Yes, they switch the world when running into the kernel) In this case,
> we need to use different data access functions for each spaces.
> That is why I introduced "ustring" type for kprobe event.
> As far as I can see, Thomas's patch is sane. Thomas, could you show us
> your result on your test environment?
> Thank you
>
> Comments from Thomas Richter:
> Test results included above.
>
> Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
Looks good to me.
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Thank you,
> ---
> tools/perf/tests/shell/lib/probe_vfs_getname.sh | 2 +-
> 1 file changed, 1 insertion(+), 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 7cb99b433888..c2cc42daf924 100644
> --- a/tools/perf/tests/shell/lib/probe_vfs_getname.sh
> +++ b/tools/perf/tests/shell/lib/probe_vfs_getname.sh
> @@ -14,7 +14,7 @@ add_probe_vfs_getname() {
> if [ $had_vfs_getname -eq 1 ] ; then
> line=$(perf probe -L getname_flags 2>&1 | egrep 'result.*=.*filename;' | sed -r 's/[[:space:]]+([[:digit:]]+)[[:space:]]+result->uptr.*/\1/')
> perf probe -q "vfs_getname=getname_flags:${line} pathname=result->name:string" || \
> - perf probe $verbose "vfs_getname=getname_flags:${line} pathname=filename:string"
> + perf probe $verbose "vfs_getname=getname_flags:${line} pathname=filename:ustring"
> fi
> }
>
> --
> 2.21.0
>
--
Masami Hiramatsu <mhiramat@kernel.org>
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [PATCH v4] perf test: Fix test trace+probe_vfs_getname.sh on s390
2020-02-17 12:10 ` Masami Hiramatsu
@ 2020-02-17 14:29 ` Arnaldo Carvalho de Melo
0 siblings, 0 replies; 3+ messages in thread
From: Arnaldo Carvalho de Melo @ 2020-02-17 14:29 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Thomas Richter, linux-kernel, linux-perf-users, gor, sumanthk,
heiko.carstens
Em Mon, Feb 17, 2020 at 09:10:10PM +0900, Masami Hiramatsu escreveu:
> On Mon, 17 Feb 2020 11:21:11 +0100
> Thomas Richter <tmricht@linux.ibm.com> wrote:
>
> > This test places a kprobe to function getname_flags() in the kernel
> > which has the following prototype:
> >
> > struct filename *
> > getname_flags(const char __user *filename, int flags, int *empty)
> >
> > Variable filename points to a filename located in user space memory.
> > Looking at
> > commit 88903c464321c ("tracing/probe: Add ustring type for user-space string")
> > the kprobe should indicate that user space memory is accessed.
> >
> > Output before:
> > [root@m35lp76 perf]# ./perf test 66 67
> > 66: Use vfs_getname probe to get syscall args filenames : FAILED!
> > 67: Check open filename arg using perf trace + vfs_getname: FAILED!
> > [root@m35lp76 perf]#
> >
> > Output after:
> > [root@m35lp76 perf]# ./perf test 66 67
> > 66: Use vfs_getname probe to get syscall args filenames : Ok
> > 67: Check open filename arg using perf trace + vfs_getname: Ok
> > [root@m35lp76 perf]#
> >
> > Comments from Masami Hiramatsu:
> > This bug doesn't happen on x86 or other archs on which user-address
> > space and kernel address space is same. On some arch (ppc64 in this case?)
> > user-address space is partially or completely same as kernel address space.
> > (Yes, they switch the world when running into the kernel) In this case,
> > we need to use different data access functions for each spaces.
> > That is why I introduced "ustring" type for kprobe event.
> > As far as I can see, Thomas's patch is sane. Thomas, could you show us
> > your result on your test environment?
> > Thank you
> >
> > Comments from Thomas Richter:
> > Test results included above.
> >
> > Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
>
> Looks good to me.
>
> Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Thanks, I tested it successfully on x86-64, applying.
- Arnaldo
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-02-17 14:29 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-02-17 10:21 [PATCH v4] perf test: Fix test trace+probe_vfs_getname.sh on s390 Thomas Richter
2020-02-17 12:10 ` Masami Hiramatsu
2020-02-17 14:29 ` Arnaldo Carvalho de Melo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).