linux-kernel - Re: kernel/timer: avoid spurious ksoftirqd wakeups

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, 02 Apr 2015 09:58:26 -0400
From:	Rik van Riel <riel@...hat.com>
To:	Marcelo Tosatti <mtosatti@...hat.com>,
	Frederic Weisbecker <fweisbec@...il.com>
CC:	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Viresh Kumar <viresh.kumar@...aro.org>
Subject: Re: kernel/timer: avoid spurious ksoftirqd wakeups

On 04/01/2015 09:44 PM, Marcelo Tosatti wrote:

> +++ b/kernel/time/tick-sched.c
> @@ -568,6 +568,7 @@ static ktime_t tick_nohz_stop_sched_tick(struct tick_sched *ts,
>  	unsigned long rcu_delta_jiffies;
>  	struct clock_event_device *dev = __this_cpu_read(tick_cpu_device.evtdev);
>  	u64 time_delta;
> +	bool raise_softirq;

You may want to initialize this to false. Nothing else
in the code ever seems to set it to false.

It may work in your test due to that address on the stack
already being zeroed out due to a lucky coincidence, but
that is not a guarantee.

> --- a/kernel/time/timer.c
> +++ b/kernel/time/timer.c
> @@ -1343,7 +1343,7 @@ static unsigned long cmp_next_hrtimer_event(unsigned long now,
>   * get_next_timer_interrupt - return the jiffy of the next pending timer
>   * @now: current time (in jiffies)
>   */
> -unsigned long get_next_timer_interrupt(unsigned long now)
> +unsigned long get_next_timer_interrupt(unsigned long now, bool *raise_softirq)
>  {
>  	struct tvec_base *base = __this_cpu_read(tvec_bases);
>  	unsigned long expires = now + NEXT_TIMER_MAX_DELTA;
> @@ -1357,6 +1357,7 @@ unsigned long get_next_timer_interrupt(unsigned long now)
>  
>  	spin_lock(&base->lock);
>  	if (base->active_timers) {
> +		*raise_softirq = true;
>  		if (time_before_eq(base->next_timer, base->timer_jiffies))
>  			base->next_timer = __next_timer_interrupt(base);
>  		expires = base->next_timer;

Given that run_timer_softirq() only actually does something
if the timer has expired, would it make sense to only raise
the softirq after the timer has expired?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/