Re: [PATCH 2/2] ring-buffer: Do not check si_mem_available() during SYSTEM_BOOTING

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] trace/ring_buffer: SMP boot failure due to premature si_mem_available() check
--

commit b21cf9115adfbd1fd082e26d147a363a37bad846
Author: Amit Machhiwal <amachhiw@linux.ibm.com>

ring-buffer: Do not check si_mem_available() during SYSTEM_BOOTING

This commit modifies early boot tracing allocation to bypass the
si_mem_available() check when system_state is SYSTEM_BOOTING. It aims to
prevent premature -ENOMEM failures on systems with deferred page
initialization.

Link: https://lore.kernel.org/all/arYskzbiaNzBR9MD@kunlun.suse.cz/

> diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> index 04bb94c29f587..a9f82e2f8fad2 100644
> --- a/kernel/trace/ring_buffer.c
> +++ b/kernel/trace/ring_buffer.c
> @@ -2452,9 +2452,15 @@ static int __rb_allocate_pages(struct ring_buffer_per_cpu *cpu_buffer,
>  	 * memory. It may not be accurate. But we don't care, we just want
>  	 * to prevent doing any allocation when it is obvious that it is
>  	 * not going to succeed.
> +	 *
> +	 * Skip this check during early boot: with CONFIG_DEFERRED_STRUCT_PAGE_INIT,
> +	 * NR_FREE_PAGES only reflects the initial non-deferred pool at this
> +	 * stage. si_mem_available() returns a false negative while actual
> +	 * allocations succeed by growing the zone on demand via
> +	 * deferred_grow_zone().
>  	 */
>  	i = si_mem_available();
> -	if (i < nr_pages)
> +	if (system_state != SYSTEM_BOOTING && i < nr_pages)

[Severity: High]
Could this condition cause an SMP boot failure by re-enabling the check
too early?

The system transitions to SYSTEM_SCHEDULING in rest_init() before the init
thread starts. When the init thread runs kernel_init_freeable(), it sets up
secondary CPUs via smp_init() before deferred memory is initialized:

init/main.c:kernel_init_freeable() {
    ...
    smp_init();
    ...
    page_alloc_init_late();
    ...
}

When smp_init() brings up a CPU, it triggers the CPU hotplug callback
trace_rb_cpu_prepare(), which eventually calls __rb_allocate_pages(). 

Since system_state is now SYSTEM_SCHEDULING (not SYSTEM_BOOTING) when
__rb_allocate_pages() is called, the new check evaluates to true and
si_mem_available() executes. Because page_alloc_init_late() hasn't run yet,
deferred memory is still uninitialized, which means si_mem_available() will
return a false negative and abort the allocation with -ENOMEM.

Would this failure propagate through the CPU hotplug state machine and
abort the bring-up of secondary CPUs when CONFIG_DEFERRED_STRUCT_PAGE_INIT
is enabled?

>  		return -ENOMEM;
>  
>  	/*

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261009163557.88467-1-amachhiw@linux.ibm.com?part=2