public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Liran Alon <liran.alon@oracle.com>
To: <shmulik.ladkani@gmail.com>
Cc: <netdev@vger.kernel.org>, <daniel@iogearbox.net>,
	<davem@davemloft.net>, <linux-kernel@vger.kernel.org>,
	<yuval.shaia@oracle.com>, <idan.brown@oracle.com>
Subject: Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns
Date: Thu, 15 Mar 2018 05:14:15 -0700 (PDT)	[thread overview]
Message-ID: <cf2dee1b-6098-47aa-bb2b-f8a44db904e3@default> (raw)


----- shmulik.ladkani@gmail.com wrote:

> Hi,
> 
> On Tue, 13 Mar 2018 17:07:22 +0200 Liran Alon <liran.alon@oracle.com>
> wrote:
> > Before this commit, dev_forward_skb() always cleared packet's
> > per-network-namespace info. Even if the packet doesn't cross
> > network namespaces.
> > 
> > The comment above dev_forward_skb() describes that this is done
> > because the receiving device may be in another network namespace.
> > However, this case can easily be tested for and therefore we can
> > scrub packet's per-network-namespace info only when receiving
> device
> > is indeed in another network namespace.
> > 
> > Therefore, this commit changes ____dev_forward_skb() to tell
> > skb_scrub_packet() that skb has crossed network-namespace only in
> case
> > transmitting device (skb->dev) network namespace is different then
> > receiving device (dev) network namespace.
> 
> Assuming the premise of this commit is correct, note it may not act
> as
> intended for xnet situation in ipvlan_process_multicast, snip:
> 
> 		nskb->dev = ipvlan->dev;
> 		if (tx_pkt)
> 			ret = dev_forward_skb(ipvlan->dev, nskb);
> 		else
> 			ret = netif_rx(nskb);
> 
> as 'dev' gets already assigned to nskb prior dev_forward_skb (hence
> in
> ____dev_forward_skb both dev and skb->dev are the same).
> Fortunately every ipvlan_multicast_enqueue call is preceded by a
> forced
> scrub; It would be future-proof to not assign nskb->dev in the
> dev_forward_skb case (assign it only in the netif_rx case).

I agree. Nice catch.
skb->dev will later get assigned in eth_type_trans() called from __dev_forward_skb().
I will do this small change in a separate patch before this patch.
(In v2 of this series)

> 
> 
> Regarding the premise of this commit, this "reduces" the
> ipvs/orphan/mark scrubbing in the following *non* xnet situations:
> 
>  1. mac2vlan port xmit to other macvlan ports in Bridge Mode
>  2. similarly for ipvlan
>  3. veth xmit
>  4. l2tp_eth_dev_recv
>  5. bpf redirect/clone_redirect ingress actions
> 
> Regarding l2tp recv, this commit seems to align the srubbing behavior
> with ip tunnels (full scrub only if crossing netns, see
> ip_tunnel_rcv).
> 
> Regarding veth xmit, it does makes sense to preserve the fields if
> not
> crossing netns. This is also the case when one uses tc mirred.
> 
> Regarding bpf redirect, well, it depends on the expectations of each
> bpf
> program.
> I'd argue that preserving the fields (at least the mark field) in the
> *non* xnet makes sense and provides more information and therefore
> more
> capabilities; Alas this might change behavior already being relied
> on.

I now noticed that a similar change was done in the past in
commit 8a83a00b0735 ("net: maintain namespace isolation
between vlan and real device"). Commit changed dev_forward_skb() from always
setting skb->mark=0 to do this only in case we cross netns.

However, a later commit: 59b9997baba5 ("Revert "net: maintain namespace
isolation between vlan and real device") seems to later reverted that change.
But I think that the regression issue mentioned in the revert isn't
related to the change proposed by this commit.
Please correct me if I'm missing something.

> 
> Maybe Daniel can comment on the matter.
> 
> Regards,
> Shmulik

             reply	other threads:[~2018-03-15 12:14 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-15 12:14 Liran Alon [this message]
  -- strict thread matches above, loose matches on Subject: below --
2018-03-15 17:14 [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns Liran Alon
2018-03-20 16:24 ` Eric W. Biederman
2018-03-20 16:44   ` Liran Alon
2018-03-20 17:07     ` Ben Greear
2018-03-20 18:35       ` Eric W. Biederman
2018-03-15 16:35 Liran Alon
2018-03-15 16:50 ` Shmulik Ladkani
2018-03-15 15:05 Liran Alon
2018-03-15 15:01 Liran Alon
2018-03-15 16:11 ` Shmulik Ladkani
2018-03-15 12:23 Liran Alon
2018-03-15 14:35 ` Roman Mashak
2018-03-15 14:53   ` Daniel Borkmann
2018-03-13 15:07 Liran Alon
2018-03-13 16:13 ` Yuval Shaia
2018-03-14 12:03   ` Yuval Shaia
2018-03-15  9:21 ` Shmulik Ladkani
2018-03-15 11:56   ` Daniel Borkmann
2018-03-15 12:50     ` Shmulik Ladkani
2018-03-15 15:13       ` Daniel Borkmann
2018-03-15 15:54         ` Shmulik Ladkani
2018-03-15 17:48           ` Daniel Borkmann
2018-03-20 14:47 ` David Miller
2018-03-20 15:34   ` Liran Alon
2018-03-20 16:00     ` David Miller
2018-03-20 16:11       ` Liran Alon
2018-03-20 16:34         ` David Miller
2018-03-20 16:39           ` Liran Alon
2018-03-20 18:51             ` valdis.kletnieks
2018-03-20 21:12               ` Liran Alon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cf2dee1b-6098-47aa-bb2b-f8a44db904e3@default \
    --to=liran.alon@oracle.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=idan.brown@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=shmulik.ladkani@gmail.com \
    --cc=yuval.shaia@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox