On Sat, Aug 22, 2026 at 11:07 PM Harry Hsu <[email protected]> wrote: > > Several symbols can share one address: > > ffffffff8ed7fef0 t __do_sys_fork > ffffffff8ed7fef0 T __ia32_sys_fork > ffffffff8ed7fef0 T __x64_sys_fork > > klp_find_ops() looks the ops up by func->old_func, i.e. by address, so > two klp_funcs of the same livepatch naming two of these symbols resolve > to the same klp_ops and are both pushed onto one ops->func_stack. > > This breaks the assumption that a single livepatch contributes at most > one entry to any func_stack. klp_ftrace_handler() picks the entry at > the top of the stack, but when both entries belong to the same livepatch > there is nothing that says which of them should be used in the PATCHED > state, and the UNPATCHED state has to end up at the original function > either way. klp_check_stack_func() cannot tell them apart either: it > asks whether the preceding entry is the original function or another > livepatch's replacement, and an aliased sibling is neither. > > Patching two aliases of one function from a single livepatch was never > meaningful, so reject it while the object is being initialized rather > than leave the redirection undefined. Compare the resolved old_func of > each klp_func against the ones already resolved for the same klp_object > and return -EINVAL on a match, naming both symbols so that the offending > pair can be found in the livepatch source. > > Fixes: 3c33f5b99d68 ("livepatch: support for repatching a function") > Suggested-by: Petr Mladek <[email protected]> > Signed-off-by: Harry Hsu <[email protected]>
Acked-by: Song Liu <[email protected]> Can we add a selftest for this case?
