linux-kernel - Re: [RFC] panic: reduce CPU consumption when finished handling panic

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: <87wmci1a0j.ffs@tglx>
Date: Fri, 21 Mar 2025 20:03:40 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Carlos Bilbao <carlos.bilbao.osdev@...il.com>, pmladek@...e.com, Andrew
 Morton <akpm@...ux-foundation.org>, jani.nikula@...el.com, open list
 <linux-kernel@...r.kernel.org>, Greg Kroah-Hartman
 <gregkh@...uxfoundation.org>, takakura@...inux.co.jp,
 john.ogness@...utronix.de
Subject: Re: [RFC] panic: reduce CPU consumption when finished handling panic

On Mon, Mar 17 2025 at 17:01, Carlos Bilbao wrote:
> After the kernel has finished handling a panic, it enters a busy-wait loop.
> But, this unnecessarily consumes CPU power and electricity. Plus, in VMs,
> this negatively impacts the throughput of other VM guests running on the
> same hypervisor.
>
> I propose introducing a function cpu_halt_end_panic() to halt the CPU
> during this state while still allowing interrupts to be processed. See my
> commit below.

That's not the way how change logs are written. You explain the problem
and then briefly how it is addressed.

No proposal, no 'see below'. Such wording does not make any sense in a
git commit. See Documentation/process/

> @@ -276,6 +276,21 @@ static void panic_other_cpus_shutdown(bool crash_kexec)
>          crash_smp_send_stop();

Your patch is malformed due to white space damage:

  patch: **** malformed patch at line 31:          crash_smp_send_stop();

> +static void cpu_halt_end_panic(void)
> +{
> +#ifdef CONFIG_X86
> +    native_safe_halt();
> +#elif defined(CONFIG_ARM)
> +    cpu_do_idle();
> +#else
> +    /*
> +     * Default to a simple busy-wait if no architecture-specific halt is
> +     * defined above
> +     */
> +    mdelay(PANIC_TIMER_STEP);
> +#endif

Architecture specific #ifdefs in core code are not the right way to
go. Split this into three patches:

1) Add a weak fallback function

void __weak cpu_halt_after_panic(void)
{
        mdelay(PANIC_TIMER_STEP);
}

2) Add non weak implementation in arch/x86

    native_safe_halt() is wrong vs. paravirtualization.

    safe_halt() is what you want.
  
3) Add non weak implementation for arch/arm

   Not my playground, so no comment

Thanks,

        tglx