]> git.baikalelectronics.ru Git - kernel.git/commit
Merge branch 'ebpf-next'
authorDavid S. Miller <davem@davemloft.net>
Sat, 6 Dec 2014 05:47:48 +0000 (21:47 -0800)
committerDavid S. Miller <davem@davemloft.net>
Sat, 6 Dec 2014 05:47:48 +0000 (21:47 -0800)
commit477be46cfa61cf2a5c4107f6c454465fafe4c1b0
treeee28163a6c53e0131fd2d3d626d02b0610eaed2b
parentcd1d0ee1f617131f70fbdbd560289bc5115082c2
parentb671eb358f3b9ecb1bf2482515cb218c8f266de4
Merge branch 'ebpf-next'

Alexei Starovoitov says:

====================
allow eBPF programs to be attached to sockets

V1->V2:

fixed comments in sample code to state clearly that packet data is accessed
with LD_ABS instructions and not internal skb fields.
Also replaced constants in:
BPF_LD_ABS(BPF_B, 14 + 9 /* R0 = ip->proto */),
with:
BPF_LD_ABS(BPF_B, ETH_HLEN + offsetof(struct iphdr, protocol) /* R0 = ip->proto */),

V1 cover:

Introduce BPF_PROG_TYPE_SOCKET_FILTER type of eBPF programs that can be
attached to sockets with setsockopt().
Allow such programs to access maps via lookup/update/delete helpers.

This feature was previewed by bpf manpage in commit 3aa09d5bd755("Merge branch 'bpf-next'")
Now it can actually run.

1st patch adds LD_ABS/LD_IND instruction verification and
2nd patch adds new setsockopt() flag.
Patches 3-6 are examples in assembler and in C.

Though native eBPF programs are way more powerful than classic filters
(attachable through similar setsockopt() call), they don't have skb field
accessors yet. Like skb->pkt_type, skb->dev->ifindex are not accessible.
There are sevaral ways to achieve that. That will be in the next set of patches.
So in this set native eBPF programs can only read data from packet and
access maps.

The most powerful example is sockex2_kern.c from patch 6 where ~200 lines of C
are compiled into ~300 of eBPF instructions.
It shows how quite complex packet parsing can be done.

LLVM used to build examples is at https://github.com/iovisor/llvm
which is fork of llvm trunk that I'm cleaning up for upstreaming.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>