On Mon 2026-01-19 08:34:42, Breno Leitao wrote:

Hello Petr,

On Mon, Jan 19, 2026 at 03:00:11PM +0100, Petr Mladek wrote:

quoted

quoted

Context: netconsole outputs the message in a different way, similarly to the
printk dictionary. I.e, taskname and cpu come after, one entry per line:

  <message>
   SUBSYSTEM=net
   DEVICE=+pci:0000:00:1f.6
   cpu=42
   taskname=NetworkManager
   ...

BTW.1: I see that netconsole actually does not show pid. So that we do not
       need the trick with caller_id2. But people might want to add it in
       the future.

Correct, I haven't found the pid important when aggregating messages in
the a fleet of hosts.

Good to know.

quoted

BTW.2: I also noticed that sysdata_append_msgid() uses netconsole-specific
       message counter.

       Note that each message has its own sequence number. It is the
       .seq member in struct printk_info. It is printed in the extended
       console output, see info_print_ext_header(). So it is printed
       even on netconsole when this extended format is used.

       I wonder if the netconsole-specific counter was added
       intentionally.

The addition was intentional. The purpose was to monitor the number of
lost netconsole messages.

Originally we were using printk seq number to track "lost" message, later
we discovered that some message numbers were never sent to netconsole
, either due to  different loglevel or supressed message. Thus, using
.seq was not useful to track lost netconsole message.

As a result, netconsole now increments the sequence number only when
a packet is sent over the wire. Therefore, any gap in the "sequence"
indicates that a packet was lost.

Makes perfect sense.

Back o this current patch, I've tested it internally and run a test for
hours without any current issue in terms of task->comm/cpu. 
How would you prefer to proceed to get the patch in?

Is the netconsole part ready for mainline?

If yes, I would suggest to send the full patchset for review and
it might go in via the networking tree.

If no, then we could try to get in at least the printk part
for 6.20. I would personally use the variant with caller_id2
just to be on the safe side.

Note that AFAIK, there are no conflicting changes on the printk side
floating around.

Best Regards,
Petr