> >> The old function will continue running, right? > > > > Correct. It will, however, call new functions. > > Ah, I see. > > So, I guess, our best bet would be to rewrite the thread function so that it > contains just the event loop and calls other non-inline functions to actually > process the requests. And, perhaps, - place klp_update_patch_state() before > schedule(). Yes, that might be the way. klp_update_patch_state() might not be even needed. If the callees are live patched, the kthread would be migrated thanks to stack checking once a task leaves the callee. > This will not help with this particular kernel version but could make it > possible to live-patch the request-processing functions in the future kernel > versions. The main thread function will remain unpatchable but it will call > the patched functions once we switch the patch_state for the thread. Yes. The only issue is if the intended fix changes the semantics which is incompatible between old and new functions (livepatch consistency model is LEAVE_PATCHED_SET, SWITCH_THREAD, see https://lore.kernel.org/lkml/20141107140458.GA21774@xxxxxxx/ for the explanation if interested). Regards Miroslav
