linux-kernel - Re: [PATCH 10/25] hrtimer: Make handling of hrtimer reprogramming and enqueuing not conditional

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]

Date:   Thu, 28 Sep 2017 10:09:28 +0200 (CEST)
From:   Anna-Maria Gleixner <anna-maria@...utronix.de>
To:     Peter Zijlstra <peterz@...radead.org>
cc:     LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...hat.com>, Christoph Hellwig <hch@....de>,
        keescook@...omium.org, John Stultz <john.stultz@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 10/25] hrtimer: Make handling of hrtimer reprogramming
 and enqueuing not conditional

On Tue, 26 Sep 2017, Peter Zijlstra wrote:

> On Thu, Aug 31, 2017 at 12:23:38PM -0000, Anna-Maria Gleixner wrote:
> > The hrtimer_reprogramming, remote timer enqueuing and handling of the
> > hrtimer_cpu_base struct member expires_next depend on the active high
> > resolution timers. This makes the code harder to understand.
> > 
> > To simplify the code, the hrtimer reprogramming is now executed
> > independently except for the real reprogramming part. The expires_next
> > stores now the first enqueued timer. Due to the adaption of the
> > check_target function, remote enqueuing is now only possible when the
> > expiry time is after the currently first expiry time independent of the
> > active high resolution timers.
> 
> Sorry, very hard to follow. What?

I'm sorry, I have to rework the commit messages...

> 
> So we do this to unconditionally track expire_next, such that we can
> (later) use hrtimer_check_target()?
> 

The main goal of this patch and the three patches before in the series
is to reduce the conditional code. I tried to split it into pieces...

next_timer stores the pointer to the first expiring timer. In
__remove_hrtimer() next_timer is compared to the removed timer; if the
pointers match then the hardware needs to be reprogrammed. This is
done to avoid the extra interrupt which was armed for the removed
timer. So its a HIGH_RES only functionality.

For the softirq mode we need that pointer to have access to the first
expiring timer unconditionally.

expires_next stores the next event armed in hardware. That's used to
check whether a timer can be enqueued remotely. If the new timer is
expiring before expires_next, then remote enqueue is not possible as
we cannot access the remote timer hardware to reprogram it. This is
currently conditional for the HIGH_RES case, but there is no reason to
make this conditional. So I made HIGH_RES and !HIGH_RES behave the
same way just to further reduce the ifdef and conditional zoo.

Anna-Maria