From nobody Thu Oct 2 03:27:41 2025 Received: from forwardcorp1d.mail.yandex.net (forwardcorp1d.mail.yandex.net [178.154.239.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7806F1F91E3; Mon, 22 Sep 2025 19:48:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=178.154.239.200 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758570539; cv=none; b=Gl9CrNv6bG6y9/2OyZSdA3gv/BYTPAZn70bnAdte7iJ5nHE1Ur3alASIS3daj3hwiPa8ehAjVfWCLk7zHYwRi9kziVFUD9pwQ+VrPQIhrYbH55jtt054/LP7DuTtf939Lipd/GZND8T4788fFbEGctN3QxYOlyJhSlZuX5O8btc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758570539; c=relaxed/simple; bh=PU/XANUrK9hEk6kA9sjjUVfSRU1bJZRYU/1EfwVatis=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=plCUCsmgPS6/4dXBAaRYTPxbEY7hxrUhJLRu5P4eoueWVDzSUPZvwUin+LdNNFkil2djxf7NaIgXRCHx27A707GHvJPWae4sfnSoi2R2Y7+mOZ5WtcaGMWqf0x7yzT96NVSG4cwsJdZMgsCOAypPN3xfSPZN+8Riq40yDt6T2jA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=yandex-team.ru; spf=pass smtp.mailfrom=yandex-team.ru; dkim=pass (1024-bit key) header.d=yandex-team.ru header.i=@yandex-team.ru header.b=CcO0io4Z; arc=none smtp.client-ip=178.154.239.200 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=yandex-team.ru Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=yandex-team.ru Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=yandex-team.ru header.i=@yandex-team.ru header.b="CcO0io4Z" Received: from mail-nwsmtp-smtp-corp-main-80.iva.yp-c.yandex.net (mail-nwsmtp-smtp-corp-main-80.iva.yp-c.yandex.net [IPv6:2a02:6b8:c0c:1621:0:640:12d9:0]) by forwardcorp1d.mail.yandex.net (Yandex) with ESMTPS id 16CC681063; Mon, 22 Sep 2025 22:48:46 +0300 (MSK) Received: from d-tatianin-lin.yandex-team.ru (unknown [2a02:6bf:8080:c27::1:3a]) by mail-nwsmtp-smtp-corp-main-80.iva.yp-c.yandex.net (smtpcorp/Yandex) with ESMTPSA id TmcMU33Goa60-MnWz3v3K; Mon, 22 Sep 2025 22:48:45 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1758570525; bh=8znYj7PjmcES13vpMIwZBkpiyRK8HzACSb8RD6m3aD4=; h=Message-Id:Date:In-Reply-To:Cc:Subject:References:To:From; b=CcO0io4Zc9m2ZHccdeCYz6KJ0EhiS4maKBRJJMVHSWljMajloRT8N5R/ClHaiV4AV 1+V1EeV0OER9kNTiJlhOPDOk/2zvvlbi2RxgjJS0Y8AcMVLdgG9m6NmqcR+RGmozLi wMQk8BLKLUWJN289u6aYC0asOmMxWaFq06hNubw0= Authentication-Results: mail-nwsmtp-smtp-corp-main-80.iva.yp-c.yandex.net; dkim=pass header.i=@yandex-team.ru From: Daniil Tatianin To: Pablo Neira Ayuso Cc: Daniil Tatianin , Jozsef Kadlecsik , Florian Westphal , Phil Sutter , "David S. Miller" , David Ahern , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , netfilter-devel@vger.kernel.org, coreteam@netfilter.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org Subject: [PATCH 1/3] netfilter/x_tables: go back to using vmalloc for xt_table_info Date: Mon, 22 Sep 2025 22:48:17 +0300 Message-Id: <20250922194819.182809-2-d-tatianin@yandex-team.ru> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20250922194819.182809-1-d-tatianin@yandex-team.ru> References: <20250922194819.182809-1-d-tatianin@yandex-team.ru> 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" This code previously always used vmalloc for anything above PAGE_ALLOC_COSTLY_ORDER, but this logic was changed in commit eacd86ca3b036 ("net/netfilter/x_tables.c: use kvmalloc() in xt_alloc= _table_info()"). The commit that changed it did so because "xt_alloc_table_info() basically opencodes kvmalloc()", which is not actually what it was doing. kvmalloc() does not attempt to go directly to vmalloc if the order the caller is trying to allocate is "expensive", instead it only uses vmalloc as a fallback in case the buddy allocator is not able to fullfill the request. The difference between the two is actually huge in case the system is under memory pressure and has no free pages of a large order. Before the change to kvmalloc we wouldn't even try going to the buddy allocator for large orders, but now we would force it to try to find a page of the required order by waking up kswapd/kcompactd and dropping reclaimable memory for no reason at all to satisfy our huge order allocation that could easily exist within vmalloc'ed memory instead. Revert the change to always call vmalloc, since this code doesn't really benefit from contiguous physical memory, and the size it allocates is directly dictated by the userspace-passed table buffer thus allowing it to torture the buddy allocator by carefully crafting a huge table that fits right at the maximum available memory order on the system. Signed-off-by: Daniil Tatianin --- net/netfilter/x_tables.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c index 90b7630421c4..c98f4b05d79d 100644 --- a/net/netfilter/x_tables.c +++ b/net/netfilter/x_tables.c @@ -1190,7 +1190,7 @@ struct xt_table_info *xt_alloc_table_info(unsigned in= t size) if (sz < sizeof(*info) || sz >=3D XT_MAX_TABLE_SIZE) return NULL; =20 - info =3D kvmalloc(sz, GFP_KERNEL_ACCOUNT); + info =3D __vmalloc(sz, GFP_KERNEL_ACCOUNT); if (!info) return NULL; =20 @@ -1210,7 +1210,7 @@ void xt_free_table_info(struct xt_table_info *info) kvfree(info->jumpstack); } =20 - kvfree(info); + vfree(info); } EXPORT_SYMBOL(xt_free_table_info); =20 --=20 2.34.1 From nobody Thu Oct 2 03:27:41 2025 Received: from forwardcorp1b.mail.yandex.net (forwardcorp1b.mail.yandex.net [178.154.239.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 887692F5302; Mon, 22 Sep 2025 19:50:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=178.154.239.136 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758570655; cv=none; b=H5jWK7gMv7WsB41KGRNbiIW6yXsd4cP5oljPbFShgga5Dyc02miV39s1nRvsvRNvAWzuJnUPHYIeDcaUtrsbjo5vcxgm3QozKSKLlu5+AWKBIZmf6vgK5tahPGCY53avKkalLEgRX8XXYPS/Q+KuTWLUFvBKVerph+4N9vGrd2s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758570655; c=relaxed/simple; bh=yqlA7vId+ku0OBurzmpSjN8elYoe+QUjP5XjIjEne1s=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=dDwJ3Tgr+A5rlbUYqf+TxqyWtKzDtcpDXyzj1CegS/KTWeXIjWErQMSXdxIQbFcEsljSKHPMHB1/B0O1hha5t+hD30Pf3cXJ3fKBeQsVx8yj0eS0CAQ9xHQwhin1btiUPWdB62PUzlcvtpzqFQLEftgI59nPnXxC7dOc2J/qhfI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=yandex-team.ru; spf=pass smtp.mailfrom=yandex-team.ru; dkim=pass (1024-bit key) header.d=yandex-team.ru header.i=@yandex-team.ru header.b=VOEC33sv; arc=none smtp.client-ip=178.154.239.136 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=yandex-team.ru Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=yandex-team.ru Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=yandex-team.ru header.i=@yandex-team.ru header.b="VOEC33sv" Received: from mail-nwsmtp-smtp-corp-main-80.iva.yp-c.yandex.net (mail-nwsmtp-smtp-corp-main-80.iva.yp-c.yandex.net [IPv6:2a02:6b8:c0c:1621:0:640:12d9:0]) by forwardcorp1b.mail.yandex.net (Yandex) with ESMTPS id 91AF788577; Mon, 22 Sep 2025 22:48:48 +0300 (MSK) Received: from d-tatianin-lin.yandex-team.ru (unknown [2a02:6bf:8080:c27::1:3a]) by mail-nwsmtp-smtp-corp-main-80.iva.yp-c.yandex.net (smtpcorp/Yandex) with ESMTPSA id TmcMU33Goa60-762HOt5G; Mon, 22 Sep 2025 22:48:47 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1758570527; bh=2QbQZ3xXww2zGM5XlqT0lRHZgoIfQAqx/2r0Ht+KoMI=; h=Message-Id:Date:In-Reply-To:Cc:Subject:References:To:From; b=VOEC33svWQgdO8JChu4rQmiwTOFSqRlqqXQkt5qrJTQtx9ILIHk6SFhOBLi73VlsH 9TP2DzEvdLj+5pVaIe1xnz8VXrbXxpNneJe62CZArbIhbHPWrIhFHoxDyO/j6Mu9qp 2qRLbM81vH9NWtxRmlB17dNYGJjEj609HaayXuPc= Authentication-Results: mail-nwsmtp-smtp-corp-main-80.iva.yp-c.yandex.net; dkim=pass header.i=@yandex-team.ru From: Daniil Tatianin To: Pablo Neira Ayuso Cc: Daniil Tatianin , Jozsef Kadlecsik , Florian Westphal , Phil Sutter , "David S. Miller" , David Ahern , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , netfilter-devel@vger.kernel.org, coreteam@netfilter.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org Subject: [PATCH 2/3] netfilter/x_tables: introduce a helper for freeing entry offsets Date: Mon, 22 Sep 2025 22:48:18 +0300 Message-Id: <20250922194819.182809-3-d-tatianin@yandex-team.ru> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20250922194819.182809-1-d-tatianin@yandex-team.ru> References: <20250922194819.182809-1-d-tatianin@yandex-team.ru> 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" Analogous to xt_free_table_info, add a helper so that the users of xt_alloc_entry_offsets don't have to assume the way the array was allocated. This also allows us to cleanly change how the array is allocated internally in the following commit. Signed-off-by: Daniil Tatianin --- include/linux/netfilter/x_tables.h | 1 + net/ipv4/netfilter/arp_tables.c | 4 ++-- net/ipv4/netfilter/ip_tables.c | 4 ++-- net/ipv6/netfilter/ip6_tables.c | 4 ++-- net/netfilter/x_tables.c | 6 ++++++ 5 files changed, 13 insertions(+), 6 deletions(-) diff --git a/include/linux/netfilter/x_tables.h b/include/linux/netfilter/x= _tables.h index 77c778d84d4c..f695230eb89c 100644 --- a/include/linux/netfilter/x_tables.h +++ b/include/linux/netfilter/x_tables.h @@ -274,6 +274,7 @@ int xt_check_entry_offsets(const void *base, const char= *elems, int xt_check_table_hooks(const struct xt_table_info *info, unsigned int va= lid_hooks); =20 unsigned int *xt_alloc_entry_offsets(unsigned int size); +void xt_free_entry_offsets(unsigned int *offsets); bool xt_find_jump_offset(const unsigned int *offsets, unsigned int target, unsigned int size); =20 diff --git a/net/ipv4/netfilter/arp_tables.c b/net/ipv4/netfilter/arp_table= s.c index 1cdd9c28ab2d..bc164c2e22b0 100644 --- a/net/ipv4/netfilter/arp_tables.c +++ b/net/ipv4/netfilter/arp_tables.c @@ -570,7 +570,7 @@ static int translate_table(struct net *net, ret =3D -ELOOP; goto out_free; } - kvfree(offsets); + xt_free_entry_offsets(offsets); =20 /* Finally, each sanity check must pass */ i =3D 0; @@ -593,7 +593,7 @@ static int translate_table(struct net *net, =20 return ret; out_free: - kvfree(offsets); + xt_free_entry_offsets(offsets); return ret; } =20 diff --git a/net/ipv4/netfilter/ip_tables.c b/net/ipv4/netfilter/ip_tables.c index 23c8deff8095..1ffd871456e1 100644 --- a/net/ipv4/netfilter/ip_tables.c +++ b/net/ipv4/netfilter/ip_tables.c @@ -708,7 +708,7 @@ translate_table(struct net *net, struct xt_table_info *= newinfo, void *entry0, ret =3D -ELOOP; goto out_free; } - kvfree(offsets); + xt_free_entry_offsets(offsets); =20 /* Finally, each sanity check must pass */ i =3D 0; @@ -731,7 +731,7 @@ translate_table(struct net *net, struct xt_table_info *= newinfo, void *entry0, =20 return ret; out_free: - kvfree(offsets); + xt_free_entry_offsets(offsets); return ret; } =20 diff --git a/net/ipv6/netfilter/ip6_tables.c b/net/ipv6/netfilter/ip6_table= s.c index d585ac3c1113..0f2999155bde 100644 --- a/net/ipv6/netfilter/ip6_tables.c +++ b/net/ipv6/netfilter/ip6_tables.c @@ -725,7 +725,7 @@ translate_table(struct net *net, struct xt_table_info *= newinfo, void *entry0, ret =3D -ELOOP; goto out_free; } - kvfree(offsets); + xt_free_entry_offsets(offsets); =20 /* Finally, each sanity check must pass */ i =3D 0; @@ -748,7 +748,7 @@ translate_table(struct net *net, struct xt_table_info *= newinfo, void *entry0, =20 return ret; out_free: - kvfree(offsets); + xt_free_entry_offsets(offsets); return ret; } =20 diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c index c98f4b05d79d..5ea95c56f3a0 100644 --- a/net/netfilter/x_tables.c +++ b/net/netfilter/x_tables.c @@ -970,6 +970,12 @@ unsigned int *xt_alloc_entry_offsets(unsigned int size) } EXPORT_SYMBOL(xt_alloc_entry_offsets); =20 +void xt_free_entry_offsets(unsigned int *offsets) +{ + kvfree(offsets); +} +EXPORT_SYMBOL(xt_free_entry_offsets); + /** * xt_find_jump_offset - check if target is a valid jump offset * --=20 2.34.1 From nobody Thu Oct 2 03:27:41 2025 Received: from forwardcorp1b.mail.yandex.net (forwardcorp1b.mail.yandex.net [178.154.239.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 02CD32F3613; Mon, 22 Sep 2025 19:50:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=178.154.239.136 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758570654; cv=none; b=Swe9YzyF9Cbrg38irtk+c6u8mMddjCfytgIn1IwAM71gHq94042/VMQcuVj2NvKSAGI8uxJOPOo9MN+mGcSzGcTbCfxQJlTagg6kHvMYwugkCBzjGbeEC8aHBHMO227JDEUnhQzuRRCVcviNOn65SLT1elGs7xgJphJ6Z5o4C9k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758570654; c=relaxed/simple; bh=IIuaOrz0FC8chHu7ILOxwOJmM63B00UIluxC+65xLfE=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=hBSLZ8JW3CFbZKON2lv4mC1JhyQGf4aXyo6ncq9VVgBQl9OxKLAvcK1QtzpeBbB7WRy8LSNw7ty4+ZRpF4cwezSg5dMEh5vY5/BFu6raQxhMqY6i3SNgV+iCS3MCqGGpSIIZy3cSjwZlxCkjhB5rWC25dMsOGJ5jIClfjJPOTTs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=yandex-team.ru; spf=pass smtp.mailfrom=yandex-team.ru; dkim=pass (1024-bit key) header.d=yandex-team.ru header.i=@yandex-team.ru header.b=WCMIMWJL; arc=none smtp.client-ip=178.154.239.136 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=yandex-team.ru Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=yandex-team.ru Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=yandex-team.ru header.i=@yandex-team.ru header.b="WCMIMWJL" Received: from mail-nwsmtp-smtp-corp-main-80.iva.yp-c.yandex.net (mail-nwsmtp-smtp-corp-main-80.iva.yp-c.yandex.net [IPv6:2a02:6b8:c0c:1621:0:640:12d9:0]) by forwardcorp1b.mail.yandex.net (Yandex) with ESMTPS id 3AEF38857E; Mon, 22 Sep 2025 22:48:50 +0300 (MSK) Received: from d-tatianin-lin.yandex-team.ru (unknown [2a02:6bf:8080:c27::1:3a]) by mail-nwsmtp-smtp-corp-main-80.iva.yp-c.yandex.net (smtpcorp/Yandex) with ESMTPSA id TmcMU33Goa60-srwXviqN; Mon, 22 Sep 2025 22:48:49 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1758570529; bh=ERVn3lgtdd/+G0FxLqF0rVkFcod05w/PTMcT604L6DQ=; h=Message-Id:Date:In-Reply-To:Cc:Subject:References:To:From; b=WCMIMWJLK29lv+34fERZqiPcN8jMoaVD5duMuwNGl67OsGtHqshss3ZBAX6zH/05o nRe81/EuqTq7c+j8DEpkwW72OoodgboTm5Q79VMTViL2V6JsDOIo+Wghy99L2Uz6AQ /oOlDd+uouw26fNMQcOI1i6imguTvqZWRKzrSD0o= Authentication-Results: mail-nwsmtp-smtp-corp-main-80.iva.yp-c.yandex.net; dkim=pass header.i=@yandex-team.ru From: Daniil Tatianin To: Pablo Neira Ayuso Cc: Daniil Tatianin , Jozsef Kadlecsik , Florian Westphal , Phil Sutter , "David S. Miller" , David Ahern , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , netfilter-devel@vger.kernel.org, coreteam@netfilter.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org Subject: [PATCH 3/3] netfilter/x_tables: allocate entry_offsets with vcalloc Date: Mon, 22 Sep 2025 22:48:19 +0300 Message-Id: <20250922194819.182809-4-d-tatianin@yandex-team.ru> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20250922194819.182809-1-d-tatianin@yandex-team.ru> References: <20250922194819.182809-1-d-tatianin@yandex-team.ru> 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" This allocation does not benefit from contiguous physical memory, and its size depends on userspace input. No reason to stress the buddy allocator and thus the entire system for allocations that can exist in vmalloc'ed memory just fine. Signed-off-by: Daniil Tatianin --- net/netfilter/x_tables.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c index 5ea95c56f3a0..06a86648b931 100644 --- a/net/netfilter/x_tables.c +++ b/net/netfilter/x_tables.c @@ -965,14 +965,14 @@ unsigned int *xt_alloc_entry_offsets(unsigned int siz= e) if (size > XT_MAX_TABLE_SIZE / sizeof(unsigned int)) return NULL; =20 - return kvcalloc(size, sizeof(unsigned int), GFP_KERNEL); + return __vcalloc(size, sizeof(unsigned int), GFP_KERNEL); =20 } EXPORT_SYMBOL(xt_alloc_entry_offsets); =20 void xt_free_entry_offsets(unsigned int *offsets) { - kvfree(offsets); + vfree(offsets); } EXPORT_SYMBOL(xt_free_entry_offsets); =20 --=20 2.34.1