linux-kernel - Re: [PATCH net 2/2] net: hibmcge: fix wrong ndo.open() after reset fail issue.

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: <20250514090808.2ae43183@kernel.org>
Date: Wed, 14 May 2025 09:08:08 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Jijie Shao <shaojijie@...wei.com>
Cc: <davem@...emloft.net>, <edumazet@...gle.com>, <pabeni@...hat.com>,
 <andrew+netdev@...n.ch>, <horms@...nel.org>, <shenjian15@...wei.com>,
 <wangpeiyang1@...wei.com>, <liuyonglong@...wei.com>,
 <chenhao418@...wei.com>, <jonathan.cameron@...wei.com>,
 <shameerali.kolothum.thodi@...wei.com>, <salil.mehta@...wei.com>,
 <netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net 2/2] net: hibmcge: fix wrong ndo.open() after reset
 fail issue.

On Wed, 14 May 2025 10:40:26 +0800 Jijie Shao wrote:
> on 2025/5/1 22:23, Jakub Kicinski wrote:
> > On Wed, 30 Apr 2025 17:31:27 +0800 Jijie Shao wrote:  
> >> If the driver reset fails, it may not work properly.
> >> Therefore, the ndo.open() operation should be rejected.  
> > Why not call netif_device_detach() if the reset failed and let the core
> > code handle blocking the callbacks?  
> 
> If driver call netif_device_detach() after reset failed,
> The network port cannot be operated. and I can't re-do the reset.
> So how does the core code handle blocking callbacks?
> Is there a good time to call netif_device_attach()?
> 
> Or I need to implement pci_error_handlers.resume()?
> 
> 
> [root@...alhost sjj]# ethtool --reset enp132s0f1 dedicated
> ETHTOOL_RESET 0xffff
> Cannot issue ETHTOOL_RESET: Device or resource busy
> [root@...alhost sjj]# ethtool --reset enp132s0f1 dedicated
> ETHTOOL_RESET 0xffff
> Cannot issue ETHTOOL_RESET: No such device
> [root@...alhost sjj]# ifconfig enp132s0f1 up
> SIOCSIFFLAGS: No such device

netdev APIs may not be the right path to recover the device after reset
failure. Can you use a PCI reset (via sysfs) or devlink ?