From: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
To: Namhyung Kim <namhyung@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
cclaudio@linux.ibm.com, Jiri Olsa <jolsa@kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] perf trace: Fix SIGSEGV when processing syscall args
Date: Mon, 11 Jul 2022 21:11:39 +0530 [thread overview]
Message-ID: <1657553759.3ij85y5uv1.naveen@linux.ibm.com> (raw)
In-Reply-To: <CAM9d7cjUVd+O3Ftg3vSAEHnZqS2ZAGez26BjyjY_ZZ3ce40qyA@mail.gmail.com>
Hi Namhyung,
Namhyung Kim wrote:
> Hello,
>
> On Thu, Jul 7, 2022 at 2:09 AM Naveen N. Rao
> <naveen.n.rao@linux.vnet.ibm.com> wrote:
>>
>> On powerpc, 'perf trace' is crashing with a SIGSEGV when trying to
>> process a perf.data file created with 'perf trace record -p':
>>
>> #0 0x00000001225b8988 in syscall_arg__scnprintf_augmented_string <snip> at builtin-trace.c:1492
>> #1 syscall_arg__scnprintf_filename <snip> at builtin-trace.c:1492
>> #2 syscall_arg__scnprintf_filename <snip> at builtin-trace.c:1486
>> #3 0x00000001225bdd9c in syscall_arg_fmt__scnprintf_val <snip> at builtin-trace.c:1973
>> #4 syscall__scnprintf_args <snip> at builtin-trace.c:2041
>> #5 0x00000001225bff04 in trace__sys_enter <snip> at builtin-trace.c:2319
>>
>> That points to the below code in tools/perf/builtin-trace.c:
>> /*
>> * If this is raw_syscalls.sys_enter, then it always comes with the 6 possible
>> * arguments, even if the syscall being handled, say "openat", uses only 4 arguments
>> * this breaks syscall__augmented_args() check for augmented args, as we calculate
>> * syscall->args_size using each syscalls:sys_enter_NAME tracefs format file,
>> * so when handling, say the openat syscall, we end up getting 6 args for the
>> * raw_syscalls:sys_enter event, when we expected just 4, we end up mistakenly
>> * thinking that the extra 2 u64 args are the augmented filename, so just check
>> * here and avoid using augmented syscalls when the evsel is the raw_syscalls one.
>> */
>> if (evsel != trace->syscalls.events.sys_enter)
>> augmented_args = syscall__augmented_args(sc, sample, &augmented_args_size, trace->raw_augmented_syscalls_args_size);
>>
>> As the comment points out, we should not be trying to augment the args
>> for raw_syscalls. However, when processing a perf.data file, we are not
>> initializing those properly. Fix the same.
>>
>> Reported-by: Claudio Carvalho <cclaudio@linux.ibm.com>
>> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
>> ---
>> tools/perf/builtin-trace.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
>> index 897fc504918b91..f075cf37a65ef8 100644
>> --- a/tools/perf/builtin-trace.c
>> +++ b/tools/perf/builtin-trace.c
>> @@ -4280,6 +4280,7 @@ static int trace__replay(struct trace *trace)
>> goto out;
>>
>> evsel = evlist__find_tracepoint_by_name(session->evlist, "raw_syscalls:sys_enter");
>> + trace->syscalls.events.sys_enter = evsel;
>> /* older kernels have syscalls tp versus raw_syscalls */
>
> Isn't it better to set it after the NULL check below?
From trace__sys_enter():
/*
* If this is raw_syscalls.sys_enter, then it always comes with the 6 possible
* arguments, even if the syscall being handled, say "openat", uses only 4 arguments
* this breaks syscall__augmented_args() check for augmented args, as we calculate
* syscall->args_size using each syscalls:sys_enter_NAME tracefs format file,
* so when handling, say the openat syscall, we end up getting 6 args for the
* raw_syscalls:sys_enter event, when we expected just 4, we end up mistakenly
* thinking that the extra 2 u64 args are the augmented filename, so just check
* here and avoid using augmented syscalls when the evsel is the raw_syscalls one.
*/
if (evsel != trace->syscalls.events.sys_enter)
augmented_args = syscall__augmented_args(sc, sample, &augmented_args_size, trace->raw_augmented_syscalls_args_size);
From the previous discussion [1], it looks like the assumption above is
that sys_enter would be set to raw_syscalls.
As such, I set it before the NULL check below, which ends up falling
back to the non-raw syscalls tracepoint.
Thanks,
Naveen
[1] https://lore.kernel.org/all/YjDSRb1wwswKpJNJ@kernel.org/
next prev parent reply other threads:[~2022-07-11 15:42 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-07 9:09 [PATCH v2] perf trace: Fix SIGSEGV when processing syscall args Naveen N. Rao
2022-07-08 20:50 ` Namhyung Kim
2022-07-11 15:41 ` Naveen N. Rao [this message]
2022-07-17 14:01 ` Arnaldo Carvalho de Melo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1657553759.3ij85y5uv1.naveen@linux.ibm.com \
--to=naveen.n.rao@linux.vnet.ibm.com \
--cc=acme@kernel.org \
--cc=cclaudio@linux.ibm.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=namhyung@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox