linux-kernel - Re: live patching design (was: Re: [PATCH 1/3] sched: add sched_task

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 24 Feb 2015 11:37:23 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Jiri Kosina <jkosina@...e.cz>
Cc:	Josh Poimboeuf <jpoimboe@...hat.com>,
	Vojtech Pavlik <vojtech@...e.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...hat.com>,
	Seth Jennings <sjenning@...hat.com>,
	linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	live-patching@...r.kernel.org
Subject: Re: live patching design (was: Re: [PATCH 1/3] sched: add
 sched_task_call())


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