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