linux-kernel - Re: [bisected] "sched: Allow per-cpu kernel threads to run on online && !active" causes warning

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, 16 Aug 2016 11:20:27 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Heiko Carstens <heiko.carstens@...ibm.com>
Cc:	Ming Lei <tom.leiming@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Yasuaki Ishimatsu <isimatu.yasuaki@...fujitsu.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	Michael Holzheu <holzheu@...ux.vnet.ibm.com>,
	Martin Schwidefsky <schwidefsky@...ibm.com>
Subject: Re: [bisected] "sched: Allow per-cpu kernel threads to run on online
 && !active" causes warning

Hello, Heiko.

On Tue, Aug 16, 2016 at 09:55:05AM +0200, Heiko Carstens wrote:
...
>
> The new standby cpu will have a "configure" sysfs attribute. If somebody
> writes "1" to it we signal the hypervisor that we want to use the cpu and
> it allocates one. If this request succeeds we finally know where the cpu is
> located topology wise and can fix up everything (and can also make the cpu
> to node mapping static).
> Note: as long as cpu isn't configured it cannot be brought online.

I see, so the binding is actually dynamic.  At least the first bring
up.

> If the cpu now is finally brought online the change_cpu_under_node() code
> within drivers/base/cpu.c fixes up the node symlinks so at least the sysfs
> representation is also correct.
> 
> If later on the cpu is brought offline, deconfigured, etc. we do not change
> the cpu_to_node mapping anymore.
> 
> So the question is how to define "first registration sticks". :)

As long as the mapping doesn't change after the first onlining of the
CPU, the workqueue side shouldn't be too difficult to fix up.  I'll
look into it.  For memory allocations, as long as the cpu <-> node
mapping is established before any memory allocation for the cpu takes
place, it should be fine too, I think.

Anyways, give me some days.  I'll look into updating workqueue so that
it works with the mapping on the first onlining.

Thanks.

-- 
tejun