Re: [PATCH v2 1/1] objtool/klp: compute sympos during checksum phase

Thank you for your contribution! Sashiko AI review found 1 potential issue(=
s) to consider:
- [High] Identical `sympos` is incorrectly assigned to intra-file duplicate=
 symbols, breaking livepatch target disambiguation.
--

--- Patch [1]: [PATCH v2 1/1] objtool/klp: compute sympos during checksum p=
hase ---
commit 00bcd90f9dc15cdd96632002648171f48c54a2cc
Author: Joe Lawrence <[email protected]>

objtool/klp: compute sympos during checksum phase

This commit changes how sympos is computed for livepatch duplicate local=20
symbols. It computes sympos during the checksum phase and writes it to a
.discard.sym_order section, rather than using heuristics in klp-diff.

> diff --git a/tools/objtool/klp-checksum.c b/tools/objtool/klp-checksum.c
> index b8e47f28997e9..d16f00a3bb2a9 100644
> --- a/tools/objtool/klp-checksum.c
> +++ b/tools/objtool/klp-checksum.c

[ ... ]

> @@ -250,6 +256,183 @@ int calculate_checksums(struct objtool_file *file)

[ ... ]

> +	/*
> +	 * For each local symbol with homonyms in the linked binary, determine
> +	 * its sympos: sort the duplicates by address (vmlinux) or symtab
> +	 * index (modules), then find our position by filename.
> +	 */
> +	idx =3D 0;
> +	for_each_sym(file->elf, sym) {

[ ... ]

> +		/* Match our compilation unit's filename against sorted entries */
> +		sym_file_name =3D sym->file ? sym->file->name : NULL;
> +		for (i =3D 0; i < nr; i++) {
> +			bool match;
> +
> +			if (sym_file_name && entries[i].file_name)
> +				match =3D !strcmp(sym_file_name, entries[i].file_name);
> +			else if (!sym_file_name && !entries[i].file_name)
> +				match =3D true;
> +			else
> +				match =3D false;
> +
> +			if (match) {
> +				pos =3D i + 1;
> +				break;
> +			}
> +		}

[Severity: High]
If an object file contains multiple identical local symbols with the same n=
ame
and from the same source file, will they all get assigned the exact same
sympos value?

Because the outer loop processes each symbol independently and the inner
matching loop breaks on the first match without tracking consumed matches,
it appears all identical intra-file duplicates will continually match the f=
irst
available entry in the sorted list and be assigned the same position.

Could this break livepatch target disambiguation if multiple identical=20
symbols in the same compilation unit share the same sympos?

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260724221730.3126=
[email protected]?part=3D1