linux-kernel - Re: [PATCH v12 9/9] cpuset: Support forced turning off of partition flag

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: <7a57412b-ccdd-be20-529b-89f0737ce41d@redhat.com>
Date:   Thu, 6 Sep 2018 17:20:38 -0400
From:   Waiman Long <longman@...hat.com>
To:     Tejun Heo <tj@...nel.org>
Cc:     Li Zefan <lizefan@...wei.com>,
        Johannes Weiner <hannes@...xchg.org>,
        Peter Zijlstra <peterz@...radead.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 v12 9/9] cpuset: Support forced turning off of partition
 flag

On 08/27/2018 01:50 PM, Waiman Long wrote:
> On 08/27/2018 12:40 PM, Tejun Heo wrote:
>> Hello, Waiman.
>>
>> On Mon, Aug 27, 2018 at 10:41:24AM -0400, Waiman Long wrote:
>>> Cpuset allows arbitrary modification of cpu list in "cpuset.cpus"
>>> even if the requested CPUs won't be granted in "cpuset.cpus.effective"
>>> as restricted by its parent. However, the validate_change() function
>>> will inhibit removal of CPUs that have been used in child cpusets.
>>>
>>> Being a partition root, however, limits the kind of cpu list
>>> modification that is allowed. Adding CPUs is not allowed if the new
>>> CPUs are not in the parent's effective cpu list that can be put into
>>> "cpuset.cpus.reserved". In addition, a child partition cannot exhaust
>>> all the parent's effective CPUs.
>>>
>>> Because of the implicit cpu exclusive nature of the partition root,
>>> cpu changes that break that cpu exclusivity will not be allowed. Other
>>> changes that break the conditions of being a partition root is generally
>>> allowed. However, the partition flag of the cpuset as well those of
>>> the descendant partitions will be forcefully turned off.
>> First of all, thanks a lot for your persistence.  I'm not necessarily
>> against the flag being forced off but wonder whether the same
>> config/effective approach can be used as in .cpus and .mems.  Can you
>> elaborate a bit on the choice here?
>>
>> Thank you.
> My current code has explicitly assumed the following relationship for
> partition root.
>
>     cpus_allowed = effective_cpus + reserved_cpus
>
> Also effective_cpus cannot be empty. Specifically, cpus_allowed has to
> be equal to effective_cpus before a cpuset can be made a partition root.
>
> Any changes that break the above conditions will turn off the partition
> flag forcefully. The only exception is cpu offlining where cpus_allowed
>> effective_cpus + reserved_cpus can happen.
> One reason for doing so is because reserved_cpus is hidden. So the main
> way to infer that is to do cpus_allowed - effective_cpus.
>
> It is probably doable to make cpus_allowed >= effective_cpus +
> reserved_cpus in general, but we may need to expose reserved_cpus as a
> read-only file, for instance. There may also be other complications that
> we will need to take care of if this is supported. My current preference
> is to not doing that unless there is compelling reason to do so.
>
> Cheers,
> Longman

For the current patch, one of conditions to allow users to turn on the
partition flag is cpus_allowed = effective_cpus. Once the partition flag
is on, the twos have to be the same too except with cpu offlining. This
patch is added to allow arbitrary modification to the cpuset.cpus file
except those that have already been forbidden in the existing code. When
the modification violates the rules of being a partition root, the flag
will be turned off or we will have to deny the modification request.

I am admitting that it is an easy way out in term of programming effort
as I am not sure how much effort is needed to enable arbitrary
modification to cpuset.cpus without force disabling and whether such an
effort is even worthwhile to do.

We can certainly relax the current restrictions in the future.  Any
suggestion to improve the patchset is welcome. I would really like to
see this merged in 4.20 (or maybe 5.0) kernel.

Cheers,
Longman