linux-kernel - Re: [PATCH] selftests/ftrace: Limit number of lines processed in 'trace'

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20221017105103.540a87c7@gandalf.local.home>
Date:   Mon, 17 Oct 2022 10:51:03 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     "Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com>
Cc:     Shuah Khan <shuah@...nel.org>, <linux-kernel@...r.kernel.org>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Akanksha J N <akanksha@...ux.vnet.ibm.com>
Subject: Re: [PATCH] selftests/ftrace: Limit number of lines processed in
 'trace'

On Mon, 17 Oct 2022 16:25:02 +0530
"Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com> wrote:

> On very large machines, ftracetest can seem to hang or otherwise take a
> very long time to complete individual tests. This can be attributed to
> statements that try to process the entire contents of 'trace'.
> 
> Limit the number of lines processed from 'trace' to resolve this. Apart
> from the change in test.d/functions to add TRACENL, this commit is the
> result of running the below command (and fixing some whitespace errors):
>   grep -l -R 'cat trace |' -- ./tools/testing/selftests/ftrace/test.d/ | \
> 	xargs -n 1 sed --in-place -e "s/cat trace |/head -\$\{TRACENL\} trace |/g"
> 

No. This shows that there's an issue in the test. This should never hang
even with a thousand CPUs.

You need to make sure that the "pause-on-trace" option is set or tracing_on
is set to 0 (disabled). Otherwise, if the tracing is still active, then the
reading of the trace file could potentially never end.

Did you have tracing enabled and "pause_on_trace" not set when you ran that
above command? If so, then it may take forever to finish. But the tests
should take care to not read the trace file unless it has stopped tracing.

If there's a case where it will read while tracing is active, then sure, we
need to limit the reporting, otherwise nack on this change.

-- Steve