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
| ||
|
Date: Wed, 17 Dec 2014 16:18:11 -0000 From: "Hubert Sokolowski" <h.sokolowski@....edu.pl> To: vyasevic@...hat.com Cc: "John Fastabend" <john.fastabend@...il.com>, "Jamal Hadi Salim" <jhs@...atatu.com>, "Roopa Prabhu" <roopa@...ulusnetworks.com>, "netdev@...r.kernel.org" <netdev@...r.kernel.org> Subject: Re: [PATCH net-next RESEND] net: Do not call ndo_dflt_fdb_dump if ndo_fdb_dump is defined. > > I don't think we have to dump uc/mc lists unconditionally. What we > want is the lower diver's view of any fdb entries it things are appropriate. > For simple cards, this becomes equivalent to uc/mc lists. For smarter cards > that override the default dumper, it makes sense for them to provide the info. > I am very glad to hear that :). > > Well, the bridge would have dumped any fdbs that pointer at the bridge > device (port is NULL) as it's egress port. Not sure about the vxlan. > For stacked situations of complex devices this make sense. For > instance if you stack vxlan on top of bridge, then from the vxlan > perspective, we want to see what macs the bridge will forward to the > vxlan. Here, the bridge is actually slightly broken as it wouldn't > actually dump all the pertinent info, but that's more of a bridge problem. I have just prepared a patch where I dump uc/mc for bridge devices by looking at (dev->priv_flags & IFF_EBRIDGE), so I have same results as without my changes. This should satisfy Jamal and Roopa. I could send it as v3 of my patch along with the results if you are interested. > > -vlad > thanks, Hubert -- Hubert Sokolowski Intel Corporation -- 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
Powered by blists - more mailing lists