linux-kernel - Re: [RFC PATCH 6/9] livepatch: create per-task consistency model

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:	Thu, 19 Feb 2015 11:51:41 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Vojtech Pavlik <vojtech@...e.com>
Cc:	Ingo Molnar <mingo@...nel.org>, Jiri Kosina <jkosina@...e.cz>,
	Josh Poimboeuf <jpoimboe@...hat.com>,
	Ingo Molnar <mingo@...hat.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	live-patching@...r.kernel.org, linux-kernel@...r.kernel.org,
	Seth Jennings <sjenning@...hat.com>
Subject: Re: [RFC PATCH 6/9] livepatch: create per-task consistency model

On Thu, Feb 19, 2015 at 11:11:53AM +0100, Vojtech Pavlik wrote:
> On Thu, Feb 19, 2015 at 10:52:51AM +0100, Peter Zijlstra wrote:
> > kthread_park() functionality seems to be exactly what you want.
> 
> It might be exactly that, indeed. The requrement of not just cleaning
> up, but also not using contents of local variables from before parking
> would need to be documented.
> 
> And kernel threads would need to start using it, too. I have been able
> to find one instance where this functionality is actually used. 

Yeah, there's work to be done there. It was introduced for the cpu
hotplug stuff, and some per-cpu threads use this through the smpboot
infrastructure.

More need to be converted. It would be relatively straight fwd to park
threaded IRQs on irq-suspend like activity for example.

> So it is
> again a matter of a massive patch adding that, like with the approach of
> converting kernel threads to workqueues.

Yeah, but not nearly all kthreads can be converted to workqueues. And
there is various problems with workqueues that make it undesirable for
some even if possible.

> By the way, if kthread_park() was implemented all through the kernel,
> would we still need the freezer for kernel threads at all? Since parking
> seems to be stronger than freezing, it could also be used for that
> purpose.

I think not; there might of course be horrible exceptions but in general
parking should be good enough indeed.
--
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/