Linux Trace Kernel
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Vincent Donnefort" <vdonnefort@google.com>
Cc: linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH v6 14/18] tracing/remotes: selftests: Add a test for the dump_on_panic tracefs file
Date: Mon, 17 Aug 2026 14:07:20 +0000	[thread overview]
Message-ID: <20260817140721.6DD5A1F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260817135517.3919534-15-vdonnefort@google.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The selftest `dump_on_panic.tc` contains an intentional early return leaving dead code that, if modified and executed, would trigger a host kernel panic.
--

--- Patch [14]: [PATCH v6 14/18] tracing/remotes: selftests: Add a test for the dump_on_panic tracefs file ---
commit b661e8678db50e2f2bef3cbb826c8b850f1bdfa3
Author: Vincent Donnefort <vdonnefort@google.com>

tracing/remotes: selftests: Add a test for the dump_on_panic tracefs file

This commit introduces a new selftest script to exercise the dump_on_panic
tracefs file, which toggles the remote buffer dump on system panic. It
verifies the behavior when the buffer is loaded and unloaded.

> diff --git a/tools/testing/selftests/ftrace/test.d/remotes/dump_on_panic.tc b/tools/testing/selftests/ftrace/test.d/remotes/dump_on_panic.tc
> new file mode 100644
> index 0000000000000..1ba025ff9838c
> --- /dev/null
> +++ b/tools/testing/selftests/ftrace/test.d/remotes/dump_on_panic.tc
> @@ -0,0 +1,51 @@
[ ... ]
> +test_dump_on_panic()
> +{
[ ... ]
> +    echo 1 > dump_on_panic
> +    echo 1 > tracing_on
> +    echo 0 > tracing_on
> +
> +    # REMOVE ME FOR A PROPER OOPS TEST
> +    return
> +
> +    echo 1 > tracing_on
> +
> +    for i in $(seq 1 32); do
> +        echo $i > write_event
> +    done
> +
> +    echo c > /proc/sysrq-trigger
> +}

[Severity: Medium]
Does leaving dead code like this in the repository create issues for test
automation?

If a developer removes the early return to run the full test, it appears it
would unconditionally panic the host kernel via sysrq-trigger.

Could this destructive part of the regression test be guarded by an explicit
opt-in environment variable instead of relying on manual code modification?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260817135517.3919534-1-vdonnefort@google.com?part=14

  reply	other threads:[~2026-08-17 14:07 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-17 13:54 [PATCH v6 00/18] tracing/remotes: Add printk, dump_on_panic and boot parameters Vincent Donnefort
2026-08-17 13:55 ` [PATCH v6 01/18] tracing/remotes: Gate tracefs files opening on trace remote registration Vincent Donnefort
2026-08-17 14:09   ` sashiko-bot
2026-08-17 13:55 ` [PATCH v6 02/18] tracing/remotes: Release tracefs,eventfs on registration failure Vincent Donnefort
2026-08-17 13:55 ` [PATCH v6 03/18] tracing/remotes: Use kstrtobool for boolean tracefs files Vincent Donnefort
2026-08-17 14:11   ` sashiko-bot
2026-08-17 13:55 ` [PATCH v6 04/18] tracing/remotes: Use a single per-remote polling work Vincent Donnefort
2026-08-17 13:55 ` [PATCH v6 05/18] tracing/simple_ring_buffer: Add support for compressed length Vincent Donnefort
2026-08-17 13:55 ` [PATCH v6 06/18] tracing/remotes: Add dmesg tracefs file Vincent Donnefort
2026-08-17 14:09   ` sashiko-bot
2026-08-17 13:55 ` [PATCH v6 07/18] tracing/remotes: selftests: Add a test for the " Vincent Donnefort
2026-08-17 14:05   ` sashiko-bot
2026-08-17 13:55 ` [PATCH v6 08/18] tracing/remotes: selftests: Prefix hypervisor folder Vincent Donnefort
2026-08-17 13:55 ` [PATCH v6 09/18] ring-buffer: Use irqsave for the reader lock in ring_buffer_poll_remote Vincent Donnefort
2026-08-17 13:55 ` [PATCH v6 10/18] ring-buffer: Use panic-friendly locking in ring_buffer_iter interface Vincent Donnefort
2026-08-17 14:04   ` sashiko-bot
2026-08-17 13:55 ` [PATCH v6 11/18] ring-buffer: Add ring_buffer_read_remote_meta_page() Vincent Donnefort
2026-08-17 13:55 ` [PATCH v6 12/18] ring-buffer: Add kerneldoc for ring_buffer_poll_remote Vincent Donnefort
2026-08-17 13:55 ` [PATCH v6 13/18] tracing/remotes: Add dump_on_panic tracefs file Vincent Donnefort
2026-08-17 14:10   ` sashiko-bot
2026-08-17 13:55 ` [PATCH v6 14/18] tracing/remotes: selftests: Add a test for the " Vincent Donnefort
2026-08-17 14:07   ` sashiko-bot [this message]
2026-08-17 13:55 ` [PATCH v6 15/18] tracing/remotes: Add poll_ms " Vincent Donnefort
2026-08-17 13:55 ` [PATCH v6 16/18] tracing/remotes: Add trace_remote cmdline options Vincent Donnefort
2026-08-17 14:12   ` sashiko-bot
2026-08-17 13:55 ` [PATCH v6 17/18] Documentation: tracing/remotes: Add detailed tracefs layout Vincent Donnefort
2026-08-17 13:55 ` [PATCH v6 18/18] Documentation/kernel-parameters: Add trace_remote Vincent Donnefort
2026-08-17 14:21   ` sashiko-bot

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=20260817140721.6DD5A1F00A3A@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=vdonnefort@google.com \
    /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