netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: ast@plumgrid.com
Cc: dborkman@redhat.com, mingo@kernel.org, wad@chromium.org,
	rostedt@goodmis.org, a.p.zijlstra@chello.nl, hpa@zytor.com,
	hagen@jauu.net, jesse@nicira.com, tglx@linutronix.de,
	masami.hiramatsu.pt@hitachi.com, tom.zanussi@linux.intel.com,
	jovi.zhangwei@gmail.com, edumazet@google.com,
	torvalds@linux-foundation.org, akpm@linux-foundation.org,
	fweisbec@gmail.com, acme@infradead.org, penberg@iki.fi,
	arjan@infradead.org, hch@infradead.org,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH v6 net-next 1/3] filter: add Extended BPF interpreter and converter
Date: Mon, 10 Mar 2014 15:22:42 -0400 (EDT)	[thread overview]
Message-ID: <20140310.152242.340501323969517196.davem@davemloft.net> (raw)
In-Reply-To: <CAMEtUuzgM5xKAXZaC+Up9bKy6MaS8V6jFGq49QY7VxQOSFgcBw@mail.gmail.com>

From: Alexei Starovoitov <ast@plumgrid.com>
Date: Fri, 7 Mar 2014 14:19:39 -0800

> On Fri, Mar 7, 2014 at 12:38 PM, David Miller <davem@davemloft.net> wrote:
> 2.
> Another alternative is to do
> struct sk_filter {
>   ..
> union {
>     unsigned int (*bpf_func)(const struct sk_buff *skb,const struct
> sock_filter *filter);
>     unsigned int (*bpf_func_ext)(void*, const struct sock_filter_ext *filter);
>     unsigned int (*bpf_func_generic)(void *, void*);
> };
> 
> assignments into sk_filter will use correct field like:
> fp->bpf_func_ext = sk_run_filter_ext;
> and the hot call macro will look like:
> #define SK_RUN_FILTER(F, CTX) (*F->bpf_func_generic)(CTX, F->insns)
> 
> I think current typecasts are equally ugly, but 'union' style
> will be cleaner from gcc point of view.

The main point is that we should only bypass the type protection provided
by the C language as an absolute last resort.

But in some cases, we can consider making an exception.

The problem with letting sk_check_filter() do the verification is that the
type is also determined by the call site.  That requires some kind of type
based or run time verification.

Although it doesn't use C typing, one thing you could do is encoded the
pointer into an unsigned long.  Then you encode the context in the lowest
bits of that value, masking them out when derferencing at run time.

So that way we can make sure seccomp _only_ runs seccomd filters.

And sockets only run socket filters with SKBs in the second argument.

> btw, ebpf jit coming in the next diff (it was also previewed in V1 series).
> 
> In the 1/3 commit log of this patch I explain the current relation
> between bpf_ext_enable and bpf_jit_enable flags.
> 
> In the next patch with ebpf jit, single bpf_jit_enable flag will act for both:
>   if (bpf_ext_enable) {
>         convert to new
>         sk_chk_filter() - check old bpf
>         if (bpf_jit_enable)
>              use new jit
>         else
>              use new interpreter
>      } else {
>         sk_chk_filter() - check old bpf
>         if (bpf_jit_enable)
>             use old jit
>         else
>             use old interpreter
>      }
> 
> I believe Daniel oked this approach, but if you object, I can do it differently.
> Are you saying 'bpf_jit_enable' flag should mean: do old jit no matter what?
> Then we would need another flag 'bpf_ext_jit_enable' as well?
> Seems overkill to me.

It is not OK to create a temporary regression in between patch sets.

You can make JIT higher priority than EBPF in this series, then once every
single JIT is converted to EBPF, you can just adjust things accordingly.

  reply	other threads:[~2014-03-10 19:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-06  3:30 [PATCH v6 net-next 0/3] filter: add Extended BPF interpreter and converter, seccomp Alexei Starovoitov
2014-03-06  3:30 ` [PATCH v6 net-next 1/3] filter: add Extended BPF interpreter and converter Alexei Starovoitov
2014-03-07 20:38   ` David Miller
2014-03-07 22:19     ` Alexei Starovoitov
2014-03-10 19:22       ` David Miller [this message]
2014-03-10 20:02         ` Alexei Starovoitov
2014-03-06  3:30 ` [PATCH v6 net-next 2/3] seccomp: convert seccomp to use extended BPF Alexei Starovoitov
2014-03-06  3:30 ` [PATCH v6 net-next 3/3] doc: filter: add Extended BPF documentation Alexei Starovoitov

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=20140310.152242.340501323969517196.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=arjan@infradead.org \
    --cc=ast@plumgrid.com \
    --cc=dborkman@redhat.com \
    --cc=edumazet@google.com \
    --cc=fweisbec@gmail.com \
    --cc=hagen@jauu.net \
    --cc=hch@infradead.org \
    --cc=hpa@zytor.com \
    --cc=jesse@nicira.com \
    --cc=jovi.zhangwei@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=mingo@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=penberg@iki.fi \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=tom.zanussi@linux.intel.com \
    --cc=torvalds@linux-foundation.org \
    --cc=wad@chromium.org \
    /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).