1. 15 Nov, 2019 4 commits
  2. 14 Nov, 2019 3 commits
    • David S. Miller's avatar
      Merge tag 'linux-can-fixes-for-5.4-20191114' of... · d15a5020
      David S. Miller authored
      Merge tag 'linux-can-fixes-for-5.4-20191114' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can
      
      Marc Kleine-Budde says:
      
      ====================
      pull-request: can 2019-11-14
      
      here another pull request for net/master consisting of one patch (including my S-o-b).
      
      Jouni Hogander's patch fixes a memory leak found by the syzbot in the slcan
      driver's error path.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d15a5020
    • David S. Miller's avatar
      Merge tag 'wireless-drivers-2019-11-14' of... · bb9b5441
      David S. Miller authored
      Merge tag 'wireless-drivers-2019-11-14' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers
      
      Kalle Valo says:
      
      ====================
      wireless-drivers fixes for v5.4
      
      Hopefully last fixes for v5.4, only one iwlwifi fix this time.
      
      iwlwifi
      
      * fix A-MSDU data corruption when using CCMP/GCMP ciphers
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bb9b5441
    • Jouni Hogander's avatar
      slcan: Fix memory leak in error path · ed50e160
      Jouni Hogander authored
      This patch is fixing memory leak reported by Syzkaller:
      
      BUG: memory leak unreferenced object 0xffff888067f65500 (size 4096):
        comm "syz-executor043", pid 454, jiffies 4294759719 (age 11.930s)
        hex dump (first 32 bytes):
          73 6c 63 61 6e 30 00 00 00 00 00 00 00 00 00 00 slcan0..........
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
        backtrace:
          [<00000000a06eec0d>] __kmalloc+0x18b/0x2c0
          [<0000000083306e66>] kvmalloc_node+0x3a/0xc0
          [<000000006ac27f87>] alloc_netdev_mqs+0x17a/0x1080
          [<0000000061a996c9>] slcan_open+0x3ae/0x9a0
          [<000000001226f0f9>] tty_ldisc_open.isra.1+0x76/0xc0
          [<0000000019289631>] tty_set_ldisc+0x28c/0x5f0
          [<000000004de5a617>] tty_ioctl+0x48d/0x1590
          [<00000000daef496f>] do_vfs_ioctl+0x1c7/0x1510
          [<0000000059068dbc>] ksys_ioctl+0x99/0xb0
          [<000000009a6eb334>] __x64_sys_ioctl+0x78/0xb0
          [<0000000053d0332e>] do_syscall_64+0x16f/0x580
          [<0000000021b83b99>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
          [<000000008ea75434>] 0xffffffffffffffff
      
      Cc: Wolfgang Grandegger <wg@grandegger.com>
      Cc: Marc Kleine-Budde <mkl@pengutronix.de>
      Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com>
      Signed-off-by: default avatarJouni Hogander <jouni.hogander@unikie.com>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      ed50e160
  3. 13 Nov, 2019 15 commits
  4. 12 Nov, 2019 6 commits
    • Ursula Braun's avatar
      net/smc: fix refcount non-blocking connect() -part 2 · 6d6dd528
      Ursula Braun authored
      If an SMC socket is immediately terminated after a non-blocking connect()
      has been called, a memory leak is possible.
      Due to the sock_hold move in
      commit 301428ea ("net/smc: fix refcounting for non-blocking connect()")
      an extra sock_put() is needed in smc_connect_work(), if the internal
      TCP socket is aborted and cancels the sk_stream_wait_connect() of the
      connect worker.
      
      Reported-by: syzbot+4b73ad6fc767e576e275@syzkaller.appspotmail.com
      Fixes: 301428ea ("net/smc: fix refcounting for non-blocking connect()")
      Signed-off-by: default avatarUrsula Braun <ubraun@linux.ibm.com>
      Signed-off-by: default avatarKarsten Graul <kgraul@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6d6dd528
    • Xiaodong Xu's avatar
      xfrm: release device reference for invalid state · 4944a4b1
      Xiaodong Xu authored
      An ESP packet could be decrypted in async mode if the input handler for
      this packet returns -EINPROGRESS in xfrm_input(). At this moment the device
      reference in skb is held. Later xfrm_input() will be invoked again to
      resume the processing.
      If the transform state is still valid it would continue to release the
      device reference and there won't be a problem; however if the transform
      state is not valid when async resumption happens, the packet will be
      dropped while the device reference is still being held.
      When the device is deleted for some reason and the reference to this
      device is not properly released, the kernel will keep logging like:
      
      unregister_netdevice: waiting for ppp2 to become free. Usage count = 1
      
      The issue is observed when running IPsec traffic over a PPPoE device based
      on a bridge interface. By terminating the PPPoE connection on the server
      end for multiple times, the PPPoE device on the client side will eventually
      get stuck on the above warning message.
      
      This patch will check the async mode first and continue to release device
      reference in async resumption, before it is dropped due to invalid state.
      
      v2: Do not assign address family from outer_mode in the transform if the
      state is invalid
      
      v3: Release device reference in the error path instead of jumping to resume
      
      Fixes: 4ce3dbe3 ("xfrm: Fix xfrm_input() to verify state is valid when (encap_type < 0)")
      Signed-off-by: default avatarXiaodong Xu <stid.smth@gmail.com>
      Reported-by: default avatarBo Chen <chenborfc@163.com>
      Tested-by: default avatarBo Chen <chenborfc@163.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      4944a4b1
    • YueHaibing's avatar
      mdio_bus: Fix PTR_ERR applied after initialization to constant · 1d463956
      YueHaibing authored
      Fix coccinelle warning:
      
      ./drivers/net/phy/mdio_bus.c:67:5-12: ERROR: PTR_ERR applied after initialization to constant on line 62
      ./drivers/net/phy/mdio_bus.c:68:5-12: ERROR: PTR_ERR applied after initialization to constant on line 62
      
      Fix this by using IS_ERR before PTR_ERR
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Fixes: 71dd6c0d ("net: phy: add support for reset-controller")
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1d463956
    • Stephan Gerhold's avatar
      NFC: nxp-nci: Fix NULL pointer dereference after I2C communication error · a71a29f5
      Stephan Gerhold authored
      I2C communication errors (-EREMOTEIO) during the IRQ handler of nxp-nci
      result in a NULL pointer dereference at the moment:
      
          BUG: kernel NULL pointer dereference, address: 0000000000000000
          Oops: 0002 [#1] PREEMPT SMP NOPTI
          CPU: 1 PID: 355 Comm: irq/137-nxp-nci Not tainted 5.4.0-rc6 #1
          RIP: 0010:skb_queue_tail+0x25/0x50
          Call Trace:
           nci_recv_frame+0x36/0x90 [nci]
           nxp_nci_i2c_irq_thread_fn+0xd1/0x285 [nxp_nci_i2c]
           ? preempt_count_add+0x68/0xa0
           ? irq_forced_thread_fn+0x80/0x80
           irq_thread_fn+0x20/0x60
           irq_thread+0xee/0x180
           ? wake_threads_waitq+0x30/0x30
           kthread+0xfb/0x130
           ? irq_thread_check_affinity+0xd0/0xd0
           ? kthread_park+0x90/0x90
           ret_from_fork+0x1f/0x40
      
      Afterward the kernel must be rebooted to work properly again.
      
      This happens because it attempts to call nci_recv_frame() with skb == NULL.
      However, unlike nxp_nci_fw_recv_frame(), nci_recv_frame() does not have any
      NULL checks for skb, causing the NULL pointer dereference.
      
      Change the code to call only nxp_nci_fw_recv_frame() in case of an error.
      Make sure to log it so it is obvious that a communication error occurred.
      The error above then becomes:
      
          nxp-nci_i2c i2c-NXP1001:00: NFC: Read failed with error -121
          nci: __nci_request: wait_for_completion_interruptible_timeout failed 0
          nxp-nci_i2c i2c-NXP1001:00: NFC: Read failed with error -121
      
      Fixes: 6be88670 ("NFC: nxp-nci_i2c: Add I2C support to NXP NCI driver")
      Signed-off-by: default avatarStephan Gerhold <stephan@gerhold.net>
      Reviewed-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a71a29f5
    • Jiri Pirko's avatar
      mlxsw: core: Enable devlink reload only on probe · 73a533ec
      Jiri Pirko authored
      Call devlink enable only during probe time and avoid deadlock
      during reload.
      Reported-by: default avatarShalom Toledo <shalomt@mellanox.com>
      Fixes: 5a508a25 ("devlink: disallow reload operation during device cleanup")
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Tested-by: default avatarShalom Toledo <shalomt@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      73a533ec
    • Aya Levin's avatar
      devlink: Add method for time-stamp on reporter's dump · d279505b
      Aya Levin authored
      When setting the dump's time-stamp, use ktime_get_real in addition to
      jiffies. This simplifies the user space implementation and bypasses
      some inconsistent behavior with translating jiffies to current time.
      The time taken is transformed into nsec, to comply with y2038 issue.
      
      Fixes: c8e1da0b ("devlink: Add health report functionality")
      Signed-off-by: default avatarAya Levin <ayal@mellanox.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d279505b
  5. 11 Nov, 2019 1 commit
  6. 10 Nov, 2019 2 commits
  7. 09 Nov, 2019 9 commits
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net · 0058b0a5
      Linus Torvalds authored
      Pull networking fixes from David Miller:
      
       1) BPF sample build fixes from Björn Töpel
      
       2) Fix powerpc bpf tail call implementation, from Eric Dumazet.
      
       3) DCCP leaks jiffies on the wire, fix also from Eric Dumazet.
      
       4) Fix crash in ebtables when using dnat target, from Florian Westphal.
      
       5) Fix port disable handling whne removing bcm_sf2 driver, from Florian
          Fainelli.
      
       6) Fix kTLS sk_msg trim on fallback to copy mode, from Jakub Kicinski.
      
       7) Various KCSAN fixes all over the networking, from Eric Dumazet.
      
       8) Memory leaks in mlx5 driver, from Alex Vesker.
      
       9) SMC interface refcounting fix, from Ursula Braun.
      
      10) TSO descriptor handling fixes in stmmac driver, from Jose Abreu.
      
      11) Add a TX lock to synchonize the kTLS TX path properly with crypto
          operations. From Jakub Kicinski.
      
      12) Sock refcount during shutdown fix in vsock/virtio code, from Stefano
          Garzarella.
      
      13) Infinite loop in Intel ice driver, from Colin Ian King.
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (108 commits)
        ixgbe: need_wakeup flag might not be set for Tx
        i40e: need_wakeup flag might not be set for Tx
        igb/igc: use ktime accessors for skb->tstamp
        i40e: Fix for ethtool -m issue on X722 NIC
        iavf: initialize ITRN registers with correct values
        ice: fix potential infinite loop because loop counter being too small
        qede: fix NULL pointer deref in __qede_remove()
        net: fix data-race in neigh_event_send()
        vsock/virtio: fix sock refcnt holding during the shutdown
        net: ethernet: octeon_mgmt: Account for second possible VLAN header
        mac80211: fix station inactive_time shortly after boot
        net/fq_impl: Switch to kvmalloc() for memory allocation
        mac80211: fix ieee80211_txq_setup_flows() failure path
        ipv4: Fix table id reference in fib_sync_down_addr
        ipv6: fixes rt6_probe() and fib6_nh->last_probe init
        net: hns: Fix the stray netpoll locks causing deadlock in NAPI path
        net: usb: qmi_wwan: add support for DW5821e with eSIM support
        CDC-NCM: handle incomplete transfer of MTU
        nfc: netlink: fix double device reference drop
        NFC: st21nfca: fix double free
        ...
      0058b0a5
    • Linus Torvalds's avatar
      Merge tag 'for-linus-2019-11-08' of git://git.kernel.dk/linux-block · 5cb8418c
      Linus Torvalds authored
      Pull block fixes from Jens Axboe:
      
       - Two NVMe device removal crash fixes, and a compat fixup for for an
         ioctl that was introduced in this release (Anton, Charles, Max - via
         Keith)
      
       - Missing error path mutex unlock for drbd (Dan)
      
       - cgroup writeback fixup on dead memcg (Tejun)
      
       - blkcg online stats print fix (Tejun)
      
      * tag 'for-linus-2019-11-08' of git://git.kernel.dk/linux-block:
        cgroup,writeback: don't switch wbs immediately on dead wbs if the memcg is dead
        block: drbd: remove a stray unlock in __drbd_send_protocol()
        blkcg: make blkcg_print_stat() print stats only for online blkgs
        nvme: change nvme_passthru_cmd64 to explicitly mark rsvd
        nvme-multipath: fix crash in nvme_mpath_clear_ctrl_paths
        nvme-rdma: fix a segmentation fault during module unload
      5cb8418c
    • David S. Miller's avatar
      Merge branch '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue · a2582cdc
      David S. Miller authored
      Jeff Kirsher says:
      
      ====================
      Intel Wired LAN Driver Fixes 2019-11-08
      
      This series contains fixes to igb, igc, ixgbe, i40e, iavf and ice
      drivers.
      
      Colin Ian King fixes a potentially wrap-around counter in a for-loop.
      
      Nick fixes the default ITR values for the iavf driver to 50 usecs
      interval.
      
      Arkadiusz fixes 'ethtool -m' for X722 devices where the correct value
      cannot be obtained from the firmware, so add X722 to the check to ensure
      the wrong value is not returned.
      
      Jake fixes igb and igc drivers in their implementation of launch time
      support by declaring skb->tstamp value as ktime_t instead of s64.
      
      Magnus fixes ixgbe and i40e where the need_wakeup flag for transmit may
      not be set for AF_XDP sockets that are only used to send packets.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a2582cdc
    • Magnus Karlsson's avatar
      ixgbe: need_wakeup flag might not be set for Tx · 0843aa8f
      Magnus Karlsson authored
      The need_wakeup flag for Tx might not be set for AF_XDP sockets that
      are only used to send packets. This happens if there is at least one
      outstanding packet that has not been completed by the hardware and we
      get that corresponding completion (which will not generate an
      interrupt since interrupts are disabled in the napi poll loop) between
      the time we stopped processing the Tx completions and interrupts are
      enabled again. In this case, the need_wakeup flag will have been
      cleared at the end of the Tx completion processing as we believe we
      will get an interrupt from the outstanding completion at a later point
      in time. But if this completion interrupt occurs before interrupts
      are enable, we lose it and should at that point really have set the
      need_wakeup flag since there are no more outstanding completions that
      can generate an interrupt to continue the processing. When this
      happens, user space will see a Tx queue need_wakeup of 0 and skip
      issuing a syscall, which means will never get into the Tx processing
      again and we have a deadlock.
      
      This patch introduces a quick fix for this issue by just setting the
      need_wakeup flag for Tx to 1 all the time. I am working on a proper
      fix for this that will toggle the flag appropriately, but it is more
      challenging than I anticipated and I am afraid that this patch will
      not be completed before the merge window closes, therefore this easier
      fix for now. This fix has a negative performance impact in the range
      of 0% to 4%. Towards the higher end of the scale if you have driver
      and application on the same core and issue a lot of packets, and
      towards no negative impact if you use two cores, lower transmission
      speeds and/or a workload that also receives packets.
      Signed-off-by: default avatarMagnus Karlsson <magnus.karlsson@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      0843aa8f
    • Magnus Karlsson's avatar
      i40e: need_wakeup flag might not be set for Tx · 70563957
      Magnus Karlsson authored
      The need_wakeup flag for Tx might not be set for AF_XDP sockets that
      are only used to send packets. This happens if there is at least one
      outstanding packet that has not been completed by the hardware and we
      get that corresponding completion (which will not generate an
      interrupt since interrupts are disabled in the napi poll loop) between
      the time we stopped processing the Tx completions and interrupts are
      enabled again. In this case, the need_wakeup flag will have been
      cleared at the end of the Tx completion processing as we believe we
      will get an interrupt from the outstanding completion at a later point
      in time. But if this completion interrupt occurs before interrupts
      are enable, we lose it and should at that point really have set the
      need_wakeup flag since there are no more outstanding completions that
      can generate an interrupt to continue the processing. When this
      happens, user space will see a Tx queue need_wakeup of 0 and skip
      issuing a syscall, which means will never get into the Tx processing
      again and we have a deadlock.
      
      This patch introduces a quick fix for this issue by just setting the
      need_wakeup flag for Tx to 1 all the time. I am working on a proper
      fix for this that will toggle the flag appropriately, but it is more
      challenging than I anticipated and I am afraid that this patch will
      not be completed before the merge window closes, therefore this easier
      fix for now. This fix has a negative performance impact in the range
      of 0% to 4%. Towards the higher end of the scale if you have driver
      and application on the same core and issue a lot of packets, and
      towards no negative impact if you use two cores, lower transmission
      speeds and/or a workload that also receives packets.
      Signed-off-by: default avatarMagnus Karlsson <magnus.karlsson@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      70563957
    • Jacob Keller's avatar
      igb/igc: use ktime accessors for skb->tstamp · 6acab13b
      Jacob Keller authored
      When implementing launch time support in the igb and igc drivers, the
      skb->tstamp value is assumed to be a s64, but it's declared as a ktime_t
      value.
      
      Although ktime_t is typedef'd to s64 it wasn't always, and the kernel
      provides accessors for ktime_t values.
      
      Use the ktime_to_timespec64 and ktime_set accessors instead of directly
      assuming that the variable is always an s64.
      
      This improves portability if the code is ever moved to another kernel
      version, or if the definition of ktime_t ever changes again in the
      future.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Acked-by: default avatarVinicius Costa Gomes <vinicius.gomes@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      6acab13b
    • Arkadiusz Kubalewski's avatar
      i40e: Fix for ethtool -m issue on X722 NIC · 4c9da6f2
      Arkadiusz Kubalewski authored
      This patch contains fix for a problem with command:
      'ethtool -m <dev>'
      which breaks functionality of:
      'ethtool <dev>'
      when called on X722 NIC
      
      Disallowed update of link phy_types on X722 NIC
      Currently correct value cannot be obtained from FW
      Previously wrong value returned by FW was used and was
      a root cause for incorrect output of 'ethtool <dev>' command
      Signed-off-by: default avatarArkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      4c9da6f2
    • Nicholas Nunley's avatar
      iavf: initialize ITRN registers with correct values · 4eda4e00
      Nicholas Nunley authored
      Since commit 92418fb1 ("i40e/i40evf: Use usec value instead of reg
      value for ITR defines") the driver tracks the interrupt throttling
      intervals in single usec units, although the actual ITRN registers are
      programmed in 2 usec units. Most register programming flows in the driver
      correctly handle the conversion, although it is currently not applied when
      the registers are initialized to their default values. Most of the time
      this doesn't present a problem since the default values are usually
      immediately overwritten through the standard adaptive throttling mechanism,
      or updated manually by the user, but if adaptive throttling is disabled and
      the interval values are left alone then the incorrect value will persist.
      
      Since the intended default interval of 50 usecs (vs. 100 usecs as
      programmed) performs better for most traffic workloads, this can lead to
      performance regressions.
      
      This patch adds the correct conversion when writing the initial values to
      the ITRN registers.
      Signed-off-by: default avatarNicholas Nunley <nicholas.d.nunley@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      4eda4e00
    • Colin Ian King's avatar
      ice: fix potential infinite loop because loop counter being too small · 615457a2
      Colin Ian King authored
      Currently the for-loop counter i is a u8 however it is being checked
      against a maximum value hw->num_tx_sched_layers which is a u16. Hence
      there is a potential wrap-around of counter i back to zero if
      hw->num_tx_sched_layers is greater than 255.  Fix this by making i
      a u16.
      
      Addresses-Coverity: ("Infinite loop")
      Fixes: b36c598c ("ice: Updates to Tx scheduler code")
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      615457a2