netdev - Re: Deliver skbs to intermediate interfaces, when using cascaded rx-handlers

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: <20140221102626.GC2870@minipsycho.orion>
Date:	Fri, 21 Feb 2014 11:26:26 +0100
From:	Jiri Pirko <jiri@...nulli.us>
To:	Tobias Waldekranz <tobias@...dekranz.com>
Cc:	netdev@...r.kernel.org
Subject: Re: Deliver skbs to intermediate interfaces, when using cascaded
 rx-handlers

Fri, Feb 21, 2014 at 11:01:58AM CET, tobias@...dekranz.com wrote:
>I have a system with the following configuration:
>
>   * eth0 is a regular Ethernet MAC, connected to a hardware switch.
>   * port[1-4] are the in-kernel representation of the switch.
>   * team0 is a regular team-interface which bonds port1 and port2.
>
>      +-------+
>      | team0 |
>      +---+---+
>          |
>     +----+----+
>     |         |
> +---+---+ +---+---+ +-------+ +-------+
> | port1 | | port2 | | port3 | | port4 | 
> +---+---+ +---+---+ +---+---+ +---+---+
>     |         |         |         |
>     +---------+----+----+---------+
>                    |
>                +---+---+
>                | eth0  |
>                +-------+
>
>Both the switch and the team driver attaches rx-handlers to their
>lower layers. The problem is that team expects LACP frames that
>are intercepted by team0, to also be delivered to the port interface
>by __netif_receive_skb_core (in the final iteration of the registered
>protocols). However in this case, when two rx-handlers are cascaded,
>the skb will be delivered to eth0, since that is the original device
>(orig_dev).
>
>There are a few ways this can be solved as far as i can see:
>
>   1. Introduce a new rx-handler return code that specifies that
>   skb->dev has been altered, like RX_HANDLER_ANOTHER, and that we
>   also want to change orig_dev to this new device.
>
>   2. Change the switch driver to return RX_HANDLER_CONSUMED and then
>   queue the skb all over again, though I am afraid that this will eat
>   some cycles.

What "switch driver" are you reffering to?



>
>   3. Keep track of all traversed interfaces and change the final
>   protocol iteration to deliver the skb to all intermediate devices.
>
>What would be your suggestion?
>
>-- 
>Thanks
> - wkz
>
>--
>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
--
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