All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
Cc: linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH v3 4/4] selftests/ftrace: Add persistent ring buffer testcases
Date: Wed, 12 Aug 2026 00:57:31 +0000	[thread overview]
Message-ID: <20260812005732.48E1F1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <178649544683.438282.14573895196260214231.stgit@devnote2>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Test enters an infinite reboot loop if the persistent trace feature fails.
--

--- Patch [4]: [PATCH v3 4/4] selftests/ftrace: Add persistent ring buffer testcases ---
commit d365a5483f67b1295e536e6d26fd4ee7166e27b3
Author: Masami Hiramatsu (Google) <mhiramat@kernel.org>

selftests/ftrace: Add persistent ring buffer testcases

Add test cases for persistent ring buffer and backup instance across guest
crash/reboot. These verify trace data retention in the boot_map instance and
preservation in the backup instance on subsequent boot.

> diff --git a/tools/testing/selftests/ftrace/boottime/tests/persistent-01-reserve-mem.sh b/tools/testing/selftests/ftrace/boottime/tests/persistent-01-reserve-mem.sh
> new file mode 100644
> index 0000000000000..49abaf518481f
> --- /dev/null
> +++ b/tools/testing/selftests/ftrace/boottime/tests/persistent-01-reserve-mem.sh
> @@ -0,0 +1,28 @@

[ ... ]

> +
> +# Check if Boot 1 marker was already written
> +if grep -q "BOOT1_MARKER" "$TRACEDIR/instances/boot_map/trace" 2>/dev/null; then
> +	# Second boot: verify persistent ring buffer content from first boot
> +	echo "PASS: persistent-01-reserve-mem"
> +	exit 0
> +fi
> +
> +# First boot: write marker to persistent buffer and trigger kernel crash/reboot
> +echo "BOOT1_MARKER" > "$TRACEDIR/instances/boot_map/trace_marker"
> +sync
> +
> +# Trigger reboot to restart into second boot
> +echo b > /proc/sysrq-trigger 2>/dev/null || echo c > /proc/sysrq-trigger 2>/dev/null || true

[Severity: Medium]
If the persistent trace feature fails to retain the BOOT1_MARKER across
reboot, could this script enter an infinite reboot loop?

Since the test falls through to the first-boot logic when the marker is
missing, it appears it will write the marker and reboot again indefinitely.
This might cause the test to run until it is killed by a global timeout
rather than failing cleanly.

> +sleep 5
> +echo "FAIL: reboot trigger failed on first boot"
> +exit 1
> diff --git a/tools/testing/selftests/ftrace/boottime/tests/persistent-02-backup-instance.sh b/tools/testing/selftests/ftrace/boottime/tests/persistent-02-backup-instance.sh
> new file mode 100644
> index 0000000000000..0b2a2f03ce4f2
> --- /dev/null
> +++ b/tools/testing/selftests/ftrace/boottime/tests/persistent-02-backup-instance.sh
> @@ -0,0 +1,40 @@

[ ... ]

> +
> +# Check if BOOT1_MARKER is in boot_map/trace (indicates second boot)
> +if grep -q "BOOT1_MARKER" "$TRACEDIR/instances/boot_map/trace" 2>/dev/null; then
> +	# Second boot: verify BOOT1_MARKER was copied into backup/trace from Boot 1
> +	if grep -q "BOOT1_MARKER" "$TRACEDIR/instances/backup/trace" 2>/dev/null; then
> +		echo "PASS: persistent-02-backup-instance"
> +		exit 0
> +	else
> +		echo "FAIL: BOOT1_MARKER found in boot_map/trace" \
> +			"but missing from backup/trace on second boot"
> +		exit 1
> +	fi
> +fi
> +
> +# First boot: write BOOT1_MARKER to boot_map and reboot via sysrq-trigger
> +echo "BOOT1_MARKER" > "$TRACEDIR/instances/boot_map/trace_marker"
> +sync
> +
> +# Trigger reboot to restart into second boot
> +echo b > /proc/sysrq-trigger 2>/dev/null || echo c > /proc/sysrq-trigger 2>/dev/null || true

[Severity: Medium]
Similarly, does this script also risk an infinite reboot loop if the marker
is missing from boot_map/trace on the second boot?

It looks like it would also fall back to triggering another reboot instead
of reporting a failure.

> +sleep 5
> +echo "FAIL: reboot trigger failed on first boot"
> +exit 1

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/178649540853.438282.4271870161169100680.stgit@devnote2?part=4

      reply	other threads:[~2026-08-12  0:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-12  0:43 [PATCH v3 0/4] selftests/ftrace: Add a boottime tracing test framework Masami Hiramatsu (Google)
2026-08-12  0:43 ` [PATCH v3 1/4] selftests/ftrace: Add generic boot " Masami Hiramatsu (Google)
2026-08-12  0:43 ` [PATCH v3 2/4] selftests/ftrace: Add boot-time tracing testcases Masami Hiramatsu (Google)
2026-08-12  0:43 ` [PATCH v3 3/4] selftests/ftrace: Add kernel cmdline " Masami Hiramatsu (Google)
2026-08-12  0:44 ` [PATCH v3 4/4] selftests/ftrace: Add persistent ring buffer testcases Masami Hiramatsu (Google)
2026-08-12  0:57   ` sashiko-bot [this message]

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=20260812005732.48E1F1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.