linux-kernel - Re: [PATCH] selftests/ftrace: Improve integration with kselftest runner

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]

Date:   Mon, 27 Mar 2023 13:43:15 -0600
From:   Shuah Khan <skhan@...uxfoundation.org>
To:     "Masami Hiramatsu (Google)" <mhiramat@...nel.org>,
        Mark Brown <broonie@...nel.org>
Cc:     Steven Rostedt <rostedt@...dmis.org>,
        Shuah Khan <shuah@...nel.org>, linux-kernel@...r.kernel.org,
        linux-trace-kernel@...r.kernel.org,
        linux-kselftest@...r.kernel.org,
        Shuah Khan <skhan@...uxfoundation.org>
Subject: Re: [PATCH] selftests/ftrace: Improve integration with kselftest
 runner

On 3/19/23 08:24, Masami Hiramatsu (Google) wrote:
> Hi Mark,
> 
> On Mon, 06 Mar 2023 15:35:10 +0000
> Mark Brown <broonie@...nel.org> wrote:
> 
>> The ftrace selftests do not currently produce KTAP output, they produce a
>> custom format much nicer for human consumption. This means that when run in
>> automated test systems we just get a single result for the suite as a whole
>> rather than recording results for individual test cases, making it harder
>> to look at the test data and masking things like inappropriate skips.
>>
>> Address this by adding support for KTAP output to the ftracetest script and
>> providing a trivial wrapper which will be invoked by the kselftest runner
>> to generate output in this format by default, users using ftracetest
>> directly will continue to get the existing output.
>>
>> This is not the most elegant solution but it is simple and effective. I
>> did consider implementing this by post processing the existing output
>> format but that felt more complex and likely to result in all output being
>> lost if something goes seriously wrong during the run which would not be
>> helpful. I did also consider just writing a separate runner script but
>> there's enough going on with things like the signal handling for that to
>> seem like it would be duplicating too much.
> 
> This looks great! and is what we need.
> 
> Acked-by: Masami Hiramatsu (Google) <mhiramat@...nel.org>
> Tested-by: Masami Hiramatsu (Google) <mhiramat@...nel.org>
> 
> Thank you!
> 
>>

Steve,

Okay to pick this up for the Linux 6.4?

thanks,
-- Shuah