LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Liran Alon <liran.alon@oracle.com>
To: <daniel@iogearbox.net>
Cc: <netdev@vger.kernel.org>, <shmulik.ladkani@gmail.com>,
	<mrv@mojatatu.com>, <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 08:05:33 -0700 (PDT)	[thread overview]
Message-ID: <eb240da0-9498-4367-8430-600a481f8159@default> (raw)


----- daniel@iogearbox.net wrote:

> On 03/15/2018 03:35 PM, Roman Mashak wrote:
> > Liran Alon <liran.alon@oracle.com> writes:
> > [...]
> >>> Overall I think it might be nice to not need scrubbing skb in
> such
> >>> cases,
> >>> although my concern would be that this has potential to break
> >>> existing
> >>> setups when they would expect mark being zero on other veth peer
> in
> >>> any
> >>> case since it's the behavior for a long time already. The safer
> >>> option
> >>> would be to have some sort of explicit opt-in e.g. on link
> creation to
> >>> let
> >>> the skb->mark pass through unscrubbed. This would definitely be a
> >>> useful
> >>> option e.g. when mark is set in the netns facing veth via
> >>> clsact/egress
> >>> on xmit and when the container is unprivileged anyway.
> >>>
> >>> Thanks,
> >>> Daniel
> >>
> >> I see your point in regards to backwards comparability.
> >> However, not scrubbing skb when it cross netns via some kernel
> functions compared to
> >> others is basically a bug which could easily break with a little
> bit of more refactoring.
> >> Therefore, it seems a bit weird to me to from now on, we will
> force
> >> every user on link creation to consider that once there was a bug
> leading
> >> to this weird behavior on specific netdevs.
> 
> Why bug specifically? It could well be that for some unpriv
> containers
> it would be fine to do e.g. in cases where orchestrator sets up
> clsact/
> egress on veth/ipvlan/etc in the container to set the mark and where
> app
> cannot mess with this while for others you need to act out of host
> facing
> veth; thus, explicit opt-in per dev could provide such more fine
> grained
> control.
> 
> > One valid use case could be preserving a source namespace nsid in
> > skb->mark when a packet crosses netns.
> 
> Right, was thinking about something similar.

I agree with all the above but this behavior was not supported both
before and after this commit. skb->mark is always zeroed when crossing netns.
This commit only changes behavior for skb crossing netdevs on *same* netns
via dev_forward_skb().

Therefore, I believe we should discuss here what we want default behavior to be
and how it should be controlled for backwards comparability.
Only after we should discuss about adding an extra feature of controlling skb scrub
per netdev or something similar.

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

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-15 15:05 Liran Alon [this message]
  -- strict thread matches above, loose matches on Subject: below --
2018-03-15 17:14 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: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-15 12:14 Liran Alon
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=eb240da0-9498-4367-8430-600a481f8159@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=mrv@mojatatu.com \
    --cc=netdev@vger.kernel.org \
    --cc=shmulik.ladkani@gmail.com \
    --cc=yuval.shaia@oracle.com \
    --subject='Re: [PATCH] net: dev_forward_skb(): Scrub packet'\''s per-netns info only when crossing netns' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).