netdev - Re: [patch net-next-2.6 V3] net: convert bonding to use rx

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: <4D62F324.6020301@gmail.com>
Date:	Tue, 22 Feb 2011 00:20:04 +0100
From:	Nicolas de Pesloüan 
	<nicolas.2p.debian@...il.com>
To:	Jiri Pirko <jpirko@...hat.com>
CC:	Jay Vosburgh <fubar@...ibm.com>,
	David Miller <davem@...emloft.net>, kaber@...sh.net,
	eric.dumazet@...il.com, netdev@...r.kernel.org,
	shemminger@...ux-foundation.org, andy@...yhouse.net,
	"Fischer, Anna" <anna.fischer@...com>
Subject: Re: [patch net-next-2.6 V3] net: convert bonding to use rx_handler

Le 20/02/2011 16:07, Jiri Pirko a écrit :
> Sun, Feb 20, 2011 at 01:12:01PM CET, nicolas.2p.debian@...il.com wrote:

[snip]

>> And thinking about all this, I wonder what the protocol handlers expect as the orig_dev value ?
>>
>> Lets imagine the following configuration: eth0 ->  bond0 ->  br0.
>>
>> What does a protocol handler listening on br0 expect for orig_dev ?
>> bond0 or eth0 ? Current implementation give eth0, but I think bond0
>> should be the right value, for proper nesting.
>
> I agree with you.

[snip}

>>> This hook is something I do not like at all :/ But anyway if should be in vlan
>>> part I think.
>>
>> Yes, and in order for the future rx_handler for vlan to properly
>> handle it, it needs to know the device just below it, not the pure
>> original device. Hence, my question about the exact meaning of
>> orig_dev...

After checking every protocol handlers installed by dev_add_pack(), it appears that only 4 of them 
really use the orig_dev parameter given by __netif_receive_skb():

- bond_3ad_lacpdu_recv() @ drivers/net/bonding/bond_3ad.c
- bond_arp_recv() @ drivers/net/bonding/bond_main.c
- packet_rcv() @ net/packet/af_packet.c
- tpacket_rcv() @ net/packet/af_packet.c

 From the bonding point of view, the meaning of orig_dev is obviously "the device one layer below 
the bonding device, through which the packet reached the bonding device". It is used by 
bond_3ad_lacpdu_recv() and bond_arp_recv(), to find the underlying slave device through which the 
LACPDU or ARP was received. (The protocol handler is registered at the bonding device level).

 From the af_packet point of view, the meaning is documented (in commit "[AF_PACKET]: Add option to 
return orig_dev to userspace") as the "physical device [that] actually received the traffic, instead 
of having the encapsulating device hide that information."

When the bonding device is just one level above the physical device, the two meanings happen to 
match the same device, by chance.

So, currently, a bonding device cannot stack properly on top of anything but physical devices. It 
might not be a problem today, but may change in the future...

	Nicolas.






--
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