From: Vlad Yasevich <vyasevic@redhat.com>
To: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>,
"David S . Miller" <davem@davemloft.net>,
Stephen Hemminger <stephen@networkplumber.org>,
netdev@vger.kernel.org
Subject: Re: [PATCH net v2 1/9] bridge: Fix the way to find old local fdb entries in br_fdb_changeaddr
Date: Fri, 03 Jan 2014 15:46:04 -0500 [thread overview]
Message-ID: <52C7218C.2000205@redhat.com> (raw)
In-Reply-To: <52C70F63.4020604@redhat.com>
On 01/03/2014 02:28 PM, Vlad Yasevich wrote:
> On 12/17/2013 07:03 AM, Toshiaki Makita wrote:
>> br_fdb_changeaddr() assumes that there is at most one local entry per port
>> per vlan. It used to be true, but since commit 36fd2b63e3b4 ("bridge: allow
>> creating/deleting fdb entries via netlink"), it has not been so.
>> Therefore, the function might fail to search a correct previous address
>> to be deleted and delete an arbitrary local entry if user has added local
>> entries manually.
>>
>> Example of problematic case:
>> ip link set eth0 address ee:ff:12:34:56:78
>> brctl addif br0 eth0
>> bridge fdb add 12:34:56:78:90:ab dev eth0 master
>> ip link set eth0 address aa:bb:cc:dd:ee:ff
>> Then, the address 12:34:56:78:90:ab might be deleted instead of
>> ee:ff:12:34:56:78, the original mac address of eth0.
>>
>> Address this issue by introducing a new flag, added_by_user, to struct
>> net_bridge_fdb_entry.
>>
>> Note that br_fdb_delete_by_port() has to set added_by_user to 0 in case
>> like:
>> ip link set eth0 address 12:34:56:78:90:ab
>> ip link set eth1 address aa:bb:cc:dd:ee:ff
>> brctl addif br0 eth0
>> bridge fdb add aa:bb:cc:dd:ee:ff dev eth0 master
>> brctl addif br0 eth1
>> brctl delif br0 eth0
>> In this case, kernel should delete the user-added entry aa:bb:cc:dd:ee:ff,
>> but it also should have been added by "brctl addif br0 eth1" originally,
>> so we don't delete it and treat it a new kernel-created entry.
>>
>
> I was looking over my patch series that adds something similar to this
> and noticed that you are not handing the NTF_USE case. That case was
> always troublesome for me as it allows for 2 different way to create
> the same FDB: one through br_fdb_update() and one through fdb_add_entry().
>
> It is possible, though I haven't found any users yet, that NTF_USE
> may be used and in that case, bridge will create a dynamic fdb and
> disregard all NUD flags. In case case, add_by_user will not be set
> either.
>
> I think that the above is broken and plan to submit a fix shortly.
Just looked again at my NTF_USE patch and while it seems ok, the whole
NTF_USE usage is racy to begin with and I am really starting to question
it's validity.
Presently, br_fdb_update() will not update local fdb entries. Instead
it will log a misleading warning... It will only let you update
non-local entries. This is fine for user-created entries, but any
operation on dynamically created entries will only persist until
the next packet. It also races against the packet, so there is
absolutely no guarantee that the values of fdb->dst and fdb->updated
will be consistent..
It seems to me that the update capability of NTF_USE would actually be
of more value on local or user-created fdb entries.
The fdb creation capability of NTF_USE should be disabled.
Thoughts?
-vlad
>
> Thanks
> -vlad
>
>> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>> ---
>> net/bridge/br_fdb.c | 5 ++++-
>> net/bridge/br_private.h | 1 +
>> 2 files changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
>> index 33e8f23..5dab230 100644
>> --- a/net/bridge/br_fdb.c
>> +++ b/net/bridge/br_fdb.c
>> @@ -104,7 +104,7 @@ void br_fdb_changeaddr(struct net_bridge_port *p, const unsigned char *newaddr)
>> struct net_bridge_fdb_entry *f;
>>
>> f = hlist_entry(h, struct net_bridge_fdb_entry, hlist);
>> - if (f->dst == p && f->is_local) {
>> + if (f->dst == p && f->is_local && !f->added_by_user) {
>> /* maybe another port has same hw addr? */
>> struct net_bridge_port *op;
>> u16 vid = f->vlan_id;
>> @@ -247,6 +247,7 @@ void br_fdb_delete_by_port(struct net_bridge *br,
>> ether_addr_equal(op->dev->dev_addr,
>> f->addr.addr)) {
>> f->dst = op;
>> + f->added_by_user = 0;
>> goto skip_delete;
>> }
>> }
>> @@ -397,6 +398,7 @@ static struct net_bridge_fdb_entry *fdb_create(struct hlist_head *head,
>> fdb->vlan_id = vid;
>> fdb->is_local = 0;
>> fdb->is_static = 0;
>> + fdb->added_by_user = 0;
>> fdb->updated = fdb->used = jiffies;
>> hlist_add_head_rcu(&fdb->hlist, head);
>> }
>> @@ -648,6 +650,7 @@ static int fdb_add_entry(struct net_bridge_port *source, const __u8 *addr,
>>
>> modified = true;
>> }
>> + fdb->added_by_user = 1;
>>
>> fdb->used = jiffies;
>> if (modified) {
>> diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
>> index 045d56e..91fb2c2 100644
>> --- a/net/bridge/br_private.h
>> +++ b/net/bridge/br_private.h
>> @@ -104,6 +104,7 @@ struct net_bridge_fdb_entry
>> mac_addr addr;
>> unsigned char is_local;
>> unsigned char is_static;
>> + unsigned char added_by_user;
>> __u16 vlan_id;
>> };
>>
>>
>
next prev parent reply other threads:[~2014-01-03 20:46 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-17 12:03 [PATCH net v2 0/9] bridge: Fix corner case problems around local fdb entries Toshiaki Makita
2013-12-17 12:03 ` [PATCH net v2 1/9] bridge: Fix the way to find old local fdb entries in br_fdb_changeaddr Toshiaki Makita
2013-12-17 15:49 ` Vlad Yasevich
2014-01-03 19:28 ` Vlad Yasevich
2014-01-03 20:46 ` Vlad Yasevich [this message]
2014-01-05 15:26 ` Toshiaki Makita
2014-01-06 11:29 ` Vlad Yasevich
2014-01-07 12:42 ` Toshiaki Makita
2014-01-07 14:44 ` Vlad Yasevich
2014-01-07 16:33 ` Toshiaki Makita
2014-01-07 17:45 ` Vlad Yasevich
2014-01-08 6:02 ` Toshiaki Makita
2013-12-17 12:03 ` [PATCH net v2 2/9] bridge: Fix the way to insert new " Toshiaki Makita
2013-12-17 16:00 ` Vlad Yasevich
2013-12-17 12:03 ` [PATCH net v2 3/9] bridge: Fix the way to find old local fdb entries in br_fdb_change_mac_address Toshiaki Makita
2013-12-17 16:01 ` Vlad Yasevich
2013-12-17 12:03 ` [PATCH net v2 4/9] bridge: Change local fdb entries whenever mac address of bridge device changes Toshiaki Makita
2013-12-17 16:22 ` Vlad Yasevich
2013-12-17 18:45 ` Vlad Yasevich
2013-12-17 12:03 ` [PATCH net v2 5/9] bridge: Fix the way to check if a local fdb entry can be deleted Toshiaki Makita
2013-12-17 18:53 ` Vlad Yasevich
2013-12-18 4:46 ` Toshiaki Makita
2013-12-18 17:22 ` Vlad Yasevich
2013-12-18 18:04 ` Stephen Hemminger
2013-12-19 12:23 ` Toshiaki Makita
2013-12-19 17:39 ` Stephen Hemminger
2013-12-20 8:02 ` Toshiaki Makita
2014-01-30 12:50 ` Toshiaki Makita
2013-12-17 12:03 ` [PATCH net v2 6/9] bridge: Properly check if local fdb entry can be deleted in br_fdb_change_mac_address Toshiaki Makita
2013-12-17 19:00 ` Vlad Yasevich
2013-12-17 19:27 ` Vlad Yasevich
2013-12-17 12:03 ` [PATCH net v2 7/9] bridge: Properly check if local fdb entry can be deleted in br_fdb_delete_by_port Toshiaki Makita
2013-12-17 19:12 ` Vlad Yasevich
2013-12-18 2:27 ` Toshiaki Makita
2013-12-18 17:50 ` Vlad Yasevich
2013-12-19 12:33 ` Toshiaki Makita
2013-12-17 12:03 ` [PATCH net v2 8/9] bridge: Properly check if local fdb entry can be deleted when deleting vlan Toshiaki Makita
2013-12-17 19:34 ` Vlad Yasevich
2013-12-18 2:55 ` Toshiaki Makita
2013-12-17 12:03 ` [PATCH net v2 9/9] bridge: Prevent possible race condition in br_fdb_change_mac_address Toshiaki Makita
2013-12-17 19:39 ` Vlad Yasevich
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=52C7218C.2000205@redhat.com \
--to=vyasevic@redhat.com \
--cc=davem@davemloft.net \
--cc=makita.toshiaki@lab.ntt.co.jp \
--cc=netdev@vger.kernel.org \
--cc=stephen@networkplumber.org \
/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;
as well as URLs for NNTP newsgroup(s).