linux-kernel - Re: timer: Report ignored local enqueue in nohz mode?

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

Message-ID: <20210305234806.GH2696@paulmck-ThinkPad-P72>
Date:   Fri, 5 Mar 2021 15:48:06 -0800
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Frederic Weisbecker <frederic@...nel.org>
Cc:     linux-kernel@...r.kernel.org, peterz@...radead.org,
        tglx@...utronix.de, mingo@...nel.org
Subject: Re: timer: Report ignored local enqueue in nohz mode?

On Fri, Mar 05, 2021 at 02:41:11PM +0100, Frederic Weisbecker wrote:
> On Wed, Mar 03, 2021 at 11:49:45AM -0800, Paul E. McKenney wrote:
> > Hello, Frederic!
> > 
> > I don't see the following commit in mainline, but figured I should
> > check with you guys to see if the problem got solved in some other way.
> > Unless I hear otherwise, I will continue to carry this patch in -rcu
> > and will send it along for the v5.13 merge window.
> 
> I have it included in a nohz series I'm about to post but since RCU is the
> motivation behind doing this, it's fine if you carry it.

Actually, please feel free to run this up the normal nohz path.
I will remove my version once yours hits mainline, as I did with
the others.

I was just curious.  ;-)

							Thanx, Paul

> I've just modified it a bit after a review from Peter:
> 
> ---
> >From 7876725b8631147967bb9e65158ef1cb2bb94372 Mon Sep 17 00:00:00 2001
> From: Frederic Weisbecker <frederic@...nel.org>
> Date: Fri, 8 Jan 2021 13:50:12 +0100
> Subject: [PATCH] timer: Report ignored local enqueue in nohz mode
> 
> Enqueuing a local timer after the tick has been stopped will result in
> the timer being ignored until the next random interrupt.
> 
> Perform sanity checks to report these situations.
> 
> Signed-off-by: Frederic Weisbecker <frederic@...nel.org>
> Cc: Peter Zijlstra <peterz@...radead.org>
> Cc: Thomas Gleixner <tglx@...utronix.de>
> Cc: Ingo Molnar<mingo@...nel.org>
> Cc: Paul E. McKenney <paulmck@...nel.org>
> Cc: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> ---
>  kernel/sched/core.c | 20 +++++++++++++++++++-
>  1 file changed, 19 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index ca2bb629595f..24552911f92b 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -674,6 +674,22 @@ int get_nohz_timer_target(void)
>  	return cpu;
>  }
>  
> +/* Make sure the timer won't be ignored in dynticks-idle case */
> +static void wake_idle_assert_possible(void)
> +{
> +#ifdef CONFIG_SCHED_DEBUG
> +	/*
> +	 * Timers are re-evaluated after idle IRQs. In case of softirq,
> +	 * we assume IRQ tail. Ksoftirqd shouldn't reach here as the
> +	 * timer base wouldn't be idle. And inline softirq processing
> +	 * after a call to local_bh_enable() within idle loop sound too
> +	 * fun to be considered here.
> +	 */
> +	WARN_ONCE(in_task(),
> +		  "Late timer enqueue may be ignored\n");
> +#endif
> +}
> +
>  /*
>   * When add_timer_on() enqueues a timer into the timer wheel of an
>   * idle CPU then this timer might expire before the next timer event
> @@ -688,8 +704,10 @@ static void wake_up_idle_cpu(int cpu)
>  {
>  	struct rq *rq = cpu_rq(cpu);
>  
> -	if (cpu == smp_processor_id())
> +	if (cpu == smp_processor_id()) {
> +		wake_idle_assert_possible();
>  		return;
> +	}
>  
>  	if (set_nr_and_not_polling(rq->idle))
>  		smp_send_reschedule(cpu);
> -- 
> 2.25.1
>