linux-kernel - 回复: 回复: [PATCH v2] sched/eevdf: Force propagating min_slice of cfs

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:
 <ME0P300MB04142599FB1D9BBF8AFECE7F8E5B2@ME0P300MB0414.AUSP300.PROD.OUTLOOK.COM>
Date: Thu, 14 Nov 2024 06:06:34 +0000
From: 解 咏梅 <xieym_ict@...mail.com>
To: Tianchen Ding <dtcccc@...ux.alibaba.com>
CC: Ingo Molnar <mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org>,
	Juri Lelli <juri.lelli@...hat.com>, Vincent Guittot
	<vincent.guittot@...aro.org>, Dietmar Eggemann <dietmar.eggemann@....com>,
	Steven Rostedt <rostedt@...dmis.org>, Ben Segall <bsegall@...gle.com>, Mel
 Gorman <mgorman@...e.de>, Valentin Schneider <vschneid@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject:
 回复: 回复: [PATCH v2] sched/eevdf: Force propagating min_slice of cfs_rq when a task changing slice

Let analyze it case by case:P

say cgroup A has 3 tasks: task A, task B, task C

1) assign taskA's slice to 0.1 ms, task B, tack C, task C all have the default slice (0.75ms)

2) task A is picked by __schedule as next task, because task A is still on rq, 
so the cfs_rq hierarchical doesn't have to change cfs_rq's min_slice, it will report it to the root cgroup

3)  task A is preempted by other task, it's still runnable. it will be requeued cgroup A's cfs_rq. similar as case 2

4) task A is preempted since it's blocked, task A's se will be retained in cgroup A's cfs_rq until it reach 0-lag state.
4.1 before 0-lag, I guess it's similar as case 2
     the logic is based on cfs_rq's avg_runtime, it supposed task A won't be pick as next task before it reach 0-lag state.
     If my understanding is wrong, pls correct me. Thanks.
4.2 After it reached 0-lag state, If it's picked by pick_task_fair, it will be removed from cgroup A cfs_rq ultimately.
     pick_next_entity->dequeue_entities(DEQUEUE_SLEEP | DEQUEUE_DELAYED)->__dequeue_entity (taskA)
    so, cgroup A's cfs_rq min_slice will be re-calculated. So the cfs_rq hierarchical  will modify their own min_slice bottom up.
4.3 After it reached 0-lag state, it will waked up. Because, the current __schedule() split the path for block/sleep from migration path. only migration path will call deactivate. so p->on_rq is still 1, ttwu_runnable will work for it to just call requeue_delayed_entity. similar as case 2

I think only case 1 has such problem.

Regards,
Yongmei.

________________________________________
发件人: Tianchen Ding <dtcccc@...ux.alibaba.com>
发送时间: 2024年11月14日 10:45
收件人: 解 咏梅 <xieym_ict@...mail.com>
抄送: Ingo Molnar <mingo@...hat.com>; Peter Zijlstra <peterz@...radead.org>; Juri Lelli <juri.lelli@...hat.com>; Vincent Guittot <vincent.guittot@...aro.org>; Dietmar Eggemann <dietmar.eggemann@....com>; Steven Rostedt <rostedt@...dmis.org>; Ben Segall <bsegall@...gle.com>; Mel Gorman <mgorman@...e.de>; Valentin Schneider <vschneid@...hat.com>; linux-kernel@...r.kernel.org <linux-kernel@...r.kernel.org>
主题: Re: 回复: [PATCH v2] sched/eevdf: Force propagating min_slice of cfs_rq when a task changing slice
 
On 2024/11/13 19:50, 解 咏梅 wrote:
> Similar problem as commit d2929762 & 8dafa9d0, but this time heap integrity is corrupted by min_slice attr.
> commit eab03c23c fixed it by explicitly calling __dequeue_entity and __enqueue_entity in reweight_entity.
>
> But, it's rare case, it only happens when adjust task's select by setting up scheduler attribute.
>

It's not rare. Since it's in enqueue/dequeue common path, wakeup/sleep may also
trigger this issue.

>
> Regards,
> Yongmei.