From: netdev-bot+sashiko@kernel.org
To: vikas.gupta@broadcom.com
Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, andrew+netdev@lunn.ch, horms@kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
bhargava.marreddy@broadcom.com, rahul-rg.gupta@broadcom.com,
vsrama-krishna.nemani@broadcom.com,
rajashekar.hudumula@broadcom.com, dharmender.garg@broadcom.com,
ajit.khaparde@broadcom.com
Subject: Re: [PATCH net-next v6 06/10] bnge: remove refcount from L2 filter
Date: Tue, 10 Nov 2026 16:19:16 +0000 [thread overview]
Message-ID: <179432755662.994134.8228412732049021470@kernel.org> (raw)
In-Reply-To: <20261106093524.838341-7-vikas.gupta@broadcom.com>
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 commit message says the patch only removes the L2 filter
refcount, but the patch also changes what bnge_alloc_l2_filter()…
--
bnge: remove refcount from L2 filter
This patch removes the refcount from struct bnge_l2_filter. From now on,
only the context that created a filter will delete it. The lookup helper
is folded into one function that asserts the netdev instance lock is
held, and bnge_alloc_l2_filter() now returns -EEXIST for a duplicate key.
> diff --git a/drivers/net/ethernet/broadcom/bnge/bnge_filter.c b/drivers/net/ethernet/broadcom/bnge/bnge_filter.c
> index a8bb441ebef9a..6316f75ca36ea 100644
> --- a/drivers/net/ethernet/broadcom/bnge/bnge_filter.c
> +++ b/drivers/net/ethernet/broadcom/bnge/bnge_filter.c
[ ... ]
> @@ -75,9 +63,10 @@ static struct bnge_l2_filter *bnge_alloc_l2_filter(struct bnge_net *bn,
>
> idx = jhash2(&key->filter_key, BNGE_L2_KEY_SIZE, bn->hash_seed) &
> BNGE_L2_FLTR_HASH_MASK;
> +
> fltr = bnge_lookup_l2_filter(bn, key, idx);
> if (fltr)
> - return fltr;
> + return ERR_PTR(-EEXIST);
[Severity: Low]
This changes what bnge_alloc_l2_filter() does, and the commit message
doesn't mention it. Could the changelog describe this?
Before this patch, a duplicate dst MAC/VLAN key returned the existing
filter with an extra reference, so the caller shared it. Now a duplicate
key is a hard error.
bnge_hwrm_set_vnic_filter() passes the error up to both of its callers.
In bnge_cfg_rx_mode() it gets treated like any other HWRM failure:
rc = bnge_hwrm_set_vnic_filter(bn, 0, i, vnic->uc_list + off);
if (rc) {
...
netdev_err(dev, "HWRM vnic filter failure rc: %d\n",
rc);
vnic->uc_filter_count = i;
return rc;
}
In bnge_init_chip() it would make open fail on the dev_addr filter.
As far as I can tell, nothing can request a duplicate key at this
commit:
- the unicast address list is already de-duplicated
- dev_addr is skipped when uc_list is filled
- there is no ndo_set_mac_address
- bnge_hwrm_clear_vnic_filter() removes every tracked filter on close
So this shouldn't change behaviour yet. A later patch in the series also
seems to depend on it on purpose, since it adds explicit -EEXIST handling
in bnge_cfg_rx_mode() for addresses "Already delivered by a user L2
rule".
The commit message only describes removing the refcount, though, so
could it also mention that duplicate keys now return -EEXIST instead of
being shared?
>
> fltr = kzalloc_obj(*fltr, gfp);
> if (!fltr)
[ ... ]
--
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261106093524.838341-1-vikas.gupta%40broadcom.com
next prev parent reply other threads:[~2026-11-10 16:19 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-06 9:35 [PATCH net-next v6 00/10] add features to bnge Vikas Gupta
2026-11-06 9:35 ` [PATCH net-next v6 01/10] bnge: restructure VNIC and filter code Vikas Gupta
2026-11-06 9:35 ` [PATCH net-next v6 02/10] bnge: add NTUPLE/ARFS VNIC Vikas Gupta
2026-11-10 16:19 ` netdev-bot+sashiko
2026-11-06 9:35 ` [PATCH net-next v6 03/10] bnge: add helper functions for multi RSS contexts Vikas Gupta
2026-11-06 9:35 ` [PATCH net-next v6 04/10] bnge: add RXFH ethtool support Vikas Gupta
2026-11-10 16:19 ` netdev-bot+sashiko
2026-11-06 9:35 ` [PATCH net-next v6 05/10] bnge: add ethtool support to manage RSS contexts Vikas Gupta
2026-11-10 16:19 ` netdev-bot+sashiko
2026-11-06 9:35 ` [PATCH net-next v6 06/10] bnge: remove refcount from L2 filter Vikas Gupta
2026-11-10 16:19 ` netdev-bot+sashiko [this message]
2026-11-06 9:35 ` [PATCH net-next v6 07/10] bnge: add NTUPLE filter infrastructure Vikas Gupta
2026-11-10 16:19 ` netdev-bot+sashiko
2026-11-06 9:35 ` [PATCH net-next v6 08/10] bnge: add NTUPLE filter support in ethtool Vikas Gupta
2026-11-10 16:19 ` netdev-bot+sashiko
2026-11-06 9:35 ` [PATCH net-next v6 09/10] bnge: add aRFS flow steering ndo support Vikas Gupta
2026-11-10 16:19 ` netdev-bot+sashiko
2026-11-06 9:35 ` [PATCH net-next v6 10/10] bnge: add cpu_rmap support for IRQ affinity Vikas Gupta
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=179432755662.994134.8228412732049021470@kernel.org \
--to=netdev-bot+sashiko@kernel.org \
--cc=ajit.khaparde@broadcom.com \
--cc=andrew+netdev@lunn.ch \
--cc=bhargava.marreddy@broadcom.com \
--cc=davem@davemloft.net \
--cc=dharmender.garg@broadcom.com \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rahul-rg.gupta@broadcom.com \
--cc=rajashekar.hudumula@broadcom.com \
--cc=vikas.gupta@broadcom.com \
--cc=vsrama-krishna.nemani@broadcom.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®