1. 30 4月, 2016 3 次提交
  2. 08 4月, 2016 1 次提交
    • A
      samples/bpf: add tracepoint vs kprobe performance tests · e3edfdec
      Alexei Starovoitov 提交于
      the first microbenchmark does
      fd=open("/proc/self/comm");
      for() {
        write(fd, "test");
      }
      and on 4 cpus in parallel:
                                            writes per sec
      base (no tracepoints, no kprobes)         930k
      with kprobe at __set_task_comm()          420k
      with tracepoint at task:task_rename       730k
      
      For kprobe + full bpf program manully fetches oldcomm, newcomm via bpf_probe_read.
      For tracepint bpf program does nothing, since arguments are copied by tracepoint.
      
      2nd microbenchmark does:
      fd=open("/dev/urandom");
      for() {
        read(fd, buf);
      }
      and on 4 cpus in parallel:
                                             reads per sec
      base (no tracepoints, no kprobes)         300k
      with kprobe at urandom_read()             279k
      with tracepoint at random:urandom_read    290k
      
      bpf progs attached to kprobe and tracepoint are noop.
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e3edfdec
  3. 07 4月, 2016 1 次提交
  4. 09 3月, 2016 2 次提交
  5. 20 2月, 2016 1 次提交
    • A
      samples/bpf: offwaketime example · a6ffe7b9
      Alexei Starovoitov 提交于
      This is simplified version of Brendan Gregg's offwaketime:
      This program shows kernel stack traces and task names that were blocked and
      "off-CPU", along with the stack traces and task names for the threads that woke
      them, and the total elapsed time from when they blocked to when they were woken
      up. The combined stacks, task names, and total time is summarized in kernel
      context for efficiency.
      
      Example:
      $ sudo ./offwaketime | flamegraph.pl > demo.svg
      Open demo.svg in the browser as FlameGraph visualization.
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a6ffe7b9
  6. 17 11月, 2015 1 次提交
  7. 03 11月, 2015 1 次提交
    • D
      bpf: add sample usages for persistent maps/progs · 42984d7c
      Daniel Borkmann 提交于
      This patch adds a couple of stand-alone examples on how BPF_OBJ_PIN
      and BPF_OBJ_GET commands can be used.
      
      Example with maps:
      
        # ./fds_example -F /sys/fs/bpf/m -P -m -k 1 -v 42
        bpf: map fd:3 (Success)
        bpf: pin ret:(0,Success)
        bpf: fd:3 u->(1:42) ret:(0,Success)
        # ./fds_example -F /sys/fs/bpf/m -G -m -k 1
        bpf: get fd:3 (Success)
        bpf: fd:3 l->(1):42 ret:(0,Success)
        # ./fds_example -F /sys/fs/bpf/m -G -m -k 1 -v 24
        bpf: get fd:3 (Success)
        bpf: fd:3 u->(1:24) ret:(0,Success)
        # ./fds_example -F /sys/fs/bpf/m -G -m -k 1
        bpf: get fd:3 (Success)
        bpf: fd:3 l->(1):24 ret:(0,Success)
      
        # ./fds_example -F /sys/fs/bpf/m2 -P -m
        bpf: map fd:3 (Success)
        bpf: pin ret:(0,Success)
        # ./fds_example -F /sys/fs/bpf/m2 -G -m -k 1
        bpf: get fd:3 (Success)
        bpf: fd:3 l->(1):0 ret:(0,Success)
        # ./fds_example -F /sys/fs/bpf/m2 -G -m
        bpf: get fd:3 (Success)
      
      Example with progs:
      
        # ./fds_example -F /sys/fs/bpf/p -P -p
        bpf: prog fd:3 (Success)
        bpf: pin ret:(0,Success)
        bpf sock:4 <- fd:3 attached ret:(0,Success)
        # ./fds_example -F /sys/fs/bpf/p -G -p
        bpf: get fd:3 (Success)
        bpf: sock:4 <- fd:3 attached ret:(0,Success)
      
        # ./fds_example -F /sys/fs/bpf/p2 -P -p -o ./sockex1_kern.o
        bpf: prog fd:5 (Success)
        bpf: pin ret:(0,Success)
        bpf: sock:3 <- fd:5 attached ret:(0,Success)
        # ./fds_example -F /sys/fs/bpf/p2 -G -p
        bpf: get fd:3 (Success)
        bpf: sock:4 <- fd:3 attached ret:(0,Success)
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      42984d7c
  8. 22 10月, 2015 1 次提交
  9. 10 8月, 2015 1 次提交
  10. 23 6月, 2015 1 次提交
    • D
      bpf: BPF based latency tracing · 0fb1170e
      Daniel Wagner 提交于
      BPF offers another way to generate latency histograms. We attach
      kprobes at trace_preempt_off and trace_preempt_on and calculate the
      time it takes to from seeing the off/on transition.
      
      The first array is used to store the start time stamp. The key is the
      CPU id. The second array stores the log2(time diff). We need to use
      static allocation here (array and not hash tables). The kprobes
      hooking into trace_preempt_on|off should not calling any dynamic
      memory allocation or free path. We need to avoid recursivly
      getting called. Besides that, it reduces jitter in the measurement.
      
      CPU 0
            latency        : count     distribution
             1 -> 1        : 0        |                                        |
             2 -> 3        : 0        |                                        |
             4 -> 7        : 0        |                                        |
             8 -> 15       : 0        |                                        |
            16 -> 31       : 0        |                                        |
            32 -> 63       : 0        |                                        |
            64 -> 127      : 0        |                                        |
           128 -> 255      : 0        |                                        |
           256 -> 511      : 0        |                                        |
           512 -> 1023     : 0        |                                        |
          1024 -> 2047     : 0        |                                        |
          2048 -> 4095     : 166723   |*************************************** |
          4096 -> 8191     : 19870    |***                                     |
          8192 -> 16383    : 6324     |                                        |
         16384 -> 32767    : 1098     |                                        |
         32768 -> 65535    : 190      |                                        |
         65536 -> 131071   : 179      |                                        |
        131072 -> 262143   : 18       |                                        |
        262144 -> 524287   : 4        |                                        |
        524288 -> 1048575  : 1363     |                                        |
      CPU 1
            latency        : count     distribution
             1 -> 1        : 0        |                                        |
             2 -> 3        : 0        |                                        |
             4 -> 7        : 0        |                                        |
             8 -> 15       : 0        |                                        |
            16 -> 31       : 0        |                                        |
            32 -> 63       : 0        |                                        |
            64 -> 127      : 0        |                                        |
           128 -> 255      : 0        |                                        |
           256 -> 511      : 0        |                                        |
           512 -> 1023     : 0        |                                        |
          1024 -> 2047     : 0        |                                        |
          2048 -> 4095     : 114042   |*************************************** |
          4096 -> 8191     : 9587     |**                                      |
          8192 -> 16383    : 4140     |                                        |
         16384 -> 32767    : 673      |                                        |
         32768 -> 65535    : 179      |                                        |
         65536 -> 131071   : 29       |                                        |
        131072 -> 262143   : 4        |                                        |
        262144 -> 524287   : 1        |                                        |
        524288 -> 1048575  : 364      |                                        |
      CPU 2
            latency        : count     distribution
             1 -> 1        : 0        |                                        |
             2 -> 3        : 0        |                                        |
             4 -> 7        : 0        |                                        |
             8 -> 15       : 0        |                                        |
            16 -> 31       : 0        |                                        |
            32 -> 63       : 0        |                                        |
            64 -> 127      : 0        |                                        |
           128 -> 255      : 0        |                                        |
           256 -> 511      : 0        |                                        |
           512 -> 1023     : 0        |                                        |
          1024 -> 2047     : 0        |                                        |
          2048 -> 4095     : 40147    |*************************************** |
          4096 -> 8191     : 2300     |*                                       |
          8192 -> 16383    : 828      |                                        |
         16384 -> 32767    : 178      |                                        |
         32768 -> 65535    : 59       |                                        |
         65536 -> 131071   : 2        |                                        |
        131072 -> 262143   : 0        |                                        |
        262144 -> 524287   : 1        |                                        |
        524288 -> 1048575  : 174      |                                        |
      CPU 3
            latency        : count     distribution
             1 -> 1        : 0        |                                        |
             2 -> 3        : 0        |                                        |
             4 -> 7        : 0        |                                        |
             8 -> 15       : 0        |                                        |
            16 -> 31       : 0        |                                        |
            32 -> 63       : 0        |                                        |
            64 -> 127      : 0        |                                        |
           128 -> 255      : 0        |                                        |
           256 -> 511      : 0        |                                        |
           512 -> 1023     : 0        |                                        |
          1024 -> 2047     : 0        |                                        |
          2048 -> 4095     : 29626    |*************************************** |
          4096 -> 8191     : 2704     |**                                      |
          8192 -> 16383    : 1090     |                                        |
         16384 -> 32767    : 160      |                                        |
         32768 -> 65535    : 72       |                                        |
         65536 -> 131071   : 32       |                                        |
        131072 -> 262143   : 26       |                                        |
        262144 -> 524287   : 12       |                                        |
        524288 -> 1048575  : 298      |                                        |
      
      All this is based on the trace3 examples written by
      Alexei Starovoitov <ast@plumgrid.com>.
      Signed-off-by: NDaniel Wagner <daniel.wagner@bmw-carit.de>
      Cc: Alexei Starovoitov <ast@plumgrid.com>
      Cc: Alexei Starovoitov <ast@plumgrid.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Cc: netdev@vger.kernel.org
      Acked-by: NAlexei Starovoitov <ast@plumgrid.com>
      Acked-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0fb1170e
  11. 22 5月, 2015 2 次提交
    • A
      samples/bpf: bpf_tail_call example for networking · 530b2c86
      Alexei Starovoitov 提交于
      Usage:
      $ sudo ./sockex3
      IP     src.port -> dst.port               bytes      packets
      127.0.0.1.42010 -> 127.0.0.1.12865         1568            8
      127.0.0.1.59526 -> 127.0.0.1.33778     11422636       173070
      127.0.0.1.33778 -> 127.0.0.1.59526  11260224828       341974
      127.0.0.1.12865 -> 127.0.0.1.42010         1832           12
      IP     src.port -> dst.port               bytes      packets
      127.0.0.1.42010 -> 127.0.0.1.12865         1568            8
      127.0.0.1.59526 -> 127.0.0.1.33778     23198092       351486
      127.0.0.1.33778 -> 127.0.0.1.59526  22972698518       698616
      127.0.0.1.12865 -> 127.0.0.1.42010         1832           12
      
      this example is similar to sockex2 in a way that it accumulates per-flow
      statistics, but it does packet parsing differently.
      sockex2 inlines full packet parser routine into single bpf program.
      This sockex3 example have 4 independent programs that parse vlan, mpls, ip, ipv6
      and one main program that starts the process.
      bpf_tail_call() mechanism allows each program to be small and be called
      on demand potentially multiple times, so that many vlan, mpls, ip in ip,
      gre encapsulations can be parsed. These and other protocol parsers can
      be added or removed at runtime. TLVs can be parsed in similar manner.
      Note, tail_call_cnt dynamic check limits the number of tail calls to 32.
      Signed-off-by: NAlexei Starovoitov <ast@plumgrid.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      530b2c86
    • A
      samples/bpf: bpf_tail_call example for tracing · 5bacd780
      Alexei Starovoitov 提交于
      kprobe example that demonstrates how future seccomp programs may look like.
      It attaches to seccomp_phase1() function and tail-calls other BPF programs
      depending on syscall number.
      
      Existing optimized classic BPF seccomp programs generated by Chrome look like:
      if (sd.nr < 121) {
        if (sd.nr < 57) {
          if (sd.nr < 22) {
            if (sd.nr < 7) {
              if (sd.nr < 4) {
                if (sd.nr < 1) {
                  check sys_read
                } else {
                  if (sd.nr < 3) {
                    check sys_write and sys_open
                  } else {
                    check sys_close
                  }
                }
              } else {
            } else {
          } else {
        } else {
      } else {
      }
      
      the future seccomp using native eBPF may look like:
        bpf_tail_call(&sd, &syscall_jmp_table, sd.nr);
      which is simpler, faster and leaves more room for per-syscall checks.
      
      Usage:
      $ sudo ./tracex5
      <...>-366   [001] d...     4.870033: : read(fd=1, buf=00007f6d5bebf000, size=771)
      <...>-369   [003] d...     4.870066: : mmap
      <...>-369   [003] d...     4.870077: : syscall=110 (one of get/set uid/pid/gid)
      <...>-369   [003] d...     4.870089: : syscall=107 (one of get/set uid/pid/gid)
         sh-369   [000] d...     4.891740: : read(fd=0, buf=00000000023d1000, size=512)
         sh-369   [000] d...     4.891747: : write(fd=1, buf=00000000023d3000, size=512)
         sh-369   [000] d...     4.891747: : read(fd=1, buf=00000000023d3000, size=512)
      Signed-off-by: NAlexei Starovoitov <ast@plumgrid.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5bacd780
  12. 13 5月, 2015 1 次提交
  13. 07 4月, 2015 1 次提交
    • A
      tc: bpf: add checksum helpers · 91bc4822
      Alexei Starovoitov 提交于
      Commit 608cd71a ("tc: bpf: generalize pedit action") has added the
      possibility to mangle packet data to BPF programs in the tc pipeline.
      This patch adds two helpers bpf_l3_csum_replace() and bpf_l4_csum_replace()
      for fixing up the protocol checksums after the packet mangling.
      
      It also adds 'flags' argument to bpf_skb_store_bytes() helper to avoid
      unnecessary checksum recomputations when BPF programs adjusting l3/l4
      checksums and documents all three helpers in uapi header.
      
      Moreover, a sample program is added to show how BPF programs can make use
      of the mangle and csum helpers.
      Signed-off-by: NAlexei Starovoitov <ast@plumgrid.com>
      Acked-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      91bc4822
  14. 02 4月, 2015 4 次提交
    • A
      samples/bpf: Add kmem_alloc()/free() tracker tool · 9811e353
      Alexei Starovoitov 提交于
      One BPF program attaches to kmem_cache_alloc_node() and
      remembers all allocated objects in the map.
      Another program attaches to kmem_cache_free() and deletes
      corresponding object from the map.
      
      User space walks the map every second and prints any objects
      which are older than 1 second.
      
      Usage:
      
      	$ sudo tracex4
      
      Then start few long living processes. The 'tracex4' will print
      something like this:
      
      	obj 0xffff880465928000 is 13sec old was allocated at ip ffffffff8105dc32
      	obj 0xffff88043181c280 is 13sec old was allocated at ip ffffffff8105dc32
      	obj 0xffff880465848000 is  8sec old was allocated at ip ffffffff8105dc32
      	obj 0xffff8804338bc280 is 15sec old was allocated at ip ffffffff8105dc32
      
      	$ addr2line -fispe vmlinux ffffffff8105dc32
      	do_fork at fork.c:1665
      
      As soon as processes exit the memory is reclaimed and 'tracex4'
      prints nothing.
      
      Similar experiment can be done with the __kmalloc()/kfree() pair.
      Signed-off-by: NAlexei Starovoitov <ast@plumgrid.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Arnaldo Carvalho de Melo <acme@infradead.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Link: http://lkml.kernel.org/r/1427312966-8434-10-git-send-email-ast@plumgrid.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      9811e353
    • A
      samples/bpf: Add IO latency analysis (iosnoop/heatmap) tool · 5c7fc2d2
      Alexei Starovoitov 提交于
      BPF C program attaches to
      blk_mq_start_request()/blk_update_request() kprobe events to
      calculate IO latency.
      
      For every completed block IO event it computes the time delta
      in nsec and records in a histogram map:
      
      	map[log10(delta)*10]++
      
      User space reads this histogram map every 2 seconds and prints
      it as a 'heatmap' using gray shades of text terminal. Black
      spaces have many events and white spaces have very few events.
      Left most space is the smallest latency, right most space is
      the largest latency in the range.
      
      Usage:
      
      	$ sudo ./tracex3
      	and do 'sudo dd if=/dev/sda of=/dev/null' in other terminal.
      
      Observe IO latencies and how different activity (like 'make
      kernel') affects it.
      
      Similar experiments can be done for network transmit latencies,
      syscalls, etc.
      
      '-t' flag prints the heatmap using normal ascii characters:
      
      $ sudo ./tracex3 -t
        heatmap of IO latency
        # - many events with this latency
          - few events
      	|1us      |10us     |100us    |1ms      |10ms     |100ms    |1s |10s
      				 *ooo. *O.#.                                    # 221
      			      .  *#     .                                       # 125
      				 ..   .o#*..                                    # 55
      			    .  . .  .  .#O                                      # 37
      				 .#                                             # 175
      				       .#*.                                     # 37
      				  #                                             # 199
      		      .              . *#*.                                     # 55
      				       *#..*                                    # 42
      				  #                                             # 266
      			      ...***Oo#*OO**o#* .                               # 629
      				  #                                             # 271
      				      . .#o* o.*o*                              # 221
      				. . o* *#O..                                    # 50
      Signed-off-by: NAlexei Starovoitov <ast@plumgrid.com>
      Cc: Arnaldo Carvalho de Melo <acme@infradead.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Link: http://lkml.kernel.org/r/1427312966-8434-9-git-send-email-ast@plumgrid.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      5c7fc2d2
    • A
      samples/bpf: Add counting example for kfree_skb() function calls and the write() syscall · d822a192
      Alexei Starovoitov 提交于
      this example has two probes in one C file that attach to
      different kprove events and use two different maps.
      
      1st probe is x64 specific equivalent of dropmon. It attaches to
      kfree_skb, retrevies 'ip' address of kfree_skb() caller and
      counts number of packet drops at that 'ip' address. User space
      prints 'location - count' map every second.
      
      2nd probe attaches to kprobe:sys_write and computes a histogram
      of different write sizes
      
      Usage:
      	$ sudo tracex2
      	location 0xffffffff81695995 count 1
      	location 0xffffffff816d0da9 count 2
      
      	location 0xffffffff81695995 count 2
      	location 0xffffffff816d0da9 count 2
      
      	location 0xffffffff81695995 count 3
      	location 0xffffffff816d0da9 count 2
      
      	557145+0 records in
      	557145+0 records out
      	285258240 bytes (285 MB) copied, 1.02379 s, 279 MB/s
      		   syscall write() stats
      	     byte_size       : count     distribution
      	       1 -> 1        : 3        |                                      |
      	       2 -> 3        : 0        |                                      |
      	       4 -> 7        : 0        |                                      |
      	       8 -> 15       : 0        |                                      |
      	      16 -> 31       : 2        |                                      |
      	      32 -> 63       : 3        |                                      |
      	      64 -> 127      : 1        |                                      |
      	     128 -> 255      : 1        |                                      |
      	     256 -> 511      : 0        |                                      |
      	     512 -> 1023     : 1118968  |************************************* |
      
      Ctrl-C at any time. Kernel will auto cleanup maps and programs
      
      	$ addr2line -ape ./bld_x64/vmlinux 0xffffffff81695995
      	0xffffffff816d0da9 0xffffffff81695995:
      	./bld_x64/../net/ipv4/icmp.c:1038 0xffffffff816d0da9:
      	./bld_x64/../net/unix/af_unix.c:1231
      Signed-off-by: NAlexei Starovoitov <ast@plumgrid.com>
      Cc: Arnaldo Carvalho de Melo <acme@infradead.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Link: http://lkml.kernel.org/r/1427312966-8434-8-git-send-email-ast@plumgrid.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      d822a192
    • A
      samples/bpf: Add simple non-portable kprobe filter example · b896c4f9
      Alexei Starovoitov 提交于
      tracex1_kern.c - C program compiled into BPF.
      
      It attaches to kprobe:netif_receive_skb()
      
      When skb->dev->name == "lo", it prints sample debug message into
      trace_pipe via bpf_trace_printk() helper function.
      
      tracex1_user.c - corresponding user space component that:
        - loads BPF program via bpf() syscall
        - opens kprobes:netif_receive_skb event via perf_event_open()
          syscall
        - attaches the program to event via ioctl(event_fd,
          PERF_EVENT_IOC_SET_BPF, prog_fd);
        - prints from trace_pipe
      
      Note, this BPF program is non-portable. It must be recompiled
      with current kernel headers. kprobe is not a stable ABI and
      BPF+kprobe scripts may no longer be meaningful when kernel
      internals change.
      
      No matter in what way the kernel changes, neither the kprobe,
      nor the BPF program can ever crash or corrupt the kernel,
      assuming the kprobes, perf and BPF subsystem has no bugs.
      
      The verifier will detect that the program is using
      bpf_trace_printk() and the kernel will print 'this is a DEBUG
      kernel' warning banner, which means that bpf_trace_printk()
      should be used for debugging of the BPF program only.
      
      Usage:
      $ sudo tracex1
                  ping-19826 [000] d.s2 63103.382648: : skb ffff880466b1ca00 len 84
                  ping-19826 [000] d.s2 63103.382684: : skb ffff880466b1d300 len 84
      
                  ping-19826 [000] d.s2 63104.382533: : skb ffff880466b1ca00 len 84
                  ping-19826 [000] d.s2 63104.382594: : skb ffff880466b1d300 len 84
      Signed-off-by: NAlexei Starovoitov <ast@plumgrid.com>
      Cc: Arnaldo Carvalho de Melo <acme@infradead.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Link: http://lkml.kernel.org/r/1427312966-8434-7-git-send-email-ast@plumgrid.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      b896c4f9
  15. 06 12月, 2014 3 次提交
    • A
      samples: bpf: large eBPF program in C · fbe33108
      Alexei Starovoitov 提交于
      sockex2_kern.c is purposefully large eBPF program in C.
      llvm compiles ~200 lines of C code into ~300 eBPF instructions.
      
      It's similar to __skb_flow_dissect() to demonstrate that complex packet parsing
      can be done by eBPF.
      Then it uses (struct flow_keys)->dst IP address (or hash of ipv6 dst) to keep
      stats of number of packets per IP.
      User space loads eBPF program, attaches it to loopback interface and prints
      dest_ip->#packets stats every second.
      
      Usage:
      $sudo samples/bpf/sockex2
      ip 127.0.0.1 count 19
      ip 127.0.0.1 count 178115
      ip 127.0.0.1 count 369437
      ip 127.0.0.1 count 559841
      ip 127.0.0.1 count 750539
      Signed-off-by: NAlexei Starovoitov <ast@plumgrid.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fbe33108
    • A
      samples: bpf: trivial eBPF program in C · a8085782
      Alexei Starovoitov 提交于
      this example does the same task as previous socket example
      in assembler, but this one does it in C.
      
      eBPF program in kernel does:
          /* assume that packet is IPv4, load one byte of IP->proto */
          int index = load_byte(skb, ETH_HLEN + offsetof(struct iphdr, protocol));
          long *value;
      
          value = bpf_map_lookup_elem(&my_map, &index);
          if (value)
              __sync_fetch_and_add(value, 1);
      
      Corresponding user space reads map[tcp], map[udp], map[icmp]
      and prints protocol stats every second
      Signed-off-by: NAlexei Starovoitov <ast@plumgrid.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a8085782
    • A
      samples: bpf: example of stateful socket filtering · 03f4723e
      Alexei Starovoitov 提交于
      this socket filter example does:
      - creates arraymap in kernel with key 4 bytes and value 8 bytes
      
      - loads eBPF program which assumes that packet is IPv4 and loads one byte of
        IP->proto from the packet and uses it as a key in a map
      
        r0 = skb->data[ETH_HLEN + offsetof(struct iphdr, protocol)];
        *(u32*)(fp - 4) = r0;
        value = bpf_map_lookup_elem(map_fd, fp - 4);
        if (value)
             (*(u64*)value) += 1;
      
      - attaches this program to raw socket
      
      - every second user space reads map[IPPROTO_TCP], map[IPPROTO_UDP], map[IPPROTO_ICMP]
        to see how many packets of given protocol were seen on loopback interface
      
      Usage:
      $sudo samples/bpf/sock_example
      TCP 0 UDP 0 ICMP 0 packets
      TCP 187600 UDP 0 ICMP 4 packets
      TCP 376504 UDP 0 ICMP 8 packets
      TCP 563116 UDP 0 ICMP 12 packets
      TCP 753144 UDP 0 ICMP 16 packets
      Signed-off-by: NAlexei Starovoitov <ast@plumgrid.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      03f4723e
  16. 19 11月, 2014 1 次提交
  17. 27 9月, 2014 1 次提交
    • A
      bpf: mini eBPF library, test stubs and verifier testsuite · 3c731eba
      Alexei Starovoitov 提交于
      1.
      the library includes a trivial set of BPF syscall wrappers:
      int bpf_create_map(int key_size, int value_size, int max_entries);
      int bpf_update_elem(int fd, void *key, void *value);
      int bpf_lookup_elem(int fd, void *key, void *value);
      int bpf_delete_elem(int fd, void *key);
      int bpf_get_next_key(int fd, void *key, void *next_key);
      int bpf_prog_load(enum bpf_prog_type prog_type,
      		  const struct sock_filter_int *insns, int insn_len,
      		  const char *license);
      bpf_prog_load() stores verifier log into global bpf_log_buf[] array
      
      and BPF_*() macros to build instructions
      
      2.
      test stubs configure eBPF infra with 'unspec' map and program types.
      These are fake types used by user space testsuite only.
      
      3.
      verifier tests valid and invalid programs and expects predefined
      error log messages from kernel.
      40 tests so far.
      
      $ sudo ./test_verifier
       #0 add+sub+mul OK
       #1 unreachable OK
       #2 unreachable2 OK
       #3 out of range jump OK
       #4 out of range jump2 OK
       #5 test1 ld_imm64 OK
       ...
      Signed-off-by: NAlexei Starovoitov <ast@plumgrid.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3c731eba
  18. 26 9月, 2014 1 次提交
  19. 13 8月, 2008 1 次提交
    • R
      docsrc: build Documentation/ sources · 3794f3e8
      Randy Dunlap 提交于
      Currently source files in the Documentation/ sub-dir can easily bit-rot
      since they are not generally buildable, either because they are hidden in
      text files or because there are no Makefile rules for them.  This needs to
      be fixed so that the source files remain usable and good examples of code
      instead of bad examples.
      
      Add the ability to build source files that are in the Documentation/ dir.
      Add to Kconfig as "BUILD_DOCSRC" config symbol.
      
      Use "CONFIG_BUILD_DOCSRC=1 make ..." to build objects from the
      Documentation/ sources.  Or enable BUILD_DOCSRC in the *config system.
      However, this symbol depends on HEADERS_CHECK since the header files need
      to be installed (for userspace builds).
      
      Built (using cross-tools) for x86-64, i386, alpha, ia64, sparc32,
      sparc64, powerpc, sh, m68k, & mips.
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3794f3e8