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

[Ingo Molnar]

* Jiri Kosina <jkosina@xxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/