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: Sun, 22 May 2011 10:52:28 +0200 From: Michał Mirosław <mirqus@...il.com> To: Nicolas de Pesloüan <nicolas.2p.debian@...il.com> Cc: Jiri Pirko <jpirko@...hat.com>, "Eric W. Biederman" <ebiederm@...ssion.com>, Jesse Gross <jesse@...ira.com>, Changli Gao <xiaosuo@...il.com>, David Miller <davem@...emloft.net>, netdev@...r.kernel.org, shemminger@...ux-foundation.org, kaber@...sh.net, fubar@...ibm.com, eric.dumazet@...il.com, andy@...yhouse.net Subject: Re: [patch net-next-2.6 v2] net: vlan: make non-hw-accel rx path similar to hw-accel 2011/5/22 Nicolas de Pesloüan <nicolas.2p.debian@...il.com>: > Le 22/05/2011 08:34, Eric W. Biederman a écrit : >> >> Jiri Pirko<jpirko@...hat.com> writes: >> >>> Sun, May 22, 2011 at 04:59:49AM CEST, nicolas.2p.debian@...il.com wrote: >>> >>> <snip> >>>> >>>> And because some setups may still require the skb not to be untagged, >>>> may be we need the ability to re-tag the skb in some situations... >>>> When a protocol handler or rx_handler is explicitly registered on a >>>> net_device which expect to receive tagged skb, we should deliver >>>> tagged skb to it... Arguably, this may sound incredible for the >>>> general case, but may be required for not-so-special cases like >>>> bridge or protocol analyzer. >>> >>> Wait, what setups/code require the skb not to be untagged? If there's >>> such, it should be fixed. >> >> tcpdump on the non-vlan interface for one. > bridge is another. More precisely, there is a difference between the > following two setups: > > 1/ eth0 - eth0.100 - br0 - eth1.200 - eth1 > > 2/ eth0 - br0 - eth1 > > In case 1, it is normal and desirable for the bridge to see untagged skb. > > In case 2, it is desirable for the bridge to see untouched (possibly tagged) > skb. If current bridge implementation is able to handle skb from which we > removed a tag, in this situation, it means that bridge currently "fix > improper untagging" by itself, by forcing re-tagging on output. I think is > should not be the job of protocol handlers to fix this. Again, a generic > feature should to it when necessary. > > Think of the following setups: > > 3/ eth0 - br0 - eth1.200 - eth1. > 4/ eth0 - eth0.100 - br0 - eth1 > > What if one expect this setup to add (3) or remove (4) one level of vlan > nesting? This is precisely what this setup suggest. How can we instruct the > bridge to do so? It is not the bridge responsibility to do any vlan > processing. bridge is expected to... bridge ! I assumed that this untaging Jiri is implementing does not remove the tag. It moves the information from skb->data to skb->vlan_tci, but the information contained is not otherwise changing. All your examples should work regardless of where the tag is stored. Best Regards, Michał Mirosław -- 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