Re: [PATCH v4 1/3] panic: Introduce arch_do_panic

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The newly introduced `arch_do_panic()` hook is placed before the explicit console flushes. On architectures that halt indefinitely within this hook (e.g., s390), the final 'end Kernel panic' message and any deferred NMI logs will be lost because the required explicit flush is never executed.
--

--- Patch [1]: [PATCH v4 1/3] panic: Introduce arch_do_panic ---
commit 6fe8c46d4a07969ba51a615fab55e7ba7120f254
Author: Mete Durlu <meted@linux.ibm.com>

panic: Introduce arch_do_panic

This patch introduces a weak hook for architectures to provide their
specific panic handlers. This aims to help clean up architecture specific
ifdef checks in the panic path.

> diff --git a/kernel/panic.c b/kernel/panic.c
> --- a/kernel/panic.c
> +++ b/kernel/panic.c
[ ... ]
> @@ -756,6 +758,7 @@ void vpanic(const char *fmt, va_list args)
>  #endif
>  	pr_emerg("---[ end Kernel panic - not syncing: %s ]---\n", buf);
>  
> +	arch_do_panic();

[Severity: Medium]
If an architecture implements this hook and halts indefinitely, will this
bypass the final explicit console flushes?

The final explicit flush happens shortly after this addition:

vpanic() {
    ...
    pr_emerg("---[ end Kernel panic - not syncing: %s ]---\n", buf);
    arch_do_panic();
    suppress_printk = 1;

    console_flush_on_panic(CONSOLE_FLUSH_PENDING);
    nbcon_atomic_flush_unsafe();
    ...
}

Could this cause deferred log messages, such as NMI backtraces or the final
panic banner, to be lost because the required explicit flush is never executed?

>  	/* Do not scroll important messages printed above */
>  	suppress_printk = 1;
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260805-arch_do_panic-v4-0-af4a36f99414@linux.ibm.com?part=1