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 <[email protected]> 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/[email protected]/ > 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/[email protected]?part=1
