netdev - Re: [PATCH rdma-next 0/9] RDMA/bnxt_re: Driver Debug Enhancements

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: <20250401134133.GD186258@ziepe.ca>
Date: Tue, 1 Apr 2025 10:41:33 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: Selvin Xavier <selvin.xavier@...adcom.com>
Cc: Leon Romanovsky <leon@...nel.org>, linux-rdma@...r.kernel.org,
	andrew.gospodarek@...adcom.com, kalesh-anakkur.purayil@...adcom.com,
	netdev@...r.kernel.org, davem@...emloft.net, edumazet@...gle.com,
	kuba@...nel.org, abeni@...hat.com, horms@...nel.org,
	michael.chan@...adcom.com
Subject: Re: [PATCH rdma-next 0/9] RDMA/bnxt_re: Driver Debug Enhancements

On Mon, Feb 24, 2025 at 02:30:04PM +0530, Selvin Xavier wrote:
> > I'm aware that you are not keeping objects itself, but their shadow
> > copy. So if you want, your FW can store these failed objects and you
> > will retrieve them through existing netdev side (ethtool -w ...).

> FW doesn't have enough memory to backup this info. It needs to
> be backed up in the host memory and FW has to write it to host memory
> when an error happens. This is possible in some newer FW versions.
> But itt is not just the HW context that we are caching here. We need to backup
> some host side driver/lib info also to correlate with the HW context.
> We have been debugging issues like this using our Out of box driver
> and we find it useful to get the context
> of failure. Some of the internal tools can decode this information and
> we want to
> have the same behavior between inbox and Out of Box driver.

Can you run some kind of daemon in userspace to collect this
information in real time, maybe using fwctl or something instead of
having the driver capture it?

Jason