[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B0C2824.5010502@trash.net>
Date: Tue, 24 Nov 2009 19:38:28 +0100
From: Patrick McHardy <kaber@...sh.net>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
CC: Arnd Bergmann <arnd@...db.de>,
virtualization@...ts.linux-foundation.org,
Herbert Xu <herbert@...dor.apana.org.au>,
Eric Dumazet <eric.dumazet@...il.com>,
Anna Fischer <anna.fischer@...com>, netdev@...r.kernel.org,
bridge@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
Mark Smith <lk-netdev@...netdev.nosense.org>,
Gerhard Stenzel <gerhard.stenzel@...ibm.com>,
Jens Osterkamp <jens@...ux.vnet.ibm.com>,
Patrick Mullaney <pmullaney@...ell.com>,
Stephen Hemminger <shemminger@...tta.com>,
Edge Virtual Bridging <evb@...oogroups.com>,
David Miller <davem@...emloft.net>
Subject: Re: [PATCH 1/4] veth: move loopback logic to common location
Eric W. Biederman wrote:
> Patrick McHardy <kaber@...sh.net> writes:
>
>> In the layered case (macvlan -> eth0) its common behaviour to
>> keep the mark however. But in case of different namespaces,
>> I think macvlan should also clear the mark on the dev_queue_xmit()
>> path since this is just a shortcut to looping the packets
>> through veth. In fact probably both of them should also clear
>> skb->priority so other namespaces don't accidentally misclassify
>> packets.
>
> That is why I pushed for what is becoming dev_forward_skb. So that
> we have one place where we can make all of those tweaks. It seems
> like in every review we find another field that should be cleared/handled
> specially.
>
> I don't quite follow what you intend with dev_queue_xmit when the macvlan
> is in one namespace and the real physical device is in another. Are
> you mentioning that the packet classifier runs in the namespace where
> the primary device lives with packets from a different namespace?
Exactly. And I think we should make sure that the namespace of
the macvlan device can't (deliberately or accidentally) cause
misclassification.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists