linux-kernel - Re: [RFC PATCH 1/6] sched/fair: check_preempt_wakeup: Fix assumption on the default policy

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.20.1609202236430.5476@nanos>
Date:   Tue, 20 Sep 2016 22:49:12 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Julien Desfossez <jdesfossez@...icios.com>
cc:     peterz@...radead.org, rostedt@...dmis.org, mingo@...hat.com,
        daolivei@...hat.com, mathieu.desnoyers@...icios.com,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 1/6] sched/fair: check_preempt_wakeup: Fix assumption
 on the default policy

On Fri, 16 Sep 2016, Julien Desfossez wrote:

> Tasks with RT or deadline scheduling class may inherit from a task with
> a "fair" scheduling class.

This makes no sense. A RT/DL task can never inherit anything from a sched
fair task. That would be inverted priority inheritance.

> This priority inheritance changes the scheduling class, but not the task
> "policy" field.
>
> Therefore, the fair scheduler should not assume that policy !=
> SCHED_NORMAL is the same as (policy == SCHED_BATCH || policy ==
> SCHED_IDLE), because the policy could also be SCHED_RR, SCHED_FIFO, or
> SCHED_DEADLINE.
> 
> The incorrect comparison in check_preempt_wakeup makes RR, FIFO and
> DEADLINE tasks which inherit from a fair task behave as if they were
> IDLE or BATCH tasks, thus awaiting the following tick before preempting
> the current task.

This is just wrong.

Priority/deadline inheritance elevates a fair task to RR/FIFO/DL, i.e. to
the scheduling class of the task which is blocked on a resource held by the
fair task.

The check_preempt_curr() callback of a scheduling class is only invoked
when the freshly woken task is in the same scheduling class as the task
which is currently on the cpu.

So which problem are you actually solving?

> Cc: Peter Zijlstra <peterz@...radead.org>
> Cc: Steven Rostedt (Red Hat) <rostedt@...dmis.org>
> Cc: Thomas Gleixner <tglx@...utronix.de>
> Cc: Ingo Molnar <mingo@...hat.com>
> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
> Signed-off-by: Julien Desfossez <jdesfossez@...icios.com>

Who wrote the patch? 

Thanks,

	tglx