[EXTERNAL] Re: [PATCH v5 0/7] multi-process and VF hotplug fixes

[Long Li]

> Subject: [EXTERNAL] Re: [PATCH v5 0/7] multi-process and VF hotplug fixes
> 
> On Thu, 26 Feb 2026 17:59:20 -0800
> Long Li <longli at microsoft.com> wrote:
> 
> > Fix several issues with VF hotplug and multi-process support in
> > netvsc, mana, mlx5, and mlx4 drivers:
> >
> > - Fix race conditions between VSP notifications and DPDK device events
> >   during VF add/remove, with proper locking of VF-related fields
> > - Add multi-process communication infrastructure for coordinating VF
> >   removal across primary and secondary processes
> > - Fix Protection Domain resource leak on device close in mana
> > - Fix devargs memory leak during VF hotplug in netvsc
> > - Fix fast-path ops (rte_eth_fp_ops) setup in secondary processes for
> >   mana, mlx5, and mlx4, ensuring burst function pointers are restored
> >   after STOP->START cycles
> >
> > v5:
> > - Patches 5,6,7: Also restore rte_eth_fp_ops burst function pointers
> >   (rx_pkt_burst, tx_pkt_burst) in START_RXTX handler, not just queue
> >   data pointers. Without this, after a STOP->START cycle the secondary
> >   process burst pointers remain set to dummy functions.
> >
> > v4:
> > - Patch 1: Check hn_vf_add() return value in netvsc_hotplug_retry
> > - Patch 1: Track fresh_attach to avoid tearing down original VF
> >   attachment when configure/start fails on an -EEXIST path
> > - Patch 2: Move counter decrement and netvsc_uninit_once() after device
> >   cleanup in eth_hn_remove() to prevent use-after-free of shared data
> > - Patch 2: Clear netvsc_shared_data on init failure paths to prevent
> >   dangling pointer
> >
> > v3:
> > - Fix review comments from v2
> >
> > v2:
> > - Initial rework of VF add/remove locking
> >
> > Long Li (7):
> >   net/netvsc: fix race conditions on VF add/remove events
> >   net/netvsc: add multi-process VF device removal support
> >   net/mana: fix PD resource leak on device close
> >   net/netvsc: fix devargs memory leak on hotplug
> >   net/mana: fix fast-path ops setup in secondary process
> >   net/mlx5: fix fast-path ops setup in secondary process
> >   net/mlx4: fix fast-path ops setup in secondary process
> >
> >  drivers/net/mana/mana.c             |  14 ++
> >  drivers/net/mana/mp.c               |   8 +
> >  drivers/net/mlx4/mlx4_mp.c          |   6 +
> >  drivers/net/mlx5/linux/mlx5_mp_os.c |   6 +
> >  drivers/net/netvsc/hn_ethdev.c      | 300 +++++++++++++++++++++++++++-
> >  drivers/net/netvsc/hn_nvs.h         |   6 +
> >  drivers/net/netvsc/hn_rxtx.c        |  40 ++--
> >  drivers/net/netvsc/hn_var.h         |   1 +
> >  drivers/net/netvsc/hn_vf.c          | 148 ++++++++------
> >  9 files changed, 437 insertions(+), 92 deletions(-)
> >
> 
> Looks okay to me, the AI review feedback raised a couple of questions.
> If it is ok will take it as is for this release.

Thank you,

I recommend taking it as is.

" Patch 1: Potential deadlock in hn_vf_close()" is a real issue that may affect netvsc shutdown, I will address this in a future patch.

Thanks,
Long

> 
> The AI summary was:
> 
> Patch 1: hn_vf_add_unlocked() — when hn_nvs_set_datapath() fails at
> switch_data_path: after a fresh attach, the VF is not detached (no goto detach).
> This leaves inconsistent state.
> 
> Patch 2: netvsc_uninit_once() — primary can free the shared memzone while
> secondaries still reference netvsc_shared_data, causing a dangling pointer. The
> local-only secondary_cnt check doesn't reflect remote secondary processes.
> 
> Warnings (should consider)
> 
> Patch 1: Potential deadlock in hn_vf_close() — holding write lock while calling
> rte_eth_dev_callback_unregister() which synchronously waits for in-progress
> callbacks that may themselves try to acquire the write lock via
> hn_remove_delayed().
> 
> There were a couple more things but these were just AI being overly paranoid.
>