Hi folks, While testing livepatch kernel modules, we found that if a kernel module has patched functions, we cannot unload and load it again (rmmod, then insmod). This hasn't happened in production yet, but it feels very risky. We use automation (chef to be specific) to handle kernel modules and livepatch. It is totally possible some weird sequence of operations would cause insmod errors on thousands of servers. Therefore, we would like to fix this issue before it hits us hard. A bit of searching with the error message shows it was a known issue [1], and a few options are discussed: "Possible ways to fix it: 1) Remove the error check in apply_relocate_add(). I don't think we should do this, because the error is actually useful for detecting corrupt modules. And also, powerpc has the similar error so this wouldn't be a universal solution. 2) In klp_unpatch_object(), call an arch-specific arch_unpatch_object() which reverses any arch-specific patching: on x86, clearing all relocation targets to zero; on powerpc, converting the instructions after relative link branches to nops. I don't think we should do this because it's not a global solution and requires fidgety arch-specific patching code. 3) Don't allow patched modules to be removed. I think this makes the most sense. Nobody needs this functionality anyway (right?). " I personally think 2) is a better approach, as it doesn't introduce any new limitations. (I admit that I only plan to implement the fix for x86). 3) seems easier to implement, we just need the livepatch to hold a reference to the module, right? But Miroslav mentioned there are some issues with 3), which I can't figure out. So, what would be the right approach to fix this issue? Is anybody working on this already? If we can agree the right approach, I am more than happy to implement it (well, x86 only for option 2). Thanks, Song [1] https://lore.kernel.org/all/1561019068-132672-1-git-send-email-cj.chengjian@xxxxxxxxxx/T/#u
