This series addresses an early boot crash and trace buffer allocation failure reported on ppc64le KVM guests [1] (and reproducible under CONFIG_DEFERRED_STRUCT_PAGE_INIT=y with large static kernel footprints).
Patch 1 fixes the crash (NULL pointer dereference in __find_event_file()): When trace buffer allocation fails during early boot, tracing is left disabled. However, tracer_init_tracefs_work_func() runs asynchronously via fs_initcall and traverses uninitialized event lists without checking tracing_disabled. Checking tracing_disabled early averts the crash. Patch 2 fixes the root cause of the early allocation failure: During early_trace_init(), __rb_allocate_pages() performs a heuristic check using si_mem_available(). Under CONFIG_DEFERRED_STRUCT_PAGE_INIT=y, NR_FREE_PAGES only reflects the initial non-deferred pool (e.g. 1 section per node) because the remaining memory has not yet been initialized. On kernels with large static binary footprints (debug configs, early SLUB/vmalloc/ftrace records), this pool is quickly consumed, causing si_mem_available() to return 0 and trigger a false -ENOMEM before the buddy allocator has the opportunity to grow the zone on demand via deferred_grow_zone(). Skipping the check during SYSTEM_BOOTING allows the allocation to succeed. Both fixes have been verified by Michal Suchánek. [1] https://lore.kernel.org/all/[email protected]/ Amit Machhiwal (2): tracing: Do not initialize tracefs work if tracing is disabled ring-buffer: Do not check si_mem_available() during SYSTEM_BOOTING kernel/trace/ring_buffer.c | 8 +++++++- kernel/trace/trace.c | 6 ++++++ 2 files changed, 13 insertions(+), 1 deletion(-) base-commit: af32da41b0327b9c6a37856ba82b6760d6c8d10e -- 2.54.0 (Apple Git-157)
