Skip to content
Snippets Groups Projects
  1. Jan 22, 2021
  2. Jan 20, 2021
  3. Jan 15, 2021
  4. Dec 10, 2020
  5. Dec 03, 2020
  6. Dec 01, 2020
  7. Nov 30, 2020
  8. Nov 27, 2020
  9. Nov 24, 2020
  10. Nov 17, 2020
  11. Nov 10, 2020
  12. Nov 09, 2020
  13. Oct 28, 2020
  14. Oct 27, 2020
  15. Oct 21, 2020
    • Daniel Borkmann's avatar
      bpf, libbpf: Guard bpf inline asm from bpf_tail_call_static · 3652c9a1
      Daniel Borkmann authored
      
      Yaniv reported a compilation error after pulling latest libbpf:
      
        [...]
        ../libbpf/src/root/usr/include/bpf/bpf_helpers.h:99:10: error:
        unknown register name 'r0' in asm
                           : "r0", "r1", "r2", "r3", "r4", "r5");
        [...]
      
      The issue got triggered given Yaniv was compiling tracing programs with native
      target (e.g. x86) instead of BPF target, hence no BTF generated vmlinux.h nor
      CO-RE used, and later llc with -march=bpf was invoked to compile from LLVM IR
      to BPF object file. Given that clang was expecting x86 inline asm and not BPF
      one the error complained that these regs don't exist on the former.
      
      Guard bpf_tail_call_static() with defined(__bpf__) where BPF inline asm is valid
      to use. BPF tracing programs on more modern kernels use BPF target anyway and
      thus the bpf_tail_call_static() function will be available for them. BPF inline
      asm is supported since clang 7 (clang <= 6 otherwise throws same above error),
      and __bpf_unreachable() since clang 8, therefore include the latter condition
      in order to prevent compilation errors for older clang versions. Given even an
      old Ubuntu 18.04 LTS has official LLVM packages all the way up to llvm-10, I did
      not bother to special case the __bpf_unreachable() inside bpf_tail_call_static()
      further.
      
      Also, undo the sockex3_kern's use of bpf_tail_call_static() sample given they
      still have the old hacky way to even compile networking progs with native instead
      of BPF target so bpf_tail_call_static() won't be defined there anymore.
      
      Fixes: 0e9f6841 ("bpf, libbpf: Add bpf_tail_call_static helper for bpf programs")
      Reported-by: default avatarYaniv Agman <yanivagman@gmail.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Acked-by: default avatarYonghong Song <yhs@fb.com>
      Tested-by: default avatarYaniv Agman <yanivagman@gmail.com>
      Link: https://lore.kernel.org/bpf/CAMy7=ZUk08w5Gc2Z-EKi4JFtuUCaZYmE4yzhJjrExXpYKR4L8w@mail.gmail.com
      Link: https://lore.kernel.org/bpf/20201021203257.26223-1-daniel@iogearbox.net
      3652c9a1
  16. Oct 14, 2020
    • Hui Su's avatar
      mm,kmemleak-test.c: move kmemleak-test.c to samples dir · 1abbef4f
      Hui Su authored
      
      kmemleak-test.c is just a kmemleak test module, which also can not be used
      as a built-in kernel module.  Thus, i think it may should not be in mm
      dir, and move the kmemleak-test.c to samples/kmemleak/kmemleak-test.c.
      Fix the spelling of built-in by the way.
      
      Signed-off-by: default avatarHui Su <sh_def@163.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Rob Herring <robh@kernel.org>
      Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
      Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
      Cc: Divya Indi <divya.indi@oracle.com>
      Cc: Tomas Winkler <tomas.winkler@intel.com>
      Cc: David Howells <dhowells@redhat.com>
      Link: https://lkml.kernel.org/r/20200925183729.GA172837@rlk
      
      
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      1abbef4f
  17. Oct 11, 2020
  18. Oct 07, 2020
Loading