linux-kernel - [PATCH 0/2] HRTICK reprogramming and optimization

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

Message-Id: <20210208073554.14629-1-juri.lelli@redhat.com>
Date:   Mon,  8 Feb 2021 08:35:52 +0100
From:   Juri Lelli <juri.lelli@...hat.com>
To:     peterz@...radead.org, mingo@...hat.com, vincent.guittot@...aro.org,
        tglx@...utronix.de
Cc:     linux-kernel@...r.kernel.org, rostedt@...dmis.org,
        dietmar.eggemann@....com, bristot@...hat.com, bsegall@...gle.com,
        mgorman@...e.de, lgoncalv@...hat.com, williams@...hat.com,
        Juri Lelli <juri.lelli@...hat.com>
Subject: [PATCH 0/2] HRTICK reprogramming and optimization

Hi All,

Hung tasks and RCU stall cases were reported on systems which were not
100% busy. Investigation of such unexpected cases (no sign of potential
starvation caused by tasks hogging the system) pointed out that the
periodic sched tick timer wasn't serviced anymore after a certain point
and that caused all machinery that depends on it (timers, RCU, etc.) to
stop working as well. This issue was however only reproducible if HRTICK
was enabled.

Looking at core dumps it was found that the rbtree of the hrtimer base
used also for the hrtick was corrupted (i.e. next as seen from the base
root and actual leftmost obtained by traversing the tree are different).
Same base is also used for periodic tick hrtimer, which might get "lost"
if the rbtree gets corrupted.

Much alike what is described in commit 1f71addd34f4c ("tick/sched: Do
not mess with an enqueued hrtimer") there is infact a race window
between hrtimer_set_expires() in hrtick_start and
hrtimer_start_expires() in __hrtick_restart() in which the former might
be operating on an already queued hrtick hrtimer, which might lead to
corruption of the base. Patch 01/02 fixes this case.

While at it, it might be desired to avoid HRTICK overhead in cases where
it is only actually used to service a specific subset of scheduling
classes (currently it services both fair and deadline “at once”). Patch
02/02 proposes an optimization by making HRTICK feature selectable on a
per class basis, so one can, say, enable it only to service DEADLINE and
leave NORMAL task preemption points less fine grained.

Series available at

https://github.com/jlelli/linux.git sched/hrtick-fixes

Hope they both make sense. Comments, questions and suggestions are more
than welcome.

Best,
Juri

Juri Lelli (2):
  sched/features: Fix hrtick reprogramming
  sched/features: Distinguish between NORMAL and DEADLINE hrtick

 kernel/sched/core.c     | 10 ++++------
 kernel/sched/deadline.c |  4 ++--
 kernel/sched/fair.c     |  4 ++--
 kernel/sched/features.h |  1 +
 kernel/sched/sched.h    | 27 +++++++++++++++++++++++++--
 5 files changed, 34 insertions(+), 12 deletions(-)

-- 
2.29.2