On Sun, 2026-05-24 at 23:59 +0000, [email protected] wrote: > Thank you for your contribution! Sashiko AI review found 1 potential > issue(s) to consider: > - [Medium] `_remove_mod` uses `die()` which will terminate the script > during cleanup operations. > -- > > commit 7b1591f4e5c3b351136e7fe2821eb2e15ae59ad0 > Author: Marcos Paulo de Souza <[email protected]> > > selftests: livepatch: Introduce _remove_mod function > > This commit introduces the _remove_mod internal function to remove a > loaded > module, intended to be used during cleanup when a testcase fails. It > also > refactors unload_mod to use this new helper function. > > > diff --git a/tools/testing/selftests/livepatch/functions.sh > > b/tools/testing/selftests/livepatch/functions.sh > > index 2bc50271729c6..3ec0b7962fc5c 100644 > > --- a/tools/testing/selftests/livepatch/functions.sh > > +++ b/tools/testing/selftests/livepatch/functions.sh > > [ ... ] > > > @@ -241,9 +241,10 @@ function load_failing_mod() { > > log "$ret" > > } > > > > -# unload_mod(modname) - unload a kernel module > > +# _remove_mod(modname) - Internal function to remove a loaded > > module. > > +# Use unload_mod() instead, which also > > updates TEST_MODS tracking. > > # modname - module name to unload > > -function unload_mod() { > > +function _remove_mod() { > > local mod="$1" > > > > # Wait for module reference count to clear ... > > @@ -261,6 +262,14 @@ function unload_mod() { > > die "failed to unload module $mod (/sys/module)" > > [Severity: Medium] > The commit message notes this function will be used to remove loaded > modules > when a testcase fails. If used in a cleanup path (such as a bash EXIT > trap), > will calling die() here terminate the script prematurely? > > If a module fails to unload (for example, if its refcount doesn't > drop), > die() executes exit 1. Inside a trap, this aborts the rest of the > cleanup process. This could skip unloading any remaining modules and > prevent final cleanup operations like pop_config() from running, > potentially > leaving kernel tracing persistently enabled and polluting the system > state > for subsequent tests.
The system is already polluted when a testcase fails nowadays, since a module is kept loaded either way, making the next tests to fail if they also try to lead the same modules. The current approach is trying to make it more reliable. > > > } > > [ ... ]
