From nobody Fri Sep 25 19:19:17 2026 Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 09C4A3DD84F for ; Wed, 9 Sep 2026 09:27:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.42 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788946053; cv=none; b=IxWXZDdmkFxDn/t+pQIy9aF8UDNqcOiwf8I5VNygQhqnnSKKVMKoi1FOgH7tk0fr+sBtXhV3M7ltUJ70lW1yifzXqj2dnnBZcys1OTuQRBqlcsPckLHcxqs2ZYfl8y/iOZJwhDZ8GASaXAY/y0LdMX+CSUinn6l49iItCpJ/LLU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788946053; c=relaxed/simple; bh=opb3piTKdPfw2gKO3g3oDpNDNotYQET8m8wmTdkj+Ow=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=VGq21tB2ePUEyqCHCNWP+18/zfc/hJERNZGHcKi51pWe0ZWFquf95pJUCXgMuFDTMdc7tZHo+sYopVgrWNsdzgIksK2N14k61/mirrFiTBVZ/C8eAVldwAtONgLlfCyko8CaWrBicknWBIKAjvi1hhAVe4InSfxp5B7S7LN7moc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=WscwqcrX; arc=none smtp.client-ip=209.85.221.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="WscwqcrX" Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-482ea739de2so3861110f8f.0 for ; Wed, 09 Sep 2026 02:27:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788946048; x=1789550848; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Tn5iao8ktJWUmrSNE1xw9a8qj82WjCSpUTURoE0uN4c=; b=WscwqcrX+24QmnAh5cBIlTV7sZvnkdwUmhhQ47jHS5J9HPr4XK9tOxS5/Z/RAkktRn RZpc9r3DInqH3+E2OWCLlLFCc1MVpnFlUHUAFJHTRg06pyNp7s2VR5zSwmKzdxkmYAor W7n9Zs309x2w48K8t7XF/Lnz/SDhSGLXy+WcQtK1Ng+iealt/EuLS+9d3oWvcDQfAu/6 NgMr+/rN47SrG/HTw0i2erx0wbGdkOGQ1jfgKLDyOZ8SDAtequ2aMKFg1YUc9TqxoIwU iYX0fuiFByRkqj2PmnMnNv3mnlVjFGqc0Eo9mP6fmqY5Sxt03P8gm24UfsmJDsI5gO2U 7zEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788946048; x=1789550848; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=Tn5iao8ktJWUmrSNE1xw9a8qj82WjCSpUTURoE0uN4c=; b=UIpoDqva6+YnG2XEfOsCeNRujO3GlhLDB52WrJ4Pxdd3kZ0Z4lh5lxykQJoWPPRpHs ru4cNzag/hRkNZtanEo8dpGy/fV7u/PM6zX9ysT75183QXh16bw2jh9DOfDVGmg3w1Ul EgKIsQoiXq87E/CBDJyjw3sz3YRs2Nu+41rwqHiikv7HpH2QSzC7pBbyDaDfHrPymVma j2w2CWLCe+VyEUIqcMwCp1NaaXiVBsuq49Xw0Bsk/3PzktwiYpS8Ax5vNUCXvHvd2KzC vkmZO0beRwjc56HNHJGPeB3vXNXblsYtoUQGXapPuQvjMgGl1FLr8bHIdXx8Ld+i961q rSrA== X-Forwarded-Encrypted: i=1; AKwUvBwHZwhawqHVggh0hWBejETyrYlo5g9lkZUcL8OrjO8PT/lSa/bUvImP7viF46iK84xsBIXUw7WZjU43jGs=@vger.kernel.org X-Gm-Message-State: AFuF++luvXhbB1h4v9CNXWQUmdBUkm4CWJfJoK3Lt7Rn4AT8fvfk8CNA CPIBs60n7z/9wsREOoSy8vm/iiHZBG52BwdfBPX6sbB0Kj3tQwp6OA5a X-Gm-Gg: AYBFou3sFKyON+gSeHjXCOV0TbxhXkTIQl4zJgK7RHw09oU+nBnWU4FSHzdT0itMWeE M63dv0d8lQQS2DR18IP7DV6DZsNa68SjvBG+2d7eASTJ4//Q9e16fgryylSfRi5GA55iUvo/Thl c/ErFKpcXSMnldlCOVoLKjnserpbyMib9kQXkZO28/X1fpq2IbrQXFxBxHn77AOtpG99C1ir9Jd JnkKxc0jUPXmi/k+IS0fJbnlCYP1XTBAMFuxoVpQ9gt4o3NvlEgpgWrYiN6I69klpuQsw15/7HL NL7WCLRKraBJ58cIaWEVGSJNrkKOVD0guo0bE+m8mwN3/6Nb53+OJVH5ldypTSVri6p4kHgdZ2q K3C//8dLLRlbkvVDQ2nbmVyukba8txl3MeJf34u2gdfx/poPi7TopOTETzt8COC3+hj5jJeJr9s /Zy78t4Th1eE0N9gXqjfrsJJFChvtNg0FCksOeW/9CYARM71CVUfxE776WTa8gk5smZhQSzmahZ iovSt/663L/8KysL9YkfHLe X-Received: by 2002:a05:6000:38c:b0:484:3fce:6ad2 with SMTP id ffacd0b85a97d-485872cd602mr38412091f8f.15.1788946047859; Wed, 09 Sep 2026 02:27:27 -0700 (PDT) Received: from kali ([169.224.126.247]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-485883c074asm41558442f8f.23.2026.09.09.02.27.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Sep 2026 02:27:27 -0700 (PDT) From: Ali Firas 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, razor@blackwall.org, roopa@nvidia.com, linux-kernel@vger.kernel.org, Ali Firas Subject: [PATCH net 1/3] vxlan: vnifilter: limit the VNI range of a single request Date: Wed, 9 Sep 2026 12:26:43 +0300 Message-ID: <20260909092645.3105263-2-alishmery18@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260909092645.3105263-1-alishmery18@gmail.com> References: <20260907141001.GA708129@shredder> <20260909092645.3105263-1-alishmery18@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" VXLAN_VNIFILTER_ENTRY_START and VXLAN_VNIFILTER_ENTRY_END are parsed without any bound on how far apart they are, so a single RTM_NEWTUNNEL message can ask for the whole 24-bit VNI space. vxlan_vni_add_del() then loops over that span creating one VNI node and one per-CPU stats block per iteration, all under rtnl_lock. Two things follow from that, both reachable by an unprivileged user in a user+network namespace, since adding VNIs only requires CAP_NET_ADMIN in the network namespace's user namespace: - the allocation is unbounded. Each VNI costs 128 bytes of slab plus 64 bytes per possible CPU, so a full in-range request costs roughly 2.1 GiB + 1 GiB per possible CPU. Measured in a QEMU guest on 2, 4 and 8 CPU configurations, every one of them ends in a global OOM with the allocating task in vxlan_vnifilter_process(). No errno is returned because the calling process is itself OOM-killed, and the OOM killer also killed unrelated root-owned processes. - rtnl_lock is held for the entire loop. rtnl is global rather than per-netns, so unrelated network configuration blocks everywhere for as long as the request runs. Measured with a plain "ip link add dummy0 type dummy" in a different network namespace: it takes 0.011 s normally, 4.472 s while a 1,000,000 VNI request runs, and during a full-range request it never completes at all. Cap the span of one request at 4096 VNIs. The limit is on a single request, not on how many VNIs a device may hold: a device can still be populated with the whole VNI space, it just takes more than one message. The value follows from how the interface is used in practice, on bridged VXLAN devices where the VNI is derived from the VLAN and so cannot exceed the 4094 usable VLAN IDs. The limit is written as a driver-local constant rather than reusing VLAN_N_VID. The two numbers coincide today, but a bound on a VXLAN netlink request is not a count of VLAN IDs, and tying them together would make a change to one silently change the other. The check sits in vxlan_process_vni_filter(), where the span is known and before any VNI is created, so it rejects the request before any work is done. Both RTM_NEWTUNNEL and RTM_DELTUNNEL reach vxlan_vni_add_del() through this one function, so a single check covers add and delete. The span is inclusive, so START=3D0 END=3D4095 is 4096 VNIs and is accepted, while START=3D0 END=3D4096 is 4097 and is rejected. A request carrying only END has START default to 0 and is bounded the same way. A start above the end selects no VNI at all and is deliberately left behaving as it does today, rather than being turned into an error by unsigned wraparound. Fixes: f9c4bb0b245c ("vxlan: vni filtering support on collect metadata devi= ce") Assisted-by: LLM Signed-off-by: Ali Firas --- drivers/net/vxlan/vxlan_vnifilter.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/drivers/net/vxlan/vxlan_vnifilter.c b/drivers/net/vxlan/vxlan_= vnifilter.c index dd94085e0886..f18ce0e1e741 100644 --- a/drivers/net/vxlan/vxlan_vnifilter.c +++ b/drivers/net/vxlan/vxlan_vnifilter.c @@ -17,6 +17,14 @@ =20 #include "vxlan_private.h" =20 +/* Maximum number of VNIs a single RTM_NEWTUNNEL or RTM_DELTUNNEL request = may + * span. VNI filtering is mainly used on bridged VXLAN devices where the = VNI + * is derived from the VLAN, so a span wider than the VLAN ID space has no + * practical use, while an unbounded span lets one netlink message create = up + * to 2^24 VNIs under rtnl_lock. + */ +#define VXLAN_VNI_FILTER_RANGE_MAX 4096 + static inline int vxlan_vni_cmp(struct rhashtable_compare_arg *arg, const void *ptr) { @@ -869,6 +877,17 @@ static int vxlan_process_vni_filter(struct vxlan_dev *= vxlan, return -EINVAL; } =20 + /* Only bound a well-formed range; a start above the end selects no + * VNI at all and is left behaving as before. + */ + if (vni_end >=3D vni_start && + vni_end - vni_start >=3D VXLAN_VNI_FILTER_RANGE_MAX) { + NL_SET_ERR_MSG_ATTR_FMT(extack, nlvnifilter, + "VNI range spans more than %u VNIs", + VXLAN_VNI_FILTER_RANGE_MAX); + return -EINVAL; + } + if (vattrs[VXLAN_VNIFILTER_ENTRY_GROUP]) { group.sin.sin_addr.s_addr =3D nla_get_in_addr(vattrs[VXLAN_VNIFILTER_ENTRY_GROUP]); --=20 2.53.0 From nobody Fri Sep 25 19:19:17 2026 Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 00A4A3DDB01 for ; Wed, 9 Sep 2026 09:27:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.46 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788946057; cv=none; b=V/ljVDHniM9Gsf37qtzji2DaxMEEpq/bmkA3dUXgmOXflOpmwSB36+s9Y6sDrIMegDft/3VjvLZ28sDtrluKkHQ8TSWcf2tge6/kUxHhockM4QDM6/6AlGGb2ZUhNLq5f/u6aTJAvoAWsOvVB020n6xE+9xTA5SskDHX5jfe6wY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788946057; c=relaxed/simple; bh=XNWBIph23mlpOAwkrFz2gQLEt8XxytxPsdwjkMDBWDM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=WOaEceG6L2fKMV+ujb35t++YJ/2yZ9eSPx1HZbJMj95QiD4/ic5NM0Qb5K43mjwSd3wFo20BZSoACY0nBdrRAl3PaWNxzrI80ehy+CdhJN64k64p9tuJtFQd4IDncgi/vYizupNGAiArAAlFoSA6ZL7xPYAzrNXe7cBNdzjEDiQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=PLCQggOf; arc=none smtp.client-ip=209.85.221.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="PLCQggOf" Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-482ea739de2so3861141f8f.0 for ; Wed, 09 Sep 2026 02:27:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788946050; x=1789550850; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=oIc+krKzuLe553b8U04qr19znUhU0RNHQaKuS2T3NkA=; b=PLCQggOfmgyok7dQwxkG1j49UZthq2o8Ic6mSzEu3xonOQSv9xc6y5vpnNnjru49JV Y+Lex9sAbEMLxTCdlAgDXDwCifkeF1ix7wIDpnKdPva2XLvXd3kxq5kMwDIrwm7Laq65 DM4QcEY9hQa7Hnl+spthW1Ubj3LzQ0Pdkc5fF9ZY0533GFsHBWbwTGdF7nI7Xz+u6G1I DKNrVvYVikG5yighTN2Usli8wU+iQtZK/cdWWcc0AtnzbkOA0EENpZjByy/zFYLZdowo reqLdi0/8qqLxxP/9DHzaHVsxneAV5xQshiQkSoboNVhaqJ+tzaGlxneDvVhA/TF5Aw3 xFZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788946050; x=1789550850; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=oIc+krKzuLe553b8U04qr19znUhU0RNHQaKuS2T3NkA=; b=C0fI7N7MUEuWMNgEsej5MmgCdOO+TRAjnhHT4FcCSMrgZZAwq1/yW055kZoBzNuwWm F5WzAfKc5mfmoLpfiRiXAOad0UXRy0ePg+cq/d9rP8mO1v36mrjswFkAOTD+jMYhLqHt /LTz8C+VpMgOwQdvuLQ+Cc8O0vFJsXWymLEqdkt4Uh2J7a68QA1Vb/YYMuLLgvDq05qn Bbd5guaOpQ7iHJlnC26JJdd5287HADv0DL/XBNYZ3j47xXfy2bEz/i+rXXZZAMItVyy4 PY+d0tzhEwIBn1ZMkjEuEBuNHwQEP7FaQd/IAq9iM59z/EAk53PndHMWqIdaz8lfveMw MIrQ== X-Forwarded-Encrypted: i=1; AKwUvBzh3HQpPYxseIhbZKbEj2D53XyypLp4s2GtmJLZseH2H09khyKo5RLvnWjMAumN/ti4gZPEn1e69fB6vmA=@vger.kernel.org X-Gm-Message-State: AFuF++m7oSqdPK8WbkERio/eBL2xDKcYJUfzNL+7/6hPKPI7PHe5o73e D293fC8HE+kaXAWpmXcRTJ/U9Vs+dOv47aO6thUKU68ABfDIXPCDF84j X-Gm-Gg: AYBFou3SwNpWCkd2oZjZqC/aEGBLTffacApRko5TjoqMf5fvGS3y8COzd4XMyXeuI2u WaF5Ui27Kuq4JNvSp+CMN7IRXo72bo+mnSdInpUf6la/nnB4UkzhCDzmmNWrxJOesM0lhcdBsCA kHvUeSh+DkkmtNiwEK6P3i7Hqm+vSzoGqJ/bvKOqdvYKkg6nOMh17x9scmQktlBcA7wdso+vGth YkgWxdm8Yq9/681OLtJnK4mz6HgRYy+V/fPKc1wL4OMaRM/h3z6jZNaxM9E/nUIUevU2LsiD27q YLXY56Kn6e83u1Ig5SHBei2J7njBoiQr7TCMVUhsAwDeM49FDel63UBvzAa8pSuJI4ZwxjA14Gu bC0N4SfEY9YJfvL2adYexOzbnGs2csjXpjWiOI3IaWudCz1rck6xrXgORgSU1ah309zVGNpW2FE WhwI2qfl9cGu+ybBng7POp0+IEgm2hH9pEwgCbqA2Z9YFzliCI1y6Q8N08mcS4gy9Gqoz6BxNF7 +VSWQc9QOTgRgPa0IDv4LwDyt8Z56nJ4Ua2 X-Received: by 2002:a05:6000:18a9:b0:485:9211:6560 with SMTP id ffacd0b85a97d-485921165d7mr29788013f8f.25.1788946050163; Wed, 09 Sep 2026 02:27:30 -0700 (PDT) Received: from kali ([169.224.126.247]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-485883c074asm41558442f8f.23.2026.09.09.02.27.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Sep 2026 02:27:29 -0700 (PDT) From: Ali Firas 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, razor@blackwall.org, roopa@nvidia.com, linux-kernel@vger.kernel.org, Ali Firas Subject: [PATCH net 2/3] vxlan: vnifilter: account VNI node and per-CPU stats to memcg Date: Wed, 9 Sep 2026 12:26:44 +0300 Message-ID: <20260909092645.3105263-3-alishmery18@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260909092645.3105263-1-alishmery18@gmail.com> References: <20260907141001.GA708129@shredder> <20260909092645.3105263-1-alishmery18@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" vxlan_vni_alloc() allocates a struct vxlan_vni_node and a per-CPU stats block for every VNI, both with plain GFP_KERNEL. Neither carries __GFP_ACCOUNT, so the memory is not charged to the cgroup of the process that asked for it. With the range of a single request now capped, one message can no longer exhaust memory on its own. This is no longer the primary defence, but it still matters: nothing limits how many capped requests a task may issue, so an unprivileged user in a user+network namespace can still accumulate an arbitrary number of VNIs, 4096 at a time, and none of it is charged to them. Per VNI the add path allocates 128 bytes of slab, an exact fit in kmalloc-128 and measured at exactly 1.000 objects per VNI, plus 64 bytes per possible CPU for the stats block. The per-CPU term is the one that grows: 256 bytes per VNI on a 2-CPU host, but 4.2 KB per VNI on a 64-CPU one. Charging both allocations confines the damage to the caller's cgroup. The kill becomes CONSTRAINT_MEMCG with oom_memcg set to that cgroup, memory.stat attributes both the slab and the percpu bytes to it, and the host survives what previously took it down. One limitation is worth stating plainly: try_charge() reclaims and then invokes the memcg OOM killer rather than returning -ENOMEM, so the request does not fail gracefully, the caller is killed. Accounting confines the blast radius, it does not turn this into a clean error. For a caller not under a memcg limit there is no change. With no limit set, the same workload installs the same number of VNIs to within 0.4%, fails at the same point, and a bounded add of 1,000,000 VNIs costs an identical 128 bytes of slab and 64 bytes per CPU. The objects simply move from kmalloc-128 to kmalloc-cg-128. Conditions to recreate the bug: - CONFIG_VXLAN, CONFIG_MEMCG. - Unprivileged user in a fresh user+network namespace (unshare -Urn), or root with CAP_NET_ADMIN. - Create a vnifilter-enabled vxlan device and add VNIs in a loop (e.g. ip link add vx0 type vxlan external vnifilter dstport 4789, then repeated bridge vni add ... commands) while watching a memcg-limited cgroup: system slab and percpu grow far faster than memory.current, pinning kernel memory outside memcg charging. Fixes: f9c4bb0b245c ("vxlan: vni filtering support on collect metadata devi= ce") Assisted-by: LLM Signed-off-by: Ali Firas --- drivers/net/vxlan/vxlan_vnifilter.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/net/vxlan/vxlan_vnifilter.c b/drivers/net/vxlan/vxlan_= vnifilter.c index f18ce0e1e741..3d6718ec3f55 100644 --- a/drivers/net/vxlan/vxlan_vnifilter.c +++ b/drivers/net/vxlan/vxlan_vnifilter.c @@ -703,10 +703,11 @@ static struct vxlan_vni_node *vxlan_vni_alloc(struct = vxlan_dev *vxlan, { struct vxlan_vni_node *vninode; =20 - vninode =3D kzalloc_obj(*vninode); + vninode =3D kzalloc_obj(*vninode, GFP_KERNEL_ACCOUNT); if (!vninode) return NULL; - vninode->stats =3D netdev_alloc_pcpu_stats(struct vxlan_vni_stats_pcpu); + vninode->stats =3D __netdev_alloc_pcpu_stats(struct vxlan_vni_stats_pcpu, + GFP_KERNEL_ACCOUNT); if (!vninode->stats) { kfree(vninode); return NULL; --=20 2.53.0 From nobody Fri Sep 25 19:19:17 2026 Received: from mail-wm2-f12.google.com (mail-wm2-f12.google.com [74.125.225.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 251933DC4A4 for ; Wed, 9 Sep 2026 09:27:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.225.140 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788946062; cv=none; b=e0KCzs+x+oa5JXmWQYZ6MYPTLf+6Xq0cx7Huc2ime6V1tH+xGJOhp5BPlGL/WE5fbCMSZvYh8Bk1+KAAcsGORRAtnvjJ8DybVCmdz3odMASVGOZ4QCdzxFiema84i3FS2wXQAHgbwc8CHlA1jMfFd3mmOUTgnwsurgQZutOpDjk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788946062; c=relaxed/simple; bh=nhZxE20iqrNouy33myorDXb8+bwJsQJcZSRRuLIwtTU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Pt0Cqya3ihB6lJD4LDo0BBNSmuDW3T9xQFPa+9V6IG+ilOonqmwHrdnzPcrT6QTnAzcd0dWmm2orTzrAYhjd+ghgmpITY8yU+4Molb4OS2hsNlbMUP5Bum1107LZo9f2ZLkvjzxMOJa5nRrMoPqnHuZg2x0HRas0pUDiBufECh4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=XPZdYCDs; arc=none smtp.client-ip=74.125.225.140 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="XPZdYCDs" Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49d0e19300cso59385e9.1 for ; Wed, 09 Sep 2026 02:27:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788946053; x=1789550853; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=0ZOiWl3M7/VaLqAJX3bE5+mtA25D2TLANT8C6ELvR88=; b=XPZdYCDsa5YsWFLRV9Ffn/xSw14ylG5wQEmTox4o3XeHfjUVJc2d8KExxzMoOx8WiN 6I2kecAf1F/YA/TzIkQnBEHMCz9zcSF9HBzCZwzxwTcE0A6hAsAcxHdmnn8sjd3jBZyc Hc9zLMdMZqj9+cXZrzaPlzyzs/5lZxp+4bh5wvPqpibbcHtR57uj4W2SXzIwcdZ8CH+L KjOGG+hziNT5IB6WBppHiNBGWnho74oOfEY+RmMOgvVmEla3Y2L7CXCsBczvssWcCdSQ JQi6l/KQVl60ZqMWToRHXBSMlUQxsycEI0XFespaYTgkUPPwaZI5T8HGekV+FSBW3c1U oSRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788946053; x=1789550853; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=0ZOiWl3M7/VaLqAJX3bE5+mtA25D2TLANT8C6ELvR88=; b=ChBLshaVGXMKu/HUqNq9GmBKL49HSABzMsH/YsFsokdECJZa88lbFN9fVBktJY7IgM vTfTpIhnpTY7fg+9DdOzLBdJS89vpUa2O1UYvP1XXf9oEITevISgunJdqEKwd2pQQjQA T85xltFhSLX8gC8GiIQXhNPx4uz3XT9nYwRGKlNdaHRkLiMdXYIKwNmmzuGFrBl+OC+T luPd8yWeVJQWE8q0pBErx11EobIPigcFfGciIIax3CqStRKYmWEmXz89kErweJDbXiVt e7MgJX9iGlNvhyKT4QTYm9E5K4buoP+rddL/prynIUcNoPB87A75CHTNrBa8dpL6mHzc z7fA== X-Forwarded-Encrypted: i=1; AKwUvBzE67gEwUFnIfALDFaLZGczjL6qndz4kPZQzZWMATosw9mn1F0LqW9mMreaMYM6pt2ZM4tl+3AyiuYx0b4=@vger.kernel.org X-Gm-Message-State: AFuF++nMIHbNVVxuOENISXfFwfypGe187jj6OW3lee3XMkeFyaPivHYd pndEIRTIYYW2Xf/Ji/hi3CkuVS0v/3H+UOVKIihqRRICSPuhSZ7fDBaQ X-Gm-Gg: AYBFou3XWBJ2Y0t7n0OohDIq1JkrpDWVQzYcxU58KxJOl8b8Ghgnwsabb86Q9d5IS+X OGo3AkMyMMMzz7avlyG2boTHi7/QI8k0S1Tm6OEFd7PrRqoxcjFmV6/IB2stOyo/tZ72QKHcy1E +uKl+hL1yyUMrDAvFHepKZ4YCFUykJf8GkdYsnY7jJaTm8glvEVmradDOSHlgGnxbkgzjRV3qDR GY2nhvsJtoaXm8L2i51/NecBEKz1nxwaEXTCYyg3ddlSMdtie1Vs+6SMAWibYPmN2FKJOh+1940 SH1wTH18Ifnxsux55nQxIAmqGh8GRL/raSgkqyNYVuYsi2/yXnLK3WyuzuLnpFLDoc9lBsKBoId zwQFeail7B0K1giEZsgdqI/4Wl5eyxUzFv3Z28UJm+RVgvB+vMmf7afmaGK0jN/mvyIDhbEKrhR KFnxPca83QKbUvtMAAWBvrseOdLcGb3WnmLG+GsA6vkMzaUCvvxuYUeTssZ5las3TGYm6b7EPpi DVHjoxbtlMqS0rN960wbVHWog== X-Received: by 2002:a05:6000:2011:b0:485:9876:82b8 with SMTP id ffacd0b85a97d-485c2411beamr100636f8f.49.1788946052430; Wed, 09 Sep 2026 02:27:32 -0700 (PDT) Received: from kali ([169.224.126.247]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-485883c074asm41558442f8f.23.2026.09.09.02.27.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Sep 2026 02:27:32 -0700 (PDT) From: Ali Firas 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, razor@blackwall.org, roopa@nvidia.com, linux-kernel@vger.kernel.org, Ali Firas Subject: [PATCH net 3/3] selftests: net: test the vxlan vnifilter VNI range limit Date: Wed, 9 Sep 2026 12:26:45 +0300 Message-ID: <20260909092645.3105263-4-alishmery18@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260909092645.3105263-1-alishmery18@gmail.com> References: <20260907141001.GA708129@shredder> <20260909092645.3105263-1-alishmery18@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" A single RTM_NEWTUNNEL or RTM_DELTUNNEL request may span at most 4096 VNIs. Nothing covered the range functionality at all, so add the boundary cases to the existing API test: a range of exactly the maximum is accepted and one VNI more is rejected, for both add and delete. The range used sits above the VNIs the surrounding tests already install, so it does not disturb them. Assisted-by: LLM Signed-off-by: Ali Firas --- .../selftests/net/test_vxlan_vnifiltering.sh | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/tools/testing/selftests/net/test_vxlan_vnifiltering.sh b/tools= /testing/selftests/net/test_vxlan_vnifiltering.sh index 8deacc565afa..464ff353d6c0 100755 --- a/tools/testing/selftests/net/test_vxlan_vnifiltering.sh +++ b/tools/testing/selftests/net/test_vxlan_vnifiltering.sh @@ -371,6 +371,19 @@ vxlan_vnifilter_api() # change vxlan vnifilter flag run_cmd "ip -netns $testns link set dev vxlan-ext1 type vxlan external no= vnifilter" log_test $? 2 "Cannot unset vnifilter flag on a device" + + # a single request may span at most 4096 vnis + run_cmd "bridge -netns $testns vni add dev vxlan-ext1 vni 10000-14095" + log_test $? 0 "Add vni range of maximum size" + + run_cmd "bridge -netns $testns vni add dev vxlan-ext1 vni 10000-14096" + log_test $? 255 "Cannot add vni range larger than maximum" + + run_cmd "bridge -netns $testns vni del dev vxlan-ext1 vni 10000-14096" + log_test $? 255 "Cannot delete vni range larger than maximum" + + run_cmd "bridge -netns $testns vni del dev vxlan-ext1 vni 10000-14095" + log_test $? 0 "Delete vni range of maximum size" } =20 # Sanity test vnifilter datapath --=20 2.53.0