linux-kernel - Re: [RFD] Freezing of kernel threads

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]

Message-ID: <alpine.LFD.0.98.0705121241300.3986@woody.linux-foundation.org>
Date:	Sat, 12 May 2007 12:57:48 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Gautham R Shenoy <ego@...ibm.com>
cc:	"Rafael J. Wysocki" <rjw@...k.pl>, Pavel Machek <pavel@....cz>,
	Oleg Nesterov <oleg@...sign.ru>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFD] Freezing of kernel threads

On Sun, 13 May 2007, Gautham R Shenoy wrote:
> 
> With the "freeze-limited-kernel-threads" scheme, we would still need
> to perform this audit, since we now have to freeze only those kernel
> threads which *may* end up calling foo().

What the *heck* is wrong with just adding proper locking or other 
synchronization?

Why the hell do people think that they don't need locking for things?

In other words, you're just adding crap to make up for other crap. That's 
*not* how we do kernel develpment. I would seriously suggest people like 
that approach MS for a position on _their_ kernel team.

The fact is, if you want to avoid problems, you do so by having clear and 
clean approaches. THAT is how you avoid bugs. Not by adding crap.

I've several times suggested that if you actually want to stop the 
machine, you can do so at the scheduler level.

So stop talking about freezing when you're talkign abotu CPU hotplug. The 
two have _nothing_ to do with each other, and if there is something this 
whole discussion has absolutely convinced me about, it's that they will 
never have anything to do with each other.

If you worry about people doing 

	for_each_online_cpu()

in the presense of hotplug, here's a couple of simple solutions:

 - Just teach for_each_online_cpu() about locking. It's not a new concept. 
   We have it all over the kernel. 

   Maybe the macro itself can take whatever locks it needs, and maybe it's 
   as simple as a rule saying that: "you must hold spinlock XYZ when you 
   do that". But it has _nothing_ to do with freezing all threads.

 - make the rule be that you cannot sleep in the above macro, and make the 
   rule be that CPU hotplug uses the same mechanisms that module unload 
   already does!

In other words, we already have *better* mechanisms for cpu hotplug than 
the freezer. We have mechanisms that there is absolutely zero controversy 
about.

IOW, have you actually looked at "stop_machine_run()", which people use 
much more than the freezer, and which has never really caused any issues, 
and didn't result in us adding *crap* to every single kernel thread?

Really. The arguments for the freezer are CRAP. Why cannot people just 
admit it? We have *better* things available, that don't *need* any of this 
crap. The "stop_machine()" stuff literally ends up just running a 
high-priority thread on each CPU, and doesn't need any special support 
anywhere.

AND IT JUST WORKS. 

(Btw, I'm pretty sure it could be used for hibernation too: just stop the 
IO at a higher level first, sync, then stop_machine_run() etc. But I don't 
care. What I care about is that the freezer() insanity doesn't _spread_).

		Linus
-
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/