netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Borkmann <dborkman@redhat.com>
To: Alexei Starovoitov <ast@plumgrid.com>
Cc: "David S. Miller" <davem@davemloft.net>,
	Ingo Molnar <mingo@kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Chema Gonzalez <chema@google.com>,
	Eric Dumazet <edumazet@google.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Arnaldo Carvalho de Melo <acme@infradead.org>,
	Jiri Olsa <jolsa@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Kees Cook <keescook@chromium.org>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 net-next 0/2] split BPF out of core networking
Date: Mon, 02 Jun 2014 10:57:56 +0200	[thread overview]
Message-ID: <538C3C94.3080206@redhat.com> (raw)
In-Reply-To: <1401692506-7796-1-git-send-email-ast@plumgrid.com>

On 06/02/2014 09:01 AM, Alexei Starovoitov wrote:
> This patch set splits BPF out of core networking into generic component
>
> patch #1 splits filter.c into two logical pieces: generic BPF core and socket
> filters. It only moves functions around. No real changes.
>
> patch #2 adds hidden CONFIG_BPF that seccomp/tracing can select
>
> The main value of the patch is not a NET separation, but rather logical boundary
> between generic BPF core and socket filtering. All socket specific code stays in
> net/core/filter.c and kernel/bpf/core.c is for generic BPF infrastructure (both
> classic and internal).
>
> Note that CONFIG_BPF_JIT is still under NET, so NET-less configs cannot use
> BPF JITs yet. This can be cleaned up in the future. Also it seems to makes sense
> to split up filter.h into generic and socket specific as well to cleanup the
> boundary further.

Hm, I really don't like that 'ripping code and headers apart' and then we believe
it's a generic abstraction. So far seccomp-BPF could live with the current state
since it was introduced, the rest of users (vast majority) is in the networking
domain (and invoked through tcpdump et al) ...

There are still parts in seccomp that show some BPF weaknesses in terms of being
'generic', for example shown in seccomp, we need to go once again over the filter
instructions after doing the usual filter sanity checks, just to whitelist what
seccomp may do in BPF.

I have not yet thought about it deeply enough, but I think we should avoid
something similar in other non-networking areas but abstract that cleanly w/o
such hacks first, for example.

> Tested with several NET and NET-less configs on arm and x86
>
> V1->V2:
> rebase on top of net-next
> split filter.c into kernel/bpf/core.c instead of net/bpf/core.c
>
> Alexei Starovoitov (2):
>    net: filter: split filter.c into two files
>    net: filter: split BPF out of core networking
>
>   arch/Kconfig           |    6 +-
>   include/linux/filter.h |    2 +
>   kernel/Makefile        |    1 +
>   kernel/bpf/Makefile    |    5 +
>   kernel/bpf/core.c      | 1063 ++++++++++++++++++++++++++++++++++++++++++++++++
>   net/Kconfig            |    1 +
>   net/core/filter.c      | 1023 +---------------------------------------------
>   7 files changed, 1079 insertions(+), 1022 deletions(-)
>   create mode 100644 kernel/bpf/Makefile
>   create mode 100644 kernel/bpf/core.c
>

  parent reply	other threads:[~2014-06-02  8:57 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-02  7:01 [PATCH v2 net-next 0/2] split BPF out of core networking Alexei Starovoitov
2014-06-02  7:01 ` [PATCH v2 net-next 1/2] net: filter: split filter.c into two files Alexei Starovoitov
2014-06-02  7:01 ` [PATCH v2 net-next 2/2] net: filter: split BPF out of core networking Alexei Starovoitov
2014-06-02  8:57 ` Daniel Borkmann [this message]
2014-06-02 15:41   ` [PATCH v2 net-next 0/2] " Alexei Starovoitov
2014-06-02 17:04     ` Daniel Borkmann
2014-06-02 19:02       ` Alexei Starovoitov
2014-06-03  8:56         ` Daniel Borkmann
2014-06-03 15:44           ` Alexei Starovoitov
2014-06-03 20:35             ` Daniel Borkmann
2014-06-03 20:58               ` Alexei Starovoitov
2014-06-03 21:40                 ` Chema Gonzalez
2014-06-04  0:38                   ` Alexei Starovoitov
2014-06-20 16:44                     ` Chema Gonzalez
2014-06-23  9:18                       ` David Laight
2014-06-23 21:57                       ` Alexei Starovoitov
2014-06-24  8:33                         ` Daniel Borkmann
2014-06-02 13:15 ` Jonathan Corbet
2014-06-02 13:24   ` Steven Rostedt
2014-06-02 14:16     ` Arnaldo Carvalho de Melo
2014-06-02 14:57       ` Alexei Starovoitov
2014-06-03 18:16         ` Ingo Molnar

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=538C3C94.3080206@redhat.com \
    --to=dborkman@redhat.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=ast@plumgrid.com \
    --cc=chema@google.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hpa@zytor.com \
    --cc=jolsa@redhat.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /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;
as well as URLs for NNTP newsgroup(s).