linux-kernel - Re: [PATCH] sched/deadline: Fix priority inheritance with multiple scheduling classes

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]

Message-ID: <jhj8sbfzptf.mognet@arm.com>
Date:   Thu, 05 Nov 2020 17:17:00 +0000
From:   Valentin Schneider <valentin.schneider@....com>
To:     Daniel Bristot de Oliveira <bristot@...hat.com>
Cc:     Juri Lelli <juri.lelli@...hat.com>, peterz@...radead.org,
        mingo@...hat.com, glenn@...ora.tech, linux-kernel@...r.kernel.org,
        rostedt@...dmis.org, vincent.guittot@...aro.org,
        dietmar.eggemann@....com, tglx@...utronix.de,
        luca.abeni@...tannapisa.it, tommaso.cucinotta@...tannapisa.it
Subject: Re: [PATCH] sched/deadline: Fix priority inheritance with multiple scheduling classes


On 05/11/20 16:33, Daniel Bristot de Oliveira wrote:
> On 11/5/20 5:12 PM, Juri Lelli wrote:
>> On 05/11/20 15:49, Valentin Schneider wrote:
>>> For my own sake, what affinity problems are you thinking of?
>>>
>>> With proxy exec we have this "funny" dance of shoving the entire blocked-on
>>> chain on a single runqueue to get the right selection out of
>>> pick_next_task(), and that needs to deal with affinity (i.e. move the task
>>> back to a sensible rq once it becomes runnable).
>>>
>>> With the current PI, the waiting tasks are blocked and enqueued in the
>>> pi_waiters tree, so as I see it affinity shouldn't matter; what am I
>>> missing / not seeing? Is that related to bandwidth handling?
>>
>> Think we might break admission control checks if donor and bosted are,
>> for example, on different exclusive sets of CPUs. Guess that is a
>> problem with proxy as well, though.

Right, that gives you different rd's...

>> As said in the comment above, this
>> is unfortunately not much more than a band-aid. Hoping we can buy us
>> some time and fix it properly with proxy.
>
> I agree with Juri that the current approach is known to be broken,
> and that the proxy execution seems to be the mechanisms to go to
> try to address these problems. However, this will take some time.
>
> Meanwhile, this patch that Juri proposes fixes problem
> in the current mechanism - using the same approach (and breaking
> in a known way :D).
>
> A proper way to handle the priority inversion with a disjoint
> set of CPUs is something that will also be an issue with proxy
> execution. But that is an even more complex topic :-(.
>
> So, IMHO, Juri's patch works well to avoid a crash,
> making the system to behave as we expected (even if
> we know that we cannot expect too much).
>

Aye, no disagreement here! I was mainly asking out of "personal interest",
given I too have an eye on proxy exec - and would actually like to get back
to it this month, if my inbox agrees.

>>> With this change, do we still need sched_dl_entity.dl_boosted? AIUI this
>>> could become
>>>
>>>   bool is_dl_boosted(struct sched_dl_entity *dl_se)
>>>   {
>>>           return pi_of(dl_se) != dl_se;
>>>   }
>>
>> Makes sense to me. I'll add this change as a separate patch if the rest
>> makes sense to people as well. :-)
>
> +1

FWIW nothing strikes me as too crazy, so with the above:

Reviewed-by: Valentin Schneider <valentin.schneider@....com>

>
> -- Daniel
>
>>
>> Thanks for the quick review!
>>
>> Best,
>> Juri
>>