1. 20 Oct, 2023 10 commits
    • Kumar Kartikeya Dwivedi's avatar
      selftests/bpf: Make linked_list failure test more robust · da1055b6
      Kumar Kartikeya Dwivedi authored
      The linked list failure test 'pop_front_off' and 'pop_back_off'
      currently rely on matching exact instruction and register values.  The
      purpose of the test is to ensure the offset is correctly incremented for
      the returned pointers from list pop helpers, which can then be used with
      container_of to obtain the real object. Hence, somehow obtaining the
      information that the offset is 48 will work for us. Make the test more
      robust by relying on verifier error string of bpf_spin_lock and remove
      dependence on fragile instruction index or register number, which can be
      affected by different clang versions used to build the selftests.
      
      Fixes: 300f19dc ("selftests/bpf: Add BPF linked list API tests")
      Reported-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Signed-off-by: default avatarKumar Kartikeya Dwivedi <memxor@gmail.com>
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Link: https://lore.kernel.org/bpf/20231020144839.2734006-1-memxor@gmail.com
      da1055b6
    • Alexei Starovoitov's avatar
      Merge branch 'add-open-coded-task-css_task-and-css-iters' · bab8ac3c
      Alexei Starovoitov authored
      Chuyi Zhou says:
      
      ====================
      Add Open-coded task, css_task and css iters
      
      This is version 6 of task, css_task and css iters support.
      
      --- Changelog ---
      
      v5 -> v6:
      
      Patch #3:
       * In bpf_iter_task_next, return pos rather than goto out. (Andrii)
      Patch #2, #3, #4:
       * Add the missing __diag_ignore_all to avoid kernel build warning
      Patch #5, #6, #7:
       * Add Andrii's ack
      
      Patch #8:
       * In BPF prog iter_css_task_for_each, return -EPERM rather than 0, and
         ensure stack_mprotect() in iters.c not success. If not, it would cause
         the subsequent 'test_lsm' fail, since the 'is_stack' check in
         test_int_hook(lsm.c) would not be guaranteed.
         (https://github.com/kernel-patches/bpf/actions/runs/6489662214/job/17624665086?pr=5790)
      
      v4 -> v5:https://lore.kernel.org/lkml/20231007124522.34834-1-zhouchuyi@bytedance.com/
      
      Patch 3~4:
       * Relax the BUILD_BUG_ON check in bpf_iter_task_new and bpf_iter_css_new to avoid
         netdev/build_32bit CI error.
         (https://netdev.bots.linux.dev/static/nipa/790929/13412333/build_32bit/stderr)
      Patch 8:
       * Initialize skel pointer to fix the LLVM-16 build CI error
         (https://github.com/kernel-patches/bpf/actions/runs/6462875618/job/17545170863)
      
      v3 -> v4:https://lore.kernel.org/all/20230925105552.817513-1-zhouchuyi@bytedance.com/
      
      * Address all the comments from Andrii in patch-3 ~ patch-6
      * Collect Tejun's ack
      * Add a extra patch to rename bpf_iter_task.c to bpf_iter_tasks.c
      * Seperate three BPF program files for selftests (iters_task.c iters_css_task.c iters_css.c)
      
      v2 -> v3:https://lore.kernel.org/lkml/20230912070149.969939-1-zhouchuyi@bytedance.com/
      
      Patch 1 (cgroup: Prepare for using css_task_iter_*() in BPF)
        * Add tj's ack and Alexei's suggest-by.
      Patch 2 (bpf: Introduce css_task open-coded iterator kfuncs)
        * Use bpf_mem_alloc/bpf_mem_free rather than kzalloc()
        * Add KF_TRUSTED_ARGS for bpf_iter_css_task_new (Alexei)
        * Move bpf_iter_css_task's definition from uapi/linux/bpf.h to
          kernel/bpf/task_iter.c and we can use it from vmlinux.h
        * Move bpf_iter_css_task_XXX's declaration from bpf_helpers.h to
          bpf_experimental.h
      Patch 3 (Introduce task open coded iterator kfuncs)
        * Change th API design keep consistent with SEC("iter/task"), support
          iterating all threads(BPF_TASK_ITERATE_ALL) and threads of a
          specific task (BPF_TASK_ITERATE_THREAD).(Andrii)
        * Move bpf_iter_task's definition from uapi/linux/bpf.h to
          kernel/bpf/task_iter.c and we can use it from vmlinux.h
        * Move bpf_iter_task_XXX's declaration from bpf_helpers.h to
          bpf_experimental.h
      Patch 4 (Introduce css open-coded iterator kfuncs)
        * Change th API design keep consistent with cgroup_iters, reuse
          BPF_CGROUP_ITER_DESCENDANTS_PRE/BPF_CGROUP_ITER_DESCENDANTS_POST
          /BPF_CGROUP_ITER_ANCESTORS_UP(Andrii)
        * Add KF_TRUSTED_ARGS for bpf_iter_css_new
        * Move bpf_iter_css's definition from uapi/linux/bpf.h to
          kernel/bpf/task_iter.c and we can use it from vmlinux.h
        * Move bpf_iter_css_XXX's declaration from bpf_helpers.h to
          bpf_experimental.h
      Patch 5 (teach the verifier to enforce css_iter and task_iter in RCU CS)
        * Add KF flag KF_RCU_PROTECTED to maintain kfuncs which need RCU CS.(Andrii)
        * Consider STACK_ITER when using bpf_for_each_spilled_reg.
      Patch 6 (Let bpf_iter_task_new accept null task ptr)
        * Add this extra patch to let bpf_iter_task_new accept a 'nullable'
        * task pointer(Andrii)
      Patch 7 (selftests/bpf: Add tests for open-coded task and css iter)
        * Add failure testcase(Alexei)
      
      Changes from v1(https://lore.kernel.org/lkml/20230827072057.1591929-1-zhouchuyi@bytedance.com/):
      - Add a pre-patch to make some preparations before supporting css_task
        iters.(Alexei)
      - Add an allowlist for css_task iters(Alexei)
      - Let bpf progs do explicit bpf_rcu_read_lock() when using process
        iters and css_descendant iters.(Alexei)
      ---------------------
      
      In some BPF usage scenarios, it will be useful to iterate the process and
      css directly in the BPF program. One of the expected scenarios is
      customizable OOM victim selection via BPF[1].
      
      Inspired by Dave's task_vma iter[2], this patchset adds three types of
      open-coded iterator kfuncs:
      
      1. bpf_task_iters. It can be used to
      1) iterate all process in the system, like for_each_forcess() in kernel.
      2) iterate all threads in the system.
      3) iterate all threads of a specific task
      
      2. bpf_css_iters. It works like css_task_iter_{start, next, end} and would
      be used to iterating tasks/threads under a css.
      
      3. css_iters. It works like css_next_descendant_{pre, post} to iterating all
      descendant css.
      
      BPF programs can use these kfuncs directly or through bpf_for_each macro.
      
      link[1]: https://lore.kernel.org/lkml/20230810081319.65668-1-zhouchuyi@bytedance.com/
      link[2]: https://lore.kernel.org/all/20230810183513.684836-1-davemarchevsky@fb.com/
      ====================
      
      Link: https://lore.kernel.org/r/20231018061746.111364-1-zhouchuyi@bytedance.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      bab8ac3c
    • Chuyi Zhou's avatar
      selftests/bpf: Add tests for open-coded task and css iter · 130e0f7a
      Chuyi Zhou authored
      This patch adds 4 subtests to demonstrate these patterns and validating
      correctness.
      
      subtest1:
      
      1) We use task_iter to iterate all process in the system and search for the
      current process with a given pid.
      
      2) We create some threads in current process context, and use
      BPF_TASK_ITER_PROC_THREADS to iterate all threads of current process. As
      expected, we would find all the threads of current process.
      
      3) We create some threads and use BPF_TASK_ITER_ALL_THREADS to iterate all
      threads in the system. As expected, we would find all the threads which was
      created.
      
      subtest2:
      
      We create a cgroup and add the current task to the cgroup. In the
      BPF program, we would use bpf_for_each(css_task, task, css) to iterate all
      tasks under the cgroup. As expected, we would find the current process.
      
      subtest3:
      
      1) We create a cgroup tree. In the BPF program, we use
      bpf_for_each(css, pos, root, XXX) to iterate all descendant under the root
      with pre and post order. As expected, we would find all descendant and the
      last iterating cgroup in post-order is root cgroup, the first iterating
      cgroup in pre-order is root cgroup.
      
      2) We wse BPF_CGROUP_ITER_ANCESTORS_UP to traverse the cgroup tree starting
      from leaf and root separately, and record the height. The diff of the
      hights would be the total tree-high - 1.
      
      subtest4:
      
      Add some failure testcase when using css_task, task and css iters, e.g,
      unlock when using task-iters to iterate tasks.
      Signed-off-by: default avatarChuyi Zhou <zhouchuyi@bytedance.com>
      Link: https://lore.kernel.org/r/20231018061746.111364-9-zhouchuyi@bytedance.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      130e0f7a
    • Chuyi Zhou's avatar
      selftests/bpf: rename bpf_iter_task.c to bpf_iter_tasks.c · ddab78cb
      Chuyi Zhou authored
      The newly-added struct bpf_iter_task has a name collision with a selftest
      for the seq_file task iter's bpf skel, so the selftests/bpf/progs file is
      renamed in order to avoid the collision.
      Signed-off-by: default avatarChuyi Zhou <zhouchuyi@bytedance.com>
      Acked-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Link: https://lore.kernel.org/r/20231018061746.111364-8-zhouchuyi@bytedance.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      ddab78cb
    • Chuyi Zhou's avatar
      bpf: Let bpf_iter_task_new accept null task ptr · cb3ecf79
      Chuyi Zhou authored
      When using task_iter to iterate all threads of a specific task, we enforce
      that the user must pass a valid task pointer to ensure safety. However,
      when iterating all threads/process in the system, BPF verifier still
      require a valid ptr instead of "nullable" pointer, even though it's
      pointless, which is a kind of surprising from usability standpoint. It
      would be nice if we could let that kfunc accept a explicit null pointer
      when we are using BPF_TASK_ITER_ALL_{PROCS, THREADS} and a valid pointer
      when using BPF_TASK_ITER_THREAD.
      
      Given a trival kfunc:
      	__bpf_kfunc void FN(struct TYPE_A *obj);
      
      BPF Prog would reject a nullptr for obj. The error info is:
      "arg#x pointer type xx xx must point to scalar, or struct with scalar"
      reported by get_kfunc_ptr_arg_type(). The reg->type is SCALAR_VALUE and
      the btf type of ref_t is not scalar or scalar_struct which leads to the
      rejection of get_kfunc_ptr_arg_type.
      
      This patch add "__nullable" annotation:
      	__bpf_kfunc void FN(struct TYPE_A *obj__nullable);
      Here __nullable indicates obj can be optional, user can pass a explicit
      nullptr or a normal TYPE_A pointer. In get_kfunc_ptr_arg_type(), we will
      detect whether the current arg is optional and register is null, If so,
      return a new kfunc_ptr_arg_type KF_ARG_PTR_TO_NULL and skip to the next
      arg in check_kfunc_args().
      Signed-off-by: default avatarChuyi Zhou <zhouchuyi@bytedance.com>
      Acked-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Link: https://lore.kernel.org/r/20231018061746.111364-7-zhouchuyi@bytedance.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      cb3ecf79
    • Chuyi Zhou's avatar
      bpf: teach the verifier to enforce css_iter and task_iter in RCU CS · dfab99df
      Chuyi Zhou authored
      css_iter and task_iter should be used in rcu section. Specifically, in
      sleepable progs explicit bpf_rcu_read_lock() is needed before use these
      iters. In normal bpf progs that have implicit rcu_read_lock(), it's OK to
      use them directly.
      
      This patch adds a new a KF flag KF_RCU_PROTECTED for bpf_iter_task_new and
      bpf_iter_css_new. It means the kfunc should be used in RCU CS. We check
      whether we are in rcu cs before we want to invoke this kfunc. If the rcu
      protection is guaranteed, we would let st->type = PTR_TO_STACK | MEM_RCU.
      Once user do rcu_unlock during the iteration, state MEM_RCU of regs would
      be cleared. is_iter_reg_valid_init() will reject if reg->type is UNTRUSTED.
      
      It is worth noting that currently, bpf_rcu_read_unlock does not
      clear the state of the STACK_ITER reg, since bpf_for_each_spilled_reg
      only considers STACK_SPILL. This patch also let bpf_for_each_spilled_reg
      search STACK_ITER.
      Signed-off-by: default avatarChuyi Zhou <zhouchuyi@bytedance.com>
      Acked-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Link: https://lore.kernel.org/r/20231018061746.111364-6-zhouchuyi@bytedance.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      dfab99df
    • Chuyi Zhou's avatar
      bpf: Introduce css open-coded iterator kfuncs · 7251d090
      Chuyi Zhou authored
      This Patch adds kfuncs bpf_iter_css_{new,next,destroy} which allow
      creation and manipulation of struct bpf_iter_css in open-coded iterator
      style. These kfuncs actually wrapps css_next_descendant_{pre, post}.
      css_iter can be used to:
      
      1) iterating a sepcific cgroup tree with pre/post/up order
      
      2) iterating cgroup_subsystem in BPF Prog, like
      for_each_mem_cgroup_tree/cpuset_for_each_descendant_pre in kernel.
      
      The API design is consistent with cgroup_iter. bpf_iter_css_new accepts
      parameters defining iteration order and starting css. Here we also reuse
      BPF_CGROUP_ITER_DESCENDANTS_PRE, BPF_CGROUP_ITER_DESCENDANTS_POST,
      BPF_CGROUP_ITER_ANCESTORS_UP enums.
      Signed-off-by: default avatarChuyi Zhou <zhouchuyi@bytedance.com>
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      Link: https://lore.kernel.org/r/20231018061746.111364-5-zhouchuyi@bytedance.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      7251d090
    • Chuyi Zhou's avatar
      bpf: Introduce task open coded iterator kfuncs · c68a78ff
      Chuyi Zhou authored
      This patch adds kfuncs bpf_iter_task_{new,next,destroy} which allow
      creation and manipulation of struct bpf_iter_task in open-coded iterator
      style. BPF programs can use these kfuncs or through bpf_for_each macro to
      iterate all processes in the system.
      
      The API design keep consistent with SEC("iter/task"). bpf_iter_task_new()
      accepts a specific task and iterating type which allows:
      
      1. iterating all process in the system (BPF_TASK_ITER_ALL_PROCS)
      
      2. iterating all threads in the system (BPF_TASK_ITER_ALL_THREADS)
      
      3. iterating all threads of a specific task (BPF_TASK_ITER_PROC_THREADS)
      Signed-off-by: default avatarChuyi Zhou <zhouchuyi@bytedance.com>
      Link: https://lore.kernel.org/r/20231018061746.111364-4-zhouchuyi@bytedance.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      c68a78ff
    • Chuyi Zhou's avatar
      bpf: Introduce css_task open-coded iterator kfuncs · 9c66dc94
      Chuyi Zhou authored
      This patch adds kfuncs bpf_iter_css_task_{new,next,destroy} which allow
      creation and manipulation of struct bpf_iter_css_task in open-coded
      iterator style. These kfuncs actually wrapps css_task_iter_{start,next,
      end}. BPF programs can use these kfuncs through bpf_for_each macro for
      iteration of all tasks under a css.
      
      css_task_iter_*() would try to get the global spin-lock *css_set_lock*, so
      the bpf side has to be careful in where it allows to use this iter.
      Currently we only allow it in bpf_lsm and bpf iter-s.
      Signed-off-by: default avatarChuyi Zhou <zhouchuyi@bytedance.com>
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      Link: https://lore.kernel.org/r/20231018061746.111364-3-zhouchuyi@bytedance.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      9c66dc94
    • Chuyi Zhou's avatar
      cgroup: Prepare for using css_task_iter_*() in BPF · 6da88306
      Chuyi Zhou authored
      This patch makes some preparations for using css_task_iter_*() in BPF
      Program.
      
      1. Flags CSS_TASK_ITER_* are #define-s and it's not easy for bpf prog to
      use them. Convert them to enum so bpf prog can take them from vmlinux.h.
      
      2. In the next patch we will add css_task_iter_*() in common kfuncs which
      is not safe. Since css_task_iter_*() does spin_unlock_irq() which might
      screw up irq flags depending on the context where bpf prog is running.
      So we should use irqsave/irqrestore here and the switching is harmless.
      Suggested-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarChuyi Zhou <zhouchuyi@bytedance.com>
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      Link: https://lore.kernel.org/r/20231018061746.111364-2-zhouchuyi@bytedance.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      6da88306
  2. 19 Oct, 2023 2 commits
  3. 18 Oct, 2023 2 commits
  4. 17 Oct, 2023 8 commits
    • Daniel Borkmann's avatar
      selftests/bpf: Add additional mprog query test coverage · 24516309
      Daniel Borkmann authored
      Add several new test cases which assert corner cases on the mprog query
      mechanism, for example, around passing in a too small or a larger array
      than the current count.
      
        ./test_progs -t tc_opts
        #252     tc_opts_after:OK
        #253     tc_opts_append:OK
        #254     tc_opts_basic:OK
        #255     tc_opts_before:OK
        #256     tc_opts_chain_classic:OK
        #257     tc_opts_chain_mixed:OK
        #258     tc_opts_delete_empty:OK
        #259     tc_opts_demixed:OK
        #260     tc_opts_detach:OK
        #261     tc_opts_detach_after:OK
        #262     tc_opts_detach_before:OK
        #263     tc_opts_dev_cleanup:OK
        #264     tc_opts_invalid:OK
        #265     tc_opts_max:OK
        #266     tc_opts_mixed:OK
        #267     tc_opts_prepend:OK
        #268     tc_opts_query:OK
        #269     tc_opts_query_attach:OK
        #270     tc_opts_replace:OK
        #271     tc_opts_revision:OK
        Summary: 20/0 PASSED, 0 SKIPPED, 0 FAILED
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Reviewed-by: default avatarAlan Maguire <alan.maguire@oracle.com>
      Link: https://lore.kernel.org/bpf/20231017081728.24769-1-daniel@iogearbox.net
      24516309
    • Yafang Shao's avatar
      selftests/bpf: Add selftest for bpf_task_under_cgroup() in sleepable prog · 44cb03f1
      Yafang Shao authored
      The result is as follows:
      
        $ tools/testing/selftests/bpf/test_progs --name=task_under_cgroup
        #237     task_under_cgroup:OK
        Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED
      
      Without the previous patch, there will be RCU warnings in dmesg when
      CONFIG_PROVE_RCU is enabled. While with the previous patch, there will
      be no warnings.
      Signed-off-by: default avatarYafang Shao <laoar.shao@gmail.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarStanislav Fomichev <sdf@google.com>
      Link: https://lore.kernel.org/bpf/20231007135945.4306-2-laoar.shao@gmail.com
      44cb03f1
    • Yafang Shao's avatar
      bpf: Fix missed rcu read lock in bpf_task_under_cgroup() · 29a7e00f
      Yafang Shao authored
      When employed within a sleepable program not under RCU protection, the
      use of 'bpf_task_under_cgroup()' may trigger a warning in the kernel log,
      particularly when CONFIG_PROVE_RCU is enabled:
      
        [ 1259.662357] WARNING: suspicious RCU usage
        [ 1259.662358] 6.5.0+ #33 Not tainted
        [ 1259.662360] -----------------------------
        [ 1259.662361] include/linux/cgroup.h:423 suspicious rcu_dereference_check() usage!
      
      Other info that might help to debug this:
      
        [ 1259.662366] rcu_scheduler_active = 2, debug_locks = 1
        [ 1259.662368] 1 lock held by trace/72954:
        [ 1259.662369]  #0: ffffffffb5e3eda0 (rcu_read_lock_trace){....}-{0:0}, at: __bpf_prog_enter_sleepable+0x0/0xb0
      
      Stack backtrace:
      
        [ 1259.662385] CPU: 50 PID: 72954 Comm: trace Kdump: loaded Not tainted 6.5.0+ #33
        [ 1259.662391] Call Trace:
        [ 1259.662393]  <TASK>
        [ 1259.662395]  dump_stack_lvl+0x6e/0x90
        [ 1259.662401]  dump_stack+0x10/0x20
        [ 1259.662404]  lockdep_rcu_suspicious+0x163/0x1b0
        [ 1259.662412]  task_css_set.part.0+0x23/0x30
        [ 1259.662417]  bpf_task_under_cgroup+0xe7/0xf0
        [ 1259.662422]  bpf_prog_7fffba481a3bcf88_lsm_run+0x5c/0x93
        [ 1259.662431]  bpf_trampoline_6442505574+0x60/0x1000
        [ 1259.662439]  bpf_lsm_bpf+0x5/0x20
        [ 1259.662443]  ? security_bpf+0x32/0x50
        [ 1259.662452]  __sys_bpf+0xe6/0xdd0
        [ 1259.662463]  __x64_sys_bpf+0x1a/0x30
        [ 1259.662467]  do_syscall_64+0x38/0x90
        [ 1259.662472]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
        [ 1259.662479] RIP: 0033:0x7f487baf8e29
        [...]
        [ 1259.662504]  </TASK>
      
      This issue can be reproduced by executing a straightforward program, as
      demonstrated below:
      
      SEC("lsm.s/bpf")
      int BPF_PROG(lsm_run, int cmd, union bpf_attr *attr, unsigned int size)
      {
              struct cgroup *cgrp = NULL;
              struct task_struct *task;
              int ret = 0;
      
              if (cmd != BPF_LINK_CREATE)
                      return 0;
      
              // The cgroup2 should be mounted first
              cgrp = bpf_cgroup_from_id(1);
              if (!cgrp)
                      goto out;
              task = bpf_get_current_task_btf();
              if (bpf_task_under_cgroup(task, cgrp))
                      ret = -1;
              bpf_cgroup_release(cgrp);
      
      out:
              return ret;
      }
      
      After running the program, if you subsequently execute another BPF program,
      you will encounter the warning.
      
      It's worth noting that task_under_cgroup_hierarchy() is also utilized by
      bpf_current_task_under_cgroup(). However, bpf_current_task_under_cgroup()
      doesn't exhibit this issue because it cannot be used in sleepable BPF
      programs.
      
      Fixes: b5ad4cdc ("bpf: Add bpf_task_under_cgroup() kfunc")
      Signed-off-by: default avatarYafang Shao <laoar.shao@gmail.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarStanislav Fomichev <sdf@google.com>
      Cc: Feng Zhou <zhoufeng.zf@bytedance.com>
      Cc: KP Singh <kpsingh@kernel.org>
      Link: https://lore.kernel.org/bpf/20231007135945.4306-1-laoar.shao@gmail.com
      29a7e00f
    • Sebastian Andrzej Siewior's avatar
      net, bpf: Add a warning if NAPI cb missed xdp_do_flush(). · 9a675ba5
      Sebastian Andrzej Siewior authored
      A few drivers were missing a xdp_do_flush() invocation after
      XDP_REDIRECT.
      
      Add three helper functions each for one of the per-CPU lists. Return
      true if the per-CPU list is non-empty and flush the list.
      
      Add xdp_do_check_flushed() which invokes each helper functions and
      creates a warning if one of the functions had a non-empty list.
      
      Hide everything behind CONFIG_DEBUG_NET.
      Suggested-by: default avatarJesper Dangaard Brouer <hawk@kernel.org>
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Reviewed-by: default avatarToke Høiland-Jørgensen <toke@redhat.com>
      Acked-by: default avatarJakub Kicinski <kuba@kernel.org>
      Acked-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Link: https://lore.kernel.org/bpf/20231016125738.Yt79p1uF@linutronix.de
      9a675ba5
    • Andrii Nakryiko's avatar
      libbpf: Don't assume SHT_GNU_verdef presence for SHT_GNU_versym section · 137df118
      Andrii Nakryiko authored
      Fix too eager assumption that SHT_GNU_verdef ELF section is going to be
      present whenever binary has SHT_GNU_versym section. It seems like either
      SHT_GNU_verdef or SHT_GNU_verneed can be used, so failing on missing
      SHT_GNU_verdef actually breaks use cases in production.
      
      One specific reported issue, which was used to manually test this fix,
      was trying to attach to `readline` function in BASH binary.
      
      Fixes: bb7fa093 ("libbpf: Support symbol versioning for uprobe")
      Reported-by: default avatarLiam Wisehart <liamwisehart@meta.com>
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Tested-by: default avatarManu Bretelle <chantr4@gmail.com>
      Reviewed-by: default avatarFangrui Song <maskray@google.com>
      Acked-by: default avatarHengqi Chen <hengqi.chen@gmail.com>
      Link: https://lore.kernel.org/bpf/20231016182840.4033346-1-andrii@kernel.org
      137df118
    • Jakub Kicinski's avatar
      Merge tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next · a3c2dd96
      Jakub Kicinski authored
      Daniel Borkmann says:
      
      ====================
      pull-request: bpf-next 2023-10-16
      
      We've added 90 non-merge commits during the last 25 day(s) which contain
      a total of 120 files changed, 3519 insertions(+), 895 deletions(-).
      
      The main changes are:
      
      1) Add missed stats for kprobes to retrieve the number of missed kprobe
         executions and subsequent executions of BPF programs, from Jiri Olsa.
      
      2) Add cgroup BPF sockaddr hooks for unix sockets. The use case is
         for systemd to reimplement the LogNamespace feature which allows
         running multiple instances of systemd-journald to process the logs
         of different services, from Daan De Meyer.
      
      3) Implement BPF CPUv4 support for s390x BPF JIT, from Ilya Leoshkevich.
      
      4) Improve BPF verifier log output for scalar registers to better
         disambiguate their internal state wrt defaults vs min/max values
         matching, from Andrii Nakryiko.
      
      5) Extend the BPF fib lookup helpers for IPv4/IPv6 to support retrieving
         the source IP address with a new BPF_FIB_LOOKUP_SRC flag,
         from Martynas Pumputis.
      
      6) Add support for open-coded task_vma iterator to help with symbolization
         for BPF-collected user stacks, from Dave Marchevsky.
      
      7) Add libbpf getters for accessing individual BPF ring buffers which
         is useful for polling them individually, for example, from Martin Kelly.
      
      8) Extend AF_XDP selftests to validate the SHARED_UMEM feature,
         from Tushar Vyavahare.
      
      9) Improve BPF selftests cross-building support for riscv arch,
         from Björn Töpel.
      
      10) Add the ability to pin a BPF timer to the same calling CPU,
         from David Vernet.
      
      11) Fix libbpf's bpf_tracing.h macros for riscv to use the generic
         implementation of PT_REGS_SYSCALL_REGS() to access syscall arguments,
         from Alexandre Ghiti.
      
      12) Extend libbpf to support symbol versioning for uprobes, from Hengqi Chen.
      
      13) Fix bpftool's skeleton code generation to guarantee that ELF data
          is 8 byte aligned, from Ian Rogers.
      
      14) Inherit system-wide cpu_mitigations_off() setting for Spectre v1/v4
          security mitigations in BPF verifier, from Yafang Shao.
      
      15) Annotate struct bpf_stack_map with __counted_by attribute to prepare
          BPF side for upcoming __counted_by compiler support, from Kees Cook.
      
      * tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next: (90 commits)
        bpf: Ensure proper register state printing for cond jumps
        bpf: Disambiguate SCALAR register state output in verifier logs
        selftests/bpf: Make align selftests more robust
        selftests/bpf: Improve missed_kprobe_recursion test robustness
        selftests/bpf: Improve percpu_alloc test robustness
        selftests/bpf: Add tests for open-coded task_vma iter
        bpf: Introduce task_vma open-coded iterator kfuncs
        selftests/bpf: Rename bpf_iter_task_vma.c to bpf_iter_task_vmas.c
        bpf: Don't explicitly emit BTF for struct btf_iter_num
        bpf: Change syscall_nr type to int in struct syscall_tp_t
        net/bpf: Avoid unused "sin_addr_len" warning when CONFIG_CGROUP_BPF is not set
        bpf: Avoid unnecessary audit log for CPU security mitigations
        selftests/bpf: Add tests for cgroup unix socket address hooks
        selftests/bpf: Make sure mount directory exists
        documentation/bpf: Document cgroup unix socket address hooks
        bpftool: Add support for cgroup unix socket address hooks
        libbpf: Add support for cgroup unix socket address hooks
        bpf: Implement cgroup sockaddr hooks for unix sockets
        bpf: Add bpf_sock_addr_set_sun_path() to allow writing unix sockaddr from bpf
        bpf: Propagate modified uaddrlen from cgroup sockaddr programs
        ...
      ====================
      
      Link: https://lore.kernel.org/r/20231016204803.30153-1-daniel@iogearbox.netSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      a3c2dd96
    • Yunsheng Lin's avatar
      page_pool: fragment API support for 32-bit arch with 64-bit DMA · 90de47f0
      Yunsheng Lin authored
      Currently page_pool_alloc_frag() is not supported in 32-bit
      arch with 64-bit DMA because of the overlap issue between
      pp_frag_count and dma_addr_upper in 'struct page' for those
      arches, which seems to be quite common, see [1], which means
      driver may need to handle it when using fragment API.
      
      It is assumed that the combination of the above arch with an
      address space >16TB does not exist, as all those arches have
      64b equivalent, it seems logical to use the 64b version for a
      system with a large address space. It is also assumed that dma
      address is page aligned when we are dma mapping a page aligned
      buffer, see [2].
      
      That means we're storing 12 bits of 0 at the lower end for a
      dma address, we can reuse those bits for the above arches to
      support 32b+12b, which is 16TB of memory.
      
      If we make a wrong assumption, a warning is emitted so that
      user can report to us.
      
      1. https://lore.kernel.org/all/20211117075652.58299-1-linyunsheng@huawei.com/
      2. https://lore.kernel.org/all/20230818145145.4b357c89@kernel.org/Tested-by: default avatarAlexander Lobakin <aleksander.lobakin@intel.com>
      Signed-off-by: default avatarYunsheng Lin <linyunsheng@huawei.com>
      CC: Lorenzo Bianconi <lorenzo@kernel.org>
      CC: Alexander Duyck <alexander.duyck@gmail.com>
      CC: Liang Chen <liangchen.linux@gmail.com>
      CC: Guillaume Tucker <guillaume.tucker@collabora.com>
      CC: Matthew Wilcox <willy@infradead.org>
      CC: Linux-MM <linux-mm@kvack.org>
      Link: https://lore.kernel.org/r/20231013064827.61135-2-linyunsheng@huawei.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      90de47f0
    • Jacob Keller's avatar
      net: stub tcp_gro_complete if CONFIG_INET=n · e411a8e3
      Jacob Keller authored
      A few networking drivers including bnx2x, bnxt, qede, and idpf call
      tcp_gro_complete as part of offloading TCP GRO. The function is only
      defined if CONFIG_INET is true, since its TCP specific and is meaningless
      if the kernel lacks IP networking support.
      
      The combination of trying to use the complex network drivers with
      CONFIG_NET but not CONFIG_INET is rather unlikely in practice: most use
      cases are going to need IP networking.
      
      The tcp_gro_complete function just sets some data in the socket buffer for
      use in processing the TCP packet in the event that the GRO was offloaded to
      the device. If the kernel lacks TCP support, such setup will simply go
      unused.
      
      The bnx2x, bnxt, and qede drivers wrap their TCP offload support in
      CONFIG_INET checks and skip handling on such kernels.
      
      The idpf driver did not check CONFIG_INET and thus fails to link if the
      kernel is configured  with CONFIG_NET=y, CONFIG_IDPF=(m|y), and
      CONFIG_INET=n.
      
      While checking CONFIG_INET does allow the driver to bypass significantly
      more instructions in the event that we know TCP networking isn't supported,
      the configuration is unlikely to be used widely.
      
      Rather than require driver authors to care about this, stub the
      tcp_gro_complete function when CONFIG_INET=n. This allows drivers to be
      left as-is. It does mean the idpf driver will perform slightly more work
      than strictly necessary when CONFIG_INET=n, since it will still execute
      some of the skb setup in idpf_rx_rsc. However, that work would be performed
      in the case where CONFIG_INET=y anyways.
      
      I did not change the existing drivers, since they appear to wrap a
      significant portion of code when CONFIG_INET=n. There is little benefit in
      trashing these drivers just to unwrap and remove the CONFIG_INET check.
      
      Using a stub for tcp_gro_complete is still beneficial, as it means future
      drivers no longer need to worry about this case of CONFIG_NET=y and
      CONFIG_INET=n, which should reduce noise from buildbots that check such a
      configuration.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Acked-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Tested-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
      Link: https://lore.kernel.org/r/20231013185502.1473541-1-jacob.e.keller@intel.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      e411a8e3
  5. 16 Oct, 2023 18 commits