linux-kernel - Re: [PATCH] sched/uclamp: Avoid setting cpu.uclamp.min bigger than cpu.uclamp.max

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: <d57e4a37-3e17-3f30-d055-729ece19f555@arm.com>
Date:   Fri, 4 Jun 2021 18:22:42 +0200
From:   Dietmar Eggemann <dietmar.eggemann@....com>
To:     Qais Yousef <qais.yousef@....com>,
        Xuewen Yan <xuewen.yan94@...il.com>
Cc:     Quentin Perret <qperret@...gle.com>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Juri Lelli <juri.lelli@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Benjamin Segall <bsegall@...gle.com>,
        Mel Gorman <mgorman@...e.de>,
        Daniel Bristot de Oliveira <bristot@...hat.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Chunyan Zhang <zhang.lyra@...il.com>,
        Ryan Y <xuewyan@...mail.com>,
        Patrick Bellasi <patrick.bellasi@...bug.net>, tj@...nel.org
Subject: Re: [PATCH] sched/uclamp: Avoid setting cpu.uclamp.min bigger than
 cpu.uclamp.max

On 04/06/2021 18:08, Qais Yousef wrote:
> On 06/03/21 10:24, Xuewen Yan wrote:
>> +CC Qais
> 
> Thanks for the CC :)
> 
>>
>>
>> Hi Quentin
>>
>> On Wed, Jun 2, 2021 at 9:22 PM Quentin Perret <qperret@...gle.com> wrote:
>>>
>>> +CC Patrick and Tejun
>>>
>>> On Wednesday 02 Jun 2021 at 20:38:03 (+0800), Xuewen Yan wrote:
>>>> From: Xuewen Yan <xuewen.yan@...soc.com>
>>>>
>>>> When setting cpu.uclamp.min/max in cgroup, there is no validating
>>>> like uclamp_validate() in __sched_setscheduler(). It may cause the
>>>> cpu.uclamp.min is bigger than cpu.uclamp.max.
>>>
>>> ISTR this was intentional. We also allow child groups to ask for
>>> whatever clamps they want, but that is always limited by the parent, and
>>> reflected in the 'effective' values, as per the cgroup delegation model.
> 
> As Quentin said. This intentional to comply with cgroup model.
> 
> See Limits and Protections sections in Documentation/admin-guide/cgroup-v2.rst
> 
> Specifically
> 
> 	"all configuration combinations are valid"
> 
> So user can set cpu.uclamp.min higher than cpu.uclamp.max. But when we apply
> the setting, cpu.uclamp.min will be capped by cpu.uclamp.max. I can see you
> found the cpu_util_update_eff() logic.

To support this:

Patrick had appropriate checks in his `[PATCH v10 12/16] sched/core:
uclamp: Extend CPU's cgroup controller`.

https://lkml.kernel.org/r/20190621084217.8167-13-patrick.bellasi@arm.com

But is was discussed that cgroup v2 `resource distribution model`
configurations (here protection/limit: uclamp_min/uclamp_max) should not
be restricted.

Further down in this thread:

"... Limits always trump protection in effect of course but please don't
limit what can be configured..."