> Subject: [EXTERNAL] Re: [PATCH v5 0/7] multi-process and VF hotplug fixes > > On Thu, 26 Feb 2026 17:59:20 -0800 > Long Li <[email protected]> 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. >
