Re: [PATCH v3 21/26] printk: Register information into meminspect
From: Petr Mladek
Date: Thu Jul 09 2026 - 04:17:33 EST
On Wed 2026-07-08 08:59:26, Lorenzo Stoakes wrote:
> On Wed, Jul 08, 2026 at 11:02:00AM +0530, Mukesh Ojha wrote:
> > Annotate vital static, dynamic information into meminspect for debugging
> >
> > Static:
> > - prb_descs
> > - prb_infos
> > - prb
> > - prb_data
> > - clear_seq
> > - printk_rb_static
> > - printk_rb_dynamic
> >
> > Dynamic:
> > - new_descs
> > - new_infos
> > - new_log_buf
> >
> > --- a/kernel/printk/printk.c
> > +++ b/kernel/printk/printk.c
> > @@ -49,6 +49,7 @@
> > #include <linux/sched/debug.h>
> > #include <linux/sched/task_stack.h>
> > #include <linux/panic.h>
> > +#include <linux/meminspect.h>
> >
> > #include <linux/uaccess.h>
> > #include <asm/sections.h>
> > @@ -518,10 +519,17 @@ static u32 log_buf_len = __LOG_BUF_LEN;
> > #endif
> > _DEFINE_PRINTKRB(printk_rb_static, CONFIG_LOG_BUF_SHIFT - PRB_AVGBITS,
> > PRB_AVGBITS, &__log_buf[0]);
> > +MEMINSPECT_NAMED_ENTRY(prb_descs, _printk_rb_static_descs);
> > +MEMINSPECT_NAMED_ENTRY(prb_infos, _printk_rb_static_infos);
> > +MEMINSPECT_NAMED_ENTRY(prb_data, __log_buf);
> > +MEMINSPECT_SIMPLE_ENTRY(printk_rb_static);
> >
> > static struct printk_ringbuffer printk_rb_dynamic;
> > +MEMINSPECT_SIMPLE_ENTRY(printk_rb_dynamic);
> >
> > struct printk_ringbuffer *prb = &printk_rb_static;
> > +MEMINSPECT_SIMPLE_ENTRY(prb);
> > +MEMINSPECT_SIMPLE_ENTRY(clear_seq);
> >
> > /*
> > * We cannot access per-CPU data (e.g. per-CPU flush irq_work) before
> > @@ -1238,6 +1246,10 @@ void __init setup_log_buf(int early)
> >
> > local_irq_restore(flags);
> >
> > + meminspect_lock_register_va(new_log_buf, new_log_buf_len);
> > + meminspect_lock_register_va(new_descs, new_descs_size);
> > + meminspect_lock_register_va(new_infos, new_infos_size);
> > +
> > /*
> > * Copy any remaining messages that might have appeared from
> > * NMI context after copying but before switching to the
>
> Overall exposing live dynamic printk information to drivers seems unwise, but
> not quite as insane as some of the other stuff thus exposed...
I agree that we should be careful with exporting symbols.
Well, if I get it correctly then at least the printk-related symbols
are already exported a similar way using vmcore_info.h API,
see log_buf_vmcoreinfo_setup().
Best Regards,
Petr