linux-kernel - Re: 5.6-rc3: WARNING: CPU: 48 PID: 17435 at kernel/sched/fair.c:380 enqueue_task

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: <15252de5-9a2d-19ae-607a-594ee88d1ba1@de.ibm.com>
Date:   Thu, 5 Mar 2020 12:28:52 +0100
From:   Christian Borntraeger <borntraeger@...ibm.com>
To:     Vincent Guittot <vincent.guittot@...aro.org>
Cc:     Dietmar Eggemann <dietmar.eggemann@....com>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: 5.6-rc3: WARNING: CPU: 48 PID: 17435 at kernel/sched/fair.c:380
 enqueue_task_fair+0x328/0x440


On 05.03.20 10:30, Vincent Guittot wrote:
> Le mercredi 04 mars 2020 à 20:59:33 (+0100), Christian Borntraeger a écrit :
>>
>> On 04.03.20 20:38, Christian Borntraeger wrote:
>>>
>>>
>>> On 04.03.20 20:19, Dietmar Eggemann wrote:
>>>>> I just realized that this system has something special. Some month ago I created 2 slices
>>>>> $ head /etc/systemd/system/*.slice
>>>>> ==> /etc/systemd/system/machine-production.slice <==
>>>>> [Unit]
>>>>> Description=VM production
>>>>> Before=slices.target
>>>>> Wants=machine.slice
>>>>> [Slice]
>>>>> CPUQuota=2000%
>>>>> CPUWeight=1000
>>>>>
>>>>> ==> /etc/systemd/system/machine-test.slice <==
>>>>> [Unit]
>>>>> Description=VM production
>>>>> Before=slices.target
>>>>> Wants=machine.slice
>>>>> [Slice]
>>>>> CPUQuota=300%
>>>>> CPUWeight=100
>>>>>
>>>>>
>>>>> And the guests are then put into these slices. that also means that this test will never use more than the 2300%.
>>>>> No matter how much CPUs the system has.
>>>>
>>>> If you could run this debug patch on top of your un-patched kernel, it would tell us which task (in the enqueue case)
>>>> and which taskgroup is causing that.
>>>>
>>>> You could then further dump the appropriate taskgroup directory under the cpu cgroup mountpoint
>>>> (to see e.g. the CFS bandwidth data). 
>>>>
>>>> I expect more than one hit since assert_list_leaf_cfs_rq() uses SCHED_WARN_ON, hence WARN_ONCE.
>>>
>>> That was quick. FWIW, I messed up dumping the cgroup mountpoint (since I restarted my guests after this happened).
>>> Will retry. See the dmesg attached. 
>>
>> New occurence (with just one extra debug line)
> 
> Could you try to add the patch below on top of dietmar's one so we will have the status of
> each level of the hierarchy ?
> The 1st level seems ok but something wrong happens while walking the hierarchy

It seems to speed up the issue when I do a compile job in parallel on the host:

Do you also need the sysfs tree?

View attachment "output" of type "text/plain" (60107 bytes)