Re: [PATCH net-next v12 4/4] net: mana: recover port on attach failure in ethtool operations

Paolo Abeni <[email protected]>
Newsgroups org.kernel.vger.linux-rdma,org.kernel.vger.bpf,org.kernel.vger.linux-hyperv,org.kernel.vger.linux-kernel,org.kernel.vger.netdev
Message-ID <[email protected]>
On 7/11/26 6:10 AM, Dipayaan Roy wrote:
> When mana_attach() fails during ethtool ring size or channel count
> changes, the port is left in a broken state with no recovery
> mechanism, requiring manual intervention to bring the port back up.
> 
> On VM SKUs without a netvsc fallback interface, this results in
> complete loss of network connectivity to the VM.
> 
> Fix by scheduling queue_reset_work when mana_attach() fails. The
> preceding patch ensures mana_detach() always completes its full
> teardown (netif_device_detach + cleanup), so the reset handler's
> mana_detach() takes the "already detached" early return, preserving
> port_st_save for a successful mana_attach() recovery.
> 
> When mana_attach() fails, choose retry values that maximize recovery
> chances: if the operation was an increase, fall back to the previous
> working values; if it was a decrease but still above default, fall
> back to defaults; otherwise use the minimum supported values.
> 
> Reviewed-by: Haiyang Zhang <[email protected]>
> Tested-by: Aditya Garg <[email protected]>
> Signed-off-by: Dipayaan Roy <[email protected]>
sashiko gemini sees quite a bit of problem with the above approach:

https://sashiko.dev/#/patchset/20260711041415.3008868-1-dipayanroy%40linux.microsoft.com

Also, changing user-setting in case of fallback is quite a bad thing to
be avoided.

Skimming over the code, it looks like than pre-allocate all the
resources and to a replace instead of detach/attach() looks feasible. I
suggest investigating such path. I also think that this last patch (and
possibly 2/4) could/should be in separate series.

Finally and most relevant thing; AI review comments should be explicitly
acknowledged by either debating them or addressing them. In both cases a
reply on the ML is expected.

/P
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.