1. 04 4月, 2019 1 次提交
    • A
      libbpf: teach libbpf about log_level bit 2 · da11b417
      Alexei Starovoitov 提交于
      Allow bpf_prog_load_xattr() to specify log_level for program loading.
      
      Teach libbpf to accept log_level with bit 2 set.
      
      Increase default BPF_LOG_BUF_SIZE from 256k to 16M.
      There is no downside to increase it to a maximum allowed by old kernels.
      Existing 256k limit caused ENOSPC errors and users were not able to see
      verifier error which is printed at the end of the verifier log.
      
      If ENOSPC is hit, double the verifier log and try again to capture
      the verifier error.
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      da11b417
  2. 08 2月, 2019 1 次提交
    • Y
      tools/bpf: add log_level to bpf_load_program_attr · a4021a35
      Yonghong Song 提交于
      The kernel verifier has three levels of logs:
          0: no logs
          1: logs mostly useful
        > 1: verbose
      
      Current libbpf API functions bpf_load_program_xattr() and
      bpf_load_program() cannot specify log_level.
      The bcc, however, provides an interface for user to
      specify log_level 2 for verbose output.
      
      This patch added log_level into structure
      bpf_load_program_attr, so users, including bcc, can use
      bpf_load_program_xattr() to change log_level. The
      supported log_level is 0, 1, and 2.
      
      The bpf selftest test_sock.c is modified to enable log_level = 2.
      If the "verbose" in test_sock.c is changed to true,
      the test will output logs like below:
        $ ./test_sock
        func#0 @0
        0: R1=ctx(id=0,off=0,imm=0) R10=fp0,call_-1
        0: (bf) r6 = r1
        1: R1=ctx(id=0,off=0,imm=0) R6_w=ctx(id=0,off=0,imm=0) R10=fp0,call_-1
        1: (61) r7 = *(u32 *)(r6 +28)
        invalid bpf_context access off=28 size=4
      
        Test case: bind4 load with invalid access: src_ip6 .. [PASS]
        ...
        Test case: bind6 allow all .. [PASS]
        Summary: 16 PASSED, 0 FAILED
      
      Some test_sock tests are negative tests and verbose verifier
      log will be printed out as shown in the above.
      Signed-off-by: NYonghong Song <yhs@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      a4021a35
  3. 02 2月, 2019 1 次提交
  4. 10 12月, 2018 1 次提交
  5. 05 12月, 2018 1 次提交
  6. 01 12月, 2018 1 次提交
    • D
      bpf: Add BPF_F_ANY_ALIGNMENT. · e9ee9efc
      David Miller 提交于
      Often we want to write tests cases that check things like bad context
      offset accesses.  And one way to do this is to use an odd offset on,
      for example, a 32-bit load.
      
      This unfortunately triggers the alignment checks first on platforms
      that do not set CONFIG_EFFICIENT_UNALIGNED_ACCESS.  So the test
      case see the alignment failure rather than what it was testing for.
      
      It is often not completely possible to respect the original intention
      of the test, or even test the same exact thing, while solving the
      alignment issue.
      
      Another option could have been to check the alignment after the
      context and other validations are performed by the verifier, but
      that is a non-trivial change to the verifier.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      e9ee9efc
  7. 22 11月, 2018 1 次提交
  8. 21 11月, 2018 1 次提交
  9. 20 10月, 2018 1 次提交
  10. 17 10月, 2018 1 次提交
  11. 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
  12. 08 10月, 2018 1 次提交
  13. 04 10月, 2018 1 次提交
  14. 11 8月, 2018 1 次提交
  15. 25 5月, 2018 1 次提交
  16. 23 5月, 2018 1 次提交
  17. 17 5月, 2018 1 次提交
  18. 09 5月, 2018 1 次提交
  19. 20 4月, 2018 2 次提交
  20. 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
  21. 29 3月, 2018 1 次提交
  22. 03 2月, 2018 1 次提交
  23. 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
  24. 05 10月, 2017 2 次提交
  25. 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
  26. 29 8月, 2017 1 次提交
  27. 20 8月, 2017 1 次提交
  28. 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
  29. 21 7月, 2017 1 次提交
  30. 07 6月, 2017 1 次提交
  31. 12 5月, 2017 1 次提交
  32. 02 4月, 2017 1 次提交
  33. 23 3月, 2017 1 次提交
  34. 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
  35. 11 2月, 2017 4 次提交