Re: [PATCH net v2] vxlan: vnifilter: validate the VNI range in vni_filter_entry_policy

[Ali Firas <alishmery18@gmail.com>]

I have the measurements now. They split into two independent problems,
which changes what I was going to send.

Cost per VNI, measured with per-cache attribution rather than estimated:
128 B slab (kmalloc-128, exactly 1.000 objects per VNI) plus 64 B per
possible CPU for the stats block. rhashtable buckets add roughly 11-21 B
amortised; the RTM_NEWTUNNEL skb is freed promptly and retains nothing.
So 256 B/VNI on 2 CPUs, and a full in-range request is about 66 GiB on a
64-CPU host. My earlier 521 B figure was an artifact of
CONFIG_SLUB_DEBUG_ON inflating the object to 384 B; it is withdrawn.

rhashtable cannot intervene: max_elems is 2^25 against a 2^24 reachable
key space, so -E2BIG is structurally unreachable. Every configuration I
tested (2/4/8 CPUs) reaches a global OOM instead, with no errno returned
because the caller is OOM-killed, and UID 0 processes killed in most
runs.

First problem, memory. GFP_KERNEL_ACCOUNT on the node and its per-CPU
stats confines this: the OOM becomes CONSTRAINT_MEMCG, the host survives,
and unconstrained callers are unaffected within 0.4% on both VNI count
and wall time. It does not produce a graceful failure — try_charge()
invokes the memcg OOM killer rather than returning -ENOMEM, and the
partially installed VNIs stay until the netns is torn down.

Second problem, and this is the one I had not measured when I wrote last
time. vxlan_vnifilter_rtnl_msg_handlers registers RTM_NEWTUNNEL with
flags = 0, so rtnetlink takes the locked path and rtnl_lock is held
across the whole loop. From a second namespace, "ip link add dummy0 type
dummy" takes 0.011 s normally, 4.47 s during a 1M-VNI request, and never
completes at all during a full-range request — it is still blocked when
the OOM killer arrives.

rtnl_lock is global rather than per-netns, so an unprivileged user in one
namespace stalls network configuration for the host and every other
namespace. memcg accounting does nothing for that. cond_resched() yields
the CPU without releasing rtnl, so it only addresses soft-lockup
warnings. As far as I can see only a per-request work cap would fix it,
and that would change uAPI since the full 24-bit space is a legitimate
request today.

So I have the accounting patch ready, but I would rather not send it as
if it closed the problem when it closes half of it. Would you prefer the
accounting patch on its own with the rtnl stall described as a known
remaining issue, or is the stall something you would want addressed
first, in which case I would need guidance on whether a cap is
acceptable at all?

Reproducer and full measurement data available on request.

Thanks,
Ali