In our production environment, upon loading a new atomic replace livepatch, we encountered an issue where the kernel module of the old livepatch remained, despite being replaced by the new one. The detailed steps to reproduce that issue can be found in patch #2. Detecting which livepatch will be replaced by the new one from userspace is not reliable, necessitating the need for the operation to be performed within the kernel itself. This patchset aims to address this issue by automatically deleting the associated module of a disabled livepatch. Since a disabled livepatch can't be enabled again and the kernel module becomes redundant, it is safe to remove it in this manner. Changes: - v1->v2: - Avoid using kpatch utility in the example (Joe, Petr) - Fix race around changing mod->state (Joe, Petr) - Don't set mod->state outside of kernel/module dir (Joe, Petr) - Alter selftests accordingly (Joe) - Split it into two patches (Petr, Miroslav) - Don't delete module from the path klp_enable_patch() (Petr, Miroslav) - Make delete_module() safe (Petr) Yafang Shao (2): module: Add a new helper delete_module() livepatch: Delete the associated module of disabled livepatch include/linux/module.h | 1 + kernel/livepatch/core.c | 16 ++-- kernel/module/main.c | 82 +++++++++++++++---- .../testing/selftests/livepatch/functions.sh | 2 + .../selftests/livepatch/test-callbacks.sh | 24 ++---- .../selftests/livepatch/test-ftrace.sh | 3 +- .../selftests/livepatch/test-livepatch.sh | 11 +-- .../testing/selftests/livepatch/test-state.sh | 15 +--- .../selftests/livepatch/test-syscall.sh | 3 +- .../testing/selftests/livepatch/test-sysfs.sh | 6 +- 10 files changed, 95 insertions(+), 68 deletions(-) -- 2.39.1
