1. 09 Sep, 2020 3 commits
    • Yonghong Song's avatar
      selftests/bpf: Fix test_sysctl_loop{1, 2} failure due to clang change · 7fb5eefd
      Yonghong Song authored
      Andrii reported that with latest clang, when building selftests, we have
      error likes:
        error: progs/test_sysctl_loop1.c:23:16: in function sysctl_tcp_mem i32 (%struct.bpf_sysctl*):
        Looks like the BPF stack limit of 512 bytes is exceeded.
        Please move large on stack variables into BPF per-cpu array map.
      
      The error is triggered by the following LLVM patch:
        https://reviews.llvm.org/D87134
      
      For example, the following code is from test_sysctl_loop1.c:
        static __always_inline int is_tcp_mem(struct bpf_sysctl *ctx)
        {
          volatile char tcp_mem_name[] = "net/ipv4/tcp_mem/very_very_very_very_long_pointless_string";
          ...
        }
      Without the above LLVM patch, the compiler did optimization to load the string
      (59 bytes long) with 7 64bit loads, 1 8bit load and 1 16bit load,
      occupying 64 byte stack size.
      
      With the above LLVM patch, the compiler only uses 8bit loads, but subregister is 32bit.
      So stack requirements become 4 * 59 = 236 bytes. Together with other stuff on
      the stack, total stack size exceeds 512 bytes, hence compiler complains and quits.
      
      To fix the issue, removing "volatile" key word or changing "volatile" to
      "const"/"static const" does not work, the string is put in .rodata.str1.1 section,
      which libbpf did not process it and errors out with
        libbpf: elf: skipping unrecognized data section(6) .rodata.str1.1
        libbpf: prog 'sysctl_tcp_mem': bad map relo against '.L__const.is_tcp_mem.tcp_mem_name'
                in section '.rodata.str1.1'
      
      Defining the string const as global variable can fix the issue as it puts the string constant
      in '.rodata' section which is recognized by libbpf. In the future, when libbpf can process
      '.rodata.str*.*' properly, the global definition can be changed back to local definition.
      
      Defining tcp_mem_name as a global, however, triggered a verifier failure.
         ./test_progs -n 7/21
        libbpf: load bpf program failed: Permission denied
        libbpf: -- BEGIN DUMP LOG ---
        libbpf:
        invalid stack off=0 size=1
        verification time 6975 usec
        stack depth 160+64
        processed 889 insns (limit 1000000) max_states_per_insn 4 total_states
        14 peak_states 14 mark_read 10
      
        libbpf: -- END LOG --
        libbpf: failed to load program 'sysctl_tcp_mem'
        libbpf: failed to load object 'test_sysctl_loop2.o'
        test_bpf_verif_scale:FAIL:114
        #7/21 test_sysctl_loop2.o:FAIL
      This actually exposed a bpf program bug. In test_sysctl_loop{1,2}, we have code
      like
        const char tcp_mem_name[] = "<...long string...>";
        ...
        char name[64];
        ...
        for (i = 0; i < sizeof(tcp_mem_name); ++i)
            if (name[i] != tcp_mem_name[i])
                return 0;
      In the above code, if sizeof(tcp_mem_name) > 64, name[i] access may be
      out of bound. The sizeof(tcp_mem_name) is 59 for test_sysctl_loop1.c and
      79 for test_sysctl_loop2.c.
      
      Without promotion-to-global change, old compiler generates code where
      the overflowed stack access is actually filled with valid value, so hiding
      the bpf program bug. With promotion-to-global change, the code is different,
      more specifically, the previous loading constants to stack is gone, and
      "name" occupies stack[-64:0] and overflow access triggers a verifier error.
      To fix the issue, adjust "name" buffer size properly.
      Reported-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: default avatarYonghong Song <yhs@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Link: https://lore.kernel.org/bpf/20200909171542.3673449-1-yhs@fb.com
      7fb5eefd
    • Yonghong Song's avatar
      selftests/bpf: Add test for map_ptr arithmetic · e6054fc1
      Yonghong Song authored
      Change selftest map_ptr_kern.c with disabling inlining for
      one of subtests, which will fail the test without previous
      verifier change. Also added to verifier test for both
      "map_ptr += scalar" and "scalar += map_ptr" arithmetic.
      Signed-off-by: default avatarYonghong Song <yhs@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Link: https://lore.kernel.org/bpf/20200908175703.2463721-1-yhs@fb.com
      e6054fc1
    • Yonghong Song's avatar
      bpf: Permit map_ptr arithmetic with opcode add and offset 0 · 7c696732
      Yonghong Song authored
      Commit 41c48f3a ("bpf: Support access
      to bpf map fields") added support to access map fields
      with CORE support. For example,
      
                  struct bpf_map {
                          __u32 max_entries;
                  } __attribute__((preserve_access_index));
      
                  struct bpf_array {
                          struct bpf_map map;
                          __u32 elem_size;
                  } __attribute__((preserve_access_index));
      
                  struct {
                          __uint(type, BPF_MAP_TYPE_ARRAY);
                          __uint(max_entries, 4);
                          __type(key, __u32);
                          __type(value, __u32);
                  } m_array SEC(".maps");
      
                  SEC("cgroup_skb/egress")
                  int cg_skb(void *ctx)
                  {
                          struct bpf_array *array = (struct bpf_array *)&m_array;
      
                          /* .. array->map.max_entries .. */
                  }
      
      In kernel, bpf_htab has similar structure,
      
      	    struct bpf_htab {
      		    struct bpf_map map;
                          ...
                  }
      
      In the above cg_skb(), to access array->map.max_entries, with CORE, the clang will
      generate two builtin's.
                  base = &m_array;
                  /* access array.map */
                  map_addr = __builtin_preserve_struct_access_info(base, 0, 0);
                  /* access array.map.max_entries */
                  max_entries_addr = __builtin_preserve_struct_access_info(map_addr, 0, 0);
      	    max_entries = *max_entries_addr;
      
      In the current llvm, if two builtin's are in the same function or
      in the same function after inlining, the compiler is smart enough to chain
      them together and generates like below:
                  base = &m_array;
                  max_entries = *(base + reloc_offset); /* reloc_offset = 0 in this case */
      and we are fine.
      
      But if we force no inlining for one of functions in test_map_ptr() selftest, e.g.,
      check_default(), the above two __builtin_preserve_* will be in two different
      functions. In this case, we will have code like:
         func check_hash():
                  reloc_offset_map = 0;
                  base = &m_array;
                  map_base = base + reloc_offset_map;
                  check_default(map_base, ...)
         func check_default(map_base, ...):
                  max_entries = *(map_base + reloc_offset_max_entries);
      
      In kernel, map_ptr (CONST_PTR_TO_MAP) does not allow any arithmetic.
      The above "map_base = base + reloc_offset_map" will trigger a verifier failure.
        ; VERIFY(check_default(&hash->map, map));
        0: (18) r7 = 0xffffb4fe8018a004
        2: (b4) w1 = 110
        3: (63) *(u32 *)(r7 +0) = r1
         R1_w=invP110 R7_w=map_value(id=0,off=4,ks=4,vs=8,imm=0) R10=fp0
        ; VERIFY_TYPE(BPF_MAP_TYPE_HASH, check_hash);
        4: (18) r1 = 0xffffb4fe8018a000
        6: (b4) w2 = 1
        7: (63) *(u32 *)(r1 +0) = r2
         R1_w=map_value(id=0,off=0,ks=4,vs=8,imm=0) R2_w=invP1 R7_w=map_value(id=0,off=4,ks=4,vs=8,imm=0) R10=fp0
        8: (b7) r2 = 0
        9: (18) r8 = 0xffff90bcb500c000
        11: (18) r1 = 0xffff90bcb500c000
        13: (0f) r1 += r2
        R1 pointer arithmetic on map_ptr prohibited
      
      To fix the issue, let us permit map_ptr + 0 arithmetic which will
      result in exactly the same map_ptr.
      Signed-off-by: default avatarYonghong Song <yhs@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Link: https://lore.kernel.org/bpf/20200908175702.2463625-1-yhs@fb.com
      7c696732
  2. 07 Sep, 2020 3 commits
  3. 04 Sep, 2020 20 commits
  4. 02 Sep, 2020 6 commits
  5. 01 Sep, 2020 8 commits
    • David S. Miller's avatar
      Merge branch 'dpaa2-eth-add-a-dpaa2_eth_-prefix-to-all-functions' · 0697fecf
      David S. Miller authored
      Ioana Ciornei says:
      
      ====================
      dpaa2-eth: add a dpaa2_eth_ prefix to all functions
      
      This is just a quick cleanup that aims at adding a dpaa2_eth_ prefix to
      all functions within the dpaa2-eth driver even if those are static and
      private to the driver. The main reason for doing this is that looking a
      perf top, for example, is becoming an inconvenience because one cannot
      easily determine which entries are dpaa2-eth related or not.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0697fecf
    • Ioana Ciornei's avatar
      dpaa2-eth: add a dpaa2_eth_ prefix to all functions in dpaa2-eth-dcb.c · 8d138373
      Ioana Ciornei authored
      Some static functions in the dpaa2-eth driver don't have the dpaa2_eth_
      prefix and this is becoming an inconvenience when looking at, for
      example, a perf top output and trying to determine easily which entries
      are dpaa2-eth related. Ammend this by adding the prefix to all the
      functions.
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8d138373
    • Ioana Ciornei's avatar
      dpaa2-eth: add a dpaa2_eth_ prefix to all functions in dpaa2-eth.c · 5d8dccf8
      Ioana Ciornei authored
      Some static functions in the dpaa2-eth driver don't have the dpaa2_eth_
      prefix and this is becoming an inconvenience when looking at, for
      example, a perf top output and trying to determine easily which entries
      are dpaa2-eth related. Ammend this by adding the prefix to all the
      functions.
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5d8dccf8
    • Ioana Ciornei's avatar
      dpaa2-eth: add a dpaa2_eth_ prefix to all functions in dpaa2-ethtool.c · e6734cd9
      Ioana Ciornei authored
      Some static functions in the dpaa2-eth driver don't have the dpaa2_eth_
      prefix and this is becoming an inconvenience when looking at, for
      example, a perf top output and trying to determine easily which entries
      are dpaa2-eth related. Ammend this by adding the prefix to all the
      functions.
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e6734cd9
    • Eelco Chaudron's avatar
      net: openvswitch: fixes crash if nf_conncount_init() fails · e0afe914
      Eelco Chaudron authored
      If nf_conncount_init fails currently the dispatched work is not canceled,
      causing problems when the timer fires. This change fixes this by not
      scheduling the work until all initialization is successful.
      
      Fixes: a65878d6 ("net: openvswitch: fixes potential deadlock in dp cleanup code")
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Signed-off-by: default avatarEelco Chaudron <echaudro@redhat.com>
      Reviewed-by: default avatarTonghao Zhang <xiangxia.m.yue@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e0afe914
    • Thomas Falcon's avatar
      ibmvnic: Harden device Command Response Queue handshake · 36a782fd
      Thomas Falcon authored
      In some cases, the device or firmware may be busy when the
      driver attempts to perform the CRQ initialization handshake.
      If the partner is busy, the hypervisor will return the H_CLOSED
      return code. The aim of this patch is that, if the device is not
      ready, to query the device a number of times, with a small wait
      time in between queries. If all initialization requests fail,
      the driver will remain in a dormant state, awaiting a signal
      from the device that it is ready for operation.
      Signed-off-by: default avatarThomas Falcon <tlfalcon@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      36a782fd
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next · 150f29f5
      David S. Miller authored
      Daniel Borkmann says:
      
      ====================
      pull-request: bpf-next 2020-09-01
      
      The following pull-request contains BPF updates for your *net-next* tree.
      
      There are two small conflicts when pulling, resolve as follows:
      
      1) Merge conflict in tools/lib/bpf/libbpf.c between 88a82120 ("libbpf: Factor
         out common ELF operations and improve logging") in bpf-next and 1e891e51
         ("libbpf: Fix map index used in error message") in net-next. Resolve by taking
         the hunk in bpf-next:
      
              [...]
              scn = elf_sec_by_idx(obj, obj->efile.btf_maps_shndx);
              data = elf_sec_data(obj, scn);
              if (!scn || !data) {
                      pr_warn("elf: failed to get %s map definitions for %s\n",
                              MAPS_ELF_SEC, obj->path);
                      return -EINVAL;
              }
              [...]
      
      2) Merge conflict in drivers/net/ethernet/mellanox/mlx5/core/en/xsk/rx.c between
         9647c57b ("xsk: i40e: ice: ixgbe: mlx5: Test for dma_need_sync earlier for
         better performance") in bpf-next and e20f0dbf ("net/mlx5e: RX, Add a prefetch
         command for small L1_CACHE_BYTES") in net-next. Resolve the two locations by retaining
         net_prefetch() and taking xsk_buff_dma_sync_for_cpu() from bpf-next. Should look like:
      
              [...]
              xdp_set_data_meta_invalid(xdp);
              xsk_buff_dma_sync_for_cpu(xdp, rq->xsk_pool);
              net_prefetch(xdp->data);
              [...]
      
      We've added 133 non-merge commits during the last 14 day(s) which contain
      a total of 246 files changed, 13832 insertions(+), 3105 deletions(-).
      
      The main changes are:
      
      1) Initial support for sleepable BPF programs along with bpf_copy_from_user() helper
         for tracing to reliably access user memory, from Alexei Starovoitov.
      
      2) Add BPF infra for writing and parsing TCP header options, from Martin KaFai Lau.
      
      3) bpf_d_path() helper for returning full path for given 'struct path', from Jiri Olsa.
      
      4) AF_XDP support for shared umems between devices and queues, from Magnus Karlsson.
      
      5) Initial prep work for full BPF-to-BPF call support in libbpf, from Andrii Nakryiko.
      
      6) Generalize bpf_sk_storage map & add local storage for inodes, from KP Singh.
      
      7) Implement sockmap/hash updates from BPF context, from Lorenz Bauer.
      
      8) BPF xor verification for scalar types & add BPF link iterator, from Yonghong Song.
      
      9) Use target's prog type for BPF_PROG_TYPE_EXT prog verification, from Udip Pant.
      
      10) Rework BPF tracing samples to use libbpf loader, from Daniel T. Lee.
      
      11) Fix xdpsock sample to really cycle through all buffers, from Weqaar Janjua.
      
      12) Improve type safety for tun/veth XDP frame handling, from Maciej Żenczykowski.
      
      13) Various smaller cleanups and improvements all over the place.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      150f29f5
    • YueHaibing's avatar
      liquidio: Remove unneeded cast from memory allocation · 8aa639e1
      YueHaibing authored
      Remove unneeded return value cast.
      This is detected by coccinelle.
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8aa639e1