linux-kernel - Re: [PATCH] perf trace: get rid of the hard-coded paths in the report scripts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTik89+p5rVfYThebTazg09wtes6_9CpP9HB6dFEB@mail.gmail.com>
Date:	Thu, 12 Aug 2010 16:50:40 -0500
From:	Tom Zanussi <tzanussi@...il.com>
To:	Stephane Eranian <eranian@...gle.com>
Cc:	linux-kernel@...r.kernel.org, acme@...radead.org, mingo@...e.hu,
	acme@...hat.com, fweisbec@...il.com, peterz@...radead.org
Subject: Re: [PATCH] perf trace: get rid of the hard-coded paths in the report scripts

On Thu, Aug 12, 2010 at 4:28 PM, Stephane Eranian <eranian@...gle.com> wrote:
> On Thu, Aug 12, 2010 at 7:59 PM, Tom Zanussi <tzanussi@...il.com> wrote:
>> The perf trace report shell scripts hard-code the exec path of the
>> scripts into their command-lines, which doesn't work if perf has been
>> installed somewhere else.
>>
>> Instead, perf trace should create the paths at run-time.  This patch
>> does that and removes the hard-coded paths from all the report scripts.
>>
>> v2 changes: The first version inadvertantly caused scripts run from
>> outside the perf exec path to fail e.g. 'perf trace -s test.py'.  The
>> fix is to try the script name without the exec path first, then the
>> version using the exec path, which restores the expected behavior.
>>
>> Reported-by: Stephane Eranian <eranian@...gle.com>
>> Signed-off-by: Tom Zanussi <tzanussi@...il.com>
>> ---
>>  tools/perf/builtin-trace.c                         |   22 ++++++++++++++++---
>>  tools/perf/scripts/perl/bin/failed-syscalls-report |    2 +-
>>  tools/perf/scripts/perl/bin/rw-by-file-report      |    2 +-
>>  tools/perf/scripts/perl/bin/rw-by-pid-report       |    2 +-
>>  tools/perf/scripts/perl/bin/rwtop-report           |    2 +-
>>  tools/perf/scripts/perl/bin/wakeup-latency-report  |    2 +-
>>  tools/perf/scripts/perl/bin/workqueue-stats-report |    2 +-
>>  .../python/bin/failed-syscalls-by-pid-report       |    2 +-
>>  .../perf/scripts/python/bin/sched-migration-report |    2 +-
>>  tools/perf/scripts/python/bin/sctop-report         |    2 +-
>>  .../python/bin/syscall-counts-by-pid-report        |    2 +-
>>  .../perf/scripts/python/bin/syscall-counts-report  |    3 +-
>>  12 files changed, 30 insertions(+), 15 deletions(-)
>>
>> diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
>> index 40a6a29..88a1883 100644
>> --- a/tools/perf/builtin-trace.c
>> +++ b/tools/perf/builtin-trace.c
>> @@ -573,6 +573,7 @@ int cmd_trace(int argc, const char **argv, const char *prefix __used)
>>        const char *suffix = NULL;
>>        const char **__argv;
>>        char *script_path;
>> +       struct stat perf_stat;
>>        int i, err;
>>
>>        if (argc >= 2 && strncmp(argv[1], "rec", strlen("rec")) == 0) {
>> @@ -689,8 +690,6 @@ int cmd_trace(int argc, const char **argv, const char *prefix __used)
>>                return -EINVAL;
>>
>>        if (generate_script_lang) {
>> -               struct stat perf_stat;
>> -
>>                int input = open(input_name, O_RDONLY);
>>                if (input < 0) {
>>                        perror("failed to open file");
>> @@ -719,10 +718,25 @@ int cmd_trace(int argc, const char **argv, const char *prefix __used)
>>        }
>>
>>        if (script_name) {
>> -               err = scripting_ops->start_script(script_name, argc, argv);
>> +               char script_exec_path[MAXPATHLEN];
>> +
>> +               snprintf(script_exec_path, MAXPATHLEN, "%s", script_name);
>> +               err = stat(script_exec_path, &perf_stat);
>
> Why not simply use access() instead of stat() here?

Yeah, that would probably be better - if this patch works for you, I
can submit a follow-on patch to do that along with some other small
patches I'm hoping to get to over the weekend...

Thanks,

Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/