From: Vlad Yasevich <vyasevic@redhat.com>
To: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Cc: "David S . Miller" <davem@davemloft.net>,
Stephen Hemminger <stephen@networkplumber.org>,
netdev@vger.kernel.org
Subject: Re: [PATCH net v2 7/9] bridge: Properly check if local fdb entry can be deleted in br_fdb_delete_by_port
Date: Wed, 18 Dec 2013 12:50:28 -0500 [thread overview]
Message-ID: <52B1E064.5070107@redhat.com> (raw)
In-Reply-To: <1387333638.3563.22.camel@ubuntu-vm-makita>
On 12/17/2013 09:27 PM, Toshiaki Makita wrote:
> On Tue, 2013-12-17 at 14:12 -0500, Vlad Yasevich wrote:
>> On 12/17/2013 07:03 AM, Toshiaki Makita wrote:
>>> br_fdb_delete_by_port() doesn't care about vlan and mac address of the
>>> bridge device.
>>>
>>> As the check is almost the same as mac address changing, slightly modify
>>> fdb_delete_local() and use it.
>>>
>>> Note:
>>> - We change the dst of a local entry when the same address is found.
>>> This occurs in the case kernel has inserted the same address for another
>>> port but has failed due to dup. We can regard changing dst as deleting
>>> old one and inserting new one that should have been added by the dup
>>> port, so we can always set its added_by_user to 0 in fdb_delete_local().
>>
>> I disagree. What happens if the user tries add a duplicate fdb with
>> the local bit set?
>
> If the user add a dup local entry, the existent entry will be
> overwritten and its add_by_user is set to 1 (if !NLM_F_EXCL).
> The user never fails to add an entry due to dup in !NLM_F_EXCL case.
You are right. This is actually a very interesting situation. User may
over-write the current entry on add, but a delete will remove the entry
instead of restoring original configuration. I wonder if this was done
on purpose...
>
>> That is permitted and in fact a default because in
>> iproute right now. That fdb should persist until the port is removed or
>> user removes the fdb.
>>
>> added_by_user flag should only be changed in the netlink code since the
>> user has full control of it.
>
> Maybe my changelog is misleading.
>
> br_fdb_delete_by_port() calls fdb_delete_local() for local entries
> regardless of its added_by_user. In this case, we have to check if
> another port has the same address and vlan, and if found, we have to
> create the entry (by changing dst). This is kernel-added entry, not
> user-added.
>
> br_fdb_changeaddr()/nbp_vlan_delete() doesn't call fdb_delete_local()
> for user-added entry.
>
> So it is safe to set added_by_user to 0 in fdb_delete_local().
>
> will reword the changelog.
Ok. Thanks for clearing this up. Looking at patch 6 made it a bit
more clear. Yes, updating the changelog makes sense since I don't see
this patch introducing the the "change in behavior" you note in the
log.
-vlad
>
> Thanks,
> Toshiaki Makita
>
>
next prev parent reply other threads:[~2013-12-18 17:50 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
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 [this message]
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=52B1E064.5070107@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 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.