mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ali Firas <alishmery18@gmail.com>
To: netdev@vger.kernel.org, idosch@nvidia.com
Cc: kuba@kernel.org, pabeni@redhat.com, davem@davemloft.net,
	edumazet@google.com, andrew+netdev@lunn.ch, horms@kernel.org,
	razor@blackwall.org, roopa@nvidia.com, shuah@kernel.org,
	linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org,
	Ali Firas <alishmery18@gmail.com>
Subject: [PATCH net-next v3 4/6] vxlan: vnifilter: clamp the dumped VNI range to the request limit
Date: Mon, 28 Sep 2026 00:52:07 +0300	[thread overview]
Message-ID: <20260927215209.2581830-5-alishmery18@gmail.com> (raw)
In-Reply-To: <20260927215209.2581830-1-alishmery18@gmail.com>

vxlan_vnifilter_dump_dev() coalesces a contiguous run of VNIs sharing a
remote into one VXLAN_VNIFILTER_ENTRY with no upper bound on the span. A
device may hold the whole 24-bit space, populated by several requests,
and dump it as a single entry START..END. Now that a single request is
bounded to VXLAN_VNI_FILTER_MSG_MAX VNIs, replaying such an entry in one
RTM_NEWTUNNEL is rejected: the kernel emits an entry it will not read
back, so a dump/replay of a device's VNI configuration fails.

Clamp a merged run to VXLAN_VNI_FILTER_MSG_MAX VNIs so every entry the
dump produces is one the input path accepts. The run is broken in the
merge condition, by ending it once it reaches the limit even when the
next VNI is contiguous and shares the remote; the two representations
then agree on the same bound.

Resume across netlink message boundaries is unchanged. cb->args[1]
counts the VNI nodes already dumped and is advanced only when a
completed entry is written; a run is still a gapless block, so its node
count equals vnirange() + 1 as before, and the clamp only moves where a
run ends. A device with more contiguous VNIs than fit in one skb still
resumes correctly, now split into limit-sized entries rather than one.

Assisted-by: LLM
Signed-off-by: Ali Firas <alishmery18@gmail.com>
---

Notes:
    v3: new patch. Clamp the dumped run to the request limit so its output replays.

 drivers/net/vxlan/vxlan_vnifilter.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/vxlan/vxlan_vnifilter.c b/drivers/net/vxlan/vxlan_vnifilter.c
index 13f4e115701a..92ea1fc94f45 100644
--- a/drivers/net/vxlan/vxlan_vnifilter.c
+++ b/drivers/net/vxlan/vxlan_vnifilter.c
@@ -382,6 +382,7 @@ static int vxlan_vnifilter_dump_dev(const struct net_device *dev,
 			continue;
 		}
 		if (!dump_stats && vnirange(vend, v) == 1 &&
+		    vnirange(vbegin, v) < VXLAN_VNI_FILTER_MSG_MAX &&
 		    vxlan_addr_equal(&v->remote_ip, &vend->remote_ip)) {
 			goto update_end;
 		} else {
-- 
2.53.0


  parent reply	other threads:[~2026-09-27 21:54 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-27 21:52 [PATCH net-next v3 0/6] vxlan: vnifilter: bound a single request and account per-VNI memory Ali Firas
2026-09-27 21:52 ` [PATCH net-next v3 1/6] vxlan: vnifilter: validate the VXLAN_VNIFILTER_ENTRY nest Ali Firas
2026-09-30  3:52   ` netdev-bot+sashiko
2026-09-27 21:52 ` [PATCH net-next v3 2/6] vxlan: vnifilter: reject VNIs outside the 24-bit space Ali Firas
2026-09-30  3:52   ` netdev-bot+sashiko
2026-09-27 21:52 ` [PATCH net-next v3 3/6] vxlan: vnifilter: bound the number of VNIs one request may touch Ali Firas
2026-09-30  3:52   ` netdev-bot+sashiko
2026-09-27 21:52 ` Ali Firas [this message]
2026-09-30  3:52   ` [PATCH net-next v3 4/6] vxlan: vnifilter: clamp the dumped VNI range to the request limit netdev-bot+sashiko
2026-09-27 21:52 ` [PATCH net-next v3 5/6] vxlan: vnifilter: account per-VNI memory to memcg Ali Firas
2026-09-30  3:52   ` netdev-bot+sashiko
2026-09-27 21:52 ` [PATCH net-next v3 6/6] selftests: net: test the vxlan vnifilter request limit and dump replay Ali Firas
2026-09-30  3:52   ` netdev-bot+sashiko

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=20260927215209.2581830-5-alishmery18@gmail.com \
    --to=alishmery18@gmail.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=idosch@nvidia.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=razor@blackwall.org \
    --cc=roopa@nvidia.com \
    --cc=shuah@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

all inboxes | Powered by JetHome®