Re: [PATCH v3 02/26] init/version: Annotate static information into meminspect

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [Medium] The linux_banner meminspect entry is duplicated in the .inspect_table section, leading to brittle size resolution based strictly on linker command-line order.

Pre-existing issues:
- [High] Adding static kernel symbols to the meminspect table triggers a kernel warning during boot because the framework incorrectly uses virt_to_phys() on non-linear addresses.
--

--- Patch [2]: [PATCH v3 02/26] init/version: Annotate static information into meminspect ---
commit fe87675e956aedb4b693667a58386a5bc91ca7cd
Author: Eugen Hristev <ehristev@kernel.org>

init/version: Annotate static information into meminspect

Annotate vital static information into inspection table:
 - init_uts_ns
 - linux_banner

Information on these variables is stored in a dedicated meminspect
section.

> diff --git a/init/version-timestamp.c b/init/version-timestamp.c
> index 375726e05f690..37bdcdd443f9b 100644
> --- a/init/version-timestamp.c
> +++ b/init/version-timestamp.c

[ ... ]

> @@ -24,3 +25,5 @@ struct uts_namespace init_uts_ns = {
>  const char linux_banner[] =
>  	"Linux version " UTS_RELEASE " (" LINUX_COMPILE_BY "@"
>  	LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION "\n";
> +
> +MEMINSPECT_SIMPLE_ENTRY(linux_banner);

[Severity: Medium]
Does this result in duplicate entries for linux_banner in the inspect_table
section?

Because init/version-timestamp.c is compiled independently as a standalone
object and also included directly by init/version.c, this macro expands twice
during the build.

This generates two entries: one with a dummy size from the early compile
phase where UTS_VERSION is a stub, and one with the actual size. While
scripts/link-vmlinux.sh currently appends version-timestamp.o last to ensure
the real size overwrites the dummy size during initialization, this approach
relies strictly on linker command-line order.

Could this break under Link Time Optimization or section sorting optimizations,
causing the dummy size to be used and truncating the banner in the inspection
tool?

> diff --git a/init/version.c b/init/version.c
> index 94c96f6fbfe6a..eeb1392365627 100644
> --- a/init/version.c
> +++ b/init/version.c

[ ... ]

> @@ -51,4 +52,6 @@ const char linux_banner[] __weak;
>  
>  #include "version-timestamp.c"
>  
> +MEMINSPECT_SIMPLE_ENTRY(init_uts_ns);

[Severity: High]
This isn't a bug introduced by this patch, but adding static kernel symbols
here triggers a kernel warning during boot because the meminspect framework
incorrectly uses virt_to_phys() on non-linear addresses.

When meminspect_prepare_table() iterates over the table unconditionally at boot:

kernel/meminspect/meminspect.c:meminspect_prepare_table()
    if (!inspect_entries[e->id].pa && inspect_entries[e->id].va)
        inspect_entries[e->id].pa = virt_to_phys(inspect_entries[e->id].va);

It passes the virtual addresses of static symbols like linux_banner and
init_uts_ns to virt_to_phys(). This records an invalid physical address in the
meminspect table, and on architectures where static kernel symbols reside in
non-linear virtual memory (like vmalloc space on arm64 or x86_64 with KASLR),
this triggers a kernel WARN.

Should the framework be updated to use __pa_symbol() for these entries instead
to safely handle non-linear kernel image addresses?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260708-meminspect-v3-v3-0-7aa5a0a74d5c@oss.qualcomm.com?part=2