On Wed, Feb 18, 2015 at 09:44:44PM +0100, Vojtech Pavlik wrote: > For live patching it doesn't matter whether code is running, sleeping or > frozen. > > What matters is whether there is state before patching that may not be > valid after patching. > > For userspace tasks, the exit from a syscall is a perfect moment for > switching to the "after" state, as all stacks, and thus all local > variables are gone and no local state exists in the kernel for the > thread. > > The freezer is a logical choice for kernel threads, however, given that > kernel threads have no defined entry/exit point and execute within a > single main function, local variables stay and thus local state persists > from before to after freezing. > > Defining that no local state within a kernel thread may be relied upon > after exiting from the freezer is certainly possible, and is already > true for many kernel threads. > > It isn't a given property of the freezer itself, though. And isn't > obvious for author of new kernel threads either. > > The ideal solution would be to convert the majority of kernel threads to > workqueues, because then there is a defined entry/exit point over which > state isn't transferred. That is a lot of work, though, and has other > drawbacks, particularly in the realtime space. kthread_park() functionality seems to be exactly what you want. -- To unsubscribe from this list: send the line "unsubscribe live-patching" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
