linux-kernel - Re: [PATCH v11 7/9] cpuset: Expose cpus.effective and mems.effective on cgroup v2 root

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:   Thu, 19 Jul 2018 13:22:36 -0400
From:   Waiman Long <longman@...hat.com>
To:     Tejun Heo <tj@...nel.org>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Li Zefan <lizefan@...wei.com>,
        Johannes Weiner <hannes@...xchg.org>,
        Ingo Molnar <mingo@...hat.com>, cgroups@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
        kernel-team@...com, pjt@...gle.com, luto@...capital.net,
        Mike Galbraith <efault@....de>, torvalds@...ux-foundation.org,
        Roman Gushchin <guro@...com>,
        Juri Lelli <juri.lelli@...hat.com>,
        Patrick Bellasi <patrick.bellasi@....com>
Subject: Re: [PATCH v11 7/9] cpuset: Expose cpus.effective and mems.effective
 on cgroup v2 root

On 07/19/2018 12:52 PM, Tejun Heo wrote:
> Hello,
>
> On Thu, Jul 19, 2018 at 11:52:46AM -0400, Waiman Long wrote:
>> BTW, the way the partition is currently implemented right now is that a
>> child cannot be a partition root unless its parent is a partition root
>> itself. That is to avoid turning on partition to affect ancestors
>> further up the hierarchy than just the parent. So in the case of a
>> container, it cannot allocate sub-partitions underneath it unless it is
>> a partition itself. Will that solve your concern?
> Hmm... so a given ancestor must be able to both
>
> 1. control which cpus are moved into a partition in all of its
>    subtree.

Not at the moment. I do have another idea of adding a "cpus.subpart"
file, for example, to indicate what CPUs a child sub-partition can use
in its partition. This control file only serves as an intention to
grant, it won't affect anything else. Before the partition flag can be
turned on, the kernel will have to check if the cpu list of the child is
also a subset of its parent's cpus.subpart as a precondition. Does that
serve the purpose of letting a parent has a say of what CPUs can be
included in a child partition?

This change will require adding a new cpumask into the cpuset structure,
the code to handle the mask as well as an additional check in the
partition enable code. That will have minimal impact to the current code.

> 2. take away any given cpu from ist subtree.
>
> Right now, I don't think it's achieving either, right?

The only way to take away the CPUs from a sub-partition is to turn off
the partition flag in the child provided that it has no sub-partitions
underneath it.

Do you want a way at the parent level to take CPUs away from child
partitions? The "cpus.subpart" file can probably be used also for this
purpose, but we have to decide what taking CPUs away from child
partition means. Does that mean automatically turn off the partition
flag in the children if there is no CPU left in the partition? There are
some implementation details that need to be fleshed out. I would prefer
not doing this as this will complicate the code without too much benefit
that I can see.

Cheers,
Longman