From: Ido Schimmel <idosch@nvidia.com>
To: Nikolay Aleksandrov <razor@blackwall.org>
Cc: Jonas Gorski <jonas.gorski@bisdn.de>,
Roopa Prabhu <roopa@nvidia.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Petr Machata <petrm@mellanox.com>,
Ido Schimmel <idosch@mellanox.com>,
bridge@lists.linux.dev, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net] net: bridge: allow users setting EXT_LEARN for user FDB entries
Date: Sun, 1 Sep 2024 14:54:40 +0300 [thread overview]
Message-ID: <ZtRWACsOAnha75Ef@shredder.mtl.com> (raw)
In-Reply-To: <b0544c31-cf64-41c7-8118-a8b504a982d1@blackwall.org>
On Sat, Aug 31, 2024 at 11:31:50AM +0300, Nikolay Aleksandrov wrote:
> On 30/08/2024 17:53, Jonas Gorski wrote:
> > When userspace wants to take over a fdb entry by setting it as
> > EXTERN_LEARNED, we set both flags BR_FDB_ADDED_BY_EXT_LEARN and
> > BR_FDB_ADDED_BY_USER in br_fdb_external_learn_add().
> >
> > If the bridge updates the entry later because its port changed, we clear
> > the BR_FDB_ADDED_BY_EXT_LEARN flag, but leave the BR_FDB_ADDED_BY_USER
> > flag set.
> >
> > If userspace then wants to take over the entry again,
> > br_fdb_external_learn_add() sees that BR_FDB_ADDED_BY_USER and skips
> > setting the BR_FDB_ADDED_BY_EXT_LEARN flags, thus silently ignores the
> > update:
> >
> > if (test_bit(BR_FDB_ADDED_BY_EXT_LEARN, &fdb->flags)) {
> > /* Refresh entry */
> > fdb->used = jiffies;
> > } else if (!test_bit(BR_FDB_ADDED_BY_USER, &fdb->flags)) {
> > /* Take over SW learned entry */
> > set_bit(BR_FDB_ADDED_BY_EXT_LEARN, &fdb->flags);
> > modified = true;
> > }
> >
> > Fix this by relaxing the condition for setting BR_FDB_ADDED_BY_EXT_LEARN
> > by also allowing it if swdev_notify is true, which it will only be for
> > user initiated updates.
> >
> > Fixes: 710ae7287737 ("net: bridge: Mark FDB entries that were added by user as such")
> > Signed-off-by: Jonas Gorski <jonas.gorski@bisdn.de>
> > ---
> > net/bridge/br_fdb.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
> > index c77591e63841..c5d9ae13a6fb 100644
> > --- a/net/bridge/br_fdb.c
> > +++ b/net/bridge/br_fdb.c
> > @@ -1472,7 +1472,8 @@ int br_fdb_external_learn_add(struct net_bridge *br, struct net_bridge_port *p,
> > if (test_bit(BR_FDB_ADDED_BY_EXT_LEARN, &fdb->flags)) {
> > /* Refresh entry */
> > fdb->used = jiffies;
> > - } else if (!test_bit(BR_FDB_ADDED_BY_USER, &fdb->flags)) {
> > + } else if (swdev_notify ||
> > + !test_bit(BR_FDB_ADDED_BY_USER, &fdb->flags)) {
> > /* Take over SW learned entry */
> > set_bit(BR_FDB_ADDED_BY_EXT_LEARN, &fdb->flags);
> > modified = true;
>
> This literally means if added_by_user || !added_by_user, so you can probably
> rewrite that whole block to be more straight-forward with test_and_set_bit -
> if it was already set then refresh, if it wasn't modified = true
Hi Nik,
You mean like this [1]?
I deleted the comment about "SW learned entry" since "extern_learn" flag
not being set does not necessarily mean the entry was learned by SW.
[1]
diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
index c77591e63841..ad7a42b505ef 100644
--- a/net/bridge/br_fdb.c
+++ b/net/bridge/br_fdb.c
@@ -1469,12 +1469,10 @@ int br_fdb_external_learn_add(struct net_bridge *br, struct net_bridge_port *p,
modified = true;
}
- if (test_bit(BR_FDB_ADDED_BY_EXT_LEARN, &fdb->flags)) {
+ if (test_and_set_bit(BR_FDB_ADDED_BY_EXT_LEARN, &fdb->flags)) {
/* Refresh entry */
fdb->used = jiffies;
- } else if (!test_bit(BR_FDB_ADDED_BY_USER, &fdb->flags)) {
- /* Take over SW learned entry */
- set_bit(BR_FDB_ADDED_BY_EXT_LEARN, &fdb->flags);
+ } else {
modified = true;
}
next prev parent reply other threads:[~2024-09-01 11:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-30 14:53 [PATCH net] net: bridge: allow users setting EXT_LEARN for user FDB entries Jonas Gorski
2024-08-31 8:31 ` Nikolay Aleksandrov
2024-09-01 11:54 ` Ido Schimmel [this message]
2024-09-01 12:25 ` Nikolay Aleksandrov
2024-09-02 7:34 ` Jonas Gorski
2024-09-02 14:59 ` Ido Schimmel
2024-09-03 7:27 ` Nikolay Aleksandrov
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=ZtRWACsOAnha75Ef@shredder.mtl.com \
--to=idosch@nvidia.com \
--cc=bridge@lists.linux.dev \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=idosch@mellanox.com \
--cc=jonas.gorski@bisdn.de \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=petrm@mellanox.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.