linux-kernel - Re: [PATCH] kernel: cpu: Handle hotplug failure for state CPUHP_AP_IDLE

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]

Date:   Thu, 6 Sep 2018 10:10:09 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Prakruthi Deepak Heragu <pheragu@...eaurora.org>
cc:     linux-kernel@...r.kernel.org, tsoni@...eaurora.org,
        ckadabi@...eaurora.org, bryanh@...eaurora.org,
        psodagud@...eaurora.org
Subject: Re: [PATCH] kernel: cpu: Handle hotplug failure for state
 CPUHP_AP_IDLE_DEAD

On Wed, 5 Sep 2018, Prakruthi Deepak Heragu wrote:

> Once the tear down hotplug handler is run, cpu is dead and enters
> into CPUHP_AP_IDLE_DEAD state. Any callbacks that fail in the state
> machine with state < CPUHP_AP_IDLE must be treated as fatal as this
> could result into timer not beig migrated away from dead cpu and run
> into issues like work queue lock ups, sched_clock timer wrapping to
> zero as sched_clock_poll which is in the hrtimer base of cpu being
> hotplugged does not get migrated.

BUG_ON() is the last resort when there is no other way out. And there is no
reason to treat such a failure as fatal unconditionally.

Why would any of those callback fail at all? And if that ever happens, then
we really can be smarter than just giving up.

Thanks,

	tglx