1. 09 12月, 2016 1 次提交
  2. 04 12月, 2016 3 次提交
  3. 03 12月, 2016 3 次提交
  4. 02 12月, 2016 1 次提交
    • T
      bpf: Add tests and samples for LWT-BPF · f74599f7
      Thomas Graf 提交于
      Adds a series of tests to verify the functionality of attaching
      BPF programs at LWT hooks.
      
      Also adds a sample which collects a histogram of packet sizes which
      pass through an LWT hook.
      
      $ ./lwt_len_hist.sh
      Starting netserver with host 'IN(6)ADDR_ANY' port '12865' and family AF_UNSPEC
      MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.253.2 () port 0 AF_INET : demo
      Recv   Send    Send
      Socket Socket  Message  Elapsed
      Size   Size    Size     Time     Throughput
      bytes  bytes   bytes    secs.    10^6bits/sec
      
       87380  16384  16384    10.00    39857.69
             1 -> 1        : 0        |                                      |
             2 -> 3        : 0        |                                      |
             4 -> 7        : 0        |                                      |
             8 -> 15       : 0        |                                      |
            16 -> 31       : 0        |                                      |
            32 -> 63       : 22       |                                      |
            64 -> 127      : 98       |                                      |
           128 -> 255      : 213      |                                      |
           256 -> 511      : 1444251  |********                              |
           512 -> 1023     : 660610   |***                                   |
          1024 -> 2047     : 535241   |**                                    |
          2048 -> 4095     : 19       |                                      |
          4096 -> 8191     : 180      |                                      |
          8192 -> 16383    : 5578023  |************************************* |
         16384 -> 32767    : 632099   |***                                   |
         32768 -> 65535    : 6575     |                                      |
      Signed-off-by: NThomas Graf <tgraf@suug.ch>
      Acked-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f74599f7
  5. 01 12月, 2016 1 次提交
  6. 30 11月, 2016 1 次提交
  7. 29 11月, 2016 1 次提交
  8. 28 11月, 2016 1 次提交
    • D
      bpf: fix multiple issues in selftest suite and samples · e00c7b21
      Daniel Borkmann 提交于
      1) The test_lru_map and test_lru_dist fails building on my machine since
         the sys/resource.h header is not included.
      
      2) test_verifier fails in one test case where we try to call an invalid
         function, since the verifier log output changed wrt printing function
         names.
      
      3) Current selftest suite code relies on sysconf(_SC_NPROCESSORS_CONF) for
         retrieving the number of possible CPUs. This is broken at least in our
         scenario and really just doesn't work.
      
         glibc tries a number of things for retrieving _SC_NPROCESSORS_CONF.
         First it tries equivalent of /sys/devices/system/cpu/cpu[0-9]* | wc -l,
         if that fails, depending on the config, it either tries to count CPUs
         in /proc/cpuinfo, or returns the _SC_NPROCESSORS_ONLN value instead.
         If /proc/cpuinfo has some issue, it returns just 1 worst case. This
         oddity is nothing new [1], but semantics/behaviour seems to be settled.
         _SC_NPROCESSORS_ONLN will parse /sys/devices/system/cpu/online, if
         that fails it looks into /proc/stat for cpuX entries, and if also that
         fails for some reason, /proc/cpuinfo is consulted (and returning 1 if
         unlikely all breaks down).
      
         While that might match num_possible_cpus() from the kernel in some
         cases, it's really not guaranteed with CPU hotplugging, and can result
         in a buffer overflow since the array in user space could have too few
         number of slots, and on perpcu map lookup, the kernel will write beyond
         that memory of the value buffer.
      
         William Tu reported such mismatches:
      
           [...] The fact that sysconf(_SC_NPROCESSORS_CONF) != num_possible_cpu()
           happens when CPU hotadd is enabled. For example, in Fusion when
           setting vcpu.hotadd = "TRUE" or in KVM, setting ./qemu-system-x86_64
           -smp 2, maxcpus=4 ... the num_possible_cpu() will be 4 and sysconf()
           will be 2 [2]. [...]
      
         Documentation/cputopology.txt says /sys/devices/system/cpu/possible
         outputs cpu_possible_mask. That is the same as in num_possible_cpus(),
         so first step would be to fix the _SC_NPROCESSORS_CONF calls with our
         own implementation. Later, we could add support to bpf(2) for passing
         a mask via CPU_SET(3), for example, to just select a subset of CPUs.
      
         BPF samples code needs this fix as well (at least so that people stop
         copying this). Thus, define bpf_num_possible_cpus() once in selftests
         and import it from there for the sample code to avoid duplicating it.
         The remaining sysconf(_SC_NPROCESSORS_CONF) in samples are unrelated.
      
      After all three issues are fixed, the test suite runs fine again:
      
        # make run_tests | grep self
        selftests: test_verifier [PASS]
        selftests: test_maps [PASS]
        selftests: test_lru_map [PASS]
        selftests: test_kmod.sh [PASS]
      
        [1] https://www.sourceware.org/ml/libc-alpha/2011-06/msg00079.html
        [2] https://www.mail-archive.com/netdev@vger.kernel.org/msg121183.html
      
      Fixes: 3059303f ("samples/bpf: update tracex[23] examples to use per-cpu maps")
      Fixes: 86af8b41 ("Add sample for adding simple drop program to link")
      Fixes: df570f57 ("samples/bpf: unit test for BPF_MAP_TYPE_PERCPU_ARRAY")
      Fixes: e1559671 ("samples/bpf: unit test for BPF_MAP_TYPE_PERCPU_HASH")
      Fixes: ebb676da ("bpf: Print function name in addition to function id")
      Fixes: 5db58faf ("bpf: Add tests for the LRU bpf_htab")
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Cc: William Tu <u9012063@gmail.com>
      Acked-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e00c7b21
  9. 26 11月, 2016 1 次提交
    • D
      samples: bpf: add userspace example for attaching eBPF programs to cgroups · d8c5b17f
      Daniel Mack 提交于
      Add a simple userpace program to demonstrate the new API to attach eBPF
      programs to cgroups. This is what it does:
      
       * Create arraymap in kernel with 4 byte keys and 8 byte values
      
       * Load eBPF program
      
         The eBPF program accesses the map passed in to store two pieces of
         information. The number of invocations of the program, which maps
         to the number of packets received, is stored to key 0. Key 1 is
         incremented on each iteration by the number of bytes stored in
         the skb.
      
       * Detach any eBPF program previously attached to the cgroup
      
       * Attach the new program to the cgroup using BPF_PROG_ATTACH
      
       * Once a second, read map[0] and map[1] to see how many bytes and
         packets were seen on any socket of tasks in the given cgroup.
      
      The program takes a cgroup path as 1st argument, and either "ingress"
      or "egress" as 2nd. Optionally, "drop" can be passed as 3rd argument,
      which will make the generated eBPF program return 0 instead of 1, so
      the kernel will drop the packet.
      
      libbpf gained two new wrappers for the new syscall commands.
      Signed-off-by: NDaniel Mack <daniel@zonque.org>
      Acked-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d8c5b17f
  10. 25 11月, 2016 2 次提交
  11. 16 11月, 2016 1 次提交
    • M
      bpf: Add tests for the LRU bpf_htab · 5db58faf
      Martin KaFai Lau 提交于
      This patch has some unit tests and a test_lru_dist.
      
      The test_lru_dist reads in the numeric keys from a file.
      The files used here are generated by a modified fio-genzipf tool
      originated from the fio test suit.  The sample data file can be
      found here: https://github.com/iamkafai/bpf-lru
      
      The zipf.* data files have 100k numeric keys and the key is also
      ranged from 1 to 100k.
      
      The test_lru_dist outputs the number of unique keys (nr_unique).
      F.e. The following means, 61239 of them is unique out of 100k keys.
      nr_misses means it cannot be found in the LRU map, so nr_misses
      must be >= nr_unique. test_lru_dist also simulates a perfect LRU
      map as a comparison:
      
      [root@arch-fb-vm1 ~]# ~/devshare/fb-kernel/linux/samples/bpf/test_lru_dist \
      /root/zipf.100k.a1_01.out 4000 1
      ...
      test_parallel_lru_dist (map_type:9 map_flags:0x0):
          task:0 BPF LRU: nr_unique:23093(/100000) nr_misses:31603(/100000)
          task:0 Perfect LRU: nr_unique:23093(/100000 nr_misses:34328(/100000)
      ....
      test_parallel_lru_dist (map_type:9 map_flags:0x2):
          task:0 BPF LRU: nr_unique:23093(/100000) nr_misses:31710(/100000)
          task:0 Perfect LRU: nr_unique:23093(/100000 nr_misses:34328(/100000)
      
      [root@arch-fb-vm1 ~]# ~/devshare/fb-kernel/linux/samples/bpf/test_lru_dist \
      /root/zipf.100k.a0_01.out 40000 1
      ...
      test_parallel_lru_dist (map_type:9 map_flags:0x0):
          task:0 BPF LRU: nr_unique:61239(/100000) nr_misses:67054(/100000)
          task:0 Perfect LRU: nr_unique:61239(/100000 nr_misses:66993(/100000)
      ...
      test_parallel_lru_dist (map_type:9 map_flags:0x2):
          task:0 BPF LRU: nr_unique:61239(/100000) nr_misses:67068(/100000)
          task:0 Perfect LRU: nr_unique:61239(/100000 nr_misses:66993(/100000)
      
      LRU map has also been added to map_perf_test:
      /* Global LRU */
      [root@kerneltest003.31.prn1 ~]# for i in 1 4 8; do echo -n "$i cpus: "; \
      ./map_perf_test 16 $i | awk '{r += $3}END{print r " updates"}'; done
       1 cpus: 2934082 updates
       4 cpus: 7391434 updates
       8 cpus: 6500576 updates
      
      /* Percpu LRU */
      [root@kerneltest003.31.prn1 ~]# for i in 1 4 8; do echo -n "$i cpus: "; \
      ./map_perf_test 32 $i | awk '{r += $3}END{print r " updates"}'; done
        1 cpus: 2896553 updates
        4 cpus: 9766395 updates
        8 cpus: 17460553 updates
      Signed-off-by: NMartin KaFai Lau <kafai@fb.com>
      Acked-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5db58faf
  12. 13 11月, 2016 1 次提交
    • M
      bpf: Add test for bpf_redirect to ipip/ip6tnl · 90e02896
      Martin KaFai Lau 提交于
      The test creates two netns, ns1 and ns2.  The host (the default netns)
      has an ipip or ip6tnl dev configured for tunneling traffic to the ns2.
      
          ping VIPS from ns1 <----> host <--tunnel--> ns2 (VIPs at loopback)
      
      The test is to have ns1 pinging VIPs configured at the loopback
      interface in ns2.
      
      The VIPs are 10.10.1.102 and 2401:face::66 (which are configured
      at lo@ns2). [Note: 0x66 => 102].
      
      At ns1, the VIPs are routed _via_ the host.
      
      At the host, bpf programs are installed at the veth to redirect packets
      from a veth to the ipip/ip6tnl.  The test is configured in a way so
      that both ingress and egress can be tested.
      
      At ns2, the ipip/ip6tnl dev is configured with the local and remote address
      specified.  The return path is routed to the dev ipip/ip6tnl.
      
      During egress test, the host also locally tests pinging the VIPs to ensure
      that bpf_redirect at egress also works for the direct egress (i.e. not
      forwarding from dev ve1 to ve2).
      Acked-by: NAlexei Starovoitov <ast@fb.com>
      Signed-off-by: NMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      90e02896
  13. 30 10月, 2016 1 次提交
    • D
      bpf: fix samples to add fake KBUILD_MODNAME · 96a8eb1e
      Daniel Borkmann 提交于
      Some of the sample files are causing issues when they are loaded with tc
      and cls_bpf, meaning tc bails out while trying to parse the resulting ELF
      file as program/map/etc sections are not present, which can be easily
      spotted with readelf(1).
      
      Currently, BPF samples are including some of the kernel headers and mid
      term we should change them to refrain from this, really. When dynamic
      debugging is enabled, we bail out due to undeclared KBUILD_MODNAME, which
      is easily overlooked in the build as clang spills this along with other
      noisy warnings from various header includes, and llc still generates an
      ELF file with mentioned characteristics. For just playing around with BPF
      examples, this can be a bit of a hurdle to take.
      
      Just add a fake KBUILD_MODNAME as a band-aid to fix the issue, same is
      done in xdp*_kern samples already.
      
      Fixes: 65d472fb ("samples/bpf: add 'pointer to packet' tests")
      Fixes: 6afb1e28 ("samples/bpf: Add tunnel set/get tests.")
      Fixes: a3f74617 ("cgroup: bpf: Add an example to do cgroup checking in BPF")
      Reported-by: NChandrasekar Kannan <ckannan@console.to>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      96a8eb1e
  14. 18 10月, 2016 2 次提交
  15. 10 10月, 2016 1 次提交
  16. 29 9月, 2016 1 次提交
    • J
      bpf: allow access into map value arrays · 48461135
      Josef Bacik 提交于
      Suppose you have a map array value that is something like this
      
      struct foo {
      	unsigned iter;
      	int array[SOME_CONSTANT];
      };
      
      You can easily insert this into an array, but you cannot modify the contents of
      foo->array[] after the fact.  This is because we have no way to verify we won't
      go off the end of the array at verification time.  This patch provides a start
      for this work.  We accomplish this by keeping track of a minimum and maximum
      value a register could be while we're checking the code.  Then at the time we
      try to do an access into a MAP_VALUE we verify that the maximum offset into that
      region is a valid access into that memory region.  So in practice, code such as
      this
      
      unsigned index = 0;
      
      if (foo->iter >= SOME_CONSTANT)
      	foo->iter = index;
      else
      	index = foo->iter++;
      foo->array[index] = bar;
      
      would be allowed, as we can verify that index will always be between 0 and
      SOME_CONSTANT-1.  If you wish to use signed values you'll have to have an extra
      check to make sure the index isn't less than 0, or do something like index %=
      SOME_CONSTANT.
      Signed-off-by: NJosef Bacik <jbacik@fb.com>
      Acked-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      48461135
  17. 27 9月, 2016 2 次提交
  18. 24 9月, 2016 4 次提交
  19. 21 9月, 2016 2 次提交
  20. 17 9月, 2016 2 次提交
  21. 09 9月, 2016 4 次提交
    • B
      rpmsg: Allow callback to return errors · 4b83c52a
      Bjorn Andersson 提交于
      Some rpmsg backends support holding on to and redelivering messages upon
      failed handling of them, so provide a way for the callback to report and
      error and allow the backends to handle this.
      Signed-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>
      4b83c52a
    • B
      rpmsg: Clean up rpmsg device vs channel naming · 92e1de51
      Bjorn Andersson 提交于
      The rpmsg device representing struct is called rpmsg_channel and the
      variable name used throughout is rpdev, with the communication happening
      on endpoints it's clearer to just call this a "device" in a public API.
      Signed-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>
      92e1de51
    • B
      rpmsg: rpmsg_send() operations takes rpmsg_endpoint · 2a48d732
      Bjorn Andersson 提交于
      The rpmsg_send() operations has been taking a rpmsg_device, but this
      forces users of secondary rpmsg_endpoints to use the rpmsg_sendto()
      interface - by extracting source and destination from the given data
      structures. If we instead pass the rpmsg_endpoint to these functions a
      service can use rpmsg_sendto() to respond to messages, even on secondary
      endpoints.
      
      In addition this would allow us to support operations on multiple
      channels in future backends that does not support off-channel
      operations.
      Signed-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>
      2a48d732
    • D
      bpf: fix range propagation on direct packet access · 2d2be8ca
      Daniel Borkmann 提交于
      LLVM can generate code that tests for direct packet access via
      skb->data/data_end in a way that currently gets rejected by the
      verifier, example:
      
        [...]
         7: (61) r3 = *(u32 *)(r6 +80)
         8: (61) r9 = *(u32 *)(r6 +76)
         9: (bf) r2 = r9
        10: (07) r2 += 54
        11: (3d) if r3 >= r2 goto pc+12
         R1=inv R2=pkt(id=0,off=54,r=0) R3=pkt_end R4=inv R6=ctx
         R9=pkt(id=0,off=0,r=0) R10=fp
        12: (18) r4 = 0xffffff7a
        14: (05) goto pc+430
        [...]
      
        from 11 to 24: R1=inv R2=pkt(id=0,off=54,r=0) R3=pkt_end R4=inv
                       R6=ctx R9=pkt(id=0,off=0,r=0) R10=fp
        24: (7b) *(u64 *)(r10 -40) = r1
        25: (b7) r1 = 0
        26: (63) *(u32 *)(r6 +56) = r1
        27: (b7) r2 = 40
        28: (71) r8 = *(u8 *)(r9 +20)
        invalid access to packet, off=20 size=1, R9(id=0,off=0,r=0)
      
      The reason why this gets rejected despite a proper test is that we
      currently call find_good_pkt_pointers() only in case where we detect
      tests like rX > pkt_end, where rX is of type pkt(id=Y,off=Z,r=0) and
      derived, for example, from a register of type pkt(id=Y,off=0,r=0)
      pointing to skb->data. find_good_pkt_pointers() then fills the range
      in the current branch to pkt(id=Y,off=0,r=Z) on success.
      
      For above case, we need to extend that to recognize pkt_end >= rX
      pattern and mark the other branch that is taken on success with the
      appropriate pkt(id=Y,off=0,r=Z) type via find_good_pkt_pointers().
      Since eBPF operates on BPF_JGT (>) and BPF_JGE (>=), these are the
      only two practical options to test for from what LLVM could have
      generated, since there's no such thing as BPF_JLT (<) or BPF_JLE (<=)
      that we would need to take into account as well.
      
      After the fix:
      
        [...]
         7: (61) r3 = *(u32 *)(r6 +80)
         8: (61) r9 = *(u32 *)(r6 +76)
         9: (bf) r2 = r9
        10: (07) r2 += 54
        11: (3d) if r3 >= r2 goto pc+12
         R1=inv R2=pkt(id=0,off=54,r=0) R3=pkt_end R4=inv R6=ctx
         R9=pkt(id=0,off=0,r=0) R10=fp
        12: (18) r4 = 0xffffff7a
        14: (05) goto pc+430
        [...]
      
        from 11 to 24: R1=inv R2=pkt(id=0,off=54,r=54) R3=pkt_end R4=inv
                       R6=ctx R9=pkt(id=0,off=0,r=54) R10=fp
        24: (7b) *(u64 *)(r10 -40) = r1
        25: (b7) r1 = 0
        26: (63) *(u32 *)(r6 +56) = r1
        27: (b7) r2 = 40
        28: (71) r8 = *(u8 *)(r9 +20)
        29: (bf) r1 = r8
        30: (25) if r8 > 0x3c goto pc+47
         R1=inv56 R2=imm40 R3=pkt_end R4=inv R6=ctx R8=inv56
         R9=pkt(id=0,off=0,r=54) R10=fp
        31: (b7) r1 = 1
        [...]
      
      Verifier test cases are also added in this work, one that demonstrates
      the mentioned example here and one that tries a bad packet access for
      the current/fall-through branch (the one with types pkt(id=X,off=Y,r=0),
      pkt(id=X,off=0,r=0)), then a case with good and bad accesses, and two
      with both test variants (>, >=).
      
      Fixes: 969bf05e ("bpf: direct packet access")
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2d2be8ca
  22. 03 9月, 2016 2 次提交
  23. 20 8月, 2016 1 次提交
    • W
      samples/bpf: Add tunnel set/get tests. · 6afb1e28
      William Tu 提交于
      The patch creates sample code exercising bpf_skb_{set,get}_tunnel_key,
      and bpf_skb_{set,get}_tunnel_opt for GRE, VXLAN, and GENEVE.  A native
      tunnel device is created in a namespace to interact with a lwtunnel
      device out of the namespace, with metadata enabled.  The bpf_skb_set_*
      program is attached to tc egress and bpf_skb_get_* is attached to egress
      qdisc.  A ping between two tunnels is used to verify correctness and
      the result of bpf_skb_get_* printed by bpf_trace_printk.
      Signed-off-by: NWilliam Tu <u9012063@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6afb1e28
  24. 13 8月, 2016 1 次提交