linux-kernel - Re: [PATCH 0/2] workqueue: fix a bug when numa mapping is changed

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: <551BAC91.208@jp.fujitsu.com>
Date:	Wed, 1 Apr 2015 17:30:09 +0900
From:	Kamezawa Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
To:	Tejun Heo <tj@...nel.org>
CC:	Gu Zheng <guz.fnst@...fujitsu.com>, <linux-kernel@...r.kernel.org>,
	<laijs@...fujitsu.com>, <isimatu.yasuaki@...fujitsu.com>,
	<tangchen@...fujitsu.com>, <izumi.taku@...fujitsu.com>
Subject: Re: [PATCH 0/2] workqueue: fix a bug when numa mapping is changed

On 2015/04/01 12:02, Tejun Heo wrote:
> On Wed, Apr 01, 2015 at 11:55:11AM +0900, Kamezawa Hiroyuki wrote:
>> Now, hot-added cpus will have the lowest free cpu id.
>>
>> Because of this, in most of systems which has only cpu-hot-add, cpu-ids are always
>> contiguous even after cpu hot add.
>> In enterprise, this would be considered as imcompatibility.
>>
>> determining cpuid <-> lapicid at boot will make cpuids sparse. That may corrupt
>> exisiting script or configuration/resource management software.
>
> Ugh... so, cpu number allocation on hot-add is part of userland
> interface that we're locked into?

We checked most of RHEL7 packages and didn't find a problem yet.
But, for examle, we know some performance test team's test program assumed contiguous
cpuids and it failed. It was an easy case because we can ask them to fix the application
but I guess there will be some amount of customers that cpuids are contiguous.

> Tying hotplug and id allocation
> order together usually isn't a good idea.  What if the cpu up fails
> while running the notifiers?  The ID is already allocated and the next
> cpu being brought up will be after a hole anyway.  Is this even
> actually gonna affect userland?
>

Maybe. It's not fail-safe but....

In general, all kernel engineers (and skilled userland engineers) knows that
cpuids cannot be always contiguous and cpuids/nodeids should be checked before
running programs. I think most of engineers should be aware of that but many
users have their own assumption :(

Basically, I don't have strong objections, you're right technically.

In summary...
  - users should not assume cpuids are contiguous.
  - all possible ids should be fixed at boot time.
  - For uses, some clarification document should be somewhere in Documenatation.

So, Gu-san
  1) determine all possible ids at boot.
  2) clarify cpuid/nodeid can have hole because of 1) in Documenation.
  3) It would be good if other guys give us ack.

In future,
I myself thinks naming system like udev for cpuid/numaid is necessary, at last.
Can that renaming feature can be cgroup/namespace feature ? If possible,
all container can have cpuids starting from 0.

Thanks,
-Kame

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