linux-kernel - Re: [PATCH 2/3] perf test: Shell - only run .sh shell files to skip other files

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: <ae8bdc2c-a444-74c1-70d5-c97d27b22ec5@foss.arm.com>
Date:   Mon, 13 Jun 2022 14:08:30 +0100
From:   Carsten Haitzler <carsten.haitzler@...s.arm.com>
To:     Leo Yan <leo.yan@...aro.org>
Cc:     linux-kernel@...r.kernel.org, coresight@...ts.linaro.org,
        suzuki.poulose@....com, mathieu.poirier@...aro.org,
        mike.leach@...aro.org, linux-perf-users@...r.kernel.org,
        acme@...nel.org
Subject: Re: [PATCH 2/3] perf test: Shell - only run .sh shell files to skip
 other files



On 5/26/22 11:14, Leo Yan wrote:
> On Thu, Apr 21, 2022 at 05:21:27PM +0100, Carsten Haitzler wrote:
>> On 4/10/22 03:28, Leo Yan wrote:
>>> On Wed, Mar 09, 2022 at 12:28:58PM +0000, carsten.haitzler@...s.arm.com wrote:
>>>> From: Carsten Haitzler <carsten.haitzler@....com>
>>>>
>>>> You edit your scripts in the tests and end up with your usual shell
>>>> backup files with ~ or .bak or something else at the end, but then your
>>>> next perf test run wants to run the backups too. You might also have perf
>>>> .data files in the directory or something else undesireable as well. You end
>>>> up chasing which test is the one you edited and the backup and have to keep
>>>> removing all the backup files, so automatically skip any files that are
>>>> not plain *.sh scripts to limit the time wasted in chasing ghosts.
>>>>
>>>> Signed-off-by: Carsten Haitzler <carsten.haitzler@....com>
>>>>
>>>> ---
>>>>    tools/perf/tests/builtin-test.c | 17 +++++++++++++++--
>>>>    1 file changed, 15 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/tools/perf/tests/builtin-test.c b/tools/perf/tests/builtin-test.c
>>>> index 3c34cb766724..3a02ba7a7a89 100644
>>>> --- a/tools/perf/tests/builtin-test.c
>>>> +++ b/tools/perf/tests/builtin-test.c
>>>> @@ -296,9 +296,22 @@ static const char *shell_test__description(char *description, size_t size,
>>>>    #define for_each_shell_test(entlist, nr, base, ent)	                \
>>>>    	for (int __i = 0; __i < nr && (ent = entlist[__i]); __i++)	\
>>>> -		if (!is_directory(base, ent) && \
>>>> +		if (ent->d_name[0] != '.' && \
>>>> +			!is_directory(base, ent) && \
>>>>    			is_executable_file(base, ent) && \
>>>> -			ent->d_name[0] != '.')
>>>> +			is_shell_script(ent->d_name))
>>>
>>> Just nitpick: since multiple conditions are added, seems to me it's good
>>> to use a single function is_executable_shell_script() to make decision
>>> if a file is an executable shell script.
>>
>> I'd certainly make a function if this was being re-used, but as the "coding
>> pattern" was to do all the tests already inside the if() in only one place,
>> I kept with the style there and didn't change the code that didn't need
>> changing. I can rewrite this code and basically make a function that is just
>> an if ...:
>>
>> bool is_exe_shell_script(const char *base, struct dirent *ent) {
>>     return ent->d_name[0] != '.'         && !is_directory(base, ent) &&
>>            is_executable_file(base, ent) && is_shell_script(ent->d_name);
>> }
>>
>> And macro becomes:
>>
>> #define for_each_shell_test(entlist, nr, base, ent) \
>>    for (int __i = 0; __i < nr && (ent = entlist[__i]); __i++) \
>>      if (is_shell(base, ent))
> 
> Sorry for long latency.

No problem.

> If the condition checking gets complex, seems to me it is reasonable to
> use a static function (or a macro?) to encapsulate the logics.

Well normally my rule i s - if it gets re-used then do it, otherwise it 
just involves more indirection to follow. :) But regardless of that, 
given some other things you ask for that kind of makes this discussion 
moot as it requires much bigger wholesale changes to the test infra 
which will make these patches a lot more work. I'll get to that later in 
mails.

>> But one catch... it really should be is_non_hidden_exe_shell_script() as
>> it's checking that it's not a hidden file AND is a shell script. Or do I
>> keep the hidden file test outside of the function in the if? If we're nit
>> picking then I need to know exactly what you want here as your suggested
>> name is actually incorrect.
> 
> I personally prefer to use the condition:
> 
>    if (is_exe_shell_script() && ent->d_name[0] != '.')
>        do_something...
> 
> The reason is the function is_exe_shell_script() is more common and we
> use it easily in wider scope.

As above - will probably have to redo a lot of the test infra involving 
the shell tests to handle some of your other requests, but if we don't 
go that way, I have got where you want to go and I can do this.

>>> And the condition checking 'ent->d_name[0] != '.'' would be redundant
>>> after we have checked the file suffix '.sh'.
>>
>> This isn't actually redundant. You can have .something.sh :) If the idea is
>> we skip anything with a . at the start first always... then the if (to me)
>> is obvious.
> 
> Yeah, I agree the checking the start char '.' is the right thing
> to do.

:)