netdev - Re: [patch net-next-2.6 v2] net: vlan: make non-hw-accel rx path similar to hw-accel

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]

Date:	Sun, 22 May 2011 12:04:50 +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 11:36, Jiri Pirko a écrit :
>> Sun, May 22, 2011 at 11:20:09AM CEST, mirqus@...il.com wrote:
>>> W dniu 22 maja 2011 11:10 użytkownik Nicolas de Pesloüan
>>> <nicolas.2p.debian@...il.com>  napisał:
>>>> Le 22/05/2011 10:52, Michał Mirosław a écrit :
>>>>> 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.
>>>> I assumed (but didn't tested) that this untagging also change the
>>>> starting
>>>> point of the payload of the packet. So protocol handlers expecting to
>>>> have
>>>> the raw packet won't see the vlan header.
>>> That would also be the case with hardware stripped tags - they need to
>>> look into skb->vlan_tci anyway.
>> Exactly. Nicolas, I do not see anything wrong on always untagging in all
>> your setups. As Michal said, vlan_tci keeps the info.
>
> I understand this.
>
> But I don't understand how the bridge code is expected to know whether it
> should re-tag the packet or not before forwarding and which value to use as
> the egress vlan tag.
>
> 1/ eth0 - br0 - eth1 : the bridge is expected to retag using skb->vlan_tci
> value.
>
> 2/ eth0 - eth0.100 - br0 - eth1.200 - eth1 : the bridge is expected to retag
> using a different value than skb->vlan_tci.

> 3/ eth0 - eth0.100 - br0 - eth1 : the bridge is expected not to re-tag,
> because the expected behavior of this setup is to untag while crossing the
> bridge.
>
> 4/ eth0 - eth0.100 - eth0.100.300 - br0 - eth1.400 - eth1.200 - eth1 : the
> bridge is expected to retag using a different value than skb->vlan_tci. What
> value would skb->vlan_tci hold when the skb will be delivered to the bridge?
> 100 or 300?
>
> From my point of view, in both setup, the bridge will receive a single value
> in skb->vlan_tci and will lack any other indication to help it decide how to
> retag when forwarding.

Packets looking like they came from eth0.100 will have skb->vlan_tci
cleared (like taking packet out of a tunnel) and then possibly filled
again with inner tag. It's really convenient to thing of VLANs as
tunnels.

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