linux-kernel - Re: [PATCH 6/6] Makes procs file writable to move all threads by tgid at once

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:	Mon, 3 Aug 2009 12:55:33 -0700
From:	Paul Menage <menage@...gle.com>
To:	"Serge E. Hallyn" <serue@...ibm.com>
Cc:	Benjamin Blum <bblum@...gle.com>,
	containers@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org
Subject: Re: [PATCH 6/6] Makes procs file writable to move all threads by tgid 
	at once

On Mon, Aug 3, 2009 at 12:45 PM, Serge E. Hallyn<serue@...ibm.com> wrote:
>
> This is probably a stupid idea, but...  what about having zero
> overhead at clone(), and instead, at cgroup_task_migrate(),
> dequeue_task()ing all of the affected threads for the duration of
> the migrate?

That doesn't sound too unreasonable, actually - it would certainly
simplify things a fair bit. Is there a standard API for doing that?
dequeue_task() itself doesn't really look like a public API. I guess
that the task freezer would be one way to accomplish this?

I can imagine that the set of people who'd complain about the latency
hit when migrating with your solution would be smaller than the people
who'd complain about the increased overhead in the normal clone case.

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