From: Ido Schimmel <idosch@nvidia.com>
To: Cheng Yongkang <teel4res@gmail.com>
Cc: Nikolay Aleksandrov <razor@blackwall.org>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@kernel.org>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
bridge@lists.linux.dev, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net] net: bridge: mcast: validate the source limit before replace
Date: Thu, 29 Oct 2026 23:06:48 +0200 [thread overview]
Message-ID: <20261029210648.GA1492006@shredder> (raw)
In-Reply-To: <179328314075.648427.9644307795980106759@gmail.com>
On Thu, Oct 29, 2026 at 07:12:20AM -0700, Cheng Yongkang wrote:
> br_mdb_replace_group_srcs() marks every existing source for deletion and
> then re-adds the sources named by the NLM_F_REPLACE request. The add loop
> checks PG_SRC_ENT_LIMIT before allocating each new source; if the
> transient source count reaches the limit, br_mdb_add_group_srcs() unwinds
> by deleting every source it processed, including the pre-existing sources
> it just refreshed. The error path only clears BR_SGRP_F_DELETE and
> cannot restore those sources or their (S,G) entries.
>
> A replace with E existing sources and N distinct request sources not
> already in the group fails at the limit if and only if E + N exceeds
> PG_SRC_ENT_LIMIT. The rejected request currently leaves the group with
> one fewer source and removes that source's (S,G) entry:
>
> before: (*,G) star_srcs=31, S present, (S,G) present
> after rejected replace: star_srcs=30, S and (S,G) removed
>
> Count those new sources and reject the request with -ENOSPC before any
> source is marked deleted or added, so a rejected replace changes no
> state. Valid replaces, including ones that transiently reach the limit,
> keep the same behavior. Other add-loop failure paths are unchanged.
>
> Fixes: 61f2183512a7 ("bridge: mcast: Support replacement of MDB port group entries")
> Cc: stable@vger.kernel.org
> Assisted-by: LLM
> Signed-off-by: Cheng Yongkang <teel4res@gmail.com>
> ---
> net/bridge/br_mdb.c | 51 ++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 50 insertions(+), 1 deletion(-)
I'm not going to review this. You already sent a bridge patch [1], which
I reviewed, asked for changes and you didn't follow up. I can only
assume that the same will happen here. I'm reacting this way because
this pattern is not unique to you (see my reply in [1], for example) and
I'm tired of it. Get a patch merged, then continue to the next one.
Also, AFAICT, this patch doesn't fix a regression (never worked) or a
security issue, so should be targeted at net-next which is currently
closed [2].
[1] https://lore.kernel.org/netdev/179268538303.70821.8213834342995341232@gmail.com/
[2] https://netdev.bots.linux.dev/net-next.html
prev parent reply other threads:[~2026-10-29 21:07 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-29 14:12 [PATCH net] net: bridge: mcast: validate the source limit before replace Cheng Yongkang
2026-10-29 21:06 ` Ido Schimmel [this message]
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=20261029210648.GA1492006@shredder \
--to=idosch@nvidia.com \
--cc=bridge@lists.linux.dev \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=razor@blackwall.org \
--cc=teel4res@gmail.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.