Currently XDP programs propagated from uppers are invisible
to safety checks. I'm trying to fix that, but AI reviewer
threw up a bunch of complaints about hv_netvsc. See previous
series here:
https://lore.kernel.org/20260928223648.2739371-1-kuba@kernel.org (local)
That series is now on hold, let's try to sanitize the hv_netvsc
behavior. AFAIU the main use case is to catch the VF as it appears,
and attach it to the netvsc SW interface. If we catch the VF
as soon as it appears we shouldn't have to worry about the VF
already having XDP attached. Let's do what bonding does and
refuse to attach if VF already has XDP, also refuse to attach
if nv_netvsc has XDP but the VF refuses the propagation.
All patches are from LLM reviews and LLM generated.
v1: https://lore.kernel.org/20261001014131.310771-1-kuba@kernel.org (local)
Jakub Kicinski (5):
hv_netvsc: fix the program refcount when the VF refuses XDP
hv_netvsc: hold the VF's instance lock when installing XDP on it
hv_netvsc: treat the VF's XDP program the way bonding treats a slave's
hv_netvsc: move a new VF to netvsc's netns from a work item
hv_netvsc: let the core take XDP off a netvsc device that is going
away
.../ethernet/microsoft/netvsc.rst | 11 +-
drivers/net/hyperv/hyperv_net.h | 3 +
drivers/net/hyperv/netvsc_bpf.c | 70 ++++++++++-
drivers/net/hyperv/netvsc_drv.c | 116 ++++++++++++++----
4 files changed, 169 insertions(+), 31 deletions(-)
--
2.56.0