linux-kernel - Re: [tip:timers/urgent] tick: Don't invoke tick_nohz_stop_sched

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: <20130515194102.GE24004@somewhere>
Date:	Wed, 15 May 2013 21:41:04 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	mingo@...nel.org, hpa@...or.com, linux-kernel@...r.kernel.org,
	jkosina@...e.cz, tony.luck@...el.com, bp@...en8.de,
	tglx@...utronix.de, prarit@...hat.com
Cc:	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:timers/urgent] tick: Don't invoke
 tick_nohz_stop_sched_tick( ) if the cpu is offline

On Tue, May 14, 2013 at 08:46:59AM -0700, tip-bot for Thomas Gleixner wrote:
> Commit-ID:  f7ea0fd639c2c48d3c61b6eec75362be290c6874
> Gitweb:     http://git.kernel.org/tip/f7ea0fd639c2c48d3c61b6eec75362be290c6874
> Author:     Thomas Gleixner <tglx@...utronix.de>
> AuthorDate: Mon, 13 May 2013 21:40:27 +0200
> Committer:  Thomas Gleixner <tglx@...utronix.de>
> CommitDate: Tue, 14 May 2013 17:40:31 +0200
> 
> tick: Don't invoke tick_nohz_stop_sched_tick() if the cpu is offline
> 
> commit 5b39939a4 (nohz: Move ts->idle_calls incrementation into strict
> idle logic) moved code out of tick_nohz_stop_sched_tick() and missed
> to bail out when the cpu is offline. That's causing subsequent
> failures as an offline CPU is supposed to die and not to fiddle with
> nohz magic.

I don't see the logic has changed after this commit. The old nohz
code was already shutting down the tick on offline CPUs.

Am I missing something?
I'm not sure which behaviour we want though, nor what the side
effect could be whether we keep or shutdown the tick.

There is also the problem of full dynticks CPUs that have their
tick stopped and then get later offlined. They may end up in the idle loop
with the tick already stopped and it's not going to be restarted. I believe
that can trigger the same issue.

I'm just not sure what I should do: restart the tick when the CPU
is offlining? What could be the side effect of that?

Thanks.
--
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/