All of lore.kernel.org
 help / color / mirror / Atom feed
From: netdev-bot+sashiko@kernel.org
To: alishmery18@gmail.com
Cc: netdev@vger.kernel.org, idosch@nvidia.com, 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, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next v2 4/5] vxlan: vnifilter: account the VNI node to memcg
Date: Sat, 19 Sep 2026 00:21:33 +0000	[thread overview]
Message-ID: <178977729399.22033.3228962563095615567@kernel.org> (raw)
In-Reply-To: <20260916193449.2552039-5-alishmery18@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider:

Critical: 0 · High: 0 · Medium: 0 · Low: 1

- [Low] Missing Fixes: tag — the concern asserts that because the patch
  corrects observable memory-controller behavior for a long-lived per-…

--

vxlan: vnifilter: account the VNI node to memcg

This switches the struct vxlan_vni_node allocation in vxlan_vni_alloc()
from plain GFP_KERNEL to GFP_KERNEL_ACCOUNT, so the per-VNI node is
charged to the caller's cgroup like the per-CPU stats block that follows
it.

Link: https://lore.kernel.org/netdev/20260909092645.3105263-1-alishmery18@gmail.com/

> diff --git a/drivers/net/vxlan/vxlan_vnifilter.c b/drivers/net/vxlan/vxlan_vnifilter.c
> index 9a1baca39d8b0..fbff52c450c07 100644
> --- a/drivers/net/vxlan/vxlan_vnifilter.c
> +++ b/drivers/net/vxlan/vxlan_vnifilter.c
> @@ -710,7 +710,7 @@ static struct vxlan_vni_node *vxlan_vni_alloc(struct vxlan_dev *vxlan,
>  {
>  	struct vxlan_vni_node *vninode;
>  
> -	vninode = kzalloc_obj(*vninode);
> +	vninode = kzalloc_obj(*vninode, GFP_KERNEL_ACCOUNT);

[Severity: Low]
This isn't a bug, but one review pass suggested this change in
vxlan_vni_alloc() should carry:

  Fixes: f9c4bb0b245c ("vxlan: vni filtering support on collect metadata device")

on the grounds that it changes observable memory-controller behaviour for a
long-lived per-VNI allocation.

Is a Fixes tag wanted here?  The comparable precedent, commit c948f51c1654
("memcg: enable accounting for net_device and Tx/Rx queues"), added
GFP_KERNEL_ACCOUNT to the netdev allocations this builds on and carries no
Fixes tag, and the sibling patch accounting the per-CPU netdev stats in this
series does not carry one either.

There is also a behavioural side to it: with GFP_KERNEL_ACCOUNT, VNI
creation that previously succeeded can now return -ENOMEM once the calling
cgroup hits its limit, which may not be desirable to backport to stable.

>  	if (!vninode)
>  		return NULL;
>  	vninode->stats = netdev_alloc_pcpu_stats(struct vxlan_vni_stats_pcpu);

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

  reply	other threads:[~2026-09-19  0:21 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-16 19:34 [PATCH net-next v2 0/5] vxlan: vnifilter: bound one request and account per-VNI memory Ali Firas
2026-09-16 19:34 ` [PATCH net-next v2 1/5] vxlan: vnifilter: reject VNIs outside the 24-bit space Ali Firas
2026-09-19  0:21   ` netdev-bot+sashiko
2026-09-21 22:09     ` Jakub Kicinski
2026-09-16 19:34 ` [PATCH net-next v2 2/5] vxlan: vnifilter: bound the number of VNIs one request may touch Ali Firas
2026-09-19  0:21   ` netdev-bot+sashiko
2026-09-16 19:34 ` [PATCH net-next v2 3/5] net: account per-CPU netdev stats to memcg Ali Firas
2026-09-19  0:21   ` netdev-bot+sashiko
2026-09-16 19:34 ` [PATCH net-next v2 4/5] vxlan: vnifilter: account the VNI node " Ali Firas
2026-09-19  0:21   ` netdev-bot+sashiko [this message]
2026-09-16 19:34 ` [PATCH net-next v2 5/5] selftests: net: test the vxlan vnifilter VNI limit Ali Firas
2026-09-19  0:21   ` 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=178977729399.22033.3228962563095615567@kernel.org \
    --to=netdev-bot+sashiko@kernel.org \
    --cc=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=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=razor@blackwall.org \
    --cc=roopa@nvidia.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.