All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Borkmann <daniel@iogearbox.net>
To: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Cc: Liran Alon <liran.alon@oracle.com>,
	davem@davemloft.net, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, idan.brown@oracle.com,
	Yuval Shaia <yuval.shaia@oracle.com>
Subject: Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns
Date: Thu, 15 Mar 2018 18:48:24 +0100	[thread overview]
Message-ID: <9115c9d2-b788-7432-2238-9ac21f632480@iogearbox.net> (raw)
In-Reply-To: <20180315175444.02d70f23@halley>

On 03/15/2018 04:54 PM, Shmulik Ladkani wrote:
> On Thu, 15 Mar 2018 16:13:39 +0100 Daniel Borkmann <daniel@iogearbox.net> wrote:
>> On 03/15/2018 01:50 PM, Shmulik Ladkani wrote:
>>>
>>> It would be beneficial to have the mark preserved when skb is injected
>>> to the slave device's rx path (especially when it's on the same netns).  
>>
>> Right, I think also here the easiest would be to have a BPF_F_PRESERVE_MARK
>> flag to opt-in in general case (xnet/non-xnet)
> 
> Sounds okay to me.
> 
>> But lets presume for a sec you would _not_ scrub it, then how are users
>> supposed to make use of this? The feature/bug may not be critical enough
>> (well, otherwise it wouldn't have been like this for long time) for stable,
>> so to write an app relying on it the behavior will change from kernel A to
>> kernel B, where you need to end up having a full blown veth run-time test
>> in order to figure it out before you can use it, not really useful either.
> 
> Let's assume BPF_F_PRESERVE_MARK is a feature then, which is available only
> in new kernels.
> As said, this flag will not be honored by older kernels.
> 
> But your "run-time test" argument is true for every new flag-bit
> introduced to bpf functions, for example:
>  BPF_F_SEQ_NUMBER was added after other skb_set_tunnel_key flags,
>  Same for BPF_F_INVALIDATE_HASH (skb_store_bytes), BPF_F_MARK_ENFORCE
>  (l4_csum_replace) and others.
> 
> With every flag addition, the flag mask validation in the corresponding
> bpf function has been relaxed to support it.
> 
> Why is BPF_F_PRESERVE_MARK any different from any previous flag addition?

Not really different than other BPF helpers, but you can simply figure it out
via BPF_PROG_TEST_RUN by calling bpf_redirect() helper on some fake ifindex
and check the return value whether it's shot or redirect. This is definitely
trivial to do and doesn't require any devs to set up compared to otherwise
full blown setup. E.g. test_verifier uses this for the test case array it
contains.

Cheers,
Daniel

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

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-13 15:07 [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns 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 [this message]
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
2018-03-15 12:14 Liran Alon
2018-03-15 12:23 Liran Alon
2018-03-15 14:35 ` Roman Mashak
2018-03-15 14:53   ` Daniel Borkmann
2018-03-15 15:01 Liran Alon
2018-03-15 16:11 ` Shmulik Ladkani
2018-03-15 15:05 Liran Alon
2018-03-15 16:35 Liran Alon
2018-03-15 16:50 ` Shmulik Ladkani
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

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=9115c9d2-b788-7432-2238-9ac21f632480@iogearbox.net \
    --to=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=idan.brown@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=liran.alon@oracle.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.