On Tue, Nov 03, 2026 at 09:55:12AM -0500, Steven Rostedt wrote:
> On Mon,  2 Nov 2026 21:44:52 -0500
> Aaron Tomlin <[email protected]> wrote:
> 
> > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> > index e8c4efa8107b..35a56f04e9b3 100644
> > --- a/kernel/trace/trace.c
> > +++ b/kernel/trace/trace.c
> > @@ -9519,6 +9519,9 @@ static void ftrace_dump_one(struct trace_array *tr, 
> > enum ftrace_dump_mode dump_m
> >     else
> >             iter.cpu_file = RING_BUFFER_ALL_CPUS;
> >  
> > +   if (printk_is_tail_full())
> > +           goto out_enable;
> > +
> >     if (tr == &global_trace)
> >             printk(KERN_TRACE "Dumping ftrace buffer:\n");
> >     else
> > @@ -9537,10 +9540,13 @@ static void ftrace_dump_one(struct trace_array *tr, 
> > enum ftrace_dump_mode dump_m
> >      * and then release the locks again.
> >      */
> >  
> > -   while (!trace_empty(&iter)) {
> > +   while (!trace_empty(&iter) && !printk_is_tail_full()) {
> 
> Wait? Is this to prevent overwriting the printk ring buffer? If so, this
> is wrong here!

Oops!

> In your change log, you mention not losing the initial oops or registers.
> But if someone is using ftrace_dump_on_oops, that's not what they are
> after. They want to know what happened that lead to the crash. That output
> is at the *end* of the trace.
> 
> By stopping the output of the ftrace buffer early, you just lost the
> information you are looking for.

Agreed. Because ftrace_dump_one() iterates from oldest to newest, stopping
once the pinned printk ring buffer fills up retains only the oldest trace
entries and discards the end of the trace leading up to the crash.

If a user explicitly enables ftrace via panic_sys_info=ftrace alongside
crash_kexec_in_memory_sys_info, freezing the printk ring buffer tail
defeats the purpose of dumping the trace buffer for the exact reason you
described.

I will drop the kernel/trace/trace.c changes altogether and skip
printk_freeze_tail(true) in panic_in_memory_sys_info() when SYS_INFO_FTRACE
is requested. That keeps console flush suppression active so the dump still
completes at RAM speed prior to kexec, while allowing the printk ring
buffer to wrap so the end of the trace is preserved.

Thank you,
-- 
Aaron Tomlin

Reply via email to