1. 13 Dec, 2018 40 commits
    • Emmanuel Grumbach's avatar
      mac80211: ignore NullFunc frames in the duplicate detection · fd54ea70
      Emmanuel Grumbach authored
      commit 990d71846a0b7281bd933c34d734e6afc7408e7e upstream.
      
      NullFunc packets should never be duplicate just like
      QoS-NullFunc packets.
      
      We saw a client that enters / exits power save with
      NullFunc frames (and not with QoS-NullFunc) despite the
      fact that the association supports HT.
      This specific client also re-uses a non-zero sequence number
      for different NullFunc frames.
      At some point, the client had to send a retransmission of
      the NullFunc frame and we dropped it, leading to a
      misalignment in the power save state.
      Fix this by never consider a NullFunc frame as duplicate,
      just like we do for QoS NullFunc frames.
      
      This fixes https://bugzilla.kernel.org/show_bug.cgi?id=201449
      
      CC: <stable@vger.kernel.org>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fd54ea70
    • Felix Fietkau's avatar
      mac80211: fix reordering of buffered broadcast packets · db32c245
      Felix Fietkau authored
      commit 9ec1190d065998650fd9260dea8cf3e1f56c0e8c upstream.
      
      If the buffered broadcast queue contains packets, letting new packets bypass
      that queue can lead to heavy reordering, since the driver is probably throttling
      transmission of buffered multicast packets after beacons.
      
      Keep buffering packets until the buffer has been cleared (and no client
      is in powersave mode).
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarFelix Fietkau <nbd@nbd.name>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      db32c245
    • Felix Fietkau's avatar
      mac80211: ignore tx status for PS stations in ieee80211_tx_status_ext · 7df29ead
      Felix Fietkau authored
      commit a317e65face482371de30246b6494feb093ff7f9 upstream.
      
      Make it behave like regular ieee80211_tx_status calls, except for the lack of
      filtered frame processing.
      This fixes spurious low-ack triggered disconnections with powersave clients
      connected to an AP.
      
      Fixes: f027c2ac ("mac80211: add ieee80211_tx_status_noskb")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarFelix Fietkau <nbd@nbd.name>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7df29ead
    • Ben Greear's avatar
      mac80211: Clear beacon_int in ieee80211_do_stop · 554eac28
      Ben Greear authored
      commit 5c21e8100dfd57c806e833ae905e26efbb87840f upstream.
      
      This fixes stale beacon-int values that would keep a netdev
      from going up.
      
      To reproduce:
      
      Create two VAP on one radio.
      vap1 has beacon-int 100, start it.
      vap2 has beacon-int 240, start it (and it will fail
        because beacon-int mismatch).
      reconfigure vap2 to have beacon-int 100 and start it.
        It will fail because the stale beacon-int 240 will be used
        in the ifup path and hostapd never gets a chance to set the
        new beacon interval.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarBen Greear <greearb@candelatech.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      554eac28
    • Vasyl Vavrychuk's avatar
      mac80211_hwsim: Timer should be initialized before device registered · 3a492ce1
      Vasyl Vavrychuk authored
      commit a1881c9b8a1edef0a5ae1d5c1b61406fe3402114 upstream.
      
      Otherwise if network manager starts configuring Wi-Fi interface
      immidiatelly after getting notification of its creation, we will get
      NULL pointer dereference:
      
        BUG: unable to handle kernel NULL pointer dereference at           (null)
        IP: [<ffffffff95ae94c8>] hrtimer_active+0x28/0x50
        ...
        Call Trace:
         [<ffffffff95ae9997>] ? hrtimer_try_to_cancel+0x27/0x110
         [<ffffffff95ae9a95>] ? hrtimer_cancel+0x15/0x20
         [<ffffffffc0803bf0>] ? mac80211_hwsim_config+0x140/0x1c0 [mac80211_hwsim]
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarVasyl Vavrychuk <vasyl.vavrychuk@globallogic.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3a492ce1
    • Macpaul Lin's avatar
      kgdboc: fix KASAN global-out-of-bounds bug in param_set_kgdboc_var() · 6d861927
      Macpaul Lin authored
      commit dada6a43b0402eba438a17ac86fdc64ac56a4607 upstream.
      
      This patch is trying to fix KE issue due to
      "BUG: KASAN: global-out-of-bounds in param_set_kgdboc_var+0x194/0x198"
      reported by Syzkaller scan."
      
      [26364:syz-executor0][name:report8t]BUG: KASAN: global-out-of-bounds in param_set_kgdboc_var+0x194/0x198
      [26364:syz-executor0][name:report&]Read of size 1 at addr ffffff900e44f95f by task syz-executor0/26364
      [26364:syz-executor0][name:report&]
      [26364:syz-executor0]CPU: 7 PID: 26364 Comm: syz-executor0 Tainted: G W 0
      [26364:syz-executor0]Call trace:
      [26364:syz-executor0][<ffffff9008095cf8>] dump_bacIctrace+Ox0/0x470
      [26364:syz-executor0][<ffffff9008096de0>] show_stack+0x20/0x30
      [26364:syz-executor0][<ffffff90089cc9c8>] dump_stack+Oxd8/0x128
      [26364:syz-executor0][<ffffff90084edb38>] print_address_description +0x80/0x4a8
      [26364:syz-executor0][<ffffff90084ee270>] kasan_report+Ox178/0x390
      [26364:syz-executor0][<ffffff90084ee4a0>] _asan_report_loadi_noabort+Ox18/0x20
      [26364:syz-executor0][<ffffff9008b092ac>] param_set_kgdboc_var+Ox194/0x198
      [26364:syz-executor0][<ffffff900813af64>] param_attr_store+Ox14c/0x270
      [26364:syz-executor0][<ffffff90081394c8>] module_attr_store+0x60/0x90
      [26364:syz-executor0][<ffffff90086690c0>] sysfs_kl_write+Ox100/0x158
      [26364:syz-executor0][<ffffff9008666d84>] kernfs_fop_write+0x27c/0x3a8
      [26364:syz-executor0][<ffffff9008508264>] do_loop_readv_writev+0x114/0x1b0
      [26364:syz-executor0][<ffffff9008509ac8>] do_readv_writev+0x4f8/0x5e0
      [26364:syz-executor0][<ffffff9008509ce4>] vfs_writev+0x7c/Oxb8
      [26364:syz-executor0][<ffffff900850ba64>] SyS_writev+Oxcc/0x208
      [26364:syz-executor0][<ffffff90080883f0>] elO_svc_naked +0x24/0x28
      [26364:syz-executor0][name:report&]
      [26364:syz-executor0][name:report&]The buggy address belongs to the variable:
      [26364:syz-executor0][name:report&] kgdb_tty_line+Ox3f/0x40
      [26364:syz-executor0][name:report&]
      [26364:syz-executor0][name:report&]Memory state around the buggy address:
      [26364:syz-executor0] ffffff900e44f800: 00 00 00 00 00 04 fa fa fa fa fa fa 00 fa fa fa
      [26364:syz-executor0] ffffff900e44f880: fa fa fa fa 00 fa fa fa fa fa fa fa 00 fa fa fa
      [26364:syz-executor0]> ffffff900e44f900: fa fa fa fa 04 fa fa fa fa fa fa fa 00 00 00 00
      [26364:syz-executor0][name:report&]                                       ^
      [26364:syz-executor0] ffffff900e44f980: 00 fa fa fa fa fa fa fa 04 fa fa fa fa fa fa fa
      [26364:syz-executor0] ffffff900e44fa00: 04 fa fa fa fa fa fa fa 00 fa fa fa fa fa fa fa
      [26364:syz-executor0][name:report&]
      [26364:syz-executor0][name:panic&]Disabling lock debugging due to kernel taint
      [26364:syz-executor0]------------[cut here]------------
      
      After checking the source code, we've found there might be an out-of-bounds
      access to "config[len - 1]" array when the variable "len" is zero.
      Signed-off-by: default avatarMacpaul Lin <macpaul@gmail.com>
      Acked-by: default avatarDaniel Thompson <daniel.thompson@linaro.org>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6d861927
    • Chanho Park's avatar
      tty: do not set TTY_IO_ERROR flag if console port · 9696ca90
      Chanho Park authored
      commit 2a48602615e0a2f563549c7d5c8d507f904cf96e upstream.
      
      Since Commit 761ed4a9 ('tty: serial_core: convert uart_close to use
      tty_port_close') and Commit 4dda864d ('tty: serial_core: Fix serial
      console crash on port shutdown), a serial port which is used as
      console can be stuck when logging out if there is a remained process.
      After logged out, agetty will try to grab the serial port but it will
      be failed because the previous process did not release the port
      correctly. To fix this, TTY_IO_ERROR bit should not be enabled of
      tty_port_close if the port is console port.
      
      Reproduce step:
      - Run background processes from serial console
      $ while true; do sleep 10; done &
      
      - Log out
      $ logout
      -> Stuck
      
      - Read journal log by journalctl | tail
      Jan 28 16:07:01 ubuntu systemd[1]: Stopped Serial Getty on ttyAMA0.
      Jan 28 16:07:01 ubuntu systemd[1]: Started Serial Getty on ttyAMA0.
      Jan 28 16:07:02 ubuntu agetty[1643]: /dev/ttyAMA0: not a tty
      
      Fixes: 761ed4a9 ("tty: serial_core: convert uart_close to use tty_port_close")
      Cc: Geert Uytterhoeven <geert+renesas@glider.be>
      Cc: Rob Herring <robh@kernel.org>
      Cc: Jiri Slaby <jslaby@suse.com>
      Signed-off-by: default avatarChanho Park <parkch98@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9696ca90
    • Peter Shih's avatar
      tty: serial: 8250_mtk: always resume the device in probe. · 32445bd5
      Peter Shih authored
      commit 100bc3e2bebf95506da57cbdf5f26b25f6da4c81 upstream.
      
      serial8250_register_8250_port calls uart_config_port, which calls
      config_port on the port before it tries to power on the port. So we need
      the port to be on before calling serial8250_register_8250_port. Change
      the code to always do a runtime resume in probe before registering port,
      and always do a runtime suspend in remove.
      
      This basically reverts the change in commit 68e5fc4a ("tty: serial:
      8250_mtk: use pm_runtime callbacks for enabling"), but still use
      pm_runtime callbacks.
      
      Fixes: 68e5fc4a ("tty: serial: 8250_mtk: use pm_runtime callbacks for enabling")
      Signed-off-by: default avatarPeter Shih <pihsun@chromium.org>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      32445bd5
    • Young Xiao's avatar
      staging: rtl8712: Fix possible buffer overrun · 902d410d
      Young Xiao authored
      commit 300cd664865bed5d50ae0a42fb4e3a6f415e8a10 upstream.
      
      In commit 8b7a13c3 ("staging: r8712u: Fix possible buffer
      overrun") we fix a potential off by one by making the limit smaller.
      The better fix is to make the buffer larger.  This makes it match up
      with the similar code in other drivers.
      
      Fixes: 8b7a13c3 ("staging: r8712u: Fix possible buffer overrun")
      Signed-off-by: default avatarYoung Xiao <YangX92@hotmail.com>
      Cc: stable <stable@vger.kernel.org>
      Reviewed-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      902d410d
    • Paulo Alcantara's avatar
      cifs: Fix separator when building path from dentry · fcfc7639
      Paulo Alcantara authored
      commit c988de29ca161823db6a7125e803d597ef75b49c upstream.
      
      Make sure to use the CIFS_DIR_SEP(cifs_sb) as path separator for
      prefixpath too. Fixes a bug with smb1 UNIX extensions.
      
      Fixes: a6b5058f ("fs/cifs: make share unaccessible at root level mountable")
      Signed-off-by: default avatarPaulo Alcantara <palcantara@suse.com>
      Reviewed-by: default avatarAurelien Aptel <aaptel@suse.com>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fcfc7639
    • Greg Kroah-Hartman's avatar
      Staging: lustre: remove two build warnings · 2f5b7679
      Greg Kroah-Hartman authored
      [for older kernels only, lustre has been removed from upstream]
      
      When someone writes:
      	strncpy(dest, source, sizeof(source));
      they really are just doing the same thing as:
      	strcpy(dest, source);
      but somehow they feel better because they are now using the "safe"
      version of the string functions.  Cargo-cult programming at its
      finest...
      
      gcc-8 rightfully warns you about doing foolish things like this.  Now
      that the stable kernels are all starting to be built using gcc-8, let's
      get rid of this warning so that we do not have to gaze at this horror.
      
      To dropt the warning, just convert the code to using strcpy() so that if
      someone really wants to audit this code and find all of the obvious
      problems, it will be easier to do so.
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2f5b7679
    • Stefan Hajnoczi's avatar
      vhost/vsock: fix use-after-free in network stack callers · 569fc4ff
      Stefan Hajnoczi authored
      [ Upstream commit 834e772c8db0c6a275d75315d90aba4ebbb1e249 ]
      
      If the network stack calls .send_pkt()/.cancel_pkt() during .release(),
      a struct vhost_vsock use-after-free is possible.  This occurs because
      .release() does not wait for other CPUs to stop using struct
      vhost_vsock.
      
      Switch to an RCU-enabled hashtable (indexed by guest CID) so that
      .release() can wait for other CPUs by calling synchronize_rcu().  This
      also eliminates vhost_vsock_lock acquisition in the data path so it
      could have a positive effect on performance.
      
      This is CVE-2018-14625 "kernel: use-after-free Read in vhost_transport_send_pkt".
      
      Cc: stable@vger.kernel.org
      Reported-and-tested-by: syzbot+bd391451452fb0b93039@syzkaller.appspotmail.com
      Reported-by: syzbot+e3e074963495f92a89ed@syzkaller.appspotmail.com
      Reported-by: syzbot+d5a0a170c5069658b141@syzkaller.appspotmail.com
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Acked-by: default avatarJason Wang <jasowang@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      569fc4ff
    • Gao feng's avatar
      vsock: lookup and setup guest_cid inside vhost_vsock_lock · 2d5a1b31
      Gao feng authored
      [ Upstream commit 6c083c2b ]
      
      Multi vsocks may setup the same cid at the same time.
      Signed-off-by: default avatarGao feng <omarapazanadi@gmail.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Reviewed-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      2d5a1b31
    • Kees Cook's avatar
      swiotlb: clean up reporting · adcc5726
      Kees Cook authored
      commit 7d63fb3af87aa67aa7d24466e792f9d7c57d8e79 upstream.
      
      This removes needless use of '%p', and refactors the printk calls to
      use pr_*() helpers instead.
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Reviewed-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      [bwh: Backported to 4.9:
       - Adjust filename
       - Remove "swiotlb: " prefix from an additional log message]
      Signed-off-by: default avatarBen Hutchings <ben.hutchings@codethink.co.uk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      adcc5726
    • Jens Axboe's avatar
      sr: pass down correctly sized SCSI sense buffer · cb101349
      Jens Axboe authored
      commit f7068114d45ec55996b9040e98111afa56e010fe upstream.
      
      We're casting the CDROM layer request_sense to the SCSI sense
      buffer, but the former is 64 bytes and the latter is 96 bytes.
      As we generally allocate these on the stack, we end up blowing
      up the stack.
      
      Fix this by wrapping the scsi_execute() call with a properly
      sized sense buffer, and copying back the bits for the CDROM
      layer.
      Reported-by: default avatarPiotr Gabriel Kosinski <pg.kosinski@gmail.com>
      Reported-by: default avatarDaniel Shapira <daniel@twistlock.com>
      Tested-by: default avatarKees Cook <keescook@chromium.org>
      Fixes: 82ed4db4 ("block: split scsi_request out of struct request")
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      [bwh: Despite what the "Fixes" field says, a buffer overrun was already
       possible if the sense data was really > 64 bytes long.
       Backported to 4.9:
       - We always need to allocate a sense buffer in order to call
         scsi_normalize_sense()
       - Remove the existing conditional heap-allocation of the sense buffer]
      Signed-off-by: default avatarBen Hutchings <ben.hutchings@codethink.co.uk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      cb101349
    • Mathias Nyman's avatar
      xhci: Prevent U1/U2 link pm states if exit latency is too long · d65afda6
      Mathias Nyman authored
      commit 0472bf06c6fd33c1a18aaead4c8f91e5a03d8d7b upstream.
      
      Don't allow USB3 U1 or U2 if the latency to wake up from the U-state
      reaches the service interval for a periodic endpoint.
      
      This is according to xhci 1.1 specification section 4.23.5.2 extra note:
      
      "Software shall ensure that a device is prevented from entering a U-state
       where its worst case exit latency approaches the ESIT."
      
      Allowing too long exit latencies for periodic endpoint confuses xHC
      internal scheduling, and new devices may fail to enumerate with a
      "Not enough bandwidth for new device state" error from the host.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d65afda6
    • Bin Liu's avatar
      dmaengine: cppi41: delete channel from pending list when stop channel · 1f717070
      Bin Liu authored
      commit 59861547ec9a9736e7882f6fb0c096a720ff811a upstream.
      
      The driver defines three states for a cppi channel.
      - idle: .chan_busy == 0 && not in .pending list
      - pending: .chan_busy == 0 && in .pending list
      - busy: .chan_busy == 1 && not in .pending list
      
      There are cases in which the cppi channel could be in the pending state
      when cppi41_dma_issue_pending() is called after cppi41_runtime_suspend()
      is called.
      
      cppi41_stop_chan() has a bug for these cases to set channels to idle state.
      It only checks the .chan_busy flag, but not the .pending list, then later
      when cppi41_runtime_resume() is called the channels in .pending list will
      be transitioned to busy state.
      
      Removing channels from the .pending list solves the problem.
      
      Fixes: 975faaeb ("dma: cppi41: start tear down only if channel is busy")
      Cc: stable@vger.kernel.org # v3.15+
      Signed-off-by: default avatarBin Liu <b-liu@ti.com>
      Reviewed-by: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
      Signed-off-by: default avatarVinod Koul <vkoul@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1f717070
    • Chuck Lever's avatar
      SUNRPC: Fix leak of krb5p encode pages · ce4a99ac
      Chuck Lever authored
      commit 8dae5398ab1ac107b1517e8195ed043d5f422bd0 upstream.
      
      call_encode can be invoked more than once per RPC call. Ensure that
      each call to gss_wrap_req_priv does not overwrite pointers to
      previously allocated memory.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@hammerspace.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ce4a99ac
    • Halil Pasic's avatar
      virtio/s390: fix race in ccw_io_helper() · 95e3e514
      Halil Pasic authored
      commit 78b1a52e05c9db11d293342e8d6d8a230a04b4e7 upstream.
      
      While ccw_io_helper() seems like intended to be exclusive in a sense that
      it is supposed to facilitate I/O for at most one thread at any given
      time, there is actually nothing ensuring that threads won't pile up at
      vcdev->wait_q. If they do, all threads get woken up and see the status
      that belongs to some other request than their own. This can lead to bugs.
      For an example see:
      https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1788432
      
      This race normally does not cause any problems. The operations provided
      by struct virtio_config_ops are usually invoked in a well defined
      sequence, normally don't fail, and are normally used quite infrequent
      too.
      
      Yet, if some of the these operations are directly triggered via sysfs
      attributes, like in the case described by the referenced bug, userspace
      is given an opportunity to force races by increasing the frequency of the
      given operations.
      
      Let us fix the problem by ensuring, that for each device, we finish
      processing the previous request before starting with a new one.
      Signed-off-by: default avatarHalil Pasic <pasic@linux.ibm.com>
      Reported-by: default avatarColin Ian King <colin.king@canonical.com>
      Cc: stable@vger.kernel.org
      Message-Id: <20180925121309.58524-3-pasic@linux.ibm.com>
      Signed-off-by: default avatarCornelia Huck <cohuck@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      95e3e514
    • Halil Pasic's avatar
      virtio/s390: avoid race on vcdev->config · 92054f4d
      Halil Pasic authored
      commit 2448a299ec416a80f699940a86f4a6d9a4f643b1 upstream.
      
      Currently we have a race on vcdev->config in virtio_ccw_get_config() and
      in virtio_ccw_set_config().
      
      This normally does not cause problems, as these are usually infrequent
      operations. However, for some devices writing to/reading from the config
      space can be triggered through sysfs attributes. For these, userspace can
      force the race by increasing the frequency.
      Signed-off-by: default avatarHalil Pasic <pasic@linux.ibm.com>
      Cc: stable@vger.kernel.org
      Message-Id: <20180925121309.58524-2-pasic@linux.ibm.com>
      Signed-off-by: default avatarCornelia Huck <cohuck@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      92054f4d
    • Takashi Iwai's avatar
      ALSA: hda/realtek - Fix speaker output regression on Thinkpad T570 · 5e51318e
      Takashi Iwai authored
      commit 54947cd64c1b8290f64bb2958e343c07270e3a58 upstream.
      
      We've got a regression report for some Thinkpad models (at least
      T570s) which shows the too low speaker output volume.  The bisection
      leaded to the commit 61fcf8ec ("ALSA: hda/realtek - Enable Thinkpad
      Dock device for ALC298 platform"), and it's basically adding the two
      pin configurations for the dock, and looks harmless.
      
      The real culprit seems, though, that the DAC assignment for the
      speaker pin is implicitly assumed on these devices, i.e. pin NID 0x14
      to be coupled with DAC NID 0x03.  When more pins are configured by the
      commit above, the auto-parser changes the DAC assignment, and this
      resulted in the regression.
      
      As a workaround, just provide the fixed pin / DAC mapping table for
      this Thinkpad fixup function.  It's no generic solution, but the
      problem itself is pretty much device-specific, so must be good
      enough.
      
      Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1554304
      Fixes: 61fcf8ec ("ALSA: hda/realtek - Enable Thinkpad Dock device for ALC298 platform")
      Cc: <stable@vger.kernel.org>
      Reported-and-tested-by: default avatarJeremy Cline <jcline@redhat.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5e51318e
    • Takashi Iwai's avatar
      ALSA: pcm: Fix interval evaluation with openmin/max · 1474395b
      Takashi Iwai authored
      commit 5363857b916c1f48027e9b96ee8be8376bf20811 upstream.
      
      As addressed in alsa-lib (commit b420056604f0), we need to fix the
      case where the evaluation of PCM interval "(x x+1]" leading to
      -EINVAL.  After applying rules, such an interval may be translated as
      "(x x+1)".
      
      Fixes: ff2d6acdf6f1 ("ALSA: pcm: Fix snd_interval_refine first/last with open min/max")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1474395b
    • Takashi Iwai's avatar
      ALSA: pcm: Call snd_pcm_unlink() conditionally at closing · ba9890ac
      Takashi Iwai authored
      commit b51abed8355e5556886623b2772fa6b7598d2282 upstream.
      
      Currently the PCM core calls snd_pcm_unlink() always unconditionally
      at closing a stream.  However, since snd_pcm_unlink() invokes the
      global rwsem down, the lock can be easily contended.  More badly, when
      a thread runs in a high priority RT-FIFO, it may stall at spinning.
      
      Basically the call of snd_pcm_unlink() is required only for the linked
      streams that are already rare occasion.  For normal use cases, this
      code path is fairly superfluous.
      
      As an optimization (and also as a workaround for the RT problem
      above in normal situations without linked streams), this patch adds a
      check before calling snd_pcm_unlink() and calls it only when needed.
      Reported-by: default avatarChanho Min <chanho.min@lge.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ba9890ac
    • Chanho Min's avatar
      ALSA: pcm: Fix starvation on down_write_nonblock() · ee8dce2b
      Chanho Min authored
      commit b888a5f713e4d17faaaff24316585a4eb07f35b7 upstream.
      
      Commit 67ec1072 ("ALSA: pcm: Fix rwsem deadlock for non-atomic PCM
      stream") fixes deadlock for non-atomic PCM stream. But, This patch
      causes antother stuck.
      If writer is RT thread and reader is a normal thread, the reader
      thread will be difficult to get scheduled. It may not give chance to
      release readlocks and writer gets stuck for a long time if they are
      pinned to single cpu.
      
      The deadlock described in the previous commit is because the linux
      rwsem queues like a FIFO. So, we might need non-FIFO writelock, not
      non-block one.
      
      My suggestion is that the writer gives reader a chance to be scheduled
      by using the minimum msleep() instaed of spinning without blocking by
      writer. Also, The *_nonblock may be changed to *_nonfifo appropriately
      to this concept.
      In terms of performance, when trylock is failed, this minimum periodic
      msleep will have the same performance as the tick-based
      schedule()/wake_up_q().
      
      [ Although this has a fairly high performance penalty, the relevant
        code path became already rare due to the previous commit ("ALSA:
        pcm: Call snd_pcm_unlink() conditionally at closing").  That is, now
        this unconditional msleep appears only when using linked streams,
        and this must be a rare case.  So we accept this as a quick
        workaround until finding a more suitable one -- tiwai ]
      
      Fixes: 67ec1072 ("ALSA: pcm: Fix rwsem deadlock for non-atomic PCM stream")
      Suggested-by: default avatarWonmin Jung <wonmin.jung@lge.com>
      Signed-off-by: default avatarChanho Min <chanho.min@lge.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ee8dce2b
    • Kai-Heng Feng's avatar
      ALSA: hda: Add support for AMD Stoney Ridge · 46da53f3
      Kai-Heng Feng authored
      commit 3deef52ce10514ccdebba8e8ab85f9cebd0eb3f7 upstream.
      
      It's similar to other AMD audio devices, it also supports D3, which can
      save some power drain.
      Signed-off-by: default avatarKai-Heng Feng <kai.heng.feng@canonical.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      46da53f3
    • Hui Peng's avatar
      ALSA: usb-audio: Fix UAF decrement if card has no live interfaces in card.c · 73000a4c
      Hui Peng authored
      commit 5f8cf712582617d523120df67d392059eaf2fc4b upstream.
      
      If a USB sound card reports 0 interfaces, an error condition is triggered
      and the function usb_audio_probe errors out. In the error path, there was a
      use-after-free vulnerability where the memory object of the card was first
      freed, followed by a decrement of the number of active chips. Moving the
      decrement above the atomic_dec fixes the UAF.
      
      [ The original problem was introduced in 3.1 kernel, while it was
        developed in a different form.  The Fixes tag below indicates the
        original commit but it doesn't mean that the patch is applicable
        cleanly. -- tiwai ]
      
      Fixes: 362e4e49 ("ALSA: usb-audio - clear chip->probing on error exit")
      Reported-by: default avatarHui Peng <benquike@gmail.com>
      Reported-by: default avatarMathias Payer <mathias.payer@nebelwelt.net>
      Signed-off-by: default avatarHui Peng <benquike@gmail.com>
      Signed-off-by: default avatarMathias Payer <mathias.payer@nebelwelt.net>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      73000a4c
    • Mathias Payer's avatar
      USB: check usb_get_extra_descriptor for proper size · fe26b8d0
      Mathias Payer authored
      commit 704620afc70cf47abb9d6a1a57f3825d2bca49cf upstream.
      
      When reading an extra descriptor, we need to properly check the minimum
      and maximum size allowed, to prevent from invalid data being sent by a
      device.
      Reported-by: default avatarHui Peng <benquike@gmail.com>
      Reported-by: default avatarMathias Payer <mathias.payer@nebelwelt.net>
      Co-developed-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarHui Peng <benquike@gmail.com>
      Signed-off-by: default avatarMathias Payer <mathias.payer@nebelwelt.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Cc: stable <stable@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fe26b8d0
    • Alexander Theissen's avatar
      usb: appledisplay: Add 27" Apple Cinema Display · c037e887
      Alexander Theissen authored
      commit d7859905301880ad3e16272399d26900af3ac496 upstream.
      
      Add another Apple Cinema Display to the list of supported displays.
      Signed-off-by: default avatarAlexander Theissen <alex.theissen@me.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c037e887
    • Harry Pan's avatar
      usb: quirk: add no-LPM quirk on SanDisk Ultra Flair device · 2457aa82
      Harry Pan authored
      commit 2f2dde6ba89b1ef1fe23c1138131b315d9aa4019 upstream.
      
      Some lower volume SanDisk Ultra Flair in 16GB, which the VID:PID is
      in 0781:5591, will aggressively request LPM of U1/U2 during runtime,
      when using this thumb drive as the OS installation key we found the
      device will generate failure during U1 exit path making it dropped
      from the USB bus, this causes a corrupted installation in system at
      the end.
      
      i.e.,
      [  166.918296] hub 2-0:1.0: state 7 ports 7 chg 0000 evt 0004
      [  166.918327] usb usb2-port2: link state change
      [  166.918337] usb usb2-port2: do warm reset
      [  166.970039] usb usb2-port2: not warm reset yet, waiting 50ms
      [  167.022040] usb usb2-port2: not warm reset yet, waiting 200ms
      [  167.276043] usb usb2-port2: status 02c0, change 0041, 5.0 Gb/s
      [  167.276050] usb 2-2: USB disconnect, device number 2
      [  167.276058] usb 2-2: unregistering device
      [  167.276060] usb 2-2: unregistering interface 2-2:1.0
      [  167.276170] xhci_hcd 0000:00:15.0: shutdown urb ffffa3c7cc695cc0 ep1in-bulk
      [  167.284055] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
      [  167.284064] sd 0:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 00 33 04 90 00 01 00 00
      ...
      
      Analyzed the USB trace in the link layer we realized it is because
      of the 6-ms timer of tRecoveryConfigurationTimeout which documented
      on the USB 3.2 Revision 1.0, the section 7.5.10.4.2 of "Exit from
      Recovery.Configuration"; device initiates U1 exit -> Recovery.Active
      -> Recovery.Configuration, then the host timer timeout makes the link
      transits to eSS.Inactive -> Rx.Detect follows by a Warm Reset.
      
      Interestingly, the other higher volume of SanDisk Ultra Flair sharing
      the same VID:PID, such as 64GB, would not request LPM during runtime,
      it sticks at U0 always, thus disabling LPM does not affect those thumb
      drives at all.
      
      The same odd occures in SanDisk Ultra Fit 16GB, VID:PID in 0781:5583.
      Signed-off-by: default avatarHarry Pan <harry.pan@intel.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2457aa82
    • Alexey Brodkin's avatar
      ARC: [zebu] Remove CONFIG_INITRAMFS_SOURCE from defconfigs · a6e441a6
      Alexey Brodkin authored
      Zebu boards were added in v4.9 and then renamed to "haps" in v4.10.
      
      Thus backporting
      commit 64234961c145 (ARC: configs: Remove CONFIG_INITRAMFS_SOURCE from defconfigs)
      we missed "zebu" defconfigs in v4.9.
      
      Note this is only applicable to "linux-4.9.y"!
      
      Spotted by KerneCI, see [1].
      
      [1] https://storage.kernelci.org/stable/linux-4.9.y/v4.9.144/arc/zebu_hs_smp_defconfig/build.logSigned-off-by: default avatarAlexey Brodkin <abrodkin@synopsys.com>
      Cc: Kevin Hilman <khilman@baylibre.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a6e441a6
    • Tetsuo Handa's avatar
      mm: don't warn about allocations which stall for too long · fbb78e97
      Tetsuo Handa authored
      commit 400e2249 upstream.
      
      Commit 63f53dea ("mm: warn about allocations which stall for too
      long") was a great step for reducing possibility of silent hang up
      problem caused by memory allocation stalls.  But this commit reverts it,
      for it is possible to trigger OOM lockup and/or soft lockups when many
      threads concurrently called warn_alloc() (in order to warn about memory
      allocation stalls) due to current implementation of printk(), and it is
      difficult to obtain useful information due to limitation of synchronous
      warning approach.
      
      Current printk() implementation flushes all pending logs using the
      context of a thread which called console_unlock().  printk() should be
      able to flush all pending logs eventually unless somebody continues
      appending to printk() buffer.
      
      Since warn_alloc() started appending to printk() buffer while waiting
      for oom_kill_process() to make forward progress when oom_kill_process()
      is processing pending logs, it became possible for warn_alloc() to force
      oom_kill_process() loop inside printk().  As a result, warn_alloc()
      significantly increased possibility of preventing oom_kill_process()
      from making forward progress.
      
      ---------- Pseudo code start ----------
      Before warn_alloc() was introduced:
      
        retry:
          if (mutex_trylock(&oom_lock)) {
            while (atomic_read(&printk_pending_logs) > 0) {
              atomic_dec(&printk_pending_logs);
              print_one_log();
            }
            // Send SIGKILL here.
            mutex_unlock(&oom_lock)
          }
          goto retry;
      
      After warn_alloc() was introduced:
      
        retry:
          if (mutex_trylock(&oom_lock)) {
            while (atomic_read(&printk_pending_logs) > 0) {
              atomic_dec(&printk_pending_logs);
              print_one_log();
            }
            // Send SIGKILL here.
            mutex_unlock(&oom_lock)
          } else if (waited_for_10seconds()) {
            atomic_inc(&printk_pending_logs);
          }
          goto retry;
      ---------- Pseudo code end ----------
      
      Although waited_for_10seconds() becomes true once per 10 seconds,
      unbounded number of threads can call waited_for_10seconds() at the same
      time.  Also, since threads doing waited_for_10seconds() keep doing
      almost busy loop, the thread doing print_one_log() can use little CPU
      resource.  Therefore, this situation can be simplified like
      
      ---------- Pseudo code start ----------
        retry:
          if (mutex_trylock(&oom_lock)) {
            while (atomic_read(&printk_pending_logs) > 0) {
              atomic_dec(&printk_pending_logs);
              print_one_log();
            }
            // Send SIGKILL here.
            mutex_unlock(&oom_lock)
          } else {
            atomic_inc(&printk_pending_logs);
          }
          goto retry;
      ---------- Pseudo code end ----------
      
      when printk() is called faster than print_one_log() can process a log.
      
      One of possible mitigation would be to introduce a new lock in order to
      make sure that no other series of printk() (either oom_kill_process() or
      warn_alloc()) can append to printk() buffer when one series of printk()
      (either oom_kill_process() or warn_alloc()) is already in progress.
      
      Such serialization will also help obtaining kernel messages in readable
      form.
      
      ---------- Pseudo code start ----------
        retry:
          if (mutex_trylock(&oom_lock)) {
            mutex_lock(&oom_printk_lock);
            while (atomic_read(&printk_pending_logs) > 0) {
              atomic_dec(&printk_pending_logs);
              print_one_log();
            }
            // Send SIGKILL here.
            mutex_unlock(&oom_printk_lock);
            mutex_unlock(&oom_lock)
          } else {
            if (mutex_trylock(&oom_printk_lock)) {
              atomic_inc(&printk_pending_logs);
              mutex_unlock(&oom_printk_lock);
            }
          }
          goto retry;
      ---------- Pseudo code end ----------
      
      But this commit does not go that direction, for we don't want to
      introduce a new lock dependency, and we unlikely be able to obtain
      useful information even if we serialized oom_kill_process() and
      warn_alloc().
      
      Synchronous approach is prone to unexpected results (e.g.  too late [1],
      too frequent [2], overlooked [3]).  As far as I know, warn_alloc() never
      helped with providing information other than "something is going wrong".
      I want to consider asynchronous approach which can obtain information
      during stalls with possibly relevant threads (e.g.  the owner of
      oom_lock and kswapd-like threads) and serve as a trigger for actions
      (e.g.  turn on/off tracepoints, ask libvirt daemon to take a memory dump
      of stalling KVM guest for diagnostic purpose).
      
      This commit temporarily loses ability to report e.g.  OOM lockup due to
      unable to invoke the OOM killer due to !__GFP_FS allocation request.
      But asynchronous approach will be able to detect such situation and emit
      warning.  Thus, let's remove warn_alloc().
      
      [1] https://bugzilla.kernel.org/show_bug.cgi?id=192981
      [2] http://lkml.kernel.org/r/CAM_iQpWuPVGc2ky8M-9yukECtS+zKjiDasNymX7rMcBjBFyM_A@mail.gmail.com
      [3] commit db73ee0d ("mm, vmscan: do not loop on too_many_isolated for ever"))
      
      Link: http://lkml.kernel.org/r/1509017339-4802-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jpSigned-off-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Reported-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Reported-by: default avataryuwang.yuwang <yuwang.yuwang@alibaba-inc.com>
      Reported-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Acked-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      
      [Resolved backport conflict due to missing 82251963, a8e99259, 9e80c719 and
       9a67f648 in 4.9 -- all of which modified this hunk being removed.]
      Signed-off-by: default avatarAmit Shah <amit@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      fbb78e97
    • Yangtao Li's avatar
      net: amd: add missing of_node_put() · 52c87255
      Yangtao Li authored
      [ Upstream commit c44c749d3b6fdfca39002e7e48e03fe9f9fe37a3 ]
      
      of_find_node_by_path() acquires a reference to the node
      returned by it and that reference needs to be dropped by its caller.
      This place doesn't do that, so fix it.
      Signed-off-by: default avatarYangtao Li <tiny.windzz@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      52c87255
    • Hangbin Liu's avatar
      team: no need to do team_notify_peers or team_mcast_rejoin when disabling port · 1c0d7303
      Hangbin Liu authored
      [ Upstream commit 5ed9dc99107144f83b6c1bb52a69b58875baf540 ]
      
      team_notify_peers() will send ARP and NA to notify peers. team_mcast_rejoin()
      will send multicast join group message to notify peers. We should do this when
      enabling/changed to a new port. But it doesn't make sense to do it when a port
      is disabled.
      
      On the other hand, when we set mcast_rejoin_count to 2, and do a failover,
      team_port_disable() will increase mcast_rejoin.count_pending to 2 and then
      team_port_enable() will increase mcast_rejoin.count_pending to 4. We will send
      4 mcast rejoin messages at latest, which will make user confused. The same
      with notify_peers.count.
      
      Fix it by deleting team_notify_peers() and team_mcast_rejoin() in
      team_port_disable().
      Reported-by: default avatarLiang Li <liali@redhat.com>
      Fixes: fc423ff0 ("team: add peer notification")
      Fixes: 492b200e ("team: add support for sending multicast rejoins")
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1c0d7303
    • Pan Bian's avatar
      iommu/vt-d: Use memunmap to free memremap · 782d0b84
      Pan Bian authored
      [ Upstream commit 829383e183728dec7ed9150b949cd6de64127809 ]
      
      memunmap() should be used to free the return of memremap(), not
      iounmap().
      
      Fixes: dfddb969 ('iommu/vt-d: Switch from ioremap_cache to memremap')
      Signed-off-by: default avatarPan Bian <bianpan2016@163.com>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      782d0b84
    • Vincent Chen's avatar
      net: faraday: ftmac100: remove netif_running(netdev) check before disabling interrupts · 94d9befe
      Vincent Chen authored
      [ Upstream commit 426a593e641ebf0d9288f0a2fcab644a86820220 ]
      
      In the original ftmac100_interrupt(), the interrupts are only disabled when
      the condition "netif_running(netdev)" is true. However, this condition
      causes kerenl hang in the following case. When the user requests to
      disable the network device, kernel will clear the bit __LINK_STATE_START
      from the dev->state and then call the driver's ndo_stop function. Network
      device interrupts are not blocked during this process. If an interrupt
      occurs between clearing __LINK_STATE_START and stopping network device,
      kernel cannot disable the interrupts due to the condition
      "netif_running(netdev)" in the ISR. Hence, kernel will hang due to the
      continuous interruption of the network device.
      
      In order to solve the above problem, the interrupts of the network device
      should always be disabled in the ISR without being restricted by the
      condition "netif_running(netdev)".
      
      [V2]
      Remove unnecessary curly braces.
      Signed-off-by: default avatarVincent Chen <vincentc@andestech.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      94d9befe
    • Olof Johansson's avatar
      mtd: rawnand: qcom: Namespace prefix some commands · fc70b21f
      Olof Johansson authored
      [ Upstream commit 33bf5519ae5dd356b182a94e3622f42860274a38 ]
      
      PAGE_READ is used by RISC-V arch code included through mm headers,
      and it makes sense to bring in a prefix on these in the driver.
      
      drivers/mtd/nand/raw/qcom_nandc.c:153: warning: "PAGE_READ" redefined
       #define PAGE_READ   0x2
      In file included from include/linux/memremap.h:7,
                       from include/linux/mm.h:27,
                       from include/linux/scatterlist.h:8,
                       from include/linux/dma-mapping.h:11,
                       from drivers/mtd/nand/raw/qcom_nandc.c:17:
      arch/riscv/include/asm/pgtable.h:48: note: this is the location of the previous definition
      
      Caught by riscv allmodconfig.
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      Reviewed-by: default avatarMiquel Raynal <miquel.raynal@bootlin.com>
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@bootlin.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      fc70b21f
    • Aya Levin's avatar
      net/mlx4: Fix UBSAN warning of signed integer overflow · 89860d2c
      Aya Levin authored
      [ Upstream commit a463146e67c848cbab5ce706d6528281b7cded08 ]
      
      UBSAN: Undefined behavior in
      drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:626:29
      signed integer overflow: 1802201963 + 1802201963 cannot be represented
      in type 'int'
      
      The union of res_reserved and res_port_rsvd[MLX4_MAX_PORTS] monitors
      granting of reserved resources. The grant operation is calculated and
      protected, thus both members of the union cannot be negative.  Changed
      type of res_reserved and of res_port_rsvd[MLX4_MAX_PORTS] from signed
      int to unsigned int, allowing large value.
      
      Fixes: 5a0d0a61 ("mlx4: Structures and init/teardown for VF resource quotas")
      Signed-off-by: default avatarAya Levin <ayal@mellanox.com>
      Signed-off-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      89860d2c
    • Tariq Toukan's avatar
      net/mlx4_core: Fix uninitialized variable compilation warning · 6485f65e
      Tariq Toukan authored
      [ Upstream commit 3ea7e7ea53c9f6ee41cb69a29c375fe9dd9a56a7 ]
      
      Initialize the uid variable to zero to avoid the compilation warning.
      
      Fixes: 7a89399f ("net/mlx4: Add mlx4_bitmap zone allocator")
      Signed-off-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      6485f65e
    • Jack Morgenstein's avatar
      net/mlx4_core: Zero out lkey field in SW2HW_MPT fw command · aa4a6a18
      Jack Morgenstein authored
      [ Upstream commit bd85fbc2038a1bbe84990b23ff69b6fc81a32b2c ]
      
      When re-registering a user mr, the mpt information for the
      existing mr when running SRIOV is obtained via the QUERY_MPT
      fw command. The returned information includes the mpt's lkey.
      
      This retrieved mpt information is used to move the mpt back
      to hardware ownership in the rereg flow (via the SW2HW_MPT
      fw command when running SRIOV).
      
      The fw API spec states that for SW2HW_MPT, the lkey field
      must be zero. Any ConnectX-3 PF driver which checks for strict spec
      adherence will return failure for SW2HW_MPT if the lkey field is not
      zero (although the fw in practice ignores this field for SW2HW_MPT).
      
      Thus, in order to conform to the fw API spec, set the lkey field to zero
      before invoking SW2HW_MPT when running SRIOV.
      
      Fixes: e630664c ("mlx4_core: Add helper functions to support MR re-registration")
      Signed-off-by: default avatarJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      aa4a6a18
    • Denis Bolotin's avatar
      qed: Fix reading wrong value in loop condition · a1597daa
      Denis Bolotin authored
      [ Upstream commit ed4eac20dcffdad47709422e0cb925981b056668 ]
      
      The value of "sb_index" is written by the hardware. Reading its value and
      writing it to "index" must finish before checking the loop condition.
      Signed-off-by: default avatarDenis Bolotin <denis.bolotin@cavium.com>
      Signed-off-by: default avatarMichal Kalderon <michal.kalderon@cavium.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a1597daa