Re: [PATCH v2] ring-buffer: Do not check si_mem_available() before deferred init completes

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] mm/trace: OOM panic via GFP_KERNEL metadata allocations
--

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

ring-buffer: Do not check si_mem_available() before deferred init completes

During early boot, si_mem_available() can return a false negative on kernels
built with CONFIG_DEFERRED_STRUCT_PAGE_INIT. Skip the si_mem_available()
check until SYSTEM_FREEING_INITMEM, when deferred pages are fully
initialized.

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..aa877a272c894 100644
> --- a/kernel/trace/ring_buffer.c
> +++ b/kernel/trace/ring_buffer.c
> @@ -2452,10 +2452,24 @@ 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.
> +	 *
> +	 * With CONFIG_DEFERRED_STRUCT_PAGE_INIT, NR_FREE_PAGES only reflects
> +	 * the initial non-deferred pool during early boot and throughout SMP
> +	 * bring-up (smp_init() runs before page_alloc_init_late() completes
> +	 * deferred initialization). si_mem_available() returns a false negative
> +	 * across this entire window while actual allocations succeed by growing
> +	 * the zone on demand via deferred_grow_zone(). Only re-enable the check
> +	 * from SYSTEM_FREEING_INITMEM onward, after page_alloc_init_late() has
> +	 * finished and si_mem_available() is accurate.
>  	 */
>  	i = si_mem_available();
> +#ifdef CONFIG_DEFERRED_STRUCT_PAGE_INIT
> +	if (system_state >= SYSTEM_FREEING_INITMEM && i < nr_pages)
> +		return -ENOMEM;

[Severity: High]
Does bypassing the si_mem_available() check during early boot expose the
kernel to an out of memory panic?

By skipping this check, __rb_allocate_pages() will proceed to the allocation
loop even if the requested nr_pages exceeds available memory. The loop
contains metadata allocations via alloc_cpu_page():

kernel/trace/ring_buffer.c:__rb_allocate_pages() {
    ...
    for (i = 0; i < nr_pages; i++) {
        bpage = alloc_cpu_page(cpu_buffer->cpu);
        if (!bpage)
            goto free_pages;
    ...
}

alloc_cpu_page() uses GFP_KERNEL without __GFP_RETRY_MAYFAIL:

#define alloc_cpu_page(cpu) (struct buffer_page *)          \
    kzalloc_node(ALIGN(sizeof(struct buffer_page),          \
               cache_line_size()), GFP_KERNEL, cpu_to_node(cpu))

If the loop exhausts the buddy allocator, won't the slab allocator's
subsequent attempt to allocate a new page for the metadata struct using
GFP_KERNEL trigger a kernel panic during early boot?

> +#else
>  	if (i < nr_pages)
>  		return -ENOMEM;
> +#endif
>  
>  	/*
>  	 * If a user thread allocates too much, and si_mem_available()

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