Re: [Ksummit-discuss] [CORE TOPIC] live patching

[Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>]

On 2015/07/09 1:13, Masami Hiramatsu wrote:
>>
>> - it would be beneficial for live patching if kernel threads could be
>>    cleaned up; currently it's a mess, with freezer points, signal handling
>>    etc. spewed randomly all over the main loop. Generalizing the API (such
>>    as improving kthread_worker and migrating kthreads to use that) would
>>    be beneficial if there are no major objections. See my related TECH
>>    TOPIC submission
>>
>> - Ingo proposed a "checkpoint"-based way for live patching, i.e. forcing
>>    all the processess out of kernel to serliaze on a well-defined execution
>>    point, perform the patching, and resume the execution.
>
> IMO, this is not acceptable especially for most of real-time scheduled tasks
> which usually the mission critical systems require. And such systems are
> the main target of the live patching feature I think, since those are
> sometimes controlling civil infrastructure systems, like trains, plants,
> factories and so on.
>
I'm sorr if this is off-topic.

I think the problem of "freezer v.s. FUSE" will happen if we neet to stop user proceesses.
AFAIK, the problem is a deadlock that fuse daemon freezes even while its client wating for a reply.

example)
    client -> page-fault -> GUP -> fuse daemon -> gethostbyname() -> nscd.8

We can't detect this kind of dependency if we need to freeze userland.

Thanks,
-Kame