1. 24 Apr, 2024 20 commits
  2. 22 Apr, 2024 2 commits
  3. 21 Apr, 2024 2 commits
  4. 20 Apr, 2024 7 commits
  5. 18 Apr, 2024 1 commit
  6. 17 Apr, 2024 2 commits
    • Quentin Deslandes's avatar
      libbpf: Fix dump of subsequent char arrays · e739e01d
      Quentin Deslandes authored
      When dumping a character array, libbpf will watch for a '\0' and set
      is_array_terminated=true if found. This prevents libbpf from printing
      the remaining characters of the array, treating it as a nul-terminated
      string.
      
      However, once this flag is set, it's never reset, leading to subsequent
      characters array not being printed properly:
      
      .str_multi = (__u8[2][16])[
          [
              'H',
              'e',
              'l',
          ],
      ],
      
      This patch saves the is_array_terminated flag and restores its
      default (false) value before looping over the elements of an array,
      then restores it afterward. This way, libbpf's behavior is unchanged
      when dumping the characters of an array, but subsequent arrays are
      printed properly:
      
      .str_multi = (__u8[2][16])[
          [
              'H',
              'e',
              'l',
          ],
          [
              'l',
              'o',
          ],
      ],
      Signed-off-by: default avatarQuentin Deslandes <qde@naccy.de>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20240413211258.134421-3-qde@naccy.de
      e739e01d
    • Quentin Deslandes's avatar
      libbpf: Fix misaligned array closing bracket · 9213e529
      Quentin Deslandes authored
      In btf_dump_array_data(), libbpf will call btf_dump_dump_type_data() for
      each element. For an array of characters, each element will be
      processed the following way:
      
      - btf_dump_dump_type_data() is called to print the character
      - btf_dump_data_pfx() prefixes the current line with the proper number
        of indentations
      - btf_dump_int_data() is called to print the character
      - After the last character is printed, btf_dump_dump_type_data() calls
        btf_dump_data_pfx() before writing the closing bracket
      
      However, for an array containing characters, btf_dump_int_data() won't
      print any '\0' and subsequent characters. This leads to situations where
      the line prefix is written, no character is added, then the prefix is
      written again before adding the closing bracket:
      
      (struct sk_metadata){
          .str_array = (__u8[14])[
              'H',
              'e',
              'l',
              'l',
              'o',
                      ],
      
      This change solves this issue by printing the '\0' character, which
      has two benefits:
      
      - The bracket closing the array is properly aligned
      - It's clear from a user point of view that libbpf uses '\0' as a
        terminator for arrays of characters.
      Signed-off-by: default avatarQuentin Deslandes <qde@naccy.de>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20240413211258.134421-2-qde@naccy.de
      9213e529
  7. 16 Apr, 2024 5 commits
  8. 12 Apr, 2024 1 commit
    • Jiri Olsa's avatar
      selftests/bpf: Add read_trace_pipe_iter function · 4d4992ff
      Jiri Olsa authored
      We have two printk tests reading trace_pipe in non blocking way,
      with the very same code. Moving that in new read_trace_pipe_iter
      function.
      
      Current read_trace_pipe is used from samples/bpf and needs to
      do blocking read and printf of the trace_pipe data, using new
      read_trace_pipe_iter to implement that.
      
      Both printk tests do early checks for the number of found messages
      and can bail earlier, but I did not find any speed difference w/o
      that condition, so I did not complicate the change more for that.
      
      Some of the samples/bpf programs use read_trace_pipe function,
      so I kept that interface untouched. I did not see any issues with
      affected samples/bpf programs other than there's slight change in
      read_trace_pipe output. The current code uses puts that adds new
      line after the printed string, so we would occasionally see extra
      new line. With this patch we read output per lines, so there's no
      need to use puts and we can use just printf instead without extra
      new line.
      Signed-off-by: default avatarJiri Olsa <jolsa@kernel.org>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarYonghong Song <yonghong.song@linux.dev>
      Link: https://lore.kernel.org/bpf/20240410140952.292261-1-jolsa@kernel.org
      4d4992ff