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

On 2026/10/19 12:57 PM, Michal Suchánek wrote:

On Fri, Oct 16, 2026 at 07:12:47PM +0530, Amit Machhiwal wrote:

quoted

During early boot (early_trace_init() called from start_kernel()),
tracing allocates initial ring buffers (temp_buffer, array_buffer, and
snapshot_buffer) for CPU 0.  Later, as secondary CPUs come online during
smp_init(), each CPU's ring buffer is allocated via trace_rb_cpu_prepare().

Before attempting page allocation, __rb_allocate_pages() performs a
heuristic check using si_mem_available() to return early with -ENOMEM if
memory appears insufficient.

<snip>

quoted

 kernel/trace/ring_buffer.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index 04bb94c29f58..aa877a272c89 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;
+#else
 	if (i < nr_pages)
 		return -ENOMEM;
+#endif
 
 	/*
 	 * If a user thread allocates too much, and si_mem_available()

base-commit: 2f2f7eeef8b0a1a9b9ca998231419873ccae8d4e

Hello,

due to other conflicting changes this no longer applies.

Will you send a rebase?

Hi Michal,

Thanks for checking and notifying.  I'll look into it and send a v3 as needed.

Thanks,
Amit