From: Ido Schimmel <idosch@nvidia.com>
To: "Hans J. Schultz" <netdev@kapio-technology.com>
Cc: davem@davemloft.net, kuba@kernel.org, netdev@vger.kernel.org,
Florian Fainelli <f.fainelli@gmail.com>,
Andrew Lunn <andrew@lunn.ch>,
Vivien Didelot <vivien.didelot@gmail.com>,
Vladimir Oltean <olteanv@gmail.com>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>,
Kurt Kanzenbach <kurt@linutronix.de>,
Hauke Mehrtens <hauke@hauke-m.de>,
Woojung Huh <woojung.huh@microchip.com>,
UNGLinuxDriver@microchip.com, Sean Wang <sean.wang@mediatek.com>,
Landen Chao <Landen.Chao@mediatek.com>,
DENG Qingfang <dqfext@gmail.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
Claudiu Manoil <claudiu.manoil@nxp.com>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
Jiri Pirko <jiri@resnulli.us>, Ivan Vecera <ivecera@redhat.com>,
Roopa Prabhu <roopa@nvidia.com>,
Nikolay Aleksandrov <razor@blackwall.org>,
Shuah Khan <shuah@kernel.org>,
Russell King <linux@armlinux.org.uk>,
Christian Marangi <ansuelsmth@gmail.com>,
Daniel Borkmann <daniel@iogearbox.net>,
Yuwei Wang <wangyuweihx@gmail.com>,
Petr Machata <petrm@nvidia.com>,
Florent Fourcot <florent.fourcot@wifirst.fr>,
Hans Schultz <schultz.hans@gmail.com>,
Joachim Wiberg <troglobit@gmail.com>,
Amit Cohen <amcohen@nvidia.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org,
bridge@lists.linux-foundation.org,
linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v7 net-next 2/9] net: bridge: add blackhole fdb entry flag
Date: Thu, 13 Oct 2022 16:29:42 +0300 [thread overview]
Message-ID: <Y0gSxhIEQD9BC/SE@shredder> (raw)
In-Reply-To: <20221009174052.1927483-3-netdev@kapio-technology.com>
On Sun, Oct 09, 2022 at 07:40:45PM +0200, Hans J. Schultz wrote:
> @@ -1018,8 +1020,9 @@ static bool fdb_handle_notify(struct net_bridge_fdb_entry *fdb, u8 notify)
> /* Update (create or replace) forwarding database entry */
> static int fdb_add_entry(struct net_bridge *br, struct net_bridge_port *source,
> const u8 *addr, struct ndmsg *ndm, u16 flags, u16 vid,
> - struct nlattr *nfea_tb[])
> + u32 ext_flags, struct nlattr *nfea_tb[])
> {
> + bool blackhole = !!(ext_flags & NTF_EXT_BLACKHOLE);
> bool is_sticky = !!(ndm->ndm_flags & NTF_STICKY);
> bool refresh = !nfea_tb[NFEA_DONT_REFRESH];
> struct net_bridge_fdb_entry *fdb;
> @@ -1092,6 +1095,14 @@ static int fdb_add_entry(struct net_bridge *br, struct net_bridge_port *source,
> modified = true;
> }
>
> + if (blackhole != test_bit(BR_FDB_BLACKHOLE, &fdb->flags)) {
> + change_bit(BR_FDB_BLACKHOLE, &fdb->flags);
> + modified = true;
> + }
> +
> + if (blackhole)
> + set_bit(BR_FDB_LOCAL, &fdb->flags);
We should instead validate earlier that NTF_EXT_BLACKHOLE is only
specified with NUD_PERMANENT. See more below.
> +
> if (test_and_clear_bit(BR_FDB_LOCKED, &fdb->flags))
> modified = true;
>
> @@ -1113,7 +1124,7 @@ static int fdb_add_entry(struct net_bridge *br, struct net_bridge_port *source,
> static int __br_fdb_add(struct ndmsg *ndm, struct net_bridge *br,
> struct net_bridge_port *p, const unsigned char *addr,
> u16 nlh_flags, u16 vid, struct nlattr *nfea_tb[],
> - struct netlink_ext_ack *extack)
> + u32 ext_flags, struct netlink_ext_ack *extack)
> {
> int err = 0;
>
> @@ -1138,9 +1149,12 @@ static int __br_fdb_add(struct ndmsg *ndm, struct net_bridge *br,
> return -EINVAL;
> }
> err = br_fdb_external_learn_add(br, p, addr, vid, true);
> + } else if ((ext_flags & NTF_EXT_BLACKHOLE) && p) {
> + NL_SET_ERR_MSG_MOD(extack, "Blackhole FDB entry cannot be applied on a port");
> + return -EINVAL;
This is too late. I can do:
# bridge fdb add 00:aa:bb:cc:dd:ee dev dummy1 master extern_learn blackhole
# bridge fdb get 00:aa:bb:cc:dd:ee br br0
00:aa:bb:cc:dd:ee dev dummy1 extern_learn master br0
Nothing will explode, but it's not ideal either.
Since we force blackhole entries to be permanent they cannot be aged by
the kernel. I'm not sure what is the use case for user space adding
externally learned blackhole entries.
How about:
diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
index d6f22e2e018a..9257a46544dd 100644
--- a/net/bridge/br_fdb.c
+++ b/net/bridge/br_fdb.c
@@ -1100,9 +1100,6 @@ static int fdb_add_entry(struct net_bridge *br, struct net_bridge_port *source,
modified = true;
}
- if (blackhole)
- set_bit(BR_FDB_LOCAL, &fdb->flags);
-
if (test_and_clear_bit(BR_FDB_LOCKED, &fdb->flags))
modified = true;
@@ -1149,9 +1146,6 @@ static int __br_fdb_add(struct ndmsg *ndm, struct net_bridge *br,
return -EINVAL;
}
err = br_fdb_external_learn_add(br, p, addr, vid, false, false, false, true);
- } else if ((ext_flags & NTF_EXT_BLACKHOLE) && p) {
- NL_SET_ERR_MSG_MOD(extack, "Blackhole FDB entry cannot be applied on a port");
- return -EINVAL;
} else {
spin_lock_bh(&br->hash_lock);
err = fdb_add_entry(br, p, addr, ndm, nlh_flags, vid, ext_flags, nfea_tb);
@@ -1214,6 +1208,21 @@ int br_fdb_add(struct ndmsg *ndm, struct nlattr *tb[],
return -EINVAL;
}
+ if (ext_flags & NTF_EXT_BLACKHOLE) {
+ if (!(ndm->ndm_state & NUD_PERMANENT)) {
+ NL_SET_ERR_MSG_MOD(extack, "Blackhole FDB entry must be permanent");
+ return -EINVAL;
+ }
+ if (p) {
+ NL_SET_ERR_MSG_MOD(extack, "Blackhole FDB entry cannot be applied on a port");
+ return -EINVAL;
+ }
+ if (ndm->ndm_flags & NTF_EXT_LEARNED) {
+ NL_SET_ERR_MSG_MOD(extack, "Blackhole FDB entry cannot be added as externally learned");
+ return -EINVAL;
+ }
+ }
+
if (tb[NDA_FDB_EXT_ATTRS]) {
attr = tb[NDA_FDB_EXT_ATTRS];
err = nla_parse_nested(nfea_tb, NFEA_MAX, attr,
With which I get:
# bridge fdb add 00:aa:bb:cc:dd:ee dev dummy1 master extern_learn blackhole
Error: bridge: Blackhole FDB entry cannot be applied on a port.
# bridge fdb add 00:aa:bb:cc:dd:ee dev br0 self extern_learn blackhole
Error: bridge: Blackhole FDB entry cannot be added as externally learned.
> } else {
> spin_lock_bh(&br->hash_lock);
> - err = fdb_add_entry(br, p, addr, ndm, nlh_flags, vid, nfea_tb);
> + err = fdb_add_entry(br, p, addr, ndm, nlh_flags, vid, ext_flags, nfea_tb);
> spin_unlock_bh(&br->hash_lock);
> }
>
> @@ -1219,10 +1233,10 @@ int br_fdb_add(struct ndmsg *ndm, struct nlattr *tb[],
>
> /* VID was specified, so use it. */
> err = __br_fdb_add(ndm, br, p, addr, nlh_flags, vid, nfea_tb,
> - extack);
> + ext_flags, extack);
> } else {
> err = __br_fdb_add(ndm, br, p, addr, nlh_flags, 0, nfea_tb,
> - extack);
> + ext_flags, extack);
> if (err || !vg || !vg->num_vlans)
> goto out;
>
> @@ -1234,7 +1248,7 @@ int br_fdb_add(struct ndmsg *ndm, struct nlattr *tb[],
> if (!br_vlan_should_use(v))
> continue;
> err = __br_fdb_add(ndm, br, p, addr, nlh_flags, v->vid,
> - nfea_tb, extack);
> + nfea_tb, ext_flags, extack);
> if (err)
> goto out;
> }
> diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
> index 068fced7693c..665d1d6bdc75 100644
> --- a/net/bridge/br_input.c
> +++ b/net/bridge/br_input.c
> @@ -193,8 +193,11 @@ int br_handle_frame_finish(struct net *net, struct sock *sk, struct sk_buff *skb
> if (dst) {
> unsigned long now = jiffies;
>
> - if (test_bit(BR_FDB_LOCAL, &dst->flags))
> + if (test_bit(BR_FDB_LOCAL, &dst->flags)) {
> + if (unlikely(test_bit(BR_FDB_BLACKHOLE, &dst->flags)))
> + goto drop;
> return br_pass_frame_up(skb);
> + }
>
> if (now != dst->used)
> dst->used = now;
> diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
> index 4ce8b8e5ae0b..e7a08657c7ed 100644
> --- a/net/bridge/br_private.h
> +++ b/net/bridge/br_private.h
> @@ -253,6 +253,7 @@ enum {
> BR_FDB_NOTIFY,
> BR_FDB_NOTIFY_INACTIVE,
> BR_FDB_LOCKED,
> + BR_FDB_BLACKHOLE,
> };
>
> struct net_bridge_fdb_key {
> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> index 8008ceb45605..ae641dfea5f2 100644
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -4054,7 +4054,7 @@ int ndo_dflt_fdb_add(struct ndmsg *ndm,
> if (tb[NDA_FLAGS_EXT])
> ext_flags = nla_get_u32(tb[NDA_FLAGS_EXT]);
>
> - if (ext_flags & NTF_EXT_LOCKED) {
> + if (ext_flags & (NTF_EXT_LOCKED | NTF_EXT_BLACKHOLE)) {
> netdev_info(dev, "invalid flags given to default FDB implementation\n");
> return err;
> }
> --
> 2.34.1
>
next prev parent reply other threads:[~2022-10-13 13:29 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-09 17:40 [PATCH v7 net-next 0/9] Extend locked port feature with FDB locked flag (MAC-Auth/MAB) Hans J. Schultz
2022-10-09 17:40 ` [PATCH v7 net-next 1/9] net: bridge: add locked entry fdb flag to extend locked port feature Hans J. Schultz
2022-10-13 12:41 ` Ido Schimmel
2022-10-09 17:40 ` [PATCH v7 net-next 2/9] net: bridge: add blackhole fdb entry flag Hans J. Schultz
2022-10-13 13:29 ` Ido Schimmel [this message]
2022-10-09 17:40 ` [PATCH v7 net-next 3/9] net: switchdev: add support for offloading of the FDB locked flag Hans J. Schultz
2022-10-13 14:06 ` Ido Schimmel
2022-10-13 18:58 ` netdev
2022-10-18 6:22 ` Ido Schimmel
2022-10-18 13:47 ` netdev
2022-10-18 14:29 ` netdev
2022-10-09 17:40 ` [PATCH v7 net-next 4/9] net: switchdev: support offloading of the FDB blackhole flag Hans J. Schultz
2022-10-13 14:21 ` Ido Schimmel
2022-10-09 17:40 ` [PATCH v7 net-next 5/9] drivers: net: dsa: add fdb entry flags to drivers Hans J. Schultz
2022-10-09 17:40 ` [PATCH v7 net-next 6/9] net: dsa: mv88e6xxx: allow reading FID when handling ATU violations Hans J. Schultz
2022-10-09 17:40 ` [PATCH v7 net-next 7/9] net: dsa: mv88e6xxx: mac-auth/MAB implementation Hans J. Schultz
2022-10-09 17:40 ` [PATCH v7 net-next 8/9] net: dsa: mv88e6xxx: add blackhole ATU entries Hans J. Schultz
2022-10-09 17:40 ` [PATCH v7 net-next 9/9] selftests: forwarding: add test of MAC-Auth Bypass to locked port tests Hans J. Schultz
2022-10-12 9:46 ` netdev
2022-10-13 14:28 ` Ido Schimmel
2022-10-13 15:17 ` netdev
2022-10-13 18:13 ` Ido Schimmel
2022-10-13 12:06 ` Ido Schimmel
2022-10-13 12:16 ` Ido Schimmel
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=Y0gSxhIEQD9BC/SE@shredder \
--to=idosch@nvidia.com \
--cc=Landen.Chao@mediatek.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=alexandre.belloni@bootlin.com \
--cc=amcohen@nvidia.com \
--cc=andrew@lunn.ch \
--cc=ansuelsmth@gmail.com \
--cc=bridge@lists.linux-foundation.org \
--cc=claudiu.manoil@nxp.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=dqfext@gmail.com \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=florent.fourcot@wifirst.fr \
--cc=hauke@hauke-m.de \
--cc=ivecera@redhat.com \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=kurt@linutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=matthias.bgg@gmail.com \
--cc=netdev@kapio-technology.com \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
--cc=petrm@nvidia.com \
--cc=razor@blackwall.org \
--cc=roopa@nvidia.com \
--cc=schultz.hans@gmail.com \
--cc=sean.wang@mediatek.com \
--cc=shuah@kernel.org \
--cc=troglobit@gmail.com \
--cc=vivien.didelot@gmail.com \
--cc=wangyuweihx@gmail.com \
--cc=woojung.huh@microchip.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