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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Wed, 19 Oct 2022 00:19:49 +0900
From:   Masami Hiramatsu (Google) <mhiramat@...nel.org>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     "Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com>,
        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 10:51:03 -0400
Steven Rostedt <rostedt@...dmis.org> wrote:

> 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.

initialize_ftrace() does this setting. So it must be set.
If you run the ftracetest on old kernel, this feature is not there and
it may cause a trouble. Naveen, can you clarify it?

Thank you,

> 
> 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


-- 
Masami Hiramatsu (Google) <mhiramat@...nel.org>