On Fri 2026-08-21 17:27:10, Petr Mladek wrote: > This might fix klp_check_stack_func() for A. But not for B. B won't > be the last entry so that klp_check_stack_func() would use > the list_next_entry() and will check for A on stack instead of > the original function. > > Another _big problem_ is in klp_ftrace_handler(). It would use A > in PATCHED state and B in UNPATCHED. But it is not clear whether > A or B should be used in the PATCHED state. And it should use > the original code in UNPATCHED state. > > IMHO, we must catch this situation when preparing livepatches > and when enabling the livepatch. A single livepatch must never > create two entries on any ops->func_stack. > > IMHO, we should catch the duplicate (aliased) entries in > klp_init_object_loaded() and return -EINVAL when they are found. > > I do not see any other solution. We could not decide which > struct klp_func should be used for the redirection when > more of them point to the same original function.
You're right, thanks for pointing this out. list_is_last() only patches over the stack-check symptom for A and still leaves B wrong, and it does nothing for the klp_ftrace_handler() ambiguity you describe - there's really no sound way to pick between A and B once they're both live entries backed by the same old_func. Rejecting the duplicate at load time is the right fix. I'll send a v2 that detects aliased old_func addresses within the same klp_object in klp_init_object_loaded() and returns -EINVAL when found, instead of touching klp_check_stack_func(). Thanks, Harry
