Netdev List
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: davem@davemloft.net
Cc: netdev@vger.kernel.org, edumazet@google.com, pabeni@redhat.com,
	andrew+netdev@lunn.ch, horms@kernel.org, haiyangz@microsoft.com,
	wei.liu@kernel.org, decui@microsoft.com,
	kameroncarr@linux.microsoft.com, ernis@linux.microsoft.com,
	Jakub Kicinski <kuba@kernel.org>
Subject: [PATCH net-next v2 0/5] hv_netvsc: make XDP propagation act more like bonding
Date: Mon,  9 Nov 2026 11:48:38 -0800	[thread overview]
Message-ID: <20261109194843.1353592-1-kuba@kernel.org> (raw)

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

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

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


             reply	other threads:[~2026-11-09 19:48 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-09 19:48 Jakub Kicinski [this message]
2026-11-09 19:48 ` [PATCH net-next v2 1/5] hv_netvsc: fix the program refcount when the VF refuses XDP Jakub Kicinski
2026-11-09 19:48 ` [PATCH net-next v2 2/5] hv_netvsc: hold the VF's instance lock when installing XDP on it Jakub Kicinski
2026-11-11 10:48   ` netdev-bot+sashiko
2026-11-09 19:48 ` [PATCH net-next v2 3/5] hv_netvsc: treat the VF's XDP program the way bonding treats a slave's Jakub Kicinski
2026-11-11 10:48   ` netdev-bot+sashiko
2026-11-11 18:35     ` Jakub Kicinski
2026-11-09 19:48 ` [PATCH net-next v2 4/5] hv_netvsc: move a new VF to netvsc's netns from a work item Jakub Kicinski
2026-11-11 10:48   ` netdev-bot+sashiko
2026-11-11 18:40     ` Jakub Kicinski
2026-11-09 19:48 ` [PATCH net-next v2 5/5] hv_netvsc: let the core take XDP off a netvsc device that is going away Jakub Kicinski
2026-11-11 10:48   ` netdev-bot+sashiko
2026-11-11 18:45     ` Jakub Kicinski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261109194843.1353592-1-kuba@kernel.org \
    --to=kuba@kernel.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=decui@microsoft.com \
    --cc=edumazet@google.com \
    --cc=ernis@linux.microsoft.com \
    --cc=haiyangz@microsoft.com \
    --cc=horms@kernel.org \
    --cc=kameroncarr@linux.microsoft.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=wei.liu@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox