Re: [PATCH v6 14/18] tracing/remotes: selftests: Add a test for the dump_on_panic tracefs file

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 <[email protected]>

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/[email protected]?part=14