netdev - Re: [Bridge] [PATCH net-next] bridge: vlan: flush the dynamically learned entries on port vlan delete

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <E72DC437-E365-4C90-B2B6-B04FDF4E91D7@cumulusnetworks.com>
Date:	Tue, 23 Jun 2015 18:16:09 +0300
From:	Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
To:	Toshiaki Makita <toshiaki.makita1@...il.com>
Cc:	netdev@...r.kernel.org, vyasevich@...il.com,
	bridge@...ts.linux-foundation.org, davem@...emloft.net
Subject: Re: [Bridge] [PATCH net-next] bridge: vlan: flush the dynamically learned entries on port vlan delete


> On Jun 23, 2015, at 6:02 PM, Toshiaki Makita <toshiaki.makita1@...il.com> wrote:
> 
> On 15/06/23 (火) 21:28, Nikolay Aleksandrov wrote:
>> Add a new argument to br_fdb_delete_by_port which allows to specify a
>> vid to match when flushing entries and use it in nbp_vlan_delete() to
>> flush the dynamically learned entries of the vlan/port pair when removing
>> a vlan from a port. Before this patch only the local mac was being
>> removed and the dynamically learned ones were left to expire.
>> Note that the do_all argument is still respected and if specified, the
>> vid will be ignored.
>> 
>> Signed-off-by: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
>> ---
>> note: There are 2 warnings, the C99 comment was already there and the 81
>>       char line is the prototype and I think it looks better this way.
>>       One unclear thing is about vid 0, I see that it can be passed to
>>       nbp_vlan_(add|delete) although the comment says it shouldn't.
> 
> nbp_vlan_add() should not be called with vid 0 because vid 0 of fdb
> entries is internally used when vlan_filtering is disabled, and such
> entries are exposed to userspace as those without any vlan id.
> bridge's vlan_filtering is respecting 802.1Q-2011 spec, which says vid 0
> cannot be used as a normal vlan id.
> If vlan 0 can be added, it should be a bug.
> 
> Toshiaki Makita

Right, that is my understanding as well. I’ll look into this and post a fix
if necessary.

Thanks,
 Nik--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html