1. 21 11月, 2018 1 次提交
  2. 20 10月, 2018 1 次提交
  3. 17 10月, 2018 1 次提交
  4. 16 10月, 2018 1 次提交
    • J
      bpf: bpftool, add flag to allow non-compat map definitions · c034a177
      John Fastabend 提交于
      Multiple map definition structures exist and user may have non-zero
      fields in their definition that are not recognized by bpftool and
      libbpf. The normal behavior is to then fail loading the map. Although
      this is a good default behavior users may still want to load the map
      for debugging or other reasons. This patch adds a --mapcompat flag
      that can be used to override the default behavior and allow loading
      the map even when it has additional non-zero fields.
      
      For now the only user is 'bpftool prog' we can switch over other
      subcommands as needed. The library exposes an API that consumes
      a flags field now but I kept the original API around also in case
      users of the API don't want to expose this. The flags field is an
      int in case we need more control over how the API call handles
      errors/features/etc in the future.
      Signed-off-by: NJohn Fastabend <john.fastabend@gmail.com>
      Acked-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      c034a177
  5. 08 10月, 2018 1 次提交
  6. 04 10月, 2018 1 次提交
  7. 11 8月, 2018 1 次提交
  8. 25 5月, 2018 1 次提交
  9. 23 5月, 2018 1 次提交
  10. 17 5月, 2018 1 次提交
  11. 09 5月, 2018 1 次提交
  12. 20 4月, 2018 2 次提交
  13. 31 3月, 2018 1 次提交
    • A
      libbpf: Support expected_attach_type at prog load · d7be143b
      Andrey Ignatov 提交于
      Support setting `expected_attach_type` at prog load time in both
      `bpf/bpf.h` and `bpf/libbpf.h`.
      
      Since both headers already have API to load programs, new functions are
      added not to break backward compatibility for existing ones:
      * `bpf_load_program_xattr()` is added to `bpf/bpf.h`;
      * `bpf_prog_load_xattr()` is added to `bpf/libbpf.h`.
      
      Both new functions accept structures, `struct bpf_load_program_attr` and
      `struct bpf_prog_load_attr` correspondingly, where new fields can be
      added in the future w/o changing the API.
      
      Standard `_xattr` suffix is used to name the new API functions.
      
      Since `bpf_load_program_name()` is not used as heavily as
      `bpf_load_program()`, it was removed in favor of more generic
      `bpf_load_program_xattr()`.
      Signed-off-by: NAndrey Ignatov <rdna@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      d7be143b
  14. 29 3月, 2018 1 次提交
  15. 03 2月, 2018 1 次提交
  16. 18 12月, 2017 1 次提交
    • A
      libbpf: add support for bpf_call · 48cca7e4
      Alexei Starovoitov 提交于
      - recognize relocation emitted by llvm
      - since all regular function will be kept in .text section and llvm
        takes care of pc-relative offsets in bpf_call instruction
        simply copy all of .text to relevant program section while adjusting
        bpf_call instructions in program section to point to newly copied
        body of instructions from .text
      - do so for all programs in the elf file
      - set all programs types to the one passed to bpf_prog_load()
      
      Note for elf files with multiple programs that use different
      functions in .text section we need to do 'linker' style logic.
      This work is still TBD
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Acked-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      48cca7e4
  17. 05 10月, 2017 2 次提交
  18. 29 9月, 2017 1 次提交
    • M
      bpf: libbpf: Provide basic API support to specify BPF obj name · 88cda1c9
      Martin KaFai Lau 提交于
      This patch extends the libbpf to provide API support to
      allow specifying BPF object name.
      
      In tools/lib/bpf/libbpf, the C symbol of the function
      and the map is used.  Regarding section name, all maps are
      under the same section named "maps".  Hence, section name
      is not a good choice for map's name.  To be consistent with
      map, bpf_prog also follows and uses its function symbol as
      the prog's name.
      
      This patch adds logic to collect function's symbols in libbpf.
      There is existing codes to collect the map's symbols and no change
      is needed.
      
      The bpf_load_program_name() and bpf_map_create_name() are
      added to take the name argument.  For the other bpf_map_create_xxx()
      variants, a name argument is directly added to them.
      
      In samples/bpf, bpf_load.c in particular, the symbol is also
      used as the map's name and the map symbols has already been
      collected in the existing code.  For bpf_prog, bpf_load.c does
      not collect the function symbol name.  We can consider to collect
      them later if there is a need to continue supporting the bpf_load.c.
      Signed-off-by: NMartin KaFai Lau <kafai@fb.com>
      Acked-by: NAlexei Starovoitov <ast@fb.com>
      Acked-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      88cda1c9
  19. 29 8月, 2017 1 次提交
  20. 20 8月, 2017 1 次提交
  21. 17 8月, 2017 1 次提交
    • J
      bpf: sockmap sample program · 69e8cc13
      John Fastabend 提交于
      This program binds a program to a cgroup and then matches hard
      coded IP addresses and adds these to a sockmap.
      
      This will receive messages from the backend and send them to
      the client.
      
           client:X <---> frontend:10000 client:X <---> backend:10001
      
      To keep things simple this is only designed for 1:1 connections
      using hard coded values. A more complete example would allow many
      backends and clients.
      
      To run,
      
       # sockmap <cgroup2_dir>
      Signed-off-by: NJohn Fastabend <john.fastabend@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      69e8cc13
  22. 21 7月, 2017 1 次提交
  23. 07 6月, 2017 1 次提交
  24. 12 5月, 2017 1 次提交
  25. 02 4月, 2017 1 次提交
  26. 23 3月, 2017 1 次提交
  27. 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
  28. 11 2月, 2017 5 次提交
  29. 09 2月, 2017 1 次提交
  30. 20 12月, 2016 1 次提交
  31. 16 12月, 2016 2 次提交
  32. 29 11月, 2016 1 次提交
  33. 05 7月, 2016 1 次提交