linux-kernel - Re: [PATCH 1/1] hotplug cpu: migrate a task within its cpuset

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 27 Aug 2007 17:01:34 +1000
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	ego@...ibm.com, Oleg Nesterov <oleg@...sign.ru>,
	Cliff Wickman <cpw@....com>, mingo@...e.hu, vatsa@...ibm.com,
	pj@....com, linux-kernel@...r.kernel.org, ntl@...ibm.com,
	Dipankar Sarma <dipankar@...ibm.com>
Subject: Re: [PATCH 1/1] hotplug cpu: migrate a task within its cpuset

On Sun, 2007-08-26 at 01:09 -0700, Andrew Morton wrote:
> On Sun, 26 Aug 2007 10:47:24 +1000 Rusty Russell <rusty@...tcorp.com.au> wrote:
> > Userspace is not monolithic.  If you refuse to take a CPU offline
> > because a task is affine, then any user can prevent a CPU from going
> > offline.
> 
> That's a kernel bug.

You mean "would be if it were implemented"?  Although consider the
equivalent forkbomb or thrashing userspace problems, where we just say
"use quotas".

Just to clarify: that is not how we work, we migrate tasks off a dying
CPU, breaking affinity and printing a warning if necessary.  

It was simple and has not proven problematic in practice.  (Userspace
cpu affinity has been a question of optimality not correctness)

> > You could, perhaps, introduce a "gentle" offline which fails if process
> > affinity can no longer be met.
> 
> Suitably privileged userspace should be able to
> 
> 1) prevent tasks from binding to CPU N then
> 2) migrate all tasks which can use CPU N over to other CPU(s) then
> 3) offline CPU N.

Indeed, (1) is missing.  I would hesitate to introduce more
infrastructure in an under-worn and over-buggy part of the kernel
though.

Rusty.

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