public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Joel Fernandes <joel@joelfernandes.org>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: linux-kernel@vger.kernel.org,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Shuah Khan <shuah@kernel.org>, Joel <agnel.joel@gmail.com>,
	rcu@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v2] rcutorture: Copy out ftrace into its own console file
Date: Tue, 15 Aug 2023 02:14:39 +0000	[thread overview]
Message-ID: <20230815021439.GA2320449@google.com> (raw)
In-Reply-To: <5bc1a075-db78-4ecd-af06-77555f4184bc@paulmck-laptop>

Hi Paul,

On Mon, Aug 14, 2023 at 03:27:33PM -0700, Paul E. McKenney wrote:
> On Mon, Aug 14, 2023 at 06:03:24PM -0400, Joel Fernandes wrote:
> > On Mon, Aug 14, 2023 at 5:27 PM Paul E. McKenney <paulmck@kernel.org> wrote:
> > >
> > > On Sun, Aug 13, 2023 at 08:36:02PM +0000, Joel Fernandes (Google) wrote:
> > > > From: Joel Fernandes (Google) <joel@joelfernandes.org>
> > > >
> > > > Often times during debugging, it is difficult to jump to the ftrace dump
> > > > in the console log and treat it independent of the result of the log file.
> > > > Copy the contents of the buffers into its own file to make it easier to refer
> > > > to the ftrace dump. The original ftrace dump is still available in the
> > > > console log if it is desired to refer to it there.
> > > >
> > > > Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
> > >
> > > Queued, thank you!  I did the usual wordsmithing, please see below.
> > >
> > > I also fixed up the indentation and spacing.  I don't know about you,
> > > but the initial format made that a bit hard for me to read.  ;-)
> > >
> > > If there are multiple ftrace dumps in a given console.log file, this
> > > will concatenate them.  Is that the intent?
> > 
> > How would you have multiple dumps, do you mean from subsequent
> > (re)boots? If so, yes I am OK with that. I usually look at the latest
> > boot attempt.
> 
> Fair, but how would you separate out the ftrace dump for the most
> recent kernel boot?  (Though please see below.)

It will print the same markers in console.log which can be used. I posted an
updated diff below.

> 
> > I was also thinking of us stopping boot loops. For example, if there
> > is a kernel issue and the system keeps rebooting, it will run forever
> > in the boot loop silently. It would be good for monitoring of
> > console.log and kill the test if the console.log is acting 'weird'.
> > Also it would be good if the console.log had a huge timestamp gap in
> > it like the TREE04 issue. Would such changes be good to make? I can
> > attempt something.
> 
> Boot loops can indeed be irritating.  So I created this commit:
> 
> 10f84c2cfb50 ("torture: Avoid torture-test reboot loops")
> 
> This passes -no-reboot to qemu, which causes qemu to just stop when
> it would otherwise reboot.  Much nicer!
> 
> The multiple-ftrace-dump issue could still appear should some torture
> test decide to turn tracing back on at some point, perhaps in response
> to a yet-as-unthought-of module parameter.
> 
> Should this ever be a problem, one approach would be to leave the
> beginning/end markers and/or number them.

Thanks for doing this! I'll add it to all my trees.

Also let us replace the diff with the below [3] to properly label potential
multiple dumps?  Example for a file like [1], it will extract as [2].

[1]:

foo
foo
Dumping ftrace buffer:
---------------------------------
blah
blah
---------------------------------
more
bar
baz
Dumping ftrace buffer:
---------------------------------
blah2
blah2
---------------------------------
bleh
bleh

[2]:

Ftrace dump 1:
blah
blah

Ftrace dump 2:
blah2
blah2

---8<-----------------------
[3]

diff --git a/tools/testing/selftests/rcutorture/bin/functions.sh b/tools/testing/selftests/rcutorture/bin/functions.sh
old mode 100644
new mode 100755
index b8e2ea23cb3f..a5c74e508e41
--- a/tools/testing/selftests/rcutorture/bin/functions.sh
+++ b/tools/testing/selftests/rcutorture/bin/functions.sh
@@ -331,3 +331,30 @@ specify_qemu_net () {
 		echo $1 -net none
 	fi
 }
+
+# Extract the ftrace output from the console log output
+# The ftrace output in the original logs look like:
+# Dumping ftrace buffer:
+# ---------------------------------
+# [...]
+# ---------------------------------
+extract_ftrace_from_console() {
+        awk '
+        /Dumping ftrace buffer:/ {
+        buffer_count++
+        print "Ftrace dump " buffer_count ":"
+        capture = 1
+        next
+    }
+    /---------------------------------/ {
+        if(capture == 1) {
+            capture = 2
+            next
+        } else if(capture == 2) {
+            capture = 0
+            print ""
+        }
+    }
+    capture == 2
+    ' "$1";
+}
diff --git a/tools/testing/selftests/rcutorture/bin/parse-console.sh b/tools/testing/selftests/rcutorture/bin/parse-console.sh
index 9ab0f6bc172c..e3d2f69ec0fb 100755
--- a/tools/testing/selftests/rcutorture/bin/parse-console.sh
+++ b/tools/testing/selftests/rcutorture/bin/parse-console.sh
@@ -182,3 +182,10 @@ if ! test -s $file.diags
 then
 	rm -f $file.diags
 fi
+
+# Call extract_ftrace_from_console function, if the output is empty,
+# don't create $file.ftrace. Otherwise output the results to $file.ftrace
+extract_ftrace_from_console $file > $file.ftrace
+if [ ! -s $file.ftrace ]; then
+	rm -f $file.ftrace
+fi
-- 
2.41.0.694.ge786442a9b-goog


  reply	other threads:[~2023-08-15  2:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-13 20:36 [PATCH v2] rcutorture: Copy out ftrace into its own console file Joel Fernandes (Google)
2023-08-14 21:27 ` Paul E. McKenney
2023-08-14 22:03   ` Joel Fernandes
2023-08-14 22:27     ` Paul E. McKenney
2023-08-15  2:14       ` Joel Fernandes [this message]
2023-08-15 18:45         ` Paul E. McKenney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230815021439.GA2320449@google.com \
    --to=joel@joelfernandes.org \
    --cc=agnel.joel@gmail.com \
    --cc=jiangshanlai@gmail.com \
    --cc=josh@joshtriplett.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=paulmck@kernel.org \
    --cc=rcu@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=shuah@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox