linux-kernel - RE: [EXTERNAL] Re: [Patch net-next v2] net: mana: Handle hardware recovery events when probing the device

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:
 <DS3PR21MB5735D041BB553CE620C68443CED4A@DS3PR21MB5735.namprd21.prod.outlook.com>
Date: Thu, 20 Nov 2025 20:32:20 +0000
From: Long Li <longli@...rosoft.com>
To: Paolo Abeni <pabeni@...hat.com>, "longli@...ux.microsoft.com"
	<longli@...ux.microsoft.com>, KY Srinivasan <kys@...rosoft.com>, Haiyang
 Zhang <haiyangz@...rosoft.com>, Wei Liu <wei.liu@...nel.org>, Dexuan Cui
	<DECUI@...rosoft.com>, "David S. Miller" <davem@...emloft.net>, Eric Dumazet
	<edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Shradha Gupta
	<shradhagupta@...ux.microsoft.com>, Simon Horman <horms@...nel.org>,
	Konstantin Taranov <kotaranov@...rosoft.com>, Souradeep Chakrabarti
	<schakrabarti@...ux.microsoft.com>, Erick Archer <erick.archer@...look.com>,
	"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>
Subject: RE: [EXTERNAL] Re: [Patch net-next v2] net: mana: Handle hardware
 recovery events when probing the device

> Subject: [EXTERNAL] Re: [Patch net-next v2] net: mana: Handle hardware
> recovery events when probing the device
> 
> On 11/18/25 2:52 AM, longli@...ux.microsoft.com wrote:
> > From: Long Li <longli@...rosoft.com>
> >
> > When MANA is being probed, it's possible that hardware is in recovery
> > mode and the device may get GDMA_EQE_HWC_RESET_REQUEST over HWC
> in the
> > middle of the probe. Detect such condition and go through the recovery
> > service procedure.
> >
> > Fixes: fbe346ce9d62 ("net: mana: Handle Reset Request from MANA NIC")
> > Signed-off-by: Long Li <longli@...rosoft.com>
> 
> Does not apply cleanly anymore due to commit
> 934fa943b53795339486cc0026b3ab7ad39dc600, please rebase and repost.

I will rebase and repost v3.

> 
> > +static void mana_recovery_delayed_func(struct work_struct *w) {
> > +	struct mana_dev_recovery_work *work;
> > +	struct mana_dev_recovery *dev, *tmp;
> > +	unsigned long flags;
> > +
> > +	work = container_of(w, struct mana_dev_recovery_work, work.work);
> > +
> > +	spin_lock_irqsave(&work->lock, flags);
> > +
> > +	list_for_each_entry_safe(dev, tmp, &work->dev_list, list) {
> > +		list_del(&dev->list);
> 
> Minor nit: here and in similar code below I find sligly more readable something
> alike:
> 
> 	while (!list_empty(&work->dev_list)) {
> 		dev = list_first_entry(&work->dev_list);
> 		list_del(dev);
> 		//...
> 
> as it's more clear that releasing the lock will not causes races, but no strong
> opinion against the current style.
> 
> /P
> 
> /P

This is better, will change to use while(!list_empty()) as you suggested.

Thank you,
Long