linux-kernel - Re: [PATCH v2] sched/fair: sanitize vruntime of entity being migrated

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: <b2ded6d7-6516-d193-cb23-1609aa03d324@arm.com>
Date:   Wed, 15 Mar 2023 14:35:45 +0100
From:   Dietmar Eggemann <dietmar.eggemann@....com>
To:     Vincent Guittot <vincent.guittot@...aro.org>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Zhang Qiao <zhangqiao22@...wei.com>,
        linux-kernel@...r.kernel.org, mingo@...hat.com,
        juri.lelli@...hat.com, rostedt@...dmis.org, bsegall@...gle.com,
        mgorman@...e.de, bristot@...hat.com, vschneid@...hat.com,
        rkagan@...zon.de
Subject: Re: [PATCH v2] sched/fair: sanitize vruntime of entity being migrated

On 15/03/2023 11:21, Vincent Guittot wrote:
> On Wed, 15 Mar 2023 at 11:15, Dietmar Eggemann <dietmar.eggemann@....com> wrote:
>>
>> On 15/03/2023 09:42, Vincent Guittot wrote:
>>> On Wed, 15 Mar 2023 at 08:18, Vincent Guittot
>>> <vincent.guittot@...aro.org> wrote:
>>>>
>>>> On Tue, 14 Mar 2023 at 18:16, Peter Zijlstra <peterz@...radead.org> wrote:
>>>>>
>>>>> On Tue, Mar 14, 2023 at 02:24:37PM +0100, Vincent Guittot wrote:
>>>>>

[...]

>> Isn't there an issue with this approach on asymmetric CPU capacity systems?
>>
>> We do a sync_entity_load_avg() in select_task_rq_fair()
>> (find_energy_efficient_cpu() for EAS and select_idle_sibling() for CAS)
>> to sync cfs_rq and se.
> 
> ah yes, I forgot this point.
> That being said, is it a valid problem for EAS based system ? I mean
> we are trying to fix a vruntime comparison overflow that can happen
> with a very long sleeping task (around 200 days) while only a very low
> weight entity is always running  during those 200 days.

True. Definitively very unlikely. But it's not only EAS, any asymmetric
CPU capacity wakeup wouldn't have this check in this case.

This dependency between sync_entity_load_avg() and the overflow
detection would be very hard to spot though (in case
sync_entity_load_avg() would get introduced in more common wakeup paths
later).