netdev - Re: [patch net-next-2.6 6/8] bonding: move processing of recv handlers into handle

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: <AANLkTi=Gt_ArqOVPJjnrAExO8Fihu8WzUhYSb_O6URQ_@mail.gmail.com>
Date:	Sun, 6 Mar 2011 17:32:55 +0100
From:	Michał Mirosław <mirqus@...il.com>
To:	Nicolas de Pesloüan 
	<nicolas.2p.debian@...il.com>
Cc:	Jiri Pirko <jpirko@...hat.com>, netdev@...r.kernel.org,
	davem@...emloft.net, shemminger@...ux-foundation.org,
	kaber@...sh.net, fubar@...ibm.com, eric.dumazet@...il.com,
	andy@...yhouse.net
Subject: Re: [patch net-next-2.6 6/8] bonding: move processing of recv
 handlers into handle_frame()

2011/3/6 Nicolas de Pesloüan <nicolas.2p.debian@...il.com>:
> Le 06/03/2011 14:34, Jiri Pirko a écrit :
>> Sun, Mar 06, 2011 at 01:24:32PM CET, nicolas.2p.debian@...il.com wrote:
[...]
>>> That being said, the current vlan_on_bond_hook() hack already suffer
>>> other troubles and for example won't support the following setup:
>>>
>>> eth0 ->  bond0 ->  br0 ->  br0.100.
>>
>> blah. Well correct me if my thinking is wrong but I cannot imagine
>> a scenario where there's not other way how to do arp monitoring than
>> over vlan.
>
> If you are connected to a switch smart enough to allow non tagged delivery
> for one vlan and all you arp_ip_targets are reachable through that vlan,
> then, yes, this hack might been useless...
>
> But...
>
> In real life, you may be connected to any kind of switch, including the most
> stupid one... or you may have trouble explaining to the network team the
> reason why you need all packets to be tagged expect for one vlan... or
> simply, some of your arp_ip_targets will be reachable through a router in
> another vlan.
>
>> So how about to just remove the vlan_on_bond_hook and forbid the
>> possibility. IMHO it should have never been introduced in the first
>> place.
>
> If it was never introduced, we would have been able to simply forbid it, but
> the feature exist since December 14th 2009, so I'm afraid we must keep it...
> :-/
>
> And as a more general rule, I think we should support "all possible"
> interface stacking setups, because this would force us to think generic,
> instead of adding special hacks for special stacking setups.
>
>>> I think we need to fix this stacking issue in a more general way.
>>
>> Well this issue is more or less out of the concept and breaks layering.
>> I cannot think of how to resolve this nicely atm.
>
> The only way I can imagine atm is something I described a few days ago:
>
> 1/ Add a late_delivery property to packet_type:
>
>        struct packet_type {
>                __be16                  type;   /* This is really
> htons(ether_type). */
>                struct net_device       *dev;   /* NULL is wildcarded here
>         */
>                int                     (*func) (struct sk_buff *,
>                                                 struct net_device *,
>                                                 struct packet_type *);
>                struct sk_buff          *(*gso_segment)(struct sk_buff *skb,
>                                                        u32 features);
>                int                     (*gso_send_check)(struct sk_buff
> *skb);
>                struct sk_buff          **(*gro_receive)(struct sk_buff
> **head,
>                                                       struct sk_buff *skb);
>                int                     (*gro_complete)(struct sk_buff *skb);
>                void                    *af_packet_priv;
> +               bool                    late_delivery;
>                struct list_head        list;
>        };
>
> 2/ Use the late_delivery property inside the ptype_all and ptype_base loops
> in __netif_receive_skb(), to skip the protocol handlers whose late_delivery
> property is false, while we walk the rx_handler path.
>
> 3/ At the end of __netif_receive_skb(), deliver the final skb to those
> ptype_all and ptype_base handlers whose late_delivery property is true.
>
> 4/ And revert back the bonding ARP monitoring to a normal protocol handler,
> having late_delivery == true.
>
> This would work with eth0 -> bond0 -> bond0.100 and eth0 -> bond0 -> br0 ->
> br0.100.
>
> This would also be reasonably generic, from my point of view. No reference
> to vlan, bonding, bridge or whatever...

Is there a particular reason why this ARP monitoring can't be done in
userspace (e.g. on AF_PACKET with suitable filter)? Marking slaves
up/down as their link goes in that direction is easy, but as more and
more link-state detecting methods/algorithms get added this is
becoming more of a mess.

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