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.0705130925290.6739@woody.linux-foundation.org>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ