Re: [PATCH v3 0/3] hexdump: Allow skipping identical lines

[Kees Cook <kees@kernel.org>]

On Wed, Oct 14, 2026 at 05:38:44PM +0200, Petr Mladek wrote:
> On Tue 2026-10-13 22:22:58, Andy Shevchenko wrote:
> > +Cc: KUnit maintainers + Kees
> > 
> > On Wed, Mar 19, 2025 at 05:08:09PM +0100, Miquel Raynal wrote:
> > > While working on NAND issues, I used print_hex_dump() a lot to compare
> > > data. But I am mostly working on embedded systems where the kernel
> > > messages go through a serial console. Sometimes network support is an
> > > option, sometimes not. Anyway, I often print buffers both in kernel
> > > space and user space to compare them, and they may be full of 0's or
> > > 1's, which means lines are repeated a lot in the output and this is slow
> > > *and* hard to compare.
> > > 
> > > I initially hacked into lib/hexdump.c for my own purpose and just
> > > discarded all the other users, but it felt like this might be a useful
> > > feature for others and decided to make it a public patch.
> > > 
> > > * First patch creates a helper named print_hex() with a prototype
> > >   containing a flags parameter, instead of an entry for the prefix type
> > >   and another entry for the ascii boolean. print_hex_dump() now
> > >   falls back to print_hex().
> > > * Second patch adds a new flag to possibly skip the identical lines.
> > > * Third patch is optional, and adds the offset at which the dump
> > >   finishes in case the last line to be printed would be skipped.
> > > 
> > > The Cc-list, as provided by get_maintainers.pl, was returning 330
> > > e-mail addresses which felt to much, so I ran the script only on the
> > > second patch (the printk/includes/debug/Doc changes). It gave this
> > > Cc-list which sounds more reasonable. Hopefully this is a smart move,
> > > otherwise let me know what you think would be best.
> > 
> > Sorry for the so late response. First of all, a bit of a background
> > development on my side. At some point a few months ago I asked John
> > Ogness to give me a private dive to the printk() guts. He explained
> > to me a lot about ow printk() circular buffer works and that the
> > implementation is nowadays done in the terms of circular buffer library
> > and printk() front-end. This gives a potential to get a clean solution
> > for the testing how printk() actually behaves.
> 
> I am curious what printk() features you would like to test.
> 
> > The main issue with the
> > real printk() is that the buffer it's using is defined globally and
> > for clean test cases the printk() can't be used. We discussed the way
> > of high-jacking that by linking an object file of printk() implementation
> > to the KUnit test, but it seems quite a tricky if ever achievable exercise.
> > 
> > Meanwhile Kees Cook seems found a nice workaround for the similar use case
> > in his recent patch series [1]. The idea is to register custom console and
> > provide a custom .write() method which is the heart of the solution. On
> > the writer side user prints something which has unique prefix, while the
> > console callback recognises that pattern and checks the rest of the line.
> 
> I ask because the solution used by Kees seems to be quite complicated
> and unreliable for the given purpose. In particular, printk() does
> only the best effort to flush messages on legacy consoles. And NBCON
> consoles drivers are even offloaded to a kthread by default as
> pointed out by John in the other mail.
> 
> It seems that Kees just want to check some particular printk() calls
> and what messages they print. It might be easier and more reliable
> to redirect printk() to an alternative implementation via a hook
> in vprintk() in kernel/printk/printk_safe.c.

Yeah, I was just trying to "prove" that seq_buf_do_printk() actually
put something onto the console (and to match up what was written and how
truncation behaved). :P I'm open to adjusting this however it should be...


-- 
Kees Cook