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]

Date:	Sun, 13 May 2007 09:33:41 -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>,
	Dipankar Sarma <dipankar@...ibm.com>,
	Ingo Molnar <mingo@...e.hu>,
	Srivatsa Vaddagiri <vatsa@...ibm.com>,
	Paul E McKenney <paulmck@...ibm.com>
Subject: Re: [RFD] Freezing of kernel threads

On Sun, 13 May 2007, Gautham R Shenoy wrote:
> 
> RFC #1: Use get_hot_cpus()- put_hot_cpus() , which follow the
> well known refcounting model.

Yes. And usign the "preempt count" as a refcount is fairly natural, no? 
We do already depend on that in many code-paths.

It also has the advantage since it's not a *blocking* lock, it's fairly 
easy to code around (ie since it nests, it avoids the kinds of nasty 
deadlocks we had with cpufreq that had totally insane calling semantics 
and different people all wanted the lock).

Of course, a real nesting lock could be used to the same effect.

> RFC #1 and #2 DO work. But, the discussions in the thread
> http://lkml.org/lkml/2007/1/26/282 gave me the impression
> that we would be better off without any code audits to
> make the code paths cpu-hotplug safe. I would leave it for others
> to shed more light here.

Well, I hope that _this_ discussion about the freezer has convinced you 
that there are no more fundamntal problems with #1/#2 than with using the 
freezer.

The freezer really needs even *more* code auditing, since it's almost 
impossible to see which thread depends on some other thread. There's a 
real reason why most kernel threads disable freezing.

At least with locking, the code-paths you require to audit are all 
actually relevant to cpu hotplug, and you can easily add dynamic 
_automated_ tests like "if you use online_cpu_map, you'd better hold the 
preempt lock".

For example, since all users of cpu_online_map should be pure *readers* 
(apart from a couple of cases that actually bring up a CPU), you can do 
things like

	#define cpu_online_map check_cpu_online_map()

	static inline cpumask_t check_cpu_online_map(void)
	{
		WARN_ON(!preempt_safe()); /* or whatever lock we decide on */
		return __real_cpu_online_map;
	}

and it will nicely catch things like that.

		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/