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

[sashiko-bot@kernel.org]

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 <song@kernel.org>

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.

> 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 @@
[ ... ]
> +/*
> + * 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.

> +
> +extern int newly_referenced(int x);
[ ... ]
> 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 @@
[ ... ]
> +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.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260915233454.2405019-1-song@kernel.org?part=33