* Vojtech Pavlik <vojt...@suse.com> wrote: > On Fri, Feb 20, 2015 at 08:49:01PM +0100, Ingo Molnar wrote: > > > > ... the choice the sysadmins have here is either have > > > the system running in an intermediate state, or have > > > the system completely dead for the *same time*. > > > Because to finish the transition successfully, all > > > the tasks have to be woken up in any case. > > > > That statement is false: an 'intermediate state' system > > where 'new' tasks are still running is still running > > and will interfere with the resolution of 'old' tasks. > > Can you suggest a way how they would interfere? The > transition happens on entering or returning from a > syscall, there is no influence between individual tasks.
Well, a 'new' task does not stop executing after returning from the syscall, right? If it's stopped (until all patching is totally complete) then you are right and I concede your point. If it's allowed to continue its workload then my point stands: subsequent execution of 'new' tasks can interfere with, slow down, interact with 'old' tasks trying to get patched. > > I think you misunderstood: the 'simple' method I > > outlined does not just 'synchronize', it actually > > executes the live patching atomically, once all tasks > > are gathered and we know they are _all_ in a safe > > state. > > The 'simple' method has to catch and freeze all tasks one > by one in syscall entry/exit, at the kernel/userspace > boundary, until all are frozen and then patch the system > atomically. Correct. > This means that each and every sleeping task in the > system has to be woken up in some way (sending a signal > ...) to exit from a syscall it is sleeping in. Same for > CPU hogs. All kernel threads need to be parked. Yes - although I'd not use signals for this, signals have side effects - but yes, something functionally equivalent. > This is exactly what you need to do for kGraft to > complete patching. My understanding of kGraft is that by default you allow tasks to continue 'in the new universe' after they are patched. Has this changed or have I misunderstood the concept? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/