From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cumulusnetworks.com; s=google; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-transfer-encoding; bh=EHJqPuYPWxlRCG4NKp13KAOTgd/Q+j9Naghg4fWQOok=; b=O/frdXV9y8Y6JjG+3pbJSFqIMNw+l1L31+vheaA45QiSPwwEvE+c6vVWekMFFrKo44 Iuo9TPgLlYuexRyzRNSif9ei7STLx6xSkB/gx9NrE9FLgE6mqjiHO1boJz6dTHbemJAx GuKEiGHmv5ljUq917u0wT4r+TGUAwJxStwn7o= Message-ID: <57A3890D.9010809@cumulusnetworks.com> Date: Thu, 04 Aug 2016 11:27:25 -0700 From: Roopa Prabhu MIME-Version: 1.0 References: <1470276679-5533-1-git-send-email-makita.toshiaki@lab.ntt.co.jp> <57A2ED94.2020709@cumulusnetworks.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Bridge] [PATCH net] bridge: Fix problems around fdb entries pointing to the bridge device List-Id: Linux Ethernet Bridging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Toshiaki Makita Cc: netdev@vger.kernel.org, bridge@lists.linux-foundation.org, Nikolay Aleksandrov , "David S. Miller" On 8/4/16, 1:15 AM, Toshiaki Makita wrote: > On 2016/08/04 16:24, Roopa Prabhu wrote: >> On 8/3/16, 7:11 PM, Toshiaki Makita wrote: >>> Adding fdb entries pointing to the bridge device uses fdb_insert(), >>> which lacks various checks and does not respect added_by_user flag. >>> >>> As a result, some inconsistent behavior can happen: >>> * Adding temporary entries succeeds but results in permanent entries. >> IIRC this is not specific to fdb entries on the bridge device. all temp >> fdb entries via iproute2 result in permanent entries. thats why 'dynamic' >> was added. > Sorry for confusing you, I meant "temp" (i.e., "static") of bridge fdb > command. > "temp", "dynamic" and "use" should not result in "permanent". > >>> * Same goes for "dynamic" and "use". >> This patch seems to not allow dynamic and use entries >> on the bridge device. I don't see a strong use-case to >> allow them, but any reason you want to add the restriction now ? > Because dynamic fdb entries pointing the bridge device cannot be > created. So it is prohibited. I cannot find other appropriate behavior > about this. > Or are you suggesting local entries with aging supported or something > like that? no, i am ok with prohibiting it, just was wondering if this is necessary. > >>> * Changing mac address of the bridge device causes deletion of >>> user-added entries. >> unless I am missing something, this does not seem to be related to the >> external fdb entry on the bridge device. > Yes this is related to manually-added fdb entries on the bridge device. > When manual addition of fdb pointing the bridge device was introduced, > we should have set added_by_user on adding the entry and modify > br_fdb_change_mac_address() to respect the flag, but both were not done. > >>> * Replacing existing entries looks successful from userspace but actually >>> not, regardless of NLM_F_EXCL flag. >> curious about this one. I will try it, but if you have an example that >> will help. > Before: > # bridge fdb add 12:34:56:78:90:ab dev enp3s0 master > # bridge fdb add 12:34:56:78:90:ab dev br0; echo $? > 0 > # bridge fdb show > ... > 12:34:56:78:90:ab dev enp3s0 master br0 permanent > > # bridge fdb replace 12:34:56:78:90:ab dev br0; echo $? > 0 > # bridge fdb show > ... > 12:34:56:78:90:ab dev enp3s0 master br0 permanent > > After: > # bridge fdb add 12:34:56:78:90:ab dev enp3s0 master > # bridge fdb add 12:34:56:78:90:ab dev br0; echo $? > RTNETLINK answers: File exists > 255 > > # bridge fdb replace 12:34:56:78:90:ab dev br0; echo $? > 0 > # bridge fdb show > ... > 12:34:56:78:90:ab dev br0 master br0 permanent > ok, thanks for the example. Acked-by: Roopa Prabhu From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roopa Prabhu Subject: Re: [PATCH net] bridge: Fix problems around fdb entries pointing to the bridge device Date: Thu, 04 Aug 2016 11:27:25 -0700 Message-ID: <57A3890D.9010809@cumulusnetworks.com> References: <1470276679-5533-1-git-send-email-makita.toshiaki@lab.ntt.co.jp> <57A2ED94.2020709@cumulusnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: "David S. Miller" , Stephen Hemminger , netdev@vger.kernel.org, bridge@lists.linux-foundation.org, Nikolay Aleksandrov To: Toshiaki Makita Return-path: Received: from mail-pa0-f54.google.com ([209.85.220.54]:36802 "EHLO mail-pa0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933852AbcHDS12 (ORCPT ); Thu, 4 Aug 2016 14:27:28 -0400 Received: by mail-pa0-f54.google.com with SMTP id pp5so84905896pac.3 for ; Thu, 04 Aug 2016 11:27:27 -0700 (PDT) In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On 8/4/16, 1:15 AM, Toshiaki Makita wrote: > On 2016/08/04 16:24, Roopa Prabhu wrote: >> On 8/3/16, 7:11 PM, Toshiaki Makita wrote: >>> Adding fdb entries pointing to the bridge device uses fdb_insert(), >>> which lacks various checks and does not respect added_by_user flag. >>> >>> As a result, some inconsistent behavior can happen: >>> * Adding temporary entries succeeds but results in permanent entries. >> IIRC this is not specific to fdb entries on the bridge device. all temp >> fdb entries via iproute2 result in permanent entries. thats why 'dynamic' >> was added. > Sorry for confusing you, I meant "temp" (i.e., "static") of bridge fdb > command. > "temp", "dynamic" and "use" should not result in "permanent". > >>> * Same goes for "dynamic" and "use". >> This patch seems to not allow dynamic and use entries >> on the bridge device. I don't see a strong use-case to >> allow them, but any reason you want to add the restriction now ? > Because dynamic fdb entries pointing the bridge device cannot be > created. So it is prohibited. I cannot find other appropriate behavior > about this. > Or are you suggesting local entries with aging supported or something > like that? no, i am ok with prohibiting it, just was wondering if this is necessary. > >>> * Changing mac address of the bridge device causes deletion of >>> user-added entries. >> unless I am missing something, this does not seem to be related to the >> external fdb entry on the bridge device. > Yes this is related to manually-added fdb entries on the bridge device. > When manual addition of fdb pointing the bridge device was introduced, > we should have set added_by_user on adding the entry and modify > br_fdb_change_mac_address() to respect the flag, but both were not done. > >>> * Replacing existing entries looks successful from userspace but actually >>> not, regardless of NLM_F_EXCL flag. >> curious about this one. I will try it, but if you have an example that >> will help. > Before: > # bridge fdb add 12:34:56:78:90:ab dev enp3s0 master > # bridge fdb add 12:34:56:78:90:ab dev br0; echo $? > 0 > # bridge fdb show > ... > 12:34:56:78:90:ab dev enp3s0 master br0 permanent > > # bridge fdb replace 12:34:56:78:90:ab dev br0; echo $? > 0 > # bridge fdb show > ... > 12:34:56:78:90:ab dev enp3s0 master br0 permanent > > After: > # bridge fdb add 12:34:56:78:90:ab dev enp3s0 master > # bridge fdb add 12:34:56:78:90:ab dev br0; echo $? > RTNETLINK answers: File exists > 255 > > # bridge fdb replace 12:34:56:78:90:ab dev br0; echo $? > 0 > # bridge fdb show > ... > 12:34:56:78:90:ab dev br0 master br0 permanent > ok, thanks for the example. Acked-by: Roopa Prabhu