Skip to content
Snippets Groups Projects
  1. May 30, 2019
  2. May 14, 2019
    • Daniel Borkmann's avatar
      bpf: test ref bit from data path and add new tests for syscall path · d2baab62
      Daniel Borkmann authored
      
      The test_lru_map is relying on marking the LRU map entry via regular
      BPF map lookup from system call side. This is basically for simplicity
      reasons. Given we fixed marking entries in that case, the test needs
      to be fixed as well. Here we add a small drop-in replacement to retain
      existing behavior for the tests by marking out of the BPF program and
      transferring the retrieved value out via temporary map. This also adds
      new test cases to track the new behavior where two elements are marked,
      one via system call side and one via program side, where the next update
      then evicts the key looked up only from system call side.
      
        # ./test_lru_map
        nr_cpus:8
      
        test_lru_sanity0 (map_type:9 map_flags:0x0): Pass
        test_lru_sanity1 (map_type:9 map_flags:0x0): Pass
        test_lru_sanity2 (map_type:9 map_flags:0x0): Pass
        test_lru_sanity3 (map_type:9 map_flags:0x0): Pass
        test_lru_sanity4 (map_type:9 map_flags:0x0): Pass
        test_lru_sanity5 (map_type:9 map_flags:0x0): Pass
        test_lru_sanity7 (map_type:9 map_flags:0x0): Pass
        test_lru_sanity8 (map_type:9 map_flags:0x0): Pass
      
        test_lru_sanity0 (map_type:10 map_flags:0x0): Pass
        test_lru_sanity1 (map_type:10 map_flags:0x0): Pass
        test_lru_sanity2 (map_type:10 map_flags:0x0): Pass
        test_lru_sanity3 (map_type:10 map_flags:0x0): Pass
        test_lru_sanity4 (map_type:10 map_flags:0x0): Pass
        test_lru_sanity5 (map_type:10 map_flags:0x0): Pass
        test_lru_sanity7 (map_type:10 map_flags:0x0): Pass
        test_lru_sanity8 (map_type:10 map_flags:0x0): Pass
      
        test_lru_sanity0 (map_type:9 map_flags:0x2): Pass
        test_lru_sanity4 (map_type:9 map_flags:0x2): Pass
        test_lru_sanity6 (map_type:9 map_flags:0x2): Pass
        test_lru_sanity7 (map_type:9 map_flags:0x2): Pass
        test_lru_sanity8 (map_type:9 map_flags:0x2): Pass
      
        test_lru_sanity0 (map_type:10 map_flags:0x2): Pass
        test_lru_sanity4 (map_type:10 map_flags:0x2): Pass
        test_lru_sanity6 (map_type:10 map_flags:0x2): Pass
        test_lru_sanity7 (map_type:10 map_flags:0x2): Pass
        test_lru_sanity8 (map_type:10 map_flags:0x2): Pass
      
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      d2baab62
  3. Feb 27, 2018
  4. Apr 17, 2017
  5. Feb 10, 2017
  6. Jan 17, 2017
  7. Nov 28, 2016
    • Daniel Borkmann's avatar
      bpf: fix multiple issues in selftest suite and samples · e00c7b21
      Daniel Borkmann authored
      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: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Cc: William Tu <u9012063@gmail.com>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e00c7b21
  8. Nov 15, 2016
    • Martin KaFai Lau's avatar
      bpf: Add tests for the LRU bpf_htab · 5db58faf
      Martin KaFai Lau authored
      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: default avatarMartin KaFai Lau <kafai@fb.com>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5db58faf
Loading