[PATCH net-next v5 0/8] vxlan: vnifilter: bound a single request and account per-VNI memory

[Ali Firas <alishmery18@gmail.com>]

The VNI filter interface accepts a VNI range with no bound on either
endpoint or on how many VNIs one message may ask for, and the memory it
allocates per VNI is not charged to the caller's cgroup. Charging it
makes adding a VNI, or changing its remote, fail routinely at a cgroup
limit, which exposes two error paths that leave configuration state
inconsistent; patches 5 and 6 fix those first.

  1: range-validate both endpoints to the 24-bit VNI space.
  2: end a dumped run, and a dumped message, at the request limit.
  3: cap one request at 4096 VNIs, summed over its entries.
  4: charge the per-VNI node and its stats to the caller's cgroup.
  5: leave an FDB entry's state and flags unchanged when an update fails.
  6: roll back a VNI add that fails.
  7: charge the VNI's default FDB entry to the caller's cgroup.
  8: selftests.

uAPI changes:

  - a VNI at or above 2^24, previously accepted and stored (and
    truncated on the wire), is rejected with -ERANGE;
  - a request asking to add or delete more than 4096 VNIs, summed over
    its entries, is rejected with -EINVAL; "bridge vni add dev X vni
    1-10000" used to be accepted;
  - "bridge vni show" splits a contiguous run longer than 4096 into
    several entries, and across several messages; the set of VNIs it
    reports is unchanged;
  - a VNI add that fails no longer leaves the VNI installed or sends
    RTM_NEWTUNNEL for it;
  - an FDB update that fails, including an RTM_NEWNEIGH, no longer
    leaves the entry's state and flags changed;
  - in a cgroup at its memory limit, adding a VNI, or adding or
    changing a VNI's remote (RTM_NEWTUNNEL), fails with -ENOMEM instead
    of charging past the limit; like any GFP_KERNEL_ACCOUNT allocation,
    the per-VNI node can first invoke the cgroup's OOM killer. A new
    remote may instead be installed without its per-CPU dst cache, whose
    allocation failing is not fatal, as before.

Patches 5 and 6 fix error paths that predate the series, and carry Fixes
tags. Neither is a memory-safety issue; both leave configuration state
inconsistent. They ride here because patch 7 makes those failures
routine at a cgroup limit, and for the earlier rollback posting Jakub
suggested net-next [1]; either can be split out to net if a maintainer
prefers. The group-join failure that patch 6 fixes is deterministic at
the default net.ipv4.igmp_max_memberships (20): the VNI stays published
and notified although it never joined its group, and a retry returns 0
without joining it. The rest of the series carries no Fixes tags. The
request cap is hardening, and Jakub asked for it to target net-next
without one [2]; of the earlier range-only patch he said it was either a
security fix needing a stronger check or something making things
slightly better that did not deserve Fixes or stable [3].

[1] https://lore.kernel.org/netdev/20260915174836.464fae55@kernel.org/
[2] https://lore.kernel.org/netdev/20260914173103.539d8838@kernel.org/
[3] https://lore.kernel.org/netdev/20260905123900.23984eda@kernel.org/

Not addressed here:

  - the device-wide default-remote change (RTM_NEWLINK) reaches the
    same per-VNI FDB entries outside the request cap, and patch 7
    force-charges them rather than hard-bounding them. Its error unwind
    re-adds old entries without checking the result, so bounding the
    walk first needs that unwind fixed;
  - vxlan_vni_add_del() still leaves the earlier VNIs of a range
    installed if a later one fails; the cap bounds that to fewer than
    4096 VNIs;
  - changing the group of an existing VNI records the new group before
    joining it, so a join that fails there leaves the VNI with no
    membership, and a retry returns 0;
  - RTM_NEWNEIGH with NLM_F_APPEND on the all-zeros or a multicast MAC
    adds a remote per request with plain GFP_ATOMIC, uncharged and not
    counted against maxaddress; accounting it is planned as a follow-up,
    building on the gfp plumbing of patch 7;
  - in QEMU (production builds, 2 and 8 vCPU), adding VNIs with remotes
    up to a 32 or 128 MiB limit left 73 to 100 bytes per VNI uncharged,
    5 to 11% of what was charged: the rhashtable bucket arrays behind
    the VNI and FDB hashes, and the per-object metadata memcg keeps for
    every accounted slab object;
  - an entry carrying END without START is read as [0, END]; whether it
    should be is left open.

Tool use: AI coding and review tools were used for code analysis, patch
preparation, review and test development. The changes were validated
with QEMU reproductions, fault injection, the kernel selftests, KASAN,
KCSAN and lockdep builds, and per-commit builds.

Changes since v4:

  - v4 patch 1 was applied as commit 599d0e97610f; these are the rest.
  - new patches 5 and 6, with Fixes tags, ordered before patch 7, which
    makes their failures routine at a cgroup limit (review of v4). Patch
    6 supersedes the separately posted rollback series.
  - patch 1 states its dependency on commit 599d0e97610f (Paolo).
  - patch 7: the vxlan_changelink() rollback keeps plain GFP_ATOMIC,
    like the call it reverses; the changelog no longer claims a clean
    failure on its own (review of v4), and says a remote can be
    installed without its dst cache at the limit.
  - patches 2 and 3: the VXLAN_VNI_FILTER_MSG_MAX comment says what the
    dump does and names vxlan_vnifilter_check_msg(); patches name each
    other by subject (review of v4).
  - patches 1, 3 and 7 say how each gap was found and what it did in
    QEMU (sinfo bot).
  - patch 8: absence probes fail when "bridge vni show" fails; the dump
    is checked against the literal split; START-only and END-only
    out-of-range cases; rollback cases driven by maxaddress and the IGMP
    membership limit (review of v4).
  - patch 8: a refused replace of a VNI's permanent default entry must
    leave it permanent through an ageing pass.
  - lines wrapped to 80 columns; rebased onto net-next, which now has
    commit 7308ef8b4a67 ("vxlan: Stop rejecting dynamic FDB entries with
    a nexthop ID"); it removed a check next to patch 5's change.
  - the Assisted-by trailers are dropped; tool use is described above
    instead, following commit 1e035297ffda ("docs: remove Assisted-by
    references").

v4: https://lore.kernel.org/netdev/20261014123814.388557-1-alishmery18@gmail.com/
Superseded rollback posting:
https://lore.kernel.org/netdev/20260911215203.3054653-1-alishmery18@gmail.com/

Ali Firas (8):
  vxlan: vnifilter: reject VNIs outside the 24-bit space
  vxlan: vnifilter: clamp the dumped VNI range to the request limit
  vxlan: vnifilter: bound the number of VNIs one request may touch
  vxlan: vnifilter: account per-VNI memory to memcg
  vxlan: leave FDB state and flags unchanged when an update fails
  vxlan: vnifilter: roll back a VNI add that fails
  vxlan: vnifilter: account the default FDB entry to memcg
  selftests: net: test the vxlan vnifilter request limit and dump replay

 drivers/net/vxlan/vxlan_core.c                |  87 ++++---
 drivers/net/vxlan/vxlan_private.h             |   7 +-
 drivers/net/vxlan/vxlan_vnifilter.c           | 192 +++++++++++---
 .../selftests/net/test_vxlan_vnifiltering.sh  | 246 +++++++++++++++++-
 4 files changed, 461 insertions(+), 71 deletions(-)


base-commit: fa5196392691051963726787944db872420dfa75
-- 
2.53.0