Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] objtool's mod_sym_in_kallsyms() diverges from the kernel's is_core_symbol() logic on PowerPC 64, leading to incorrect sympos calculation for livepatches. --
--- Patch [8]: [PATCH 08/14] objtool/klp,livepatch: Resolve module symbols against core kallsyms --- commit 5384e2809ccb86e9339029bde934f86f745e7b61 Author: Josh Poimboeuf <[email protected]> objtool/klp,livepatch: Resolve module symbols against core kallsyms This commit updates livepatch to use a module's position in the core symbol table as its sympos. It enforces this by using module_kallsyms_on_each_core_symbol() at runtime and mirroring the is_core_symbol() filter in objtool. > diff --git a/tools/objtool/klp-sympos.c b/tools/objtool/klp-sympos.c > index bbfae516d3395..34bb8d1971bd2 100644 > --- a/tools/objtool/klp-sympos.c > +++ b/tools/objtool/klp-sympos.c > @@ -367,6 +367,17 @@ static unsigned long find_vmlinux_sympos(struct symbol > *sym) > return sympos; > } > > +static bool mod_sym_in_kallsyms(struct symbol *sym) > +{ > + if (is_undef_sym(sym)) > + return false; > + > + if (!(sym->sec->sh.sh_flags & SHF_ALLOC)) > + return false; > + > + return !strstarts(sym->sec->name, ".init"); [Severity: Medium] Will this hardcoded filter improperly exclude .init symbols on PowerPC 64? On PowerPC 64, module_init_section() unconditionally returns false, meaning the kernel treats .init sections as core memory. This hardcoded string matching appears to diverge from the kernel's is_core_symbol() logic on that architecture, potentially leading to incorrect sympos calculations for livepatches if an object contains duplicate symbols where at least one resides in an .init section. > +} -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=8
