Re: [PATCH next v2 0/7] Introduce l3_dev pointer for L3 processing

Le 14/03/2016 18:57, Mahesh Bandewar a écrit : On Sun, Mar 13, 2016 at 8:53 PM, David Miller wrote: [snip] Furthermore, when you walk across the ns boundary, that old device has to disappear. That's why that is the device assigned to skb->dev. The layer boundaries are

Re: [PATCH next v2 0/7] Introduce l3_dev pointer for L3 processing

On Sun, Mar 13, 2016 at 8:53 PM, David Miller wrote: > > Please stop pretending that this device switching is ok, it's not. +1 This is what I have been complaining about since v1...

Re: [PATCH next v2 0/7] Introduce l3_dev pointer for L3 processing

On Sun, Mar 13, 2016 at 5:01 PM, Mahesh Bandewar wrote: >>> If I understand correctly (and as Cong already said), information are >>> leaking >>> between netns during the input phase. On the tx side, skb_scrub_packet() is >>> called, but not on the rx side. I think it's wrong.

Re: [PATCH next v2 0/7] Introduce l3_dev pointer for L3 processing

On Sun, Mar 13, 2016 at 8:53 PM, David Miller wrote: > From: Mahesh Bandewar > Date: Sun, 13 Mar 2016 19:29:58 -0700 > >> On Sun, Mar 13, 2016 at 6:50 PM, David Miller wrote: >>> It doesn't matter whether doing so or not makes sense.

Re: [PATCH next v2 0/7] Introduce l3_dev pointer for L3 processing

From: Mahesh Bandewar Date: Sun, 13 Mar 2016 19:29:58 -0700 > On Sun, Mar 13, 2016 at 6:50 PM, David Miller wrote: >> It doesn't matter whether doing so or not makes sense. >> >> You're going to have to find a way to do both, and also I'm concerned >>

Re: [PATCH next v2 0/7] Introduce l3_dev pointer for L3 processing

On Sun, Mar 13, 2016 at 6:50 PM, David Miller wrote: > From: Mahesh Bandewar > Date: Wed, 9 Mar 2016 13:49:49 -0800 > >> This does happen as expected for egress traffic however on ingress >> traffic, the IPvlan packet-handler changes the skb->dev and

Re: [PATCH next v2 0/7] Introduce l3_dev pointer for L3 processing

From: Mahesh Bandewar Date: Wed, 9 Mar 2016 13:49:49 -0800 > This does happen as expected for egress traffic however on ingress > traffic, the IPvlan packet-handler changes the skb->dev and this > forces packet to be processed with the IPvlan slave and it's > associated ns.

Re: [PATCH next v2 0/7] Introduce l3_dev pointer for L3 processing

>> If I understand correctly (and as Cong already said), information are >> leaking >> between netns during the input phase. On the tx side, skb_scrub_packet() is >> called, but not on the rx side. I think it's wrong. There should be an >> explicit >> boundary. > > That is not what I am

Re: [PATCH next v2 0/7] Introduce l3_dev pointer for L3 processing

> If I understand correctly (and as Cong already said), information are > leaking > between netns during the input phase. On the tx side, skb_scrub_packet() is > called, but not on the rx side. I think it's wrong. There should be an > explicit > boundary. > I think we used to do dev_forward_skb()

Re: [PATCH next v2 0/7] Introduce l3_dev pointer for L3 processing

On Thu, Mar 10, 2016 at 1:47 AM, Nicolas Dichtel wrote: > Le 09/03/2016 22:49, Mahesh Bandewar a écrit : >> >> From: Mahesh Bandewar >> >> One of the major request (for enhancement) that I have received >> from various users of IPvlan in L3 mode is

Re: [PATCH next v2 0/7] Introduce l3_dev pointer for L3 processing

Le 09/03/2016 22:49, Mahesh Bandewar a écrit : From: Mahesh Bandewar One of the major request (for enhancement) that I have received from various users of IPvlan in L3 mode is its inability to handle IPtables. While looking at the code and how we handle ingress, the

[PATCH next v2 0/7] Introduce l3_dev pointer for L3 processing

From: Mahesh Bandewar One of the major request (for enhancement) that I have received from various users of IPvlan in L3 mode is its inability to handle IPtables. While looking at the code and how we handle ingress, the problem can be attributed to the asymmetry in the way