Hi, On Mon, 26 Sep 2016 16:43:16 +0200 Hannes Frederic Sowa <han...@stressinduktion.org> wrote: > On 26.09.2016 03:35, Florian Westphal wrote: > > > > Yes, but I think we get same issue when we deal with stacked > > interfaces, and redirect is to e.g. vlan on top of physical device. > > We do have the adjacent upper lists in all netdevices, calculating if a > mirred actions would insert the skb on a stacked device above us should > be as easy as querying netdev_has_upper_dev and should be possible to > check that during config time.
This does not seem the right direction: - We should NOT ban egress redirect to an "upper device", this limits flexibility available today: One may validly redirect to an "upper device" according to a very specific criteria such that the skb will NOT be caught again by the filter when re-iterated down the stack. - And even if we did, at "config time" as you say, one can always stack the target device ontop the filtered device at a LATER time. And obviously, testing "is upper" while executing action is a bad idea. - Moreover, as Daniel noted, this is just a band-aid which limitely addresses only few of the already existing troubles with stacked virtual netdevices (with or without act_mirred). Frankly, I think the loop-detection suggestions overload act_mirred with AI that might imply limitations not well assessed (even on existing usecases). If needed, I'd go with the "recursion detection" suggested by Daniel, which is simple and aids with the issues of "egress" redirect that already exist today. Moreover, as the patch series is all about "ingress redirect" support, the "recursion detection" deserves a series of its own, we shouldn't bundle these two distinct features. Regards, Shmulik
