linux-kernel - Re: [PATCH v9 23/32] timers: Retrieve next expiry of pinned/non-pinned timers separately

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]

Message-ID: <20231206094735.HMFIZlHa@linutronix.de>
Date:   Wed, 6 Dec 2023 10:47:35 +0100
From:   Sebastian Siewior <bigeasy@...utronix.de>
To:     Anna-Maria Behnsen <anna-maria@...utronix.de>
Cc:     linux-kernel@...r.kernel.org,
        Peter Zijlstra <peterz@...radead.org>,
        John Stultz <jstultz@...gle.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Eric Dumazet <edumazet@...gle.com>,
        "Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
        Arjan van de Ven <arjan@...radead.org>,
        "Paul E . McKenney" <paulmck@...nel.org>,
        Frederic Weisbecker <frederic@...nel.org>,
        Rik van Riel <riel@...riel.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Giovanni Gherdovich <ggherdovich@...e.cz>,
        Lukasz Luba <lukasz.luba@....com>,
        "Gautham R . Shenoy" <gautham.shenoy@....com>,
        Srinivas Pandruvada <srinivas.pandruvada@...el.com>,
        K Prateek Nayak <kprateek.nayak@....com>,
        Richard Cochran <richardcochran@...il.com>
Subject: Re: [PATCH v9 23/32] timers: Retrieve next expiry of
 pinned/non-pinned timers separately

On 2023-12-01 10:26:45 [+0100], Anna-Maria Behnsen wrote:
> For the conversion of the NOHZ timer placement to a pull at expiry time
> model it's required to have separate expiry times for the pinned and the
> non-pinned (movable) timers. Therefore struct timer_events is introduced.
> 
> No functional change
> 
> Originally-by: Richard Cochran (linutronix GmbH) <richardcochran@...il.com>
> Signed-off-by: Anna-Maria Behnsen <anna-maria@...utronix.de>
> Reviewed-by: Frederic Weisbecker <frederic@...nel.org>
…
> index 366ea26ce3ba..0d53d853ae22 100644
> --- a/kernel/time/timer.c
> +++ b/kernel/time/timer.c
…
> @@ -2022,13 +2028,31 @@ static inline u64 __get_next_timer_interrupt(unsigned long basej, u64 basem,
>  
>  	nextevt = local_first ? nextevt_local : nextevt_global;
>  
> -	if (base_local->timers_pending || base_global->timers_pending) {
> +	/*
> +	 * If the @nextevt is at max. one tick away, use @nextevt and store
> +	 * it in the local expiry value. The next global event is irrelevant in
> +	 * this case and can be left as KTIME_MAX.
> +	 */
> +	if (time_before_eq(nextevt, basej + 1)) {
>  		/* If we missed a tick already, force 0 delta */
>  		if (time_before(nextevt, basej))
>  			nextevt = basej;
> -		expires = basem + (u64)(nextevt - basej) * TICK_NSEC;
> +		tevt.local = basem + (u64)(nextevt - basej) * TICK_NSEC;
> +		goto unlock;

You claim "No functional change" in the patch description. However if
you take the shortcut here you don't update `idle' if set and you don't
__forward_timer_base(). The `idle` parameter doesn't matter because it
was false and will remain false as per current logic.

But what about the forward of the timer base? It is probably not real
problem since the next add/mod timer call will forward it.

Sebastian