linux-kernel - Re: [PATCH net-next 0/2] net: netconsole: convert to NBCON console infrastructure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <bvmrtic6pr52cxwf6mis526zz4sbxstxjd2wiqkd2emueatv33@eccynoxgjgo2>
Date: Mon, 19 Jan 2026 08:34:42 -0800
From: Breno Leitao <leitao@...ian.org>
To: Petr Mladek <pmladek@...e.com>
Cc: John Ogness <john.ogness@...utronix.de>, osandov@...ndov.com, 
	mpdesouza@...e.com, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, 
	asantostc@...il.com, efault@....de, gustavold@...il.com, calvin@...nvd.org, 
	jv@...sburgh.net, kernel-team@...a.com, Simon Horman <horms@...nel.org>, 
	Andrew Lunn <andrew+netdev@...n.ch>, "David S. Miller" <davem@...emloft.net>, 
	Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, 
	Paolo Abeni <pabeni@...hat.com>, rostedt@...dmis.org
Subject: Re: [PATCH net-next 0/2] net: netconsole: convert to NBCON console
 infrastructure

Hello Petr,

On Mon, Jan 19, 2026 at 03:00:11PM +0100, Petr Mladek wrote:
> > 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
> >    ...
> 
> I see. Honestly, I never liked the way how dictionary was printed.
> It used another syntax than loglevel, sequence id, and timestamp.
> It might be confusing and complicate parsing.
> 
> But it is a personal opinion. Others might like it because
> it might be easier for human eyes parsing.
> 
> IMHO, the information needs some parsing anyway to make it human readable:
> 
>   + people do not know the log level meaning out of head
>   + message id is there primary to detect lost messages
>   + timestamp needs conversion, definitely
> 
> Sigh, the use of lower case letters for "cpu" and "taskname" made it
> even more inconsistent. I would voted against it if I did the review ;-)

Me too. ;-)

At least, we can use it to differentiate what is coming from pritnk
dictionary and netconsole.

> > Here is the full patch I was using to test the integration of netconsole and
> > the previous printk patch:
> > 
> > https://github.com/leitao/linux/commit/4175dc10719a15844b3a0bd7aa38158a913181a3
> 
> 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.


> 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.

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?

Thanks
--breno