1. 21 8月, 2017 1 次提交
  2. 05 8月, 2017 1 次提交
  3. 27 7月, 2017 1 次提交
    • J
      bpf: don't zero out the info struct in bpf_obj_get_info_by_fd() · d777b2dd
      Jakub Kicinski 提交于
      The buffer passed to bpf_obj_get_info_by_fd() should be initialized
      to zeros.  Kernel will enforce that to guarantee we can safely extend
      info structures in the future.
      
      Making the bpf_obj_get_info_by_fd() call in libbpf perform the zeroing
      is problematic, however, since some members of the info structures
      may need to be initialized by the callers (for instance pointers
      to buffers to which kernel is to dump translated and jited images).
      
      Remove the zeroing and fix up the in-tree callers before any kernel
      has been released with this code.
      
      As Daniel points out this seems to be the intended operation anyway,
      since commit 95b9afd3 ("bpf: Test for bpf ID") is itself setting
      the buffer pointers before calling bpf_obj_get_info_by_fd().
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Acked-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d777b2dd
  4. 21 7月, 2017 1 次提交
  5. 07 6月, 2017 1 次提交
  6. 12 5月, 2017 1 次提交
  7. 23 4月, 2017 1 次提交
  8. 02 4月, 2017 2 次提交
  9. 23 3月, 2017 1 次提交
  10. 10 3月, 2017 1 次提交
  11. 28 2月, 2017 1 次提交
  12. 16 2月, 2017 1 次提交
  13. 13 2月, 2017 1 次提交
    • A
      bpf: introduce BPF_F_ALLOW_OVERRIDE flag · 7f677633
      Alexei Starovoitov 提交于
      If BPF_F_ALLOW_OVERRIDE flag is used in BPF_PROG_ATTACH command
      to the given cgroup the descendent cgroup will be able to override
      effective bpf program that was inherited from this cgroup.
      By default it's not passed, therefore override is disallowed.
      
      Examples:
      1.
      prog X attached to /A with default
      prog Y fails to attach to /A/B and /A/B/C
      Everything under /A runs prog X
      
      2.
      prog X attached to /A with allow_override.
      prog Y fails to attach to /A/B with default (non-override)
      prog M attached to /A/B with allow_override.
      Everything under /A/B runs prog M only.
      
      3.
      prog X attached to /A with allow_override.
      prog Y fails to attach to /A with default.
      The user has to detach first to switch the mode.
      
      In the future this behavior may be extended with a chain of
      non-overridable programs.
      
      Also fix the bug where detach from cgroup where nothing is attached
      was not throwing error. Return ENOENT in such case.
      
      Add several testcases and adjust libbpf.
      
      Fixes: 30070984 ("cgroup: add support for eBPF programs")
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Acked-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NTejun Heo <tj@kernel.org>
      Acked-by: NDaniel Mack <daniel@zonque.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7f677633
  14. 11 2月, 2017 6 次提交
  15. 09 2月, 2017 1 次提交
  16. 01 2月, 2017 3 次提交
    • J
      tools lib bpf: Add bpf_object__pin() · d5148d85
      Joe Stringer 提交于
      Add a new API to pin a BPF object to the filesystem. The user can
      specify the path within a BPF filesystem to pin the object.
      Programs will be pinned under a subdirectory named the same as the
      program, with each instance appearing as a numbered file under that
      directory, and maps will be pinned under the path using the name of
      the map as the file basename.
      
      For example, with the directory '/sys/fs/bpf/foo' and a BPF object which
      contains two instances of a program named 'bar', and a map named 'baz':
      
      /sys/fs/bpf/foo/bar/0
      /sys/fs/bpf/foo/bar/1
      /sys/fs/bpf/foo/baz
      Signed-off-by: NJoe Stringer <joe@ovn.org>
      Cc: Alexei Starovoitov <ast@fb.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: Wang Nan <wangnan0@huawei.com>
      Cc: netdev@vger.kernel.org
      Link: http://lkml.kernel.org/r/20170126212001.14103-4-joe@ovn.org
      [ Check snprintf >= for truncation, as snprintf(bf, size, ...) == size also means truncation ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      d5148d85
    • J
      tools lib bpf: Add bpf_map__pin() · b6989f35
      Joe Stringer 提交于
      Add a new API to pin a BPF map to the filesystem. The user can specify
      the path full path within a BPF filesystem to pin the map.
      Signed-off-by: NJoe Stringer <joe@ovn.org>
      Cc: Alexei Starovoitov <ast@fb.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: Wang Nan <wangnan0@huawei.com>
      Cc: netdev@vger.kernel.org
      Link: http://lkml.kernel.org/r/20170126212001.14103-3-joe@ovn.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      b6989f35
    • J
      tools lib bpf: Add BPF program pinning APIs · f367540c
      Joe Stringer 提交于
      Add new APIs to pin a BPF program (or specific instances) to the
      filesystem.  The user can specify the path full path within a BPF
      filesystem to pin the program.
      
      bpf_program__pin_instance(prog, path, n) will pin the nth instance of
      'prog' to the specified path.
      
      bpf_program__pin(prog, path) will create the directory 'path' (if it
      does not exist) and pin each instance within that directory. For
      instance, path/0, path/1, path/2.
      
      Committer notes:
      
      - Add missing headers for mkdir()
      
      - Check strdup() for failure
      
      - Check snprintf >= size, not >, as == also means truncated, see 'man
        snprintf', return value.
      
      - Conditionally define BPF_FS_MAGIC, as it isn't in magic.h in older
        systems and we're not yet having a tools/include/uapi/linux/magic.h
        copy.
      
      - Do not include linux/magic.h, not present in older distros.
      Signed-off-by: NJoe Stringer <joe@ovn.org>
      Cc: Alexei Starovoitov <ast@fb.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: Wang Nan <wangnan0@huawei.com>
      Cc: netdev@vger.kernel.org
      Link: http://lkml.kernel.org/r/20170126212001.14103-2-joe@ovn.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      f367540c
  17. 26 1月, 2017 4 次提交
  18. 20 12月, 2016 1 次提交
  19. 16 12月, 2016 2 次提交
  20. 11 12月, 2016 1 次提交
  21. 29 11月, 2016 3 次提交
  22. 25 11月, 2016 1 次提交
    • E
      tools lib bpf: Fix maps resolution · 4708bbda
      Eric Leblond 提交于
      It is not correct to assimilate the elf data of the maps section to an
      array of map definition. In fact the sizes differ. The offset provided
      in the symbol section has to be used instead.
      
      This patch fixes a bug causing a elf with two maps not to load
      correctly.
      
      Wang Nan added:
      
      This patch requires a name for each BPF map, so array of BPF maps is not
      allowed. This restriction is reasonable, because kernel verifier forbid
      indexing BPF map from such array unless the index is a fixed value, but
      if the index is fixed why not merging it into name?
      
      For example:
      
      Program like this:
        ...
        unsigned long cpu = get_smp_processor_id();
        int *pval = map_lookup_elem(&map_array[cpu], &key);
        ...
      
      Generates bytecode like this:
      
      0: (b7) r1 = 0
      1: (63) *(u32 *)(r10 -4) = r1
      2: (b7) r1 = 680997
      3: (63) *(u32 *)(r10 -8) = r1
      4: (85) call 8
      5: (67) r0 <<= 4
      6: (18) r1 = 0x112dd000
      8: (0f) r0 += r1
      9: (bf) r2 = r10
      10: (07) r2 += -4
      11: (bf) r1 = r0
      12: (85) call 1
      
      Where instruction 8 is the computation, 8 and 11 render r1 to an invalid
      value for function map_lookup_elem, causes verifier report error.
      Signed-off-by: NEric Leblond <eric@regit.org>
      Cc: Alexei Starovoitov <ast@fb.com>
      Cc: He Kuang <hekuang@huawei.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      [ Merge bpf_object__init_maps_name into bpf_object__init_maps.
        Fix segfault for buggy BPF script Validate obj->maps ]
      Cc: Zefan Li <lizefan@huawei.com>
      Cc: pi3orama@163.com
      Link: http://lkml.kernel.org/r/20161115040617.69788-5-wangnan0@huawei.comSigned-off-by: NWang Nan <wangnan0@huawei.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      4708bbda
  23. 26 7月, 2016 1 次提交
  24. 14 7月, 2016 2 次提交
  25. 13 7月, 2016 1 次提交