* [PATCH] Notify userspace about bridge learning MAC on new port
@ 2013-04-15 10:29 ` michael-dev
0 siblings, 0 replies; 4+ messages in thread
From: michael-dev @ 2013-04-15 10:29 UTC (permalink / raw)
To: stephen; +Cc: davem, netdev, bridge, linux-kernel, projekt-wlan
[-- Attachment #1: Type: text/plain, Size: 491 bytes --]
Hi,
currently, the userspace is informed about the port the MAC is learned
on a bridge and about the bridge removing the MAC from its forwarding
table, but not when the MAC is learned on a different port. This is
inconsistent and makes it difficult for applications to keep track of
all MACs learned by a bridge on a subset of its ports.
Please find attached a patch that fixes this by sending an RTM_NEWNEIGH
message when the forwarding destination port changes.
Regards,
M. Braun
[-- Attachment #2: 999-make-bridge-notify-switched-port.diff --]
[-- Type: text/plain, Size: 1213 bytes --]
Notify userspace about bridge learning MAC on new port
Currently, the userspace is informed about the port the MAC is learned on a
bridge and about the bridge removing the MAC from its forwarding table, but not
when the MAC is learned on a different port.
This is inconsistent and makes it difficult for applications to keep track
of all MACs learned by a bridge on a subset of its ports.
Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
--- a/net/bridge/br_fdb.c 2013-04-15 11:21:51.638963668 +0200
+++ b/net/bridge/br_fdb.c 2013-04-15 11:23:55.941166319 +0200
@@ -408,6 +408,7 @@ static int fdb_insert(struct net_bridge
{
struct hlist_head *head = &br->hash[br_mac_hash(addr, vid)];
struct net_bridge_fdb_entry *fdb;
+ struct net_bridge_port *origsrc;
if (!is_valid_ether_addr(addr))
return -EINVAL;
@@ -471,8 +472,12 @@ void br_fdb_update(struct net_bridge *br
source->dev->name);
} else {
/* fastpath: update of existing entry */
+ origsrc = fdb->dst;
fdb->dst = source;
fdb->updated = jiffies;
+ /* notify applications of modified slave device */
+ if (origsrc != source)
+ fdb_notify(br, fdb, RTM_NEWNEIGH);
}
} else {
spin_lock(&br->hash_lock);
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bridge] [PATCH] Notify userspace about bridge learning MAC on new port
@ 2013-04-15 10:29 ` michael-dev
0 siblings, 0 replies; 4+ messages in thread
From: michael-dev @ 2013-04-15 10:29 UTC (permalink / raw)
To: stephen; +Cc: projekt-wlan, netdev, bridge, davem, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 491 bytes --]
Hi,
currently, the userspace is informed about the port the MAC is learned
on a bridge and about the bridge removing the MAC from its forwarding
table, but not when the MAC is learned on a different port. This is
inconsistent and makes it difficult for applications to keep track of
all MACs learned by a bridge on a subset of its ports.
Please find attached a patch that fixes this by sending an RTM_NEWNEIGH
message when the forwarding destination port changes.
Regards,
M. Braun
[-- Attachment #2: 999-make-bridge-notify-switched-port.diff --]
[-- Type: text/plain, Size: 1213 bytes --]
Notify userspace about bridge learning MAC on new port
Currently, the userspace is informed about the port the MAC is learned on a
bridge and about the bridge removing the MAC from its forwarding table, but not
when the MAC is learned on a different port.
This is inconsistent and makes it difficult for applications to keep track
of all MACs learned by a bridge on a subset of its ports.
Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
--- a/net/bridge/br_fdb.c 2013-04-15 11:21:51.638963668 +0200
+++ b/net/bridge/br_fdb.c 2013-04-15 11:23:55.941166319 +0200
@@ -408,6 +408,7 @@ static int fdb_insert(struct net_bridge
{
struct hlist_head *head = &br->hash[br_mac_hash(addr, vid)];
struct net_bridge_fdb_entry *fdb;
+ struct net_bridge_port *origsrc;
if (!is_valid_ether_addr(addr))
return -EINVAL;
@@ -471,8 +472,12 @@ void br_fdb_update(struct net_bridge *br
source->dev->name);
} else {
/* fastpath: update of existing entry */
+ origsrc = fdb->dst;
fdb->dst = source;
fdb->updated = jiffies;
+ /* notify applications of modified slave device */
+ if (origsrc != source)
+ fdb_notify(br, fdb, RTM_NEWNEIGH);
}
} else {
spin_lock(&br->hash_lock);
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] Notify userspace about bridge learning MAC on new port
2014-03-12 13:14 Michael Braun
@ 2014-03-18 1:50 ` David Miller
0 siblings, 0 replies; 4+ messages in thread
From: David Miller @ 2014-03-18 1:50 UTC (permalink / raw)
To: michael-dev; +Cc: stephen, netdev, bridge
From: Michael Braun <michael-dev@fami-braun.de>
Date: Wed, 12 Mar 2014 14:14:56 +0100
> Currently, the userspace is informed about the port the MAC is learned on a
> bridge and about the bridge removing the MAC from its forwarding table, but not
> when the MAC is learned on a different port.
> This is inconsistent and makes it difficult for applications to keep track
> of all MACs learned by a bridge on a subset of its ports.
>
> Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
> Acked-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Please use a proper subsystem prefix in your Subject lines, for
example:
"Subject: [PATCH] bridge: Notify userspace about learning MAC on new port"
Would have been more appropriate here.
Stephen, can you review the substance of this patch please?
^ permalink raw reply [flat|nested] 4+ messages in thread
* [PATCH] Notify userspace about bridge learning MAC on new port
@ 2014-03-12 13:14 Michael Braun
2014-03-18 1:50 ` David Miller
0 siblings, 1 reply; 4+ messages in thread
From: Michael Braun @ 2014-03-12 13:14 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, bridge, Michael Braun
Currently, the userspace is informed about the port the MAC is learned on a
bridge and about the bridge removing the MAC from its forwarding table, but not
when the MAC is learned on a different port.
This is inconsistent and makes it difficult for applications to keep track
of all MACs learned by a bridge on a subset of its ports.
Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
Acked-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Cc: <bridge@lists.linux-foundation.org>
Cc: <netdev@vger.kernel.org>
---
net/bridge/br_fdb.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
index 9203d5a..25a7772 100644
--- a/net/bridge/br_fdb.c
+++ b/net/bridge/br_fdb.c
@@ -487,6 +487,7 @@ void br_fdb_update(struct net_bridge *br, struct net_bridge_port *source,
{
struct hlist_head *head = &br->hash[br_mac_hash(addr, vid)];
struct net_bridge_fdb_entry *fdb;
+ struct net_bridge_port *origsrc;
/* some users want to always flood. */
if (hold_time(br) == 0)
@@ -507,10 +508,14 @@ void br_fdb_update(struct net_bridge *br, struct net_bridge_port *source,
source->dev->name);
} else {
/* fastpath: update of existing entry */
+ origsrc = fdb->dst;
fdb->dst = source;
fdb->updated = jiffies;
if (unlikely(added_by_user))
fdb->added_by_user = 1;
+ /* notify applications of modified slave device */
+ if (origsrc != source)
+ fdb_notify(br, fdb, RTM_NEWNEIGH);
}
} else {
spin_lock(&br->hash_lock);
--
1.8.3.2
^ permalink raw reply related [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-03-18 1:50 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-04-15 10:29 [PATCH] Notify userspace about bridge learning MAC on new port michael-dev
2013-04-15 10:29 ` [Bridge] " michael-dev
2014-03-12 13:14 Michael Braun
2014-03-18 1:50 ` David Miller
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.