Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The test fails to verify its own claim that a function is functionally unpatched after an atomic replacement.
--
commit abfccb0026870ac46d37d3802586498b0874cba2
Author: Yafang Shao [off-list ref]
selftests/livepatch: Add function test for provides/obsoletes
This commit adds selftest scenarios for livepatches using the provides
and obsoletes features to ensure patches with different provides IDs do
not modify the same function. It verifies replacement and coexistence
behaviors for different function combinations. Tests are skipped on legacy
kernels.
quoted hunk ↗ jump to hunk
diff --git a/tools/testing/selftests/livepatch/test-provides-obsoletes.sh b/tools/testing/selftests/livepatch/test-provides-obsoletes.sh
--- a/tools/testing/selftests/livepatch/test-provides-obsoletes.sh
+++ b/tools/testing/selftests/livepatch/test-provides-obsoletes.sh
[ ... ]
quoted hunk ↗ jump to hunk
+# - after the replacement /proc/meminfo is no longer patched, while
+# /proc/cmdline is patched
+# - unload the replacing livepatch, then the replaced one
+
+start_test "different functions, atomic replace works (nops)"
+
+load_lp $MOD_MEMINFO provides=1
+
+grep 'live patched' /proc/meminfo > /dev/kmsg
+
+load_lp $MOD_CMDLINE provides=1
+
+grep 'live patched' /proc/cmdline > /dev/kmsg
+
+disable_lp $MOD_CMDLINE
[Severity: Medium]
The test documentation explicitly claims that after the replacement,
/proc/meminfo is no longer patched while /proc/cmdline is patched.
However, only /proc/cmdline is checked during this sequence.
Should there be an additional step to grep /proc/meminfo and verify it
is functionally unpatched before disabling the livepatch? If the atomic
replace logic had a flaw that accidentally left /proc/meminfo patched,
it appears this verification would be missed and the test would still pass.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260909024324.16002-1-laoar.shao@gmail.com?part=9