linux-kernel - Re: [PATCH v3] sched: cpuset: Don't rebuild root domains on suspend-resume

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] [day] [month] [year] [list]

Date:   Tue, 14 Mar 2023 12:41:36 +0100
From:   Dietmar Eggemann <dietmar.eggemann@....com>
To:     Juri Lelli <juri.lelli@...hat.com>,
        Qais Yousef <qyousef@...alina.io>
Cc:     Hao Luo <haoluo@...gle.com>, Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>,
        Waiman Long <longman@...hat.com>,
        Steven Rostedt <rostedt@...dmis.org>, tj@...nel.org,
        linux-kernel@...r.kernel.org, luca.abeni@...tannapisa.it,
        claudio@...dence.eu.com, tommaso.cucinotta@...tannapisa.it,
        bristot@...hat.com, mathieu.poirier@...aro.org,
        cgroups@...r.kernel.org,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Wei Wang <wvw@...gle.com>, Rick Yiu <rickyiu@...gle.com>,
        Quentin Perret <qperret@...gle.com>,
        Heiko Carstens <hca@...ux.ibm.com>,
        Vasily Gorbik <gor@...ux.ibm.com>,
        Alexander Gordeev <agordeev@...ux.ibm.com>,
        Sudeep Holla <sudeep.holla@....com>,
        Zefan Li <lizefan.x@...edance.com>, linux-s390@...r.kernel.org,
        x86@...nel.org
Subject: Re: [PATCH v3] sched: cpuset: Don't rebuild root domains on
 suspend-resume

On 13/03/2023 18:10, Dietmar Eggemann wrote:
> On 13/03/2023 17:37, Juri Lelli wrote:
>> On 11/03/23 18:51, Qais Yousef wrote:
>>> On 03/09/23 14:23, Hao Luo wrote:
>>>> On Wed, Mar 8, 2023 at 10:55 PM Juri Lelli <juri.lelli@...hat.com> wrote:
>>>>>
>>>>> On 08/03/23 10:01, Hao Luo wrote:
>>>>>> On Wed, Mar 8, 2023 at 2:20 AM Juri Lelli <juri.lelli@...hat.com> wrote:
>>>>>>>
>>>>>>> On 01/03/23 17:03, Qais Yousef wrote:
>>>>>>>> On 03/01/23 15:26, Juri Lelli wrote:
> 
> [...]
> 
>>> Yeah I am working on 5.10 too (this will need to be backported to 5.10 and 5.15
>>> ultimately) and had the same crash because task is NULL.
>>>
>>> Fixed it this way which I think what you intended to do Juri? It moves the
>>> check for dl_task(task) inside cgroup_taskset_for_each() loop.
>>>
>>> 	diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
>>> 	index 83a8943467fb..06d6bb68d86b 100644
>>> 	--- a/kernel/cgroup/cpuset.c
>>> 	+++ b/kernel/cgroup/cpuset.c
>>> 	@@ -2495,11 +2495,11 @@ static int cpuset_can_attach(struct cgroup_taskset *tset)
>>> 			ret = security_task_setscheduler(task);
>>> 			if (ret)
>>> 				goto out_unlock;
>>> 	-       }
>>> 	 
>>> 	-       if (dl_task(task)) {
>>> 	-               cs->deadline_tasks++;
>>> 	-               cpuset_attach_old_cs->deadline_tasks--;
>>> 	+               if (dl_task(task)) {
>>> 	+                       cs->deadline_tasks++;
>>> 	+                       cpuset_attach_old_cs->deadline_tasks--;
>>> 	+               }
>>> 		}
>>> 	 
>>> 		/*
>>
>> Duh, indeed.
>>
>>> Like Hao I don't have any deadline tasks in the system. With the fix above
>>> I don't notice the delay on suspend resume using your patches.
>>
>> OK, cool.
>>
>>> If you want any debug; please feel free to add them into your branch so I can
>>> run with that and give you the log.
>>
>> Will need to find time to run some tests with DEADLINE tasks, yeah.
>> Maybe Dietmar, since you reported as well the issue above with your
>> testing, you could help with testing DEADLINE?
> 
> Ah, now I see! It's the same issue I saw. And it's not specifically
> related to DL tasks. Any tasks which you move into a cpuset will trigger
> this.
> Yeah, can do some DL tests later on this fix.

This fix also works for my DL test.

root@...o:~# ps2 | grep DLN
   83    83 140      0   - DLN sugov:0
   84    84 140      0   - DLN sugov:1
 1601  1602 140      0   - DLN thread0-0
 1601  1603 140      0   - DLN thread0-1
 1601  1604 140      0   - DLN thread0-2
 1601  1605 140      0   - DLN thread0-3
 1601  1606 140      0   - DLN thread0-4
 1601  1607 140      0   - DLN thread0-5
 1601  1608 140      0   - DLN thread0-6
 1601  1609 140      0   - DLN thread0-7
 1601  1610 140      0   - DLN thread0-8
 1601  1611 140      0   - DLN thread0-9
 1601  1612 140      0   - DLN thread0-10
 1601  1613 140      0   - DLN thread0-11

cgroupv1

root@...o:# cd /sys/fs/cgroup/cpuset
root@...o:# mkdir cs1
root@...o:# echo 0 > cs1/cpuset.mems
root@...o:# echo 0,3-5 > cs1/cpuset.cpus

root@...o:# cgclassify -g cpuset:cs1 1602 1603 1604 $$

One remaining doubt: `cgclassify` will still move one task at a time so
cpuset_can_attach() has to deal with one task per call. But
cgroup_taskset_for_each() says that tset can contain multiple tasks. In
this case we would have to think about only changing cs->deadline_tasks
if all tasks can be moved.
Don't know which test would trigger a tset with multiple tasks in
cpuset_can_attach().