1. 09 Aug, 2019 1 commit
  2. 01 Aug, 2019 4 commits
    • Alexei Starovoitov's avatar
      selftests/bpf: tests for jmp to 1st insn · f1fc7249
      Alexei Starovoitov authored
      Add 2 tests that check JIT code generation to jumps to 1st insn.
      1st test is similar to syzbot reproducer.
      The backwards branch is never taken at runtime.
      2nd test has branch to 1st insn that executes.
      The test is written as two bpf functions, since it's not possible
      to construct valid single bpf program that jumps to 1st insn.
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarSong Liu <songliubraving@fb.com>
      f1fc7249
    • Alexei Starovoitov's avatar
      bpf: fix x64 JIT code generation for jmp to 1st insn · 7c2e988f
      Alexei Starovoitov authored
      Introduction of bounded loops exposed old bug in x64 JIT.
      JIT maintains the array of offsets to the end of all instructions to
      compute jmp offsets.
      addrs[0] - offset of the end of the 1st insn (that includes prologue).
      addrs[1] - offset of the end of the 2nd insn.
      JIT didn't keep the offset of the beginning of the 1st insn,
      since classic BPF didn't have backward jumps and valid extended BPF
      couldn't have a branch to 1st insn, because it didn't allow loops.
      With bounded loops it's possible to construct a valid program that
      jumps backwards to the 1st insn.
      Fix JIT by computing:
      addrs[0] - offset of the end of prologue == start of the 1st insn.
      addrs[1] - offset of the end of 1st insn.
      
      v1->v2:
      - Yonghong noticed a bug in jit linfo.
        Fix it by passing 'addrs + 1' to bpf_prog_fill_jited_linfo(),
        since it expects insn_to_jit_off array to be offsets to last byte.
      
      Reported-by: syzbot+35101610ff3e83119b1b@syzkaller.appspotmail.com
      Fixes: 2589726d ("bpf: introduce bounded loops")
      Fixes: 0a14842f ("net: filter: Just In Time compiler for x86-64")
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarSong Liu <songliubraving@fb.com>
      7c2e988f
    • Andrii Nakryiko's avatar
      libbpf: set BTF FD for prog only when there is supported .BTF.ext data · 3415ec64
      Andrii Nakryiko authored
      5d01ab7b ("libbpf: fix erroneous multi-closing of BTF FD")
      introduced backwards-compatibility issue, manifesting itself as -E2BIG
      error returned on program load due to unknown non-zero btf_fd attribute
      value for BPF_PROG_LOAD sys_bpf() sub-command.
      
      This patch fixes bug by ensuring that we only ever associate BTF FD with
      program if there is a BTF.ext data that was successfully loaded into
      kernel, which automatically means kernel supports func_info/line_info
      and associated BTF FD for progs (checked and ensured also by BTF
      sanitization code).
      
      Fixes: 5d01ab7b ("libbpf: fix erroneous multi-closing of BTF FD")
      Reported-by: default avatarAndrey Ignatov <rdna@fb.com>
      Signed-off-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      3415ec64
    • Takshak Chahande's avatar
      libbpf : make libbpf_num_possible_cpus function thread safe · 56fbc241
      Takshak Chahande authored
      Having static variable `cpus` in libbpf_num_possible_cpus function
      without guarding it with mutex makes this function thread-unsafe.
      
      If multiple threads accessing this function, in the current form; it
      leads to incrementing the static variable value `cpus` in the multiple
      of total available CPUs.
      
      Used local stack variable to calculate the number of possible CPUs and
      then updated the static variable using WRITE_ONCE().
      
      Changes since v1:
       * added stack variable to calculate cpus
       * serialized static variable update using WRITE_ONCE()
       * fixed Fixes tag
      
      Fixes: 6446b315 ("bpf: add a new API libbpf_num_possible_cpus()")
      Signed-off-by: default avatarTakshak Chahande <ctakshak@fb.com>
      Acked-by: default avatarAndrey Ignatov <rdna@fb.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      56fbc241
  3. 27 Jul, 2019 1 commit
    • Andrii Nakryiko's avatar
      libbpf: fix erroneous multi-closing of BTF FD · 5d01ab7b
      Andrii Nakryiko authored
      Libbpf stores associated BTF FD per each instance of bpf_program. When
      program is unloaded, that FD is closed. This is wrong, because leads to
      a race and possibly closing of unrelated files, if application
      simultaneously opens new files while bpf_programs are unloaded.
      
      It's also unnecessary, because struct btf "owns" that FD, and
      btf__free(), called from bpf_object__close() will close it. Thus the fix
      is to never have per-program BTF FD and fetch it from obj->btf, when
      necessary.
      
      Fixes: 2993e051 ("tools/bpf: add support to read .BTF.ext sections")
      Reported-by: default avatarAndrey Ignatov <rdna@fb.com>
      Signed-off-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      5d01ab7b
  4. 26 Jul, 2019 10 commits
  5. 25 Jul, 2019 18 commits
  6. 24 Jul, 2019 6 commits
    • Cong Wang's avatar
      netrom: hold sock when setting skb->destructor · 4638faac
      Cong Wang authored
      sock_efree() releases the sock refcnt, if we don't hold this refcnt
      when setting skb->destructor to it, the refcnt would not be balanced.
      This leads to several bug reports from syzbot.
      
      I have checked other users of sock_efree(), all of them hold the
      sock refcnt.
      
      Fixes: c8c8218e ("netrom: fix a memory leak in nr_rx_frame()")
      Reported-and-tested-by: <syzbot+622bdabb128acc33427d@syzkaller.appspotmail.com>
      Reported-and-tested-by: <syzbot+6eaef7158b19e3fec3a0@syzkaller.appspotmail.com>
      Reported-and-tested-by: <syzbot+9399c158fcc09b21d0d2@syzkaller.appspotmail.com>
      Reported-and-tested-by: <syzbot+a34e5f3d0300163f0c87@syzkaller.appspotmail.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4638faac
    • Arnd Bergmann's avatar
      ovs: datapath: hide clang frame-overflow warnings · 26063790
      Arnd Bergmann authored
      Some functions in the datapath code are factored out so that each
      one has a stack frame smaller than 1024 bytes with gcc. However,
      when compiling with clang, the functions are inlined more aggressively
      and combined again so we get
      
      net/openvswitch/datapath.c:1124:12: error: stack frame size of 1528 bytes in function 'ovs_flow_cmd_set' [-Werror,-Wframe-larger-than=]
      
      Marking both get_flow_actions() and ovs_nla_init_match_and_action()
      as 'noinline_for_stack' gives us the same behavior that we see with
      gcc, and no warning. Note that this does not mean we actually use
      less stack, as the functions call each other, and we still get
      three copies of the large 'struct sw_flow_key' type on the stack.
      
      The comment tells us that this was previously considered safe,
      presumably since the netlink parsing functions are called with
      a known backchain that does not also use a lot of stack space.
      
      Fixes: 9cc9a5cb ("datapath: Avoid using stack larger than 1024.")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      26063790
    • Jakub Kicinski's avatar
      net/tls: add myself as a co-maintainer · 47b79bbb
      Jakub Kicinski authored
      I've been spending quite a bit of time fixing and
      preventing bit rot in the core TLS code. TLS seems
      to only be growing in importance, I'd like to help
      ensuring the quality of our implementation.
      Signed-off-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Acked-by: default avatarSimon Horman <simon.horman@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      47b79bbb
    • Andreas Schwab's avatar
      net: phy: mscc: initialize stats array · f972037e
      Andreas Schwab authored
      The memory allocated for the stats array may contain arbitrary data.
      
      Fixes: e4f9ba64 ("net: phy: mscc: add support for VSC8514 PHY.")
      Fixes: 00d70d8e ("net: phy: mscc: add support for VSC8574 PHY")
      Fixes: a5afc167 ("net: phy: mscc: add support for VSC8584 PHY")
      Fixes: f76178dc ("net: phy: mscc: add ethtool statistics counters")
      Signed-off-by: default avatarAndreas Schwab <schwab@suse.de>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f972037e
    • Arseny Solokha's avatar
      net: phylink: don't start and stop SGMII PHYs in SFP modules twice · c7fa7f56
      Arseny Solokha authored
      SFP modules connected using the SGMII interface have their own PHYs which
      are handled by the struct phylink's phydev field. On the other hand, for
      the modules connected using 1000Base-X interface that field is not set.
      
      Since commit ce0aa27f ("sfp: add sfp-bus to bridge between network
      devices and sfp cages") phylink_start() ends up setting the phydev field
      using the sfp-bus infrastructure, which eventually calls phy_start() on it,
      and then calling phy_start() again on the same phydev from phylink_start()
      itself. Similar call sequence holds for phylink_stop(), only in the reverse
      order. This results in WARNs during network interface bringup and shutdown
      when a copper SFP module is connected, as phy_start() and phy_stop() are
      called twice in a row for the same phy_device:
      
        % ip link set up dev eth0
        ------------[ cut here ]------------
        called from state UP
        WARNING: CPU: 1 PID: 155 at drivers/net/phy/phy.c:895 phy_start+0x74/0xc0
        Modules linked in:
        CPU: 1 PID: 155 Comm: backend Not tainted 5.2.0+ #1
        NIP:  c0227bf0 LR: c0227bf0 CTR: c004d224
        REGS: df547720 TRAP: 0700   Not tainted  (5.2.0+)
        MSR:  00029000 <CE,EE,ME>  CR: 24002822  XER: 00000000
      
        GPR00: c0227bf0 df5477d8 df5d7080 00000014 df9d2370 df9d5ac4 1f4eb000 00000001
        GPR08: c061fe58 00000000 00000000 df5477d8 0000003c 100c8768 00000000 00000000
        GPR16: df486a00 c046f1c8 c046eea0 00000000 c046e904 c0239604 db68449c 00000000
        GPR24: e9083204 00000000 00000001 db684460 e9083404 00000000 db6dce00 db6dcc00
        NIP [c0227bf0] phy_start+0x74/0xc0
        LR [c0227bf0] phy_start+0x74/0xc0
        Call Trace:
        [df5477d8] [c0227bf0] phy_start+0x74/0xc0 (unreliable)
        [df5477e8] [c023cad0] startup_gfar+0x398/0x3f4
        [df547828] [c023cf08] gfar_enet_open+0x364/0x374
        [df547898] [c029d870] __dev_open+0xe4/0x140
        [df5478c8] [c029db70] __dev_change_flags+0xf0/0x188
        [df5478f8] [c029dc28] dev_change_flags+0x20/0x54
        [df547918] [c02ae304] do_setlink+0x310/0x818
        [df547a08] [c02b1eb8] __rtnl_newlink+0x384/0x6b0
        [df547c28] [c02b222c] rtnl_newlink+0x48/0x68
        [df547c48] [c02ad7c8] rtnetlink_rcv_msg+0x240/0x27c
        [df547c98] [c02cc068] netlink_rcv_skb+0x8c/0xf0
        [df547cd8] [c02cba3c] netlink_unicast+0x114/0x19c
        [df547d08] [c02cbd74] netlink_sendmsg+0x2b0/0x2c0
        [df547d58] [c027b668] sock_sendmsg_nosec+0x20/0x40
        [df547d68] [c027d080] ___sys_sendmsg+0x17c/0x1dc
        [df547e98] [c027df7c] __sys_sendmsg+0x68/0x84
        [df547ef8] [c027e430] sys_socketcall+0x1a0/0x204
        [df547f38] [c000d1d8] ret_from_syscall+0x0/0x38
        --- interrupt: c01 at 0xfd4e030
            LR = 0xfd4e010
        Instruction dump:
        813f0188 38800000 2b890005 419d0014 3d40c046 5529103a 394aa208 7c8a482e
        3c60c046 3863a1b8 4cc63182 4be009a1 <0fe00000> 48000030 3c60c046 3863a1d0
        ---[ end trace d4c095aeaf6ea998 ]---
      
      and
      
        % ip link set down dev eth0
        ------------[ cut here ]------------
        called from state HALTED
        WARNING: CPU: 1 PID: 184 at drivers/net/phy/phy.c:858 phy_stop+0x3c/0x88
      
        <...>
      
        Call Trace:
        [df581788] [c0228450] phy_stop+0x3c/0x88 (unreliable)
        [df581798] [c022d548] sfp_sm_phy_detach+0x1c/0x44
        [df5817a8] [c022e8cc] sfp_sm_event+0x4b0/0x87c
        [df581848] [c022f04c] sfp_upstream_stop+0x34/0x44
        [df581858] [c0225608] phylink_stop+0x7c/0xe4
        [df581868] [c023c57c] stop_gfar+0x7c/0x94
        [df581888] [c023c5b8] gfar_close+0x24/0x94
        [df5818a8] [c0298688] __dev_close_many+0xdc/0xf8
        [df5818c8] [c029db58] __dev_change_flags+0xd8/0x188
        [df5818f8] [c029dc28] dev_change_flags+0x20/0x54
        [df581918] [c02ae304] do_setlink+0x310/0x818
        [df581a08] [c02b1eb8] __rtnl_newlink+0x384/0x6b0
        [df581c28] [c02b222c] rtnl_newlink+0x48/0x68
        [df581c48] [c02ad7c8] rtnetlink_rcv_msg+0x240/0x27c
        [df581c98] [c02cc068] netlink_rcv_skb+0x8c/0xf0
        [df581cd8] [c02cba3c] netlink_unicast+0x114/0x19c
        [df581d08] [c02cbd74] netlink_sendmsg+0x2b0/0x2c0
        [df581d58] [c027b668] sock_sendmsg_nosec+0x20/0x40
        [df581d68] [c027d080] ___sys_sendmsg+0x17c/0x1dc
        [df581e98] [c027df7c] __sys_sendmsg+0x68/0x84
        [df581ef8] [c027e430] sys_socketcall+0x1a0/0x204
        [df581f38] [c000d1d8] ret_from_syscall+0x0/0x38
      
        <...>
      
        ---[ end trace d4c095aeaf6ea999 ]---
      
      SFP modules with the 1000Base-X interface are not affected.
      
      Place explicit calls to phy_start() and phy_stop() before enabling or after
      disabling an attached SFP module, where phydev is not yet set (or is
      already unset), so they will be made only from the inside of sfp-bus, if
      needed.
      
      Fixes: 21796261 ("net: phy: warn if phy_start is called from invalid state")
      Signed-off-by: default avatarArseny Solokha <asolokha@kb.kras.ru>
      Acked-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c7fa7f56
    • David S. Miller's avatar
      Merge tag 'linux-can-fixes-for-5.3-20190724' of... · 09ea2679
      David S. Miller authored
      Merge tag 'linux-can-fixes-for-5.3-20190724' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can
      
      Marc Kleine-Budde says:
      
      ====================
      pull-request: can 2019-07-24
      
      this is a pull reqeust of 7 patches for net/master.
      
      The first patch is by Rasmus Villemoes add a missing netif_carrier_off() to
      register_candev() so that generic netdev trigger based LEDs are initially off.
      
      Nikita Yushchenko's patch for the rcar_canfd driver fixes a possible IRQ storm
      on high load.
      
      The patch by Weitao Hou for the mcp251x driver add missing error checking to
      the work queue allocation.
      
      Both Wen Yang's and Joakim Zhang's patch for the flexcan driver fix a problem
      with the stop-mode.
      
      Stephane Grosjean contributes a patch for the peak_usb driver to fix a
      potential double kfree_skb().
      
      The last patch is by YueHaibing and fixes the error path in can-gw's
      cgw_module_init() function.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      09ea2679