1. 23 Dec, 2019 9 commits
    • Johannes Berg's avatar
      iwlwifi: mvm: fix SKB leak on invalid queue · b9f726c9
      Johannes Berg authored
      It used to be the case that if we got here, we wouldn't warn
      but instead allocate the queue (DQA). With using the mac80211
      TXQs model this changed, and we really have nothing to do with
      the frame here anymore, hence the warning now.
      
      However, clearly we missed in coding & review that this is now
      a pure error path and leaks the SKB if we return 0 instead of
      an indication that the SKB needs to be freed. Fix this.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Fixes: cfbc6c4c ("iwlwifi: mvm: support mac80211 TXQs model")
      Signed-off-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      b9f726c9
    • Johannes Berg's avatar
      iwlwifi: pcie: extend hardware workaround to context-info · d84a7a65
      Johannes Berg authored
      After more investigation on the hardware side, it appears that the
      hardware bug regarding 2^32 boundary reaching/crossing also affects
      other uses of the DMA engine, in particular the ones triggered by
      the context-info (image loader) mechanism.
      
      It also turns out that the bug only affects devices with gen2 TX
      hardware engine, so we don't need to change context info for gen3.
      The TX path workarounds are simpler to still keep for both though.
      
      Add the workaround to that code as well; this is a lot simpler as
      we have just a single way to allocate DMA memory there.
      
      I made the algorithm recursive (with a small limit) since it's
      actually (almost) impossible to hit this today - dma_alloc_coherent
      is currently documented to always return 32-bit addressable memory
      regardless of the DMA mask for it, and so we could only get REALLY
      unlucky to get the very last page in that area.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      d84a7a65
    • Haim Dreyfuss's avatar
      iwlwifi: Don't ignore the cap field upon mcc update · 2763bba6
      Haim Dreyfuss authored
      When receiving a new MCC driver get all the data about the new country
      code and its regulatory information.
      Mistakenly, we ignored the cap field, which includes global regulatory
      information which should be applies to every channel.
      Fix it.
      Signed-off-by: default avatarHaim Dreyfuss <haim.dreyfuss@intel.com>
      Signed-off-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      2763bba6
    • Johannes Berg's avatar
      iwlwifi: mvm: report TX rate to mac80211 directly for RS offload · ed780545
      Johannes Berg authored
      If we have offloaded rate scaling, which is always true for those
      devices supporting HE, then report the TX rate directly from the
      data the firmware gives us, instead of only passing it to mac80211
      on frame status only and for it to track it.
      
      First of all, this makes us always report the last good rate that
      the rate scaling algorithm picked, which is better than reporting
      the last rate for any frame since management frames etc. are sent
      with very low rates and could interfere.
      
      Additionally, this allows us to properly report HE rates, though
      in case there's a lot of trigger-based traffic, we don't get any
      choice in the rates and don't report that properly right now.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      ed780545
    • Luca Coelho's avatar
      iwlwifi: mvm: fix NVM check for 3168 devices · b3f20e09
      Luca Coelho authored
      We had a check on !NVM_EXT and then a check for NVM_SDP in the else
      block of this if.  The else block, obviously, could only be reached if
      using NVM_EXT, so it would never be NVM_SDP.
      
      Fix that by checking whether the nvm_type is IWL_NVM instead of
      checking for !IWL_NVM_EXT to solve this issue.
      Reported-by: default avatarStefan Sperling <stsp@stsp.name>
      Signed-off-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      b3f20e09
    • Luca Coelho's avatar
      iwlwifi: fix TLV fragment allocation loop · 4f565ee2
      Luca Coelho authored
      In the allocation loop, "pages" will never become zero (because of the
      DIV_ROUND_UP), so if we can't allocate any size and pages becomes 1,
      we will keep trying to allocate 1 page until it succeeds.  And in that
      case, as coverity reported, block will never be NULL.
      Reported-by: default avatarcoverity-bot <keescook+coverity-bot@chromium.org>
      Addresses-Coverity-ID: 1487402 ("Control flow issues")
      Fixes: 14124b25 ("iwlwifi: dbg_ini: implement monitor allocation flow")
      Signed-off-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      Fixes: 14124b25 ("iwlwifi: dbg_ini: implement monitor allocation flow")
      Signed-off-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      4f565ee2
    • Johannes Berg's avatar
      iwlwifi: pcie: allocate smaller dev_cmd for TX headers · a89c72ff
      Johannes Berg authored
      As noted in the previous commit, due to the way we allocate the
      dev_cmd headers with 324 byte size, and 4/8 byte alignment, the
      part we use of them (bytes 20..40-68) could still cross a page
      and thus 2^32 boundary.
      
      Address this by using alignment to ensure that the allocation
      cannot cross a page boundary, on hardware that's affected. To
      make that not cause more memory consumption, reduce the size of
      the allocations to the necessary size - we go from 324 bytes in
      each allocation to 60/68 on gen2 depending on family, and ~120
      or so on gen1 (so on gen1 it's a pure reduction in size, since
      we don't need alignment there).
      
      To avoid size and clearing issues, add a new structure that's
      just the header, and use kmem_cache_zalloc().
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      a89c72ff
    • Johannes Berg's avatar
      iwlwifi: pcie: detect the DMA bug and warn if it happens · c5a4e8eb
      Johannes Berg authored
      Warn if the DMA bug is going to happen. We don't have a good
      way of actually aborting in this case and we have workarounds
      in place for the cases where it happens, but in order to not
      be surprised add a safety-check and warn.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      c5a4e8eb
    • Johannes Berg's avatar
      iwlwifi: pcie: work around DMA hardware bug · c4a786b3
      Johannes Berg authored
      There's a hardware bug in the flow handler (DMA engine), if the
      address + len of some TB wraps around a 2^32 boundary, the carry
      bit is then carried over into the next TB.
      
      Work around this by copying the data to a new page when we find
      this situation, and then copy it in a way that we cannot hit the
      very end of the page.
      
      To be able to free the new page again later we need to chain it
      to the TSO page, use the last pointer there to make sure we can
      never use the page fully for DMA, and thus cannot cause the same
      overflow situation on this page.
      
      This leaves a few potential places (where we didn't observe the
      problem) unaddressed:
       * The second TB could reach or cross the end of a page (and thus
         2^32) due to the way we allocate the dev_cmd for the header
       * For host commands, a similar thing could happen since they're
         just kmalloc().
      We'll address these in further commits.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      c4a786b3
  2. 20 Dec, 2019 2 commits
  3. 19 Dec, 2019 1 commit
  4. 18 Dec, 2019 11 commits
  5. 17 Dec, 2019 9 commits
    • David S. Miller's avatar
      Merge tag 'wireless-drivers-2019-12-17' of... · 040cda8a
      David S. Miller authored
      Merge tag 'wireless-drivers-2019-12-17' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers
      
      Kalle Valo says:
      
      ====================
      wireless-drivers fixes for v5.5
      
      First set of fixes for v5.5. Fixing security issues, some regressions
      and few major bugs.
      
      mwifiex
      
      * security fix for handling country Information Elements (CVE-2019-14895)
      
      * security fix for handling TDLS Information Elements
      
      ath9k
      
      * fix endian issue with ath9k_pci_owl_loader
      
      mt76
      
      * fix default mac address handling
      
      iwlwifi
      
      * fix merge damage which lead to firmware crashing during boot on some devices
      
      * fix device initialisation regression on some devices
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      040cda8a
    • Ioana Ciornei's avatar
      dpaa2-ptp: fix double free of the ptp_qoriq IRQ · daa6eb5a
      Ioana Ciornei authored
      Upon reusing the ptp_qoriq driver, the ptp_qoriq_free() function was
      used on the remove path to free any allocated resources.
      The ptp_qoriq IRQ is among these resources that are freed in
      ptp_qoriq_free() even though it is also a managed one (allocated using
      devm_request_threaded_irq).
      
      Drop the resource managed version of requesting the IRQ in order to not
      trigger a double free of the interrupt as below:
      
      [  226.731005] Trying to free already-free IRQ 126
      [  226.735533] WARNING: CPU: 6 PID: 749 at kernel/irq/manage.c:1707
      __free_irq+0x9c/0x2b8
      [  226.743435] Modules linked in:
      [  226.746480] CPU: 6 PID: 749 Comm: bash Tainted: G        W
      5.4.0-03629-gfd7102c32b2c-dirty #912
      [  226.755857] Hardware name: NXP Layerscape LX2160ARDB (DT)
      [  226.761244] pstate: 40000085 (nZcv daIf -PAN -UAO)
      [  226.766022] pc : __free_irq+0x9c/0x2b8
      [  226.769758] lr : __free_irq+0x9c/0x2b8
      [  226.773493] sp : ffff8000125039f0
      (...)
      [  226.856275] Call trace:
      [  226.858710]  __free_irq+0x9c/0x2b8
      [  226.862098]  free_irq+0x30/0x70
      [  226.865229]  devm_irq_release+0x14/0x20
      [  226.869054]  release_nodes+0x1b0/0x220
      [  226.872790]  devres_release_all+0x34/0x50
      [  226.876790]  device_release_driver_internal+0x100/0x1c0
      
      Fixes: d346c9e8 ("dpaa2-ptp: reuse ptp_qoriq driver")
      Cc: Yangbo Lu <yangbo.lu@nxp.com>
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Reviewed-by: default avatarYangbo Lu <yangbo.lu@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      daa6eb5a
    • David S. Miller's avatar
      Merge tag 'mac80211-for-net-2019-10-16' of... · ad125c6c
      David S. Miller authored
      Merge tag 'mac80211-for-net-2019-10-16' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
      
      Johannes Berg says:
      
      ====================
      A handful of fixes:
       * disable AQL on most drivers, addressing the iwlwifi issues
       * fix double-free on network namespace changes
       * fix TID field in frames injected through monitor interfaces
       * fix ieee80211_calc_rx_airtime()
       * fix NULL pointer dereference in rfkill (and remove BUG_ON)
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ad125c6c
    • Arnd Bergmann's avatar
      net: dsa: ocelot: add NET_VENDOR_MICROSEMI dependency · 95bed1a9
      Arnd Bergmann authored
      Selecting MSCC_OCELOT_SWITCH is not possible when NET_VENDOR_MICROSEMI
      is disabled:
      
      WARNING: unmet direct dependencies detected for MSCC_OCELOT_SWITCH
        Depends on [n]: NETDEVICES [=y] && ETHERNET [=n] && NET_VENDOR_MICROSEMI [=n] && NET_SWITCHDEV [=y] && HAS_IOMEM [=y]
        Selected by [m]:
        - NET_DSA_MSCC_FELIX [=m] && NETDEVICES [=y] && HAVE_NET_DSA [=y] && NET_DSA [=y] && PCI [=y]
      
      Add a Kconfig dependency on NET_VENDOR_MICROSEMI, which also implies
      CONFIG_NETDEVICES.
      
      Depending on a vendor config violates menuconfig locality for the DSA
      driver, but is the smallest compromise since all other solutions are
      much more complicated (see [0]).
      
      https://www.spinics.net/lists/netdev/msg618808.html
      
      Fixes: 56051948 ("net: dsa: ocelot: add driver for Felix switch family")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarMao Wenan <maowenan@huawei.com>
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      95bed1a9
    • Navid Emamdoost's avatar
      net: gemini: Fix memory leak in gmac_setup_txqs · f37f7103
      Navid Emamdoost authored
      In the implementation of gmac_setup_txqs() the allocated desc_ring is
      leaked if TX queue base is not aligned. Release it via
      dma_free_coherent.
      
      Fixes: 4d5ae32f ("net: ethernet: Add a driver for Gemini gigabit ethernet")
      Signed-off-by: default avatarNavid Emamdoost <navid.emamdoost@gmail.com>
      Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f37f7103
    • Florian Fainelli's avatar
      net: dsa: b53: Fix egress flooding settings · 63cc54a6
      Florian Fainelli authored
      There were several issues with 53568438 ("net: dsa: b53: Add support for port_egress_floods callback") that resulted in breaking connectivity for standalone ports:
      
      - both user and CPU ports must allow unicast and multicast forwarding by
        default otherwise this just flat out breaks connectivity for
        standalone DSA ports
      - IP multicast is treated similarly as multicast, but has separate
        control registers
      - the UC, MC and IPMC lookup failure register offsets were wrong, and
        instead used bit values that are meaningful for the
        B53_IP_MULTICAST_CTRL register
      
      Fixes: 53568438 ("net: dsa: b53: Add support for port_egress_floods callback")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarVivien Didelot <vivien.didelot@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      63cc54a6
    • David S. Miller's avatar
      Merge branch 'vsock-fixes' · 1865a7b3
      David S. Miller authored
      Stefano Garzarella says:
      
      ====================
      vsock/virtio: fix null-pointer dereference and related precautions
      
      This series mainly solves a possible null-pointer dereference in
      virtio_transport_recv_listen() introduced with the multi-transport
      support [PATCH 1].
      
      PATCH 2 adds a WARN_ON check for the same potential issue
      and a returned error in the virtio_transport_send_pkt_info() function
      to avoid crashing the kernel.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1865a7b3
    • Stefano Garzarella's avatar
      vsock/virtio: add WARN_ON check on virtio_transport_get_ops() · 4aaf5961
      Stefano Garzarella authored
      virtio_transport_get_ops() and virtio_transport_send_pkt_info()
      can only be used on connecting/connected sockets, since a socket
      assigned to a transport is required.
      
      This patch adds a WARN_ON() on virtio_transport_get_ops() to check
      this requirement, a comment and a returned error on
      virtio_transport_send_pkt_info(),
      Signed-off-by: default avatarStefano Garzarella <sgarzare@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4aaf5961
    • Stefano Garzarella's avatar
      vsock/virtio: fix null-pointer dereference in virtio_transport_recv_listen() · df18fa14
      Stefano Garzarella authored
      With multi-transport support, listener sockets are not bound to any
      transport. So, calling virtio_transport_reset(), when an error
      occurs, on a listener socket produces the following null-pointer
      dereference:
      
        BUG: kernel NULL pointer dereference, address: 00000000000000e8
        #PF: supervisor read access in kernel mode
        #PF: error_code(0x0000) - not-present page
        PGD 0 P4D 0
        Oops: 0000 [#1] SMP PTI
        CPU: 0 PID: 20 Comm: kworker/0:1 Not tainted 5.5.0-rc1-ste-00003-gb4be21f316ac-dirty #56
        Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014
        Workqueue: virtio_vsock virtio_transport_rx_work [vmw_vsock_virtio_transport]
        RIP: 0010:virtio_transport_send_pkt_info+0x20/0x130 [vmw_vsock_virtio_transport_common]
        Code: 1f 84 00 00 00 00 00 0f 1f 00 55 48 89 e5 41 57 41 56 41 55 49 89 f5 41 54 49 89 fc 53 48 83 ec 10 44 8b 76 20 e8 c0 ba fe ff <48> 8b 80 e8 00 00 00 e8 64 e3 7d c1 45 8b 45 00 41 8b 8c 24 d4 02
        RSP: 0018:ffffc900000b7d08 EFLAGS: 00010282
        RAX: 0000000000000000 RBX: ffff88807bf12728 RCX: 0000000000000000
        RDX: ffff88807bf12700 RSI: ffffc900000b7d50 RDI: ffff888035c84000
        RBP: ffffc900000b7d40 R08: ffff888035c84000 R09: ffffc900000b7d08
        R10: ffff8880781de800 R11: 0000000000000018 R12: ffff888035c84000
        R13: ffffc900000b7d50 R14: 0000000000000000 R15: ffff88807bf12724
        FS:  0000000000000000(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 00000000000000e8 CR3: 00000000790f4004 CR4: 0000000000160ef0
        DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
        DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
        Call Trace:
         virtio_transport_reset+0x59/0x70 [vmw_vsock_virtio_transport_common]
         virtio_transport_recv_pkt+0x5bb/0xe50 [vmw_vsock_virtio_transport_common]
         ? detach_buf_split+0xf1/0x130
         virtio_transport_rx_work+0xba/0x130 [vmw_vsock_virtio_transport]
         process_one_work+0x1c0/0x300
         worker_thread+0x45/0x3c0
         kthread+0xfc/0x130
         ? current_work+0x40/0x40
         ? kthread_park+0x90/0x90
         ret_from_fork+0x35/0x40
        Modules linked in: sunrpc kvm_intel kvm vmw_vsock_virtio_transport vmw_vsock_virtio_transport_common irqbypass vsock virtio_rng rng_core
        CR2: 00000000000000e8
        ---[ end trace e75400e2ea2fa824 ]---
      
      This happens because virtio_transport_reset() calls
      virtio_transport_send_pkt_info() that can be used only on
      connecting/connected sockets.
      
      This patch fixes the issue, using virtio_transport_reset_no_sock()
      instead of virtio_transport_reset() when we are handling a listener
      socket.
      
      Fixes: c0cfa2d8 ("vsock: add multi-transports support")
      Signed-off-by: default avatarStefano Garzarella <sgarzare@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      df18fa14
  6. 16 Dec, 2019 1 commit
  7. 15 Dec, 2019 7 commits