Re: [PATCH net-next v4 4/7] vxlan: vnifilter: bound the number of VNIs one request may touch

[netdev-bot+sashiko@kernel.org]

Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.

Low priority / nit picks for your consideration:

- [Low] The comment above VXLAN_VNI_FILTER_MSG_MAX in
  drivers/net/vxlan/vxlan_vnifilter.c says: "A later patch bounds a…

--

vxlan: vnifilter: bound the number of VNIs one request may touch

This commit adds vxlan_vnifilter_check_msg(). It adds up the VNI spans of
every VXLAN_VNIFILTER_ENTRY in an RTM_NEWTUNNEL or RTM_DELTUNNEL request.
If the total is more than VXLAN_VNI_FILTER_MSG_MAX, the whole message is
rejected before any entry is applied. The range extraction is moved into
vxlan_vni_filter_entry_range() so the check and the dispatch path use the
same logic.

> diff --git a/drivers/net/vxlan/vxlan_vnifilter.c b/drivers/net/vxlan/vxlan_vnifilter.c
> index 5beec29eb84a8..2999dd536625e 100644
> --- a/drivers/net/vxlan/vxlan_vnifilter.c
> +++ b/drivers/net/vxlan/vxlan_vnifilter.c

[ ... ]

> +/* Reject a request touching more than VXLAN_VNI_FILTER_MSG_MAX VNIs before any
> + * of its entries is acted on. Both add and delete walk the span one VNI at a
> + * time under rtnl_lock, so both are bounded. Entries are applied one at a time
> + * and each one notifies as it goes, so a limit checked inside the dispatch loop
> + * would leave the entries ahead of the offending one already applied.
> + */
> +static int vxlan_vnifilter_check_msg(const struct nlmsghdr *nlh,
> +				     struct netlink_ext_ack *extack)

[Severity: Low]
This isn't a bug, but should the comment above VXLAN_VNI_FILTER_MSG_MAX
be updated now that this function exists?

The preceding patch added this to the top of vxlan_vnifilter.c:

/* The dump coalesces a contiguous run of VNIs into entries, and packs entries
 * into netlink messages, of at most this many VNIs each, so every message the
 * dump emits stays within what the input path will accept on replay. A later
 * patch bounds a single RTM_NEWTUNNEL/RTM_DELTUNNEL request to the same number.
 */
#define VXLAN_VNI_FILTER_MSG_MAX	4096

This commit is the later patch that sentence refers to. Once it is
applied, the comment still describes the per-request limit as future work.
The text is also the same at the end of the series.

Could the last sentence say that vxlan_vnifilter_check_msg() applies the
same bound to a single request?

[ ... ]

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261014123814.388557-1-alishmery18%40gmail.com