linux-kernel - Re: [RFC] Cpu-hotplug: Using the Process Freezer (try2)

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, 3 Apr 2007 18:26:19 +0530
From:	Srivatsa Vaddagiri <vatsa@...ibm.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Gautham R Shenoy <ego@...ibm.com>, akpm@...ux-foundation.org,
	paulmck@...ibm.com, torvalds@...ux-foundation.org,
	linux-kernel@...r.kernel.org, Oleg Nesterov <oleg@...sign.ru>,
	"Rafael J. Wysocki" <rjw@...k.pl>, dipankar@...ibm.com,
	dino@...ibm.com, masami.hiramatsu.pt@...achi.com
Subject: Re: [RFC] Cpu-hotplug: Using the Process Freezer (try2)

On Mon, Apr 02, 2007 at 08:56:07PM +0200, Ingo Molnar wrote:
> ok. But the only real problem would be for_each_online_cpu() loops that 
> might sleep, correct? 

I would shy from saying that "that's the only problem". It could also be

	for_each_cpu_mask(some_mask)
		do_something_which_sleeps();

where some_mask is suppsoed to represent a subset of online cpus.

For ex: policy->cpus is a mask maintained by cpufreq, which it iterates thr' 
whenever changing cpu frequency. The cpus in that mask are supposed to be 
a subset of online cpus (with CPU_ONLINE/DEAD handlers in cpufreq.c adjusting 
the mask upon hotplug).

We could adopt a similar trick (get/put_each_cpu_mask) that you describe
below in those extended cases as well.

> the 10% loops that _can_ schedule would trigger the __might_sleep() 
> atomicity test in schedule()), and those would have to be converted a 
> bit more cleverly, on a case by case basis.

The real question is how do we convert over those sleeping
for_each_cpu_mask users (for ex: flush_workqueue) such that they don't
block freezer/hotplug for long periods?

One option is to probably rewrite them to understand that
online[or a derived]_map could have changed everytime they come out of a 
(un)interruptible sleep and deal with arising races appropriately. That
would mean a bit of maintenance headache unfortunately (I was hoping
freezer will lead to zero maintenance headache :)

Besides, how problematic is this in practise (that threads sleep for
extended durations in TASK_INTERRUPTIBLE state breaking
freezer/suspend/hotplug)?

Should we ignore this for the timebeing and take up later as and when
users report problems?

-- 
Regards,
vatsa
-
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/