1. 01 Aug, 2022 15 commits
  2. 31 Jul, 2022 1 commit
  3. 30 Jul, 2022 17 commits
  4. 29 Jul, 2022 7 commits
    • Yang Li's avatar
      bpf: Remove unneeded semicolon · 14250fa4
      Yang Li authored
      Eliminate the following coccicheck warning:
      /kernel/bpf/trampoline.c:101:2-3: Unneeded semicolon
      Reported-by: default avatarAbaci Robot <abaci@linux.alibaba.com>
      Signed-off-by: default avatarYang Li <yang.lee@linux.alibaba.com>
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Link: https://lore.kernel.org/bpf/20220725222733.55613-1-yang.lee@linux.alibaba.com
      14250fa4
    • Joe Burton's avatar
      libbpf: Add bpf_obj_get_opts() · 395fc4fa
      Joe Burton authored
      Add an extensible variant of bpf_obj_get() capable of setting the
      `file_flags` parameter.
      
      This parameter is needed to enable unprivileged access to BPF maps.
      Without a method like this, users must manually make the syscall.
      Signed-off-by: default avatarJoe Burton <jevburton@google.com>
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Link: https://lore.kernel.org/bpf/20220729202727.3311806-1-jevburton.kernel@gmail.com
      395fc4fa
    • Jakub Kicinski's avatar
      netdevsim: Avoid allocation warnings triggered from user space · d0b80a9e
      Jakub Kicinski authored
      We need to suppress warnings from sily map sizes. Also switch
      from GFP_USER to GFP_KERNEL_ACCOUNT, I'm pretty sure I misunderstood
      the flags when writing this code.
      
      Fixes: 395cacb5 ("netdevsim: bpf: support fake map offload")
      Reported-by: syzbot+ad24705d3fd6463b18c6@syzkaller.appspotmail.com
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Link: https://lore.kernel.org/bpf/20220726213605.154204-1-kuba@kernel.org
      d0b80a9e
    • Xu Kuohai's avatar
      bpf: Fix NULL pointer dereference when registering bpf trampoline · 3b317abc
      Xu Kuohai authored
      A panic was reported on arm64:
      
      [   44.517109] audit: type=1334 audit(1658859870.268:59): prog-id=19 op=LOAD
      [   44.622031] Unable to handle kernel NULL pointer dereference at
      virtual address 0000000000000010
      [   44.624321] Mem abort info:
      [   44.625049]   ESR = 0x0000000096000004
      [   44.625935]   EC = 0x25: DABT (current EL), IL = 32 bits
      [   44.627182]   SET = 0, FnV = 0
      [   44.627930]   EA = 0, S1PTW = 0
      [   44.628684]   FSC = 0x04: level 0 translation fault
      [   44.629788] Data abort info:
      [   44.630474]   ISV = 0, ISS = 0x00000004
      [   44.631362]   CM = 0, WnR = 0
      [   44.632041] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000100ab5000
      [   44.633494] [0000000000000010] pgd=0000000000000000, p4d=0000000000000000
      [   44.635202] Internal error: Oops: 96000004 [#1] SMP
      [   44.636452] Modules linked in: xfs crct10dif_ce ghash_ce virtio_blk
      virtio_console virtio_mmio qemu_fw_cfg
      [   44.638713] CPU: 2 PID: 1 Comm: systemd Not tainted 5.19.0-rc7 #1
      [   44.640164] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
      [   44.641799] pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
      [   44.643404] pc : ftrace_set_filter_ip+0x24/0xa0
      [   44.644659] lr : bpf_trampoline_update.constprop.0+0x428/0x4a0
      [   44.646118] sp : ffff80000803b9f0
      [   44.646950] x29: ffff80000803b9f0 x28: ffff0b5d80364400 x27: ffff80000803bb48
      [   44.648721] x26: ffff8000085ad000 x25: ffff0b5d809d2400 x24: 0000000000000000
      [   44.650493] x23: 00000000ffffffed x22: ffff0b5dd7ea0900 x21: 0000000000000000
      [   44.652279] x20: 0000000000000000 x19: 0000000000000000 x18: ffffffffffffffff
      [   44.654067] x17: 0000000000000000 x16: 0000000000000000 x15: ffffffffffffffff
      [   44.655787] x14: ffff0b5d809d2498 x13: ffff0b5d809d2432 x12: 0000000005f5e100
      [   44.657535] x11: abcc77118461cefd x10: 000000000000005f x9 : ffffa7219cb5b190
      [   44.659254] x8 : ffffa7219c8e0000 x7 : 0000000000000000 x6 : ffffa7219db075e0
      [   44.661066] x5 : ffffa7219d3130e0 x4 : ffffa7219cab9da0 x3 : 0000000000000000
      [   44.662837] x2 : 0000000000000000 x1 : ffffa7219cb7a5c0 x0 : 0000000000000000
      [   44.664675] Call trace:
      [   44.665274]  ftrace_set_filter_ip+0x24/0xa0
      [   44.666327]  bpf_trampoline_update.constprop.0+0x428/0x4a0
      [   44.667696]  __bpf_trampoline_link_prog+0xcc/0x1c0
      [   44.668834]  bpf_trampoline_link_prog+0x40/0x64
      [   44.669919]  bpf_tracing_prog_attach+0x120/0x490
      [   44.671011]  link_create+0xe0/0x2b0
      [   44.671869]  __sys_bpf+0x484/0xd30
      [   44.672706]  __arm64_sys_bpf+0x30/0x40
      [   44.673678]  invoke_syscall+0x78/0x100
      [   44.674623]  el0_svc_common.constprop.0+0x4c/0xf4
      [   44.675783]  do_el0_svc+0x38/0x4c
      [   44.676624]  el0_svc+0x34/0x100
      [   44.677429]  el0t_64_sync_handler+0x11c/0x150
      [   44.678532]  el0t_64_sync+0x190/0x194
      [   44.679439] Code: 2a0203f4 f90013f5 2a0303f5 f9001fe1 (f9400800)
      [   44.680959] ---[ end trace 0000000000000000 ]---
      [   44.682111] Kernel panic - not syncing: Oops: Fatal exception
      [   44.683488] SMP: stopping secondary CPUs
      [   44.684551] Kernel Offset: 0x2721948e0000 from 0xffff800008000000
      [   44.686095] PHYS_OFFSET: 0xfffff4a380000000
      [   44.687144] CPU features: 0x010,00022811,19001080
      [   44.688308] Memory Limit: none
      [   44.689082] ---[ end Kernel panic - not syncing: Oops: Fatal exception ]---
      
      It's caused by a NULL tr->fops passed to ftrace_set_filter_ip(). tr->fops
      is initialized to NULL and is assigned to an allocated memory address if
      CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS is enabled. Since there is no
      direct call on arm64 yet, the config can't be enabled.
      
      To fix it, call ftrace_set_filter_ip() only if tr->fops is not NULL.
      
      Fixes: 00963a2e ("bpf: Support bpf_trampoline on functions with IPMODIFY (e.g. livepatch)")
      Reported-by: default avatarBruno Goncalves <bgoncalv@redhat.com>
      Signed-off-by: default avatarXu Kuohai <xukuohai@huawei.com>
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Tested-by: default avatarBruno Goncalves <bgoncalv@redhat.com>
      Acked-by: default avatarSong Liu <songliubraving@fb.com>
      Acked-by: default avatarJiri Olsa <jolsa@kernel.org>
      Link: https://lore.kernel.org/bpf/20220728114048.3540461-1-xukuohai@huaweicloud.com
      3b317abc
    • Song Liu's avatar
      bpf: Fix test_progs -j error with fentry/fexit tests · dc81f8d1
      Song Liu authored
      When multiple threads are attaching/detaching fentry/fexit programs to
      the same trampoline, we may call register_fentry on the same trampoline
      twice: register_fentry(), unregister_fentry(), then register_fentry again.
      This causes ftrace_set_filter_ip() for the same ip on tr->fops twice,
      which leaves duplicated ip in tr->fops. The extra ip is not cleaned up
      properly on unregister and thus causes failures with further register in
      register_ftrace_direct_multi():
      
      register_ftrace_direct_multi()
      {
              ...
              for (i = 0; i < size; i++) {
                      hlist_for_each_entry(entry, &hash->buckets[i], hlist) {
                              if (ftrace_find_rec_direct(entry->ip))
                                      goto out_unlock;
                      }
              }
              ...
      }
      
      This can be triggered with parallel fentry/fexit tests with test_progs:
      
        ./test_progs -t fentry,fexit -j
      
      Fix this by resetting tr->fops in ftrace_set_filter_ip(), so that there
      will never be duplicated entries in tr->fops.
      
      Fixes: 00963a2e ("bpf: Support bpf_trampoline on functions with IPMODIFY (e.g. livepatch)")
      Reported-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Signed-off-by: default avatarSong Liu <song@kernel.org>
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Link: https://lore.kernel.org/bpf/20220729194106.1207472-1-song@kernel.org
      dc81f8d1
    • Daniel Müller's avatar
      selftests/bpf: Bump internal send_signal/send_signal_tracepoint timeout · 639de43e
      Daniel Müller authored
      The send_signal/send_signal_tracepoint is pretty flaky, with at least
      one failure in every ten runs on a few attempts I've tried it:
        > test_send_signal_common:PASS:pipe_c2p 0 nsec
        > test_send_signal_common:PASS:pipe_p2c 0 nsec
        > test_send_signal_common:PASS:fork 0 nsec
        > test_send_signal_common:PASS:skel_open_and_load 0 nsec
        > test_send_signal_common:PASS:skel_attach 0 nsec
        > test_send_signal_common:PASS:pipe_read 0 nsec
        > test_send_signal_common:PASS:pipe_write 0 nsec
        > test_send_signal_common:PASS:reading pipe 0 nsec
        > test_send_signal_common:PASS:reading pipe error: size 0 0 nsec
        > test_send_signal_common:FAIL:incorrect result unexpected incorrect result: actual 48 != expected 50
        > test_send_signal_common:PASS:pipe_write 0 nsec
        > #139/1   send_signal/send_signal_tracepoint:FAIL
      
      The reason does not appear to be a correctness issue in the strict
      sense. Rather, we merely do not receive the signal we are waiting for
      within the provided timeout.
      Let's bump the timeout by a factor of ten. With that change I have not
      been able to reproduce the failure in 150+ iterations. I am also sneaking
      in a small simplification to the test_progs test selection logic.
      Signed-off-by: default avatarDaniel Müller <deso@posteo.net>
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Acked-by: default avatarJiri Olsa <jolsa@kernel.org>
      Acked-by: default avatarYonghong Song <yhs@fb.com>
      Link: https://lore.kernel.org/bpf/20220727182955.4044988-1-deso@posteo.net
      639de43e
    • Jörn-Thorben Hinz's avatar
      bpftool: Don't try to return value from void function in skeleton · a6df0674
      Jörn-Thorben Hinz authored
      A skeleton generated by bpftool previously contained a return followed
      by an expression in OBJ_NAME__detach(), which has return type void. This
      did not hurt, the bpf_object__detach_skeleton() called there returns
      void itself anyway, but led to a warning when compiling with e.g.
      -pedantic.
      Signed-off-by: default avatarJörn-Thorben Hinz <jthinz@mailbox.tu-berlin.de>
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Reviewed-by: default avatarQuentin Monnet <quentin@isovalent.com>
      Link: https://lore.kernel.org/bpf/20220726133203.514087-1-jthinz@mailbox.tu-berlin.de
      a6df0674