Re: live patching design (was: Re: [PATCH 1/3] sched: add sched_task_call())

From: Jiri Kosina
Date: Sat Feb 21 2015 - 13:58:01 EST

On Sat, 21 Feb 2015, Ingo Molnar wrote:

> > 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 similar to my proposal I came up with not too long time ago; a
fake signal (analogically to, but not exactly the same, what freezer is
using), that will just make tasks cycle through userspace/kernelspace
boundary without other side-effects.

> > 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?

What Vojtech meant here, I believe, is that the effort you have to make to
force all tasks to queue themselves to park them on a safe place and then
restart their execution is exactly the same as the effort you have to make
to make kGraft converge and succeed.

But admittedly, if we reserve a special sort-of signal for making the
tasks pass through a safe checkpoint (and make them queue there (your
solution) or make them just pass through it and continue (current
kGraft)), it might reduce the time this effort needs considerably.

Jiri Kosina
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at