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/[email protected] 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. I do not have access to Hyper-V. I did 6 cycles of reviews and back and forth with the LLM over these, so I think they should be okay-ish. Let's be clear tho, that I do not care one bit about this driver and it's brokenness is blocking core work. 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 drivers/net/hyperv/hyperv_net.h | 3 + drivers/net/hyperv/netvsc_bpf.c | 27 ++++++++- drivers/net/hyperv/netvsc_drv.c | 98 +++++++++++++++++++++++++-------- 3 files changed, 103 insertions(+), 25 deletions(-) -- 2.55.0
