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
