Re: [PATCH v4 33/58] objtool/klp: Add test for new references to exported symbols

On Tue, Sep 15, 2026 at 4:48 PM [off-list ref] wrote:

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] objtool: test omits allowed module dependency case
--

commit f7100fa9cd984257015aa5ab4b28f4c57a67cb53
Author: Song Liu [off-list ref]

objtool/klp: Add test for new references to exported symbols

This commit adds a test to verify the behavior of objtool livepatching when a
patch introduces a new reference to an exported symbol. It tests both vmlinux
exports and undeclared module exports.

quoted

diff --git a/tools/objtool/tests/generic/fixtures/new_export_ref.c b/tools/objtool/tests/generic/fixtures/new_export_ref.c
--- /dev/null
+++ b/tools/objtool/tests/generic/fixtures/new_export_ref.c

@@ -0,0 +1,20 @@

[ ... ]

quoted

+/*
+ * A reference which only exists in the patched build.  The symbol has no twin
+ * in the original object, so what klp diff may do with it depends entirely on
+ * whether Module.symvers says it is exported, and by what.
+ */
+
+static const char __modinfo[]
+     __attribute__((section(".modinfo"), used, aligned(1))) = "\0name=vmlinux";

[Severity: Medium]
Does hardcoding the object name to "vmlinux" in __modinfo prevent simulating a
module patch? It seems this might make it impossible to test the allowed module
dependency path.

quoted

+
+extern int newly_referenced(int x);

[ ... ]

quoted

diff --git a/tools/objtool/tests/generic/test-new-export-ref.sh b/tools/objtool/tests/generic/test-new-export-ref.sh
--- /dev/null
+++ b/tools/objtool/tests/generic/test-new-export-ref.sh

@@ -0,0 +1,34 @@

[ ... ]

quoted

+export_syms
+add_exports other_mod newly_referenced
+run_diff 255
+assert_diff_log 'undeclared module dependency'
+
+pass "new reference allowed to a vmlinux export, rejected for a module export"

[Severity: Medium]
Does this test omit the allowed module dependency case? The script asserts that
new module exports are strictly rejected, completely missing the scenario where
they are allowed (when a pre-existing module dependency exists) as described in
commit 72d76d0c18eb.

Adding a new case in v5 to cover this case.

Thanks,
Song