linux-kernel - Re: [PATCH] sched: Fix rt

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

Message-ID: <1472497740717843.0.mail@mail>
Date:   Tue, 30 Aug 2016 04:08:55 +0900
From:   "Yin-goo Yim" <ygyim@...kuk.ac.kr>
To:     "Andreas Mohr" <andi@...as.de>
Cc:     "Dongsheng Yang" <yangds.fnst@...fujitsu.com>,
        "Thomas Gleixner" <tglx@...utronix.de>,
        <linux-kernel@...r.kernel.org>, <mingo@...hat.com>,
        <peterz@...radead.org>, <torvalds@...ux-foundation.org>,
        <jinh@...kuk.ac.kr>
Subject: Re: [PATCH] sched: Fix rt_task to work properly

Thank you for your immediate response.

> AFAICS this change is a larger layer violation (dependency issue)
> since AFAIK prio.h is a generic, common base header
> which is to provide priority definitions
> common to *all* of the
> more specific scheduler sub handling
> (deadline, rt, ...),
> which thus should not have to aggregate
> any specific knowledge whatsoever about
> various scheduler sub type specific handling.

We agree that the prio.h file has to be generic, but we thought that adding 
the priority information of deadline scheduler (i.e., #define MAX_DL_PRIO 0) 
to this file should be fine, because prio.h already has the priority 
information for cfs and rt schedulers (i.e., MAX_PRIO and MAX_RT_PRIO).

> rt_prio() quite likely is to be seen as an *rt-specific* API
> since it is defined in the *rt-specific* rt.h header.
> IOW, rt_prio() is *not to be used* for any areas where we
> do not have an RT case
> (quite certainly header docs should be added to rt_prio()
> to definitely emphasize this fact,
> maybe something like
> "Note that since this is an RT API it is meaningful for RT tasks only").

The rt_prio() function returns 1 or 0 according to whether or not the 
corresponding process is an rt task. Thus, we believe that rt_prio() is a 
suitable function to determine if a task is rt one, and can be called even 
for non-rt tasks. Indeed we can easily find examples where 
rt_prio()/rt_task() is called for an arbitrary process without limiting to 
rt tasks (e.g., sched_fork()).

Though our initial intention was to fix the origin of the problem, if you/we 
are not convinced of our patch due to dependency issues, we can reinforce 
the conditional statement in tg_has_rt_tasks() by adding !dl_task(p) as 
follows:

if (!dl_task(p) && rt_task(p) && task_group(p) == tg)

In this manner, we can avoid modifying the header files in 
include/linux/sched/, while having the same effect with respect to cgroup.

Thanks,
Yin-goo Yim