1. 25 Mar, 2019 3 commits
    • Alexei Starovoitov's avatar
      Merge branch 'libbpf-fixup' · a7d6ac37
      Alexei Starovoitov authored
      Daniel Borkmann says:
      
      ====================
      First one is fixing version in Makefile and shared object and
      second one clarifies bump in version. Thanks!
      
      v1 -> v2:
        - Fix up soname, thanks Stanislav!
      ====================
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      a7d6ac37
    • Daniel Borkmann's avatar
      bpf, libbpf: clarify bump in libbpf version info · 63197f78
      Daniel Borkmann authored
      The current documentation suggests that we would need to bump the
      libbpf version on every change. Lets clarify this a bit more and
      reflect what we do today in practice, that is, bumping it once per
      development cycle.
      
      Fixes: 76d1b894 ("libbpf: Document API and ABI conventions")
      Reported-by: default avatarStanislav Fomichev <sdf@google.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      63197f78
    • Daniel Borkmann's avatar
      bpf, libbpf: fix version info and add it to shared object · 1d382264
      Daniel Borkmann authored
      Even though libbpf's versioning script for the linker (libbpf.map)
      is pointing to 0.0.2, the BPF_EXTRAVERSION in the Makefile has
      not been updated along with it and is therefore still on 0.0.1.
      
      While fixing up, I also noticed that the generated shared object
      versioning information is missing, typical convention is to have
      a linker name (libbpf.so), soname (libbpf.so.0) and real name
      (libbpf.so.0.0.2) for library management. This is based upon the
      LIBBPF_VERSION as well.
      
      The build will then produce the following bpf libraries:
      
        # ll libbpf*
        libbpf.a
        libbpf.so -> libbpf.so.0.0.2
        libbpf.so.0 -> libbpf.so.0.0.2
        libbpf.so.0.0.2
      
        # readelf -d libbpf.so.0.0.2 | grep SONAME
        0x000000000000000e (SONAME)             Library soname: [libbpf.so.0]
      
      And install them accordingly:
      
        # rm -rf /tmp/bld; mkdir /tmp/bld; make -j$(nproc) O=/tmp/bld install
      
        Auto-detecting system features:
        ...                        libelf: [ on  ]
        ...                           bpf: [ on  ]
      
          CC       /tmp/bld/libbpf.o
          CC       /tmp/bld/bpf.o
          CC       /tmp/bld/nlattr.o
          CC       /tmp/bld/btf.o
          CC       /tmp/bld/libbpf_errno.o
          CC       /tmp/bld/str_error.o
          CC       /tmp/bld/netlink.o
          CC       /tmp/bld/bpf_prog_linfo.o
          CC       /tmp/bld/libbpf_probes.o
          CC       /tmp/bld/xsk.o
          LD       /tmp/bld/libbpf-in.o
          LINK     /tmp/bld/libbpf.a
          LINK     /tmp/bld/libbpf.so.0.0.2
          LINK     /tmp/bld/test_libbpf
          INSTALL  /tmp/bld/libbpf.a
          INSTALL  /tmp/bld/libbpf.so.0.0.2
      
        # ll /usr/local/lib64/libbpf.*
        /usr/local/lib64/libbpf.a
        /usr/local/lib64/libbpf.so -> libbpf.so.0.0.2
        /usr/local/lib64/libbpf.so.0 -> libbpf.so.0.0.2
        /usr/local/lib64/libbpf.so.0.0.2
      
      Fixes: 1bf4b058 ("tools: bpftool: add probes for eBPF program types")
      Fixes: 1b76c13e ("bpf tools: Introduce 'bpf' library and add bpf feature check")
      Reported-by: default avatarStanislav Fomichev <sdf@google.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      1d382264
  2. 22 Mar, 2019 1 commit
    • Jakub Kicinski's avatar
      bpf: verifier: propagate liveness on all frames · 83d16312
      Jakub Kicinski authored
      Commit 7640ead9 ("bpf: verifier: make sure callees don't prune
      with caller differences") connected up parentage chains of all
      frames of the stack.  It didn't, however, ensure propagate_liveness()
      propagates all liveness information along those chains.
      
      This means pruning happening in the callee may generate explored
      states with incomplete liveness for the chains in lower frames
      of the stack.
      
      The included selftest is similar to the prior one from commit
      7640ead9 ("bpf: verifier: make sure callees don't prune with
      caller differences"), where callee would prune regardless of the
      difference in r8 state.
      
      Now we also initialize r9 to 0 or 1 based on a result from get_random().
      r9 is never read so the walk with r9 = 0 gets pruned (correctly) after
      the walk with r9 = 1 completes.
      
      The selftest is so arranged that the pruning will happen in the
      callee.  Since callee does not propagate read marks of r8, the
      explored state at the pruning point prior to the callee will
      now ignore r8.
      
      Propagate liveness on all frames of the stack when pruning.
      
      Fixes: f4d7e40a ("bpf: introduce function calls (verification)")
      Signed-off-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      83d16312
  3. 21 Mar, 2019 2 commits
    • Xu Yu's avatar
      bpf: do not restore dst_reg when cur_state is freed · 0803278b
      Xu Yu authored
      Syzkaller hit 'KASAN: use-after-free Write in sanitize_ptr_alu' bug.
      
      Call trace:
      
        dump_stack+0xbf/0x12e
        print_address_description+0x6a/0x280
        kasan_report+0x237/0x360
        sanitize_ptr_alu+0x85a/0x8d0
        adjust_ptr_min_max_vals+0x8f2/0x1ca0
        adjust_reg_min_max_vals+0x8ed/0x22e0
        do_check+0x1ca6/0x5d00
        bpf_check+0x9ca/0x2570
        bpf_prog_load+0xc91/0x1030
        __se_sys_bpf+0x61e/0x1f00
        do_syscall_64+0xc8/0x550
        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Fault injection trace:
      
        kfree+0xea/0x290
        free_func_state+0x4a/0x60
        free_verifier_state+0x61/0xe0
        push_stack+0x216/0x2f0	          <- inject failslab
        sanitize_ptr_alu+0x2b1/0x8d0
        adjust_ptr_min_max_vals+0x8f2/0x1ca0
        adjust_reg_min_max_vals+0x8ed/0x22e0
        do_check+0x1ca6/0x5d00
        bpf_check+0x9ca/0x2570
        bpf_prog_load+0xc91/0x1030
        __se_sys_bpf+0x61e/0x1f00
        do_syscall_64+0xc8/0x550
        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      When kzalloc() fails in push_stack(), free_verifier_state() will free
      current verifier state. As push_stack() returns, dst_reg was restored
      if ptr_is_dst_reg is false. However, as member of the cur_state,
      dst_reg is also freed, and error occurs when dereferencing dst_reg.
      Simply fix it by testing ret of push_stack() before restoring dst_reg.
      
      Fixes: 979d63d5 ("bpf: prevent out of bounds speculation on pointer arithmetic")
      Signed-off-by: default avatarXu Yu <xuyu@linux.alibaba.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      0803278b
    • Martin KaFai Lau's avatar
      bpf: Only print ref_obj_id for refcounted reg · cba368c1
      Martin KaFai Lau authored
      Naresh reported that test_align fails because of the mismatch at the
      verbose printout of the register states.  The reason is due to the newly
      added ref_obj_id.
      
      ref_obj_id is only useful for refcounted reg.  Thus, this patch fixes it
      by only printing ref_obj_id for refcounted reg.  While at it, it also uses
      comma instead of space to separate between "id" and "ref_obj_id".
      
      Fixes: 1b986589 ("bpf: Fix bpf_tcp_sock and bpf_sk_fullsock issue related to bpf_sk_release")
      Reported-by: default avatarNaresh Kamboju <naresh.kamboju@linaro.org>
      Signed-off-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Acked-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      cba368c1
  4. 18 Mar, 2019 3 commits
    • Martynas Pumputis's avatar
      bpf: Try harder when allocating memory for large maps · f01a7dbe
      Martynas Pumputis authored
      It has been observed that sometimes a higher order memory allocation
      for BPF maps fails when there is no obvious memory pressure in a system.
      E.g. the map (BPF_MAP_TYPE_LRU_HASH, key=38, value=56, max_elems=524288)
      could not be created due to vmalloc unable to allocate 75497472B,
      when the system's memory consumption (in MB) was the following:
      
          Total: 3942 Used: 837 (21.24%) Free: 138 Buffers: 239 Cached: 2727
      
      Later analysis [1] by Michal Hocko showed that the vmalloc was not trying
      to reclaim memory from the page cache and was failing prematurely due to
      __GFP_NORETRY.
      
      Considering dcda9b04 ("mm, tree wide: replace __GFP_REPEAT by
      __GFP_RETRY_MAYFAIL with more useful semantic") and [1], we can replace
      __GFP_NORETRY with __GFP_RETRY_MAYFAIL, as it won't invoke OOM killer
      and will try harder to fulfil allocation requests.
      
      Unfortunately, replacing the body of the BPF map memory allocation
      function with the kvmalloc_node helper function is not an option at
      this point in time, given 1) kmalloc is non-optional for higher order
      allocations, and 2) passing __GFP_RETRY_MAYFAIL to the kmalloc would
      stress the slab allocator too much for large requests.
      
      The change has been tested with the workloads mentioned above and by
      observing oom_kill value from /proc/vmstat.
      
      [1]: https://lore.kernel.org/bpf/20190310071318.GW5232@dhcp22.suse.cz/Signed-off-by: default avatarMartynas Pumputis <m@lambda.lt>
      Acked-by: default avatarYonghong Song <yhs@fb.com>
      Cc: Michal Hocko <mhocko@suse.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20190318153940.GL8924@dhcp22.suse.cz/
      f01a7dbe
    • Erik Hugne's avatar
      tipc: allow service ranges to be connect()'ed on RDM/DGRAM · ea239314
      Erik Hugne authored
      We move the check that prevents connecting service ranges to after
      the RDM/DGRAM check, and move address sanity control to a separate
      function that also validates the service range.
      
      Fixes: 23998835 ("tipc: improve address sanity check in tipc_connect()")
      Signed-off-by: default avatarErik Hugne <erik.hugne@gmail.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ea239314
    • Randy Dunlap's avatar
      networking: fix snmp_counter.rst Doc. Warnings · 65e9a6d2
      Randy Dunlap authored
      Fix documentation markup warnings in snmp_counter.rst:
      
      Documentation/networking/snmp_counter.rst:416: WARNING: Title underline too short.
      Documentation/networking/snmp_counter.rst:684: WARNING: Bullet list ends without a blank line; unexpected unindent.
      Documentation/networking/snmp_counter.rst:693: WARNING: Title underline too short.
      Documentation/networking/snmp_counter.rst:707: WARNING: Bullet list ends without a blank line; unexpected unindent.
      Documentation/networking/snmp_counter.rst:712: WARNING: Bullet list ends without a blank line; unexpected unindent.
      Documentation/networking/snmp_counter.rst:722: WARNING: Title underline too short.
      Documentation/networking/snmp_counter.rst:733: WARNING: Bullet list ends without a blank line; unexpected unindent.
      Documentation/networking/snmp_counter.rst:736: WARNING: Bullet list ends without a blank line; unexpected unindent.
      Documentation/networking/snmp_counter.rst:739: WARNING: Bullet list ends without a blank line; unexpected unindent.
      
      Fixes: 80cc4950 ("net: Add part of TCP counts explanations in snmp_counters.rst")
      Fixes: 8e2ea53a ("add snmp counters document")
      Fixes: a6c7c7aa ("net: add document for several snmp counters")
      Signed-off-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Cc: yupeng <yupeng0921@gmail.com>
      65e9a6d2
  5. 17 Mar, 2019 1 commit
  6. 16 Mar, 2019 8 commits
  7. 15 Mar, 2019 11 commits
  8. 14 Mar, 2019 11 commits