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]

Message-ID: <20070402111828.GA14771@elte.hu>
Date:	Mon, 2 Apr 2007 13:18:28 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Srivatsa Vaddagiri <vatsa@...ibm.com>
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)

* Srivatsa Vaddagiri <vatsa@...ibm.com> wrote:

> On Mon, Apr 02, 2007 at 08:16:12AM +0200, Ingo Molnar wrote:
> > hm, shouldnt the make be frozen immediately?
> > 
> > doesnt the 'please freeze ASAP' flag get propagated to all tasks, 
> > immediately? After that point any cloning activity should duplicate 
> > that flag too, resulting in any new child freezing immediately too.
> 
> afaics, setting the 'please freeze asap' flag is racy wrt 
> dup_task_struct (where the child's tsk->thread_info->flags are copied 
> from its parent?). Secondly, from what I understand, it takes a 'flag 
> to be set + signal marked pending' for the child task to be frozen. If 
> that is the case, then copy_process may not propogae the signal to the 
> child, which could mean mean that we can be in a catch-up game in 
> freeze_processes, trying to freeze processes we didnt see in earlier 
> passes.
> 
> I think copy_process() can check for something like this:
> 
> 	write_lock_irq(&tasklist_lock);
> 
> 	...
> 
> 	if (freezing(current))
> 		freeze_process(p);	/* function exported by freezer */

yeah. (is that safe with tasklist_lock held?)

i'm wondering whether we could do even better than the signal approach. 
I _think_ the best approach would be to only wait for tasks that are _on 
the runqueue_. I.e. any task that has scheduled away with 
TASK_UNINTERRUPTIBLE (and might not be able to process signal events for 
a long time) is still freezable because it scheduled away.

the only freeze-unsafe task is one that is on the runqueue, executing 
some unknown kernel code. But the number of those is typically pretty 
low, even with very large make -j task-counts.

now, the current approach approximates that set of tasks, but not 
completely: in particular TASK_UNINTERRUPTIBLE sleeping threads can 
introduce arbitrary long delays (and hence freezing failures). [in 
addition to any fork-related 'leaks' of freeze-notification]

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