Messages in this thread | | | Date | Thu, 19 Feb 2015 10:52:51 +0100 | From | Peter Zijlstra <> | Subject | Re: [RFC PATCH 6/9] livepatch: create per-task consistency model |
| |
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.
| |