1. 07 Mar, 2023 21 commits
    • Alexei Starovoitov's avatar
      Merge branch 'bpf: bpf memory usage' · a73dc912
      Alexei Starovoitov authored
      Yafang Shao says:
      
      ====================
      
      Currently we can't get bpf memory usage reliably either from memcg or
      from bpftool.
      
      In memcg, there's not a 'bpf' item in memory.stat, but only 'kernel',
      'sock', 'vmalloc' and 'percpu' which may related to bpf memory. With
      these items we still can't get the bpf memory usage, because bpf memory
      usage may far less than the kmem in a memcg, for example, the dentry may
      consume lots of kmem.
      
      bpftool now shows the bpf memory footprint, which is difference with bpf
      memory usage. The difference can be quite great in some cases, for example,
      
      - non-preallocated bpf map
        The non-preallocated bpf map memory usage is dynamically changed. The
        allocated elements count can be from 0 to the max entries. But the
        memory footprint in bpftool only shows a fixed number.
      
      - bpf metadata consumes more memory than bpf element
        In some corner cases, the bpf metadata can consumes a lot more memory
        than bpf element consumes. For example, it can happen when the element
        size is quite small.
      
      - some maps don't have key, value or max_entries
        For example the key_size and value_size of ringbuf is 0, so its
        memlock is always 0.
      
      We need a way to show the bpf memory usage especially there will be more
      and more bpf programs running on the production environment and thus the
      bpf memory usage is not trivial.
      
      This patchset introduces a new map ops ->map_mem_usage to calculate the
      memory usage. Note that we don't intend to make the memory usage 100%
      accurate, while our goal is to make sure there is only a small difference
      between what bpftool reports and the real memory. That small difference
      can be ignored compared to the total usage.  That is enough to monitor
      the bpf memory usage. For example, the user can rely on this value to
      monitor the trend of bpf memory usage, compare the difference in bpf
      memory usage between different bpf program versions, figure out which
      maps consume large memory, and etc.
      
      This patchset implements the bpf memory usage for all maps, and yet there's
      still work to do. We don't want to introduce runtime overhead in the
      element update and delete path, but we have to do it for some
      non-preallocated maps,
      - devmap, xskmap
        When we update or delete an element, it will allocate or free memory.
        In order to track this dynamic memory, we have to track the count in
        element update and delete path.
      
      - cpumap
        The element size of each cpumap element is not determinated. If we
        want to track the usage, we have to count the size of all elements in
        the element update and delete path. So I just put it aside currently.
      
      - local_storage, bpf_local_storage
        When we attach or detach a cgroup, it will allocate or free memory. If
        we want to track the dynamic memory, we also need to do something in
        the update and delete path. So I just put it aside currently.
      
      - offload map
        The element update and delete of offload map is via the netdev dev_ops,
        in which it may dynamically allocate or free memory, but this dynamic
        memory isn't counted in offload map memory usage currently.
      
      The result of each map can be found in the individual patch.
      
      We may also need to track per-container bpf memory usage, that will be
      addressed by a different patchset.
      
      Changes:
      v3->v4: code improvement on ringbuf (Andrii)
              use READ_ONCE() to read lpm_trie (Tao)
              explain why we can't get bpf memory usage from memcg.
      v2->v3: check callback at map creation time and avoid warning (Alexei)
              fix build error under CONFIG_BPF=n (lkp@intel.com)
      v1->v2: calculate the memory usage within bpf (Alexei)
      - [v1] bpf, mm: bpf memory usage
        https://lwn.net/Articles/921991/
      - [RFC PATCH v2] mm, bpf: Add BPF into /proc/meminfo
        https://lwn.net/Articles/919848/
      - [RFC PATCH v1] mm, bpf: Add BPF into /proc/meminfo
        https://lwn.net/Articles/917647/
      - [RFC PATCH] bpf, mm: Add a new item bpf into memory.stat
        https://lore.kernel.org/bpf/20220921170002.29557-1-laoar.shao@gmail].com/
      ====================
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      a73dc912
    • Yafang Shao's avatar
      bpf: enforce all maps having memory usage callback · 6b4a6ea2
      Yafang Shao authored
      We have implemented memory usage callback for all maps, and we enforce
      any newly added map having a callback as well. We check this callback at
      map creation time. If it doesn't have the callback, we will return
      EINVAL.
      Signed-off-by: default avatarYafang Shao <laoar.shao@gmail.com>
      Link: https://lore.kernel.org/r/20230305124615.12358-19-laoar.shao@gmail.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      6b4a6ea2
    • Yafang Shao's avatar
      bpf: offload map memory usage · 9629363c
      Yafang Shao authored
      A new helper is introduced to calculate offload map memory usage. But
      currently the memory dynamically allocated in netdev dev_ops, like
      nsim_map_update_elem, is not counted. Let's just put it aside now.
      Signed-off-by: default avatarYafang Shao <laoar.shao@gmail.com>
      Link: https://lore.kernel.org/r/20230305124615.12358-18-laoar.shao@gmail.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      9629363c
    • Yafang Shao's avatar
      bpf, net: xskmap memory usage · b4fd0d67
      Yafang Shao authored
      A new helper is introduced to calculate xskmap memory usage.
      
      The xfsmap memory usage can be dynamically changed when we add or remove
      a xsk_map_node. Hence we need to track the count of xsk_map_node to get
      its memory usage.
      
      The result as follows,
      - before
      10: xskmap  name count_map  flags 0x0
              key 4B  value 4B  max_entries 65536  memlock 524288B
      
      - after
      10: xskmap  name count_map  flags 0x0 <<< no elements case
              key 4B  value 4B  max_entries 65536  memlock 524608B
      Signed-off-by: default avatarYafang Shao <laoar.shao@gmail.com>
      Link: https://lore.kernel.org/r/20230305124615.12358-17-laoar.shao@gmail.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      b4fd0d67
    • Yafang Shao's avatar
      bpf, net: sock_map memory usage · 73d2c619
      Yafang Shao authored
      sockmap and sockhash don't have something in common in allocation, so let's
      introduce different helpers to calculate their memory usage.
      
      The reuslt as follows,
      
      - before
      28: sockmap  name count_map  flags 0x0
              key 4B  value 4B  max_entries 65536  memlock 524288B
      29: sockhash  name count_map  flags 0x0
              key 4B  value 4B  max_entries 65536  memlock 524288B
      
      - after
      28: sockmap  name count_map  flags 0x0
              key 4B  value 4B  max_entries 65536  memlock 524608B
      29: sockhash  name count_map  flags 0x0  <<<< no updated elements
              key 4B  value 4B  max_entries 65536  memlock 1048896B
      Signed-off-by: default avatarYafang Shao <laoar.shao@gmail.com>
      Link: https://lore.kernel.org/r/20230305124615.12358-16-laoar.shao@gmail.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      73d2c619
    • Yafang Shao's avatar
      bpf, net: bpf_local_storage memory usage · 7490b7f1
      Yafang Shao authored
      A new helper is introduced into bpf_local_storage map to calculate the
      memory usage. This helper is also used by other maps like
      bpf_cgrp_storage, bpf_inode_storage, bpf_task_storage and etc.
      
      Note that currently the dynamically allocated storage elements are not
      counted in the usage, since it will take extra runtime overhead in the
      elements update or delete path. So let's put it aside now, and implement
      it in the future when someone really need it.
      Signed-off-by: default avatarYafang Shao <laoar.shao@gmail.com>
      Link: https://lore.kernel.org/r/20230305124615.12358-15-laoar.shao@gmail.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      7490b7f1
    • Yafang Shao's avatar
      bpf: local_storage memory usage · 2f536977
      Yafang Shao authored
      A new helper is introduced to calculate local_storage map memory usage.
      Currently the dynamically allocated elements are not counted, since it
      will take runtime overhead in the element update or delete path. So
      let's put it aside currently, and implement it in the future if the user
      really needs it.
      Signed-off-by: default avatarYafang Shao <laoar.shao@gmail.com>
      Link: https://lore.kernel.org/r/20230305124615.12358-14-laoar.shao@gmail.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      2f536977
    • Yafang Shao's avatar
      bpf: bpf_struct_ops memory usage · f062226d
      Yafang Shao authored
      A new helper is introduced to calculate bpf_struct_ops memory usage.
      
      The result as follows,
      
      - before
      1: struct_ops  name count_map  flags 0x0
              key 4B  value 256B  max_entries 1  memlock 4096B
              btf_id 73
      
      - after
      1: struct_ops  name count_map  flags 0x0
              key 4B  value 256B  max_entries 1  memlock 5016B
              btf_id 73
      Signed-off-by: default avatarYafang Shao <laoar.shao@gmail.com>
      Link: https://lore.kernel.org/r/20230305124615.12358-13-laoar.shao@gmail.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      f062226d
    • Yafang Shao's avatar
      bpf: queue_stack_maps memory usage · c6e66b42
      Yafang Shao authored
      A new helper is introduced to calculate queue_stack_maps memory usage.
      
      The result as follows,
      
      - before
      20: queue  name count_map  flags 0x0
              key 0B  value 4B  max_entries 65536  memlock 266240B
      21: stack  name count_map  flags 0x0
              key 0B  value 4B  max_entries 65536  memlock 266240B
      
      - after
      20: queue  name count_map  flags 0x0
              key 0B  value 4B  max_entries 65536  memlock 524288B
      21: stack  name count_map  flags 0x0
              key 0B  value 4B  max_entries 65536  memlock 524288B
      Signed-off-by: default avatarYafang Shao <laoar.shao@gmail.com>
      Link: https://lore.kernel.org/r/20230305124615.12358-12-laoar.shao@gmail.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      c6e66b42
    • Yafang Shao's avatar
      bpf: devmap memory usage · fa5e83df
      Yafang Shao authored
      A new helper is introduced to calculate the memory usage of devmap and
      devmap_hash. The number of dynamically allocated elements are recored
      for devmap_hash already, but not for devmap. To track the memory size of
      dynamically allocated elements, this patch also count the numbers for
      devmap.
      
      The result as follows,
      - before
      40: devmap  name count_map  flags 0x80
              key 4B  value 4B  max_entries 65536  memlock 524288B
      41: devmap_hash  name count_map  flags 0x80
              key 4B  value 4B  max_entries 65536  memlock 524288B
      
      - after
      40: devmap  name count_map  flags 0x80  <<<< no elements
              key 4B  value 4B  max_entries 65536  memlock 524608B
      41: devmap_hash  name count_map  flags 0x80 <<<< no elements
              key 4B  value 4B  max_entries 65536  memlock 524608B
      
      Note that the number of buckets is same with max_entries for devmap_hash
      in this case.
      Signed-off-by: default avatarYafang Shao <laoar.shao@gmail.com>
      Link: https://lore.kernel.org/r/20230305124615.12358-11-laoar.shao@gmail.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      fa5e83df
    • Yafang Shao's avatar
      bpf: cpumap memory usage · 835f1fca
      Yafang Shao authored
      A new helper is introduced to calculate cpumap memory usage. The size of
      cpu_entries can be dynamically changed when we update or delete a cpumap
      element, but this patch doesn't include the memory size of cpu_entry
      yet. We can dynamically calculate the memory usage when we alloc or free
      a cpu_entry, but it will take extra runtime overhead, so let just put it
      aside currently. Note that the size of different cpu_entry may be
      different as well.
      
      The result as follows,
      - before
      48: cpumap  name count_map  flags 0x4
              key 4B  value 4B  max_entries 64  memlock 4096B
      
      - after
      48: cpumap  name count_map  flags 0x4
              key 4B  value 4B  max_entries 64  memlock 832B
      Signed-off-by: default avatarYafang Shao <laoar.shao@gmail.com>
      Link: https://lore.kernel.org/r/20230305124615.12358-10-laoar.shao@gmail.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      835f1fca
    • Yafang Shao's avatar
      bpf: bloom_filter memory usage · 71a49abe
      Yafang Shao authored
      Introduce a new helper to calculate the bloom_filter memory usage.
      
      The result as follows,
      - before
      16: bloom_filter  flags 0x0
              key 0B  value 8B  max_entries 65536  memlock 524288B
      
      - after
      16: bloom_filter  flags 0x0
              key 0B  value 8B  max_entries 65536  memlock 65856B
      Signed-off-by: default avatarYafang Shao <laoar.shao@gmail.com>
      Link: https://lore.kernel.org/r/20230305124615.12358-9-laoar.shao@gmail.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      71a49abe
    • Yafang Shao's avatar
      bpf: ringbuf memory usage · 2f7e4ab2
      Yafang Shao authored
      A new helper ringbuf_map_mem_usage() is introduced to calculate ringbuf
      memory usage.
      
      The result as follows,
      - before
      15: ringbuf  name count_map  flags 0x0
              key 0B  value 0B  max_entries 65536  memlock 0B
      
      - after
      15: ringbuf  name count_map  flags 0x0
              key 0B  value 0B  max_entries 65536  memlock 78424B
      Signed-off-by: default avatarYafang Shao <laoar.shao@gmail.com>
      Acked-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Link: https://lore.kernel.org/r/20230305124615.12358-8-laoar.shao@gmail.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      2f7e4ab2
    • Yafang Shao's avatar
      bpf: reuseport_array memory usage · 2e89caf0
      Yafang Shao authored
      A new helper is introduced to calculate reuseport_array memory usage.
      
      The result as follows,
      - before
      14: reuseport_sockarray  name count_map  flags 0x0
              key 4B  value 8B  max_entries 65536  memlock 1048576B
      
      - after
      14: reuseport_sockarray  name count_map  flags 0x0
              key 4B  value 8B  max_entries 65536  memlock 524544B
      Signed-off-by: default avatarYafang Shao <laoar.shao@gmail.com>
      Link: https://lore.kernel.org/r/20230305124615.12358-7-laoar.shao@gmail.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      2e89caf0
    • Yafang Shao's avatar
      bpf: stackmap memory usage · cbb9b606
      Yafang Shao authored
      A new helper is introduced to get stackmap memory usage. Some small
      memory allocations are ignored as their memory size is quite small
      compared to the totol usage.
      
      The result as follows,
      - before
      16: stack_trace  name count_map  flags 0x0
              key 4B  value 8B  max_entries 65536  memlock 1048576B
      
      - after
      16: stack_trace  name count_map  flags 0x0
              key 4B  value 8B  max_entries 65536  memlock 2097472B
      Signed-off-by: default avatarYafang Shao <laoar.shao@gmail.com>
      Link: https://lore.kernel.org/r/20230305124615.12358-6-laoar.shao@gmail.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      cbb9b606
    • Yafang Shao's avatar
      bpf: arraymap memory usage · 1746d055
      Yafang Shao authored
      Introduce array_map_mem_usage() to calculate arraymap memory usage. In
      this helper, some small memory allocations are ignored, like the
      allocation of struct bpf_array_aux in prog_array. The inner_map_meta in
      array_of_map is also ignored.
      
      The result as follows,
      
      - before
      11: array  name count_map  flags 0x0
              key 4B  value 4B  max_entries 65536  memlock 524288B
      12: percpu_array  name count_map  flags 0x0
              key 4B  value 4B  max_entries 65536  memlock 8912896B
      13: perf_event_array  name count_map  flags 0x0
              key 4B  value 4B  max_entries 65536  memlock 524288B
      14: prog_array  name count_map  flags 0x0
              key 4B  value 4B  max_entries 65536  memlock 524288B
      15: cgroup_array  name count_map  flags 0x0
              key 4B  value 4B  max_entries 65536  memlock 524288B
      
      - after
      11: array  name count_map  flags 0x0
              key 4B  value 4B  max_entries 65536  memlock 524608B
      12: percpu_array  name count_map  flags 0x0
              key 4B  value 4B  max_entries 65536  memlock 17301824B
      13: perf_event_array  name count_map  flags 0x0
              key 4B  value 4B  max_entries 65536  memlock 524608B
      14: prog_array  name count_map  flags 0x0
              key 4B  value 4B  max_entries 65536  memlock 524608B
      15: cgroup_array  name count_map  flags 0x0
              key 4B  value 4B  max_entries 65536  memlock 524608B
      Signed-off-by: default avatarYafang Shao <laoar.shao@gmail.com>
      Link: https://lore.kernel.org/r/20230305124615.12358-5-laoar.shao@gmail.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      1746d055
    • Yafang Shao's avatar
      bpf: hashtab memory usage · 304849a2
      Yafang Shao authored
      htab_map_mem_usage() is introduced to calculate hashmap memory usage. In
      this helper, some small memory allocations are ignore, as their size is
      quite small compared with the total size. The inner_map_meta in
      hash_of_map is also ignored.
      
      The result for hashtab as follows,
      
      - before this change
      1: hash  name count_map  flags 0x1  <<<< no prealloc, fully set
              key 16B  value 24B  max_entries 1048576  memlock 41943040B
      2: hash  name count_map  flags 0x1  <<<< no prealloc, none set
              key 16B  value 24B  max_entries 1048576  memlock 41943040B
      3: hash  name count_map  flags 0x0  <<<< prealloc
              key 16B  value 24B  max_entries 1048576  memlock 41943040B
      
      The memlock is always a fixed size whatever it is preallocated or
      not, and whatever the count of allocated elements is.
      
      - after this change
      1: hash  name count_map  flags 0x1    <<<< non prealloc, fully set
              key 16B  value 24B  max_entries 1048576  memlock 117441536B
      2: hash  name count_map  flags 0x1    <<<< non prealloc, non set
              key 16B  value 24B  max_entries 1048576  memlock 16778240B
      3: hash  name count_map  flags 0x0    <<<< prealloc
              key 16B  value 24B  max_entries 1048576  memlock 109056000B
      
      The memlock now is hashtab actually allocated.
      
      The result for percpu hash map as follows,
      - before this change
      4: percpu_hash  name count_map  flags 0x0       <<<< prealloc
              key 16B  value 24B  max_entries 1048576  memlock 822083584B
      5: percpu_hash  name count_map  flags 0x1       <<<< no prealloc
              key 16B  value 24B  max_entries 1048576  memlock 822083584B
      
      - after this change
      4: percpu_hash  name count_map  flags 0x0
              key 16B  value 24B  max_entries 1048576  memlock 897582080B
      5: percpu_hash  name count_map  flags 0x1
              key 16B  value 24B  max_entries 1048576  memlock 922748736B
      
      At worst, the difference can be 10x, for example,
      - before this change
      6: hash  name count_map  flags 0x0
              key 4B  value 4B  max_entries 1048576  memlock 8388608B
      
      - after this change
      6: hash  name count_map  flags 0x0
              key 4B  value 4B  max_entries 1048576  memlock 83889408B
      Signed-off-by: default avatarYafang Shao <laoar.shao@gmail.com>
      Acked-by: default avatarHou Tao <houtao1@huawei.com>
      Link: https://lore.kernel.org/r/20230305124615.12358-4-laoar.shao@gmail.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      304849a2
    • Yafang Shao's avatar
      bpf: lpm_trie memory usage · 41d5941e
      Yafang Shao authored
      trie_mem_usage() is introduced to calculate the lpm_trie memory usage.
      Some small memory allocations are ignored. The inner node is also
      ignored.
      
      The result as follows,
      
      - before
      10: lpm_trie  flags 0x1
              key 8B  value 8B  max_entries 65536  memlock 1048576B
      
      - after
      10: lpm_trie  flags 0x1
              key 8B  value 8B  max_entries 65536  memlock 2291536B
      Signed-off-by: default avatarYafang Shao <laoar.shao@gmail.com>
      Link: https://lore.kernel.org/r/20230305124615.12358-3-laoar.shao@gmail.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      41d5941e
    • Yafang Shao's avatar
      bpf: add new map ops ->map_mem_usage · 90a5527d
      Yafang Shao authored
      Add a new map ops ->map_mem_usage to print the memory usage of a
      bpf map.
      
      This is a preparation for the followup change.
      Signed-off-by: default avatarYafang Shao <laoar.shao@gmail.com>
      Link: https://lore.kernel.org/r/20230305124615.12358-2-laoar.shao@gmail.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      90a5527d
    • Nathan Chancellor's avatar
      bpf: Increase size of BTF_ID_LIST without CONFIG_DEBUG_INFO_BTF again · 2d5bcdcd
      Nathan Chancellor authored
      After commit 66e3a13e ("bpf: Add bpf_dynptr_slice and bpf_dynptr_slice_rdwr"),
      clang builds without CONFIG_DEBUG_INFO_BTF warn:
      
        kernel/bpf/verifier.c:10298:24: warning: array index 16 is past the end of the array (that has type 'u32[16]' (aka 'unsigned int[16]')) [-Warray-bounds]
                                           meta.func_id == special_kfunc_list[KF_bpf_dynptr_slice_rdwr]) {
                                                           ^                  ~~~~~~~~~~~~~~~~~~~~~~~~
        kernel/bpf/verifier.c:9150:1: note: array 'special_kfunc_list' declared here
        BTF_ID_LIST(special_kfunc_list)
        ^
        include/linux/btf_ids.h:207:27: note: expanded from macro 'BTF_ID_LIST'
        #define BTF_ID_LIST(name) static u32 __maybe_unused name[16];
                                  ^
        1 warning generated.
      
      A warning of this nature was previously addressed by
      commit beb3d47d ("bpf: Fix a BTF_ID_LIST bug with CONFIG_DEBUG_INFO_BTF not set")
      but there have been new kfuncs added since then.
      
      Quadruple the size of the CONFIG_DEBUG_INFO_BTF=n definition so that
      this problem is unlikely to show up for some time.
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/1810Signed-off-by: default avatarNathan Chancellor <nathan@kernel.org>
      Reviewed-by: default avatarTom Rix <trix@redhat.com>
      Link: https://lore.kernel.org/r/20230307-bpf-kfuncs-warray-bounds-v1-1-00ad3191f3a6@kernel.orgSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      2d5bcdcd
    • Jakub Kicinski's avatar
      Merge tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next · 36e5e391
      Jakub Kicinski authored
      Daniel Borkmann says:
      
      ====================
      pull-request: bpf-next 2023-03-06
      
      We've added 85 non-merge commits during the last 13 day(s) which contain
      a total of 131 files changed, 7102 insertions(+), 1792 deletions(-).
      
      The main changes are:
      
      1) Add skb and XDP typed dynptrs which allow BPF programs for more
         ergonomic and less brittle iteration through data and variable-sized
         accesses, from Joanne Koong.
      
      2) Bigger batch of BPF verifier improvements to prepare for upcoming BPF
         open-coded iterators allowing for less restrictive looping capabilities,
         from Andrii Nakryiko.
      
      3) Rework RCU enforcement in the verifier, add kptr_rcu and enforce BPF
         programs to NULL-check before passing such pointers into kfunc,
         from Alexei Starovoitov.
      
      4) Add support for kptrs in percpu hashmaps, percpu LRU hashmaps and in
         local storage maps, from Kumar Kartikeya Dwivedi.
      
      5) Add BPF verifier support for ST instructions in convert_ctx_access()
         which will help new -mcpu=v4 clang flag to start emitting them,
         from Eduard Zingerman.
      
      6) Make uprobe attachment Android APK aware by supporting attachment
         to functions inside ELF objects contained in APKs via function names,
         from Daniel Müller.
      
      7) Add a new flag BPF_F_TIMER_ABS flag for bpf_timer_start() helper
         to start the timer with absolute expiration value instead of relative
         one, from Tero Kristo.
      
      8) Add a new kfunc bpf_cgroup_from_id() to look up cgroups via id,
         from Tejun Heo.
      
      9) Extend libbpf to support users manually attaching kprobes/uprobes
         in the legacy/perf/link mode, from Menglong Dong.
      
      10) Implement workarounds in the mips BPF JIT for DADDI/R4000,
         from Jiaxun Yang.
      
      11) Enable mixing bpf2bpf and tailcalls for the loongarch BPF JIT,
          from Hengqi Chen.
      
      12) Extend BPF instruction set doc with describing the encoding of BPF
          instructions in terms of how bytes are stored under big/little endian,
          from Jose E. Marchesi.
      
      13) Follow-up to enable kfunc support for riscv BPF JIT, from Pu Lehui.
      
      14) Fix bpf_xdp_query() backwards compatibility on old kernels,
          from Yonghong Song.
      
      15) Fix BPF selftest cross compilation with CLANG_CROSS_FLAGS,
          from Florent Revest.
      
      16) Improve bpf_cpumask_ma to only allocate one bpf_mem_cache,
          from Hou Tao.
      
      17) Fix BPF verifier's check_subprogs to not unnecessarily mark
          a subprogram with has_tail_call, from Ilya Leoshkevich.
      
      18) Fix arm syscall regs spec in libbpf's bpf_tracing.h, from Puranjay Mohan.
      
      * tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next: (85 commits)
        selftests/bpf: Add test for legacy/perf kprobe/uprobe attach mode
        selftests/bpf: Split test_attach_probe into multi subtests
        libbpf: Add support to set kprobe/uprobe attach mode
        tools/resolve_btfids: Add /libsubcmd to .gitignore
        bpf: add support for fixed-size memory pointer returns for kfuncs
        bpf: generalize dynptr_get_spi to be usable for iters
        bpf: mark PTR_TO_MEM as non-null register type
        bpf: move kfunc_call_arg_meta higher in the file
        bpf: ensure that r0 is marked scratched after any function call
        bpf: fix visit_insn()'s detection of BPF_FUNC_timer_set_callback helper
        bpf: clean up visit_insn()'s instruction processing
        selftests/bpf: adjust log_fixup's buffer size for proper truncation
        bpf: honor env->test_state_freq flag in is_state_visited()
        selftests/bpf: enhance align selftest's expected log matching
        bpf: improve regsafe() checks for PTR_TO_{MEM,BUF,TP_BUFFER}
        bpf: improve stack slot state printing
        selftests/bpf: Disassembler tests for verifier.c:convert_ctx_access()
        selftests/bpf: test if pointer type is tracked for BPF_ST_MEM
        bpf: allow ctx writes using BPF_ST_MEM instruction
        bpf: Use separate RCU callbacks for freeing selem
        ...
      ====================
      
      Link: https://lore.kernel.org/r/20230307004346.27578-1-daniel@iogearbox.netSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      36e5e391
  2. 06 Mar, 2023 5 commits
  3. 04 Mar, 2023 14 commits