linux-kernel - Re: [PATCH net-next v2] net: mana: Improve diagnostic logging for better debuggability

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] [day] [month] [year] [list]

Message-ID: <20260126195850.GO13967@unreal>
Date: Mon, 26 Jan 2026 21:58:50 +0200
From: Leon Romanovsky <leon@...nel.org>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Erni Sri Satya Vennela <ernis@...ux.microsoft.com>, kys@...rosoft.com,
	haiyangz@...rosoft.com, wei.liu@...nel.org, decui@...rosoft.com,
	longli@...rosoft.com, andrew+netdev@...n.ch, davem@...emloft.net,
	edumazet@...gle.com, pabeni@...hat.com, kotaranov@...rosoft.com,
	shradhagupta@...ux.microsoft.com, yury.norov@...il.com,
	dipayanroy@...ux.microsoft.com, shirazsaleem@...rosoft.com,
	ssengar@...ux.microsoft.com, gargaditya@...ux.microsoft.com,
	linux-hyperv@...r.kernel.org, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v2] net: mana: Improve diagnostic logging for
 better debuggability

On Thu, Jan 22, 2026 at 06:07:45PM -0800, Jakub Kicinski wrote:
> On Thu, 22 Jan 2026 09:43:42 -0800 Erni Sri Satya Vennela wrote:
> > On Wed, Jan 21, 2026 at 08:14:12PM -0800, Jakub Kicinski wrote:
> > > On Tue, 20 Jan 2026 22:56:55 -0800 Erni Sri Satya Vennela wrote:  
> > > > Enhance MANA driver logging to provide better visibility into
> > > > hardware configuration and error states during driver initialization
> > > > and runtime operations.  
> > >   
> > > > +	dev_info(gc->dev, "Max Resources: msix_usable=%u max_queues=%u\n",
> > > > +		 gc->num_msix_usable, gc->max_num_queues);  
> > >   
> > > > +	dev_info(dev, "Device Config: max_vports=%u adapter_mtu=%u bm_hostmode=%u\n",
> > > > +		 *max_num_vports, gc->adapter_mtu, *bm_hostmode);  
> > > 
> > > IIUC in networking we try to follow the mantra that if the system is
> > > functioning correctly there should be no logs. You can expose the debug
> > > info via ethtool, devlink, debugfs etc. Take your pick.  
> > 
> > We discussed this internally and noted that customers often cannot
> > reliably reproduce the VM issue. In such cases, the only evidence
> > available is the dmesg logs captured during the incident. Asking them to
> > re-enable debug options later is not practical, since the problem may
> > not occur again. Similarly, exposing the information via ethtool,
> > devlink, or debugfs is less effective because the data is transient and
> > lost after a reboot. As these messages are printed only once during
> > initialization, and not repeated during runtime or driver load/unload,
> > we decided to keep them at info level to aid troubleshooting without
> > adding noise.
> 
> You will have to build proper support tooling like every single vendor
> before you. Presumably you can also log from the hypervisor side which
> makes your life so much easier than supporting real HW. Yet, real
> NIC don't spew random trash to the logs all the time. SMH. Respectfully,
> next time y'all "discuss things internally" start with the question of
> what makes your case special :|

+100

Interesting. Completely independent of your comment, I provided the same
feedback on their mana_ib driver. They added debug logs to nearly every
command, even though those commands already had existing debug logging.

https://lore.kernel.org/linux-rdma/20260122131442.GL13201@unreal/T/#m51e8a12f4bca4a6c1377c5531c8a6d94a43af1e5

"In order to simplify things for you: unless you can clearly justify why this
print is required and why you cannot proceed without it, I must ask you to stop
adding any new debug or error messages to the mana_ib driver. There is a wide
range of existing tools and well‑established practices for debugging the kernel,
and none of them require spamming dmesg."

Thanks