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

Ingo Molnar
2015-02-24T10:37:30Z

* Jiri Kosina <jkosina@suse.cz> wrote:

> On Sat, 21 Feb 2015, Ingo Molnar wrote:
>
> > (It does have some other requirements, such as making
> > all syscalls interruptible to a 'special' signalling
> > method that only live patching triggers - even syscalls
> > that are under the normal ABI uninterruptible, such as
> > sys_sync().)
>
> BTW I didn't really understand this -- could you please
> elaborate what exactly do you propose to do here in your
> "simplified" patching method (i.e. serializing everybody
> at the kernel boundary) for TASK_UNINTERRUPTIBLE
> processess?

So I'd try to separate out the two main categories of
uninterruptible sleepers:

- those who just serialize with other local CPUs/tasks
relatively quickly

- those who are waiting for some potentially very long and
open ended request. [such as IO, potentially network IO.]

I'd only touch the latter: a prominent example would be
sys_sync(). I'd leave alone the myriads of other
uninterruptible sleepers.

> But I didn't understand your claims regarding
> uninterruptible sleeps in your paragraph above.
> sys_sync() is one thing, that's just waiting
> uninterruptibly for completion. But how about all the
> mutex waitiers in TASK_UNINTERRUPTIBLE, for example?

I'd not touch those - unless they are waiting for something
that will not be done by the time we park all tasks: for
example NFS might have uninterruptible sleeps, and
sys_sync() will potentially do IO for minutes.

I think it would be the exception, not the rule - but it
would give us an approach that allows us to touch 'any'
kernel code if its wait times are unreasonably long or open
ended.

Thanks,

Ingo