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 for Android: free password hash cracker in your pocket

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

Message-ID: <aXJhzi58GqLKtui4@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
Date: Thu, 22 Jan 2026 09:43:42 -0800
From: Erni Sri Satya Vennela <ernis@...ux.microsoft.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: 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,
	leon@...nel.org, 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 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.

- Vennela