linux-kernel - Re: [PATCH 4/4] sched,fair: Fix PELT integrity for new tasks

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: <CANRm+Cw3ZcadLrgRh6MKVdFnCc97AQSb2kOra07m_u6EgbzUzg@mail.gmail.com>
Date:	Mon, 1 Aug 2016 15:30:25 +0800
From:	Wanpeng Li <kernellwp@...il.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Yuyang Du <yuyang.du@...el.com>, Ingo Molnar <mingo@...nel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Mike Galbraith <umgwanakikbuti@...il.com>,
	Benjamin Segall <bsegall@...gle.com>,
	Paul Turner <pjt@...gle.com>,
	Morten Rasmussen <morten.rasmussen@....com>,
	Dietmar Eggemann <dietmar.eggemann@....com>,
	Matt Fleming <matt@...eblueprint.co.uk>,
	Vincent Guittot <vincent.guittot@...aro.org>
Subject: Re: [PATCH 4/4] sched,fair: Fix PELT integrity for new tasks

2016-06-17 20:01 GMT+08:00 Peter Zijlstra <peterz@...radead.org>:
> Vincent and Yuyang found another few scenarios in which entity
> tracking goes wobbly.
>
> The scenarios are basically due to the fact that new tasks are not
> immediately attached and thereby differ from the normal situation -- a
> task is always attached to a cfs_rq load average (such that it
> includes its blocked contribution) and are explicitly
> detached/attached on migration to another cfs_rq.
>
> Scenario 1: switch to fair class
>
>   p->sched_class = fair_class;
>   if (queued)
>     enqueue_task(p);
>       ...
>         enqueue_entity()
>           enqueue_entity_load_avg()
>             migrated = !sa->last_update_time (true)
>             if (migrated)
>               attach_entity_load_avg()
>   check_class_changed()
>     switched_from() (!fair)
>     switched_to()   (fair)
>       switched_to_fair()
>         attach_entity_load_avg()
>
> If @p is a new task that hasn't been fair before, it will have
> !last_update_time and, per the above, end up in
> attach_entity_load_avg() _twice_.
>
> Scenario 2: change between cgroups
>
>   sched_move_group(p)
>     if (queued)
>       dequeue_task()
>     task_move_group_fair()
>       detach_task_cfs_rq()
>         detach_entity_load_avg()
>       set_task_rq()
>       attach_task_cfs_rq()
>         attach_entity_load_avg()
>     if (queued)
>       enqueue_task();
>         ...
>           enqueue_entity()
>             enqueue_entity_load_avg()
>               migrated = !sa->last_update_time (true)
>               if (migrated)
>                 attach_entity_load_avg()
>
> Similar as with scenario 1, if @p is a new task, it will have
> !load_update_time and we'll end up in attach_entity_load_avg()
> _twice_.
>
> Furthermore, notice how we do a detach_entity_load_avg() on something
> that wasn't attached to begin with.
>
> As stated above; the problem is that the new task isn't yet attached
> to the load tracking and thereby violates the invariant assumption.
>
> This patch remedies this by ensuring a new task is indeed properly
> attached to the load tracking on creation, through
> post_init_entity_util_avg().
>
> Of course, this isn't entirely as straight forward as one might think,
> since the task is hashed before we call wake_up_new_task() and thus

What's the meaning of "the task is hashed before we call wake_up_new_task()"?

Regards,
Wanpeng Li