1. 16 Sep, 2019 40 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.19.73 · db2d0b7c
      Greg Kroah-Hartman authored
      db2d0b7c
    • yongduan's avatar
      vhost: make sure log_num < in_num · ba03ee62
      yongduan authored
      commit 060423bf upstream.
      
      The code assumes log_num < in_num everywhere, and that is true as long as
      in_num is incremented by descriptor iov count, and log_num by 1. However
      this breaks if there's a zero sized descriptor.
      
      As a result, if a malicious guest creates a vring desc with desc.len = 0,
      it may cause the host kernel to crash by overflowing the log array. This
      bug can be triggered during the VM migration.
      
      There's no need to log when desc.len = 0, so just don't increment log_num
      in this case.
      
      Fixes: 3a4d5c94 ("vhost_net: a kernel-level virtio server")
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarLidong Chen <lidongchen@tencent.com>
      Signed-off-by: default avatarruippan <ruippan@tencent.com>
      Signed-off-by: default avataryongduan <yongduan@tencent.com>
      Acked-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Reviewed-by: default avatarTyler Hicks <tyhicks@canonical.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ba03ee62
    • Gustavo Romero's avatar
      powerpc/tm: Fix restoring FP/VMX facility incorrectly on interrupts · 569775bd
      Gustavo Romero authored
      [ Upstream commit a8318c13 ]
      
      When in userspace and MSR FP=0 the hardware FP state is unrelated to
      the current process. This is extended for transactions where if tbegin
      is run with FP=0, the hardware checkpoint FP state will also be
      unrelated to the current process. Due to this, we need to ensure this
      hardware checkpoint is updated with the correct state before we enable
      FP for this process.
      
      Unfortunately we get this wrong when returning to a process from a
      hardware interrupt. A process that starts a transaction with FP=0 can
      take an interrupt. When the kernel returns back to that process, we
      change to FP=1 but with hardware checkpoint FP state not updated. If
      this transaction is then rolled back, the FP registers now contain the
      wrong state.
      
      The process looks like this:
         Userspace:                      Kernel
      
                     Start userspace
                      with MSR FP=0 TM=1
                        < -----
         ...
         tbegin
         bne
                     Hardware interrupt
                         ---- >
                                          <do_IRQ...>
                                          ....
                                          ret_from_except
                                            restore_math()
      				        /* sees FP=0 */
                                              restore_fp()
                                                tm_active_with_fp()
      					    /* sees FP=1 (Incorrect) */
                                                load_fp_state()
                                              FP = 0 -> 1
                        < -----
                     Return to userspace
                       with MSR TM=1 FP=1
                       with junk in the FP TM checkpoint
         TM rollback
         reads FP junk
      
      When returning from the hardware exception, tm_active_with_fp() is
      incorrectly making restore_fp() call load_fp_state() which is setting
      FP=1.
      
      The fix is to remove tm_active_with_fp().
      
      tm_active_with_fp() is attempting to handle the case where FP state
      has been changed inside a transaction. In this case the checkpointed
      and transactional FP state is different and hence we must restore the
      FP state (ie. we can't do lazy FP restore inside a transaction that's
      used FP). It's safe to remove tm_active_with_fp() as this case is
      handled by restore_tm_state(). restore_tm_state() detects if FP has
      been using inside a transaction and will set load_fp and call
      restore_math() to ensure the FP state (checkpoint and transaction) is
      restored.
      
      This is a data integrity problem for the current process as the FP
      registers are corrupted. It's also a security problem as the FP
      registers from one process may be leaked to another.
      
      Similarly for VMX.
      
      A simple testcase to replicate this will be posted to
      tools/testing/selftests/powerpc/tm/tm-poison.c
      
      This fixes CVE-2019-15031.
      
      Fixes: a7771176 ("powerpc: Don't enable FP/Altivec if not checkpointed")
      Cc: stable@vger.kernel.org # 4.15+
      Signed-off-by: default avatarGustavo Romero <gromero@linux.ibm.com>
      Signed-off-by: default avatarMichael Neuling <mikey@neuling.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20190904045529.23002-2-gromero@linux.vnet.ibm.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      569775bd
    • Breno Leitao's avatar
      powerpc/tm: Remove msr_tm_active() · 052bc385
      Breno Leitao authored
      [ Upstream commit 5c784c84 ]
      
      Currently msr_tm_active() is a wrapper around MSR_TM_ACTIVE() if
      CONFIG_PPC_TRANSACTIONAL_MEM is set, or it is just a function that
      returns false if CONFIG_PPC_TRANSACTIONAL_MEM is not set.
      
      This function is not necessary, since MSR_TM_ACTIVE() just do the same and
      could be used, removing the dualism and simplifying the code.
      
      This patchset remove every instance of msr_tm_active() and replaced it
      by MSR_TM_ACTIVE().
      Signed-off-by: default avatarBreno Leitao <leitao@debian.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      052bc385
    • Lyude Paul's avatar
      PCI: Reset both NVIDIA GPU and HDA in ThinkPad P50 workaround · f193e022
      Lyude Paul authored
      [ Upstream commit ad54567a ]
      
      quirk_reset_lenovo_thinkpad_50_nvgpu() resets NVIDIA GPUs to work around
      an apparent BIOS defect.  It previously used pci_reset_function(), and
      the available method was a bus reset, which was fine because there was
      only one function on the bus.  After b516ea58 ("PCI: Enable NVIDIA
      HDA controllers"), there are now two functions (the HDA controller and
      the GPU itself) on the bus, so the reset fails.
      
      Use pci_reset_bus() explicitly instead of pci_reset_function() since it's
      OK to reset both devices.
      
      [bhelgaas: commit log, add e0547c81]
      Fixes: b516ea58 ("PCI: Enable NVIDIA HDA controllers")
      Fixes: e0547c81 ("PCI: Reset Lenovo ThinkPad P50 nvgpu at boot if necessary")
      Link: https://lore.kernel.org/r/20190801220117.14952-1-lyude@redhat.comSigned-off-by: default avatarLyude Paul <lyude@redhat.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Cc: Lukas Wunner <lukas@wunner.de>
      Cc: Daniel Drake <drake@endlessm.com>
      Cc: Aaron Plattner <aplattner@nvidia.com>
      Cc: Peter Wu <peter@lekensteyn.nl>
      Cc: Ilia Mirkin <imirkin@alum.mit.edu>
      Cc: Karol Herbst <kherbst@redhat.com>
      Cc: Maik Freudenberg <hhfeuer@gmx.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f193e022
    • Colin Ian King's avatar
      ext4: unsigned int compared against zero · ff693225
      Colin Ian King authored
      [ Upstream commit fbbbbd2f ]
      
      There are two cases where u32 variables n and err are being checked
      for less than zero error values, the checks is always false because
      the variables are not signed. Fix this by making the variables ints.
      
      Addresses-Coverity: ("Unsigned compared against 0")
      Fixes: 345c0dbf ("ext4: protect journal inode's blocks using block_validity")
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ff693225
    • Theodore Ts'o's avatar
      ext4: fix block validity checks for journal inodes using indirect blocks · 292666d2
      Theodore Ts'o authored
      [ Upstream commit 170417c8 ]
      
      Commit 345c0dbf ("ext4: protect journal inode's blocks using
      block_validity") failed to add an exception for the journal inode in
      ext4_check_blockref(), which is the function used by ext4_get_branch()
      for indirect blocks.  This caused attempts to read from the ext3-style
      journals to fail with:
      
      [  848.968550] EXT4-fs error (device sdb7): ext4_get_branch:171: inode #8: block 30343695: comm jbd2/sdb7-8: invalid block
      
      Fix this by adding the missing exception check.
      
      Fixes: 345c0dbf ("ext4: protect journal inode's blocks using block_validity")
      Reported-by: default avatarArthur Marsh <arthur.marsh@internode.on.net>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      292666d2
    • Theodore Ts'o's avatar
      ext4: don't perform block validity checks on the journal inode · 97fbf573
      Theodore Ts'o authored
      [ Upstream commit 0a944e8a ]
      
      Since the journal inode is already checked when we added it to the
      block validity's system zone, if we check it again, we'll just trigger
      a failure.
      
      This was causing failures like this:
      
      [   53.897001] EXT4-fs error (device sda): ext4_find_extent:909: inode
      #8: comm jbd2/sda-8: pblk 121667583 bad header/extent: invalid extent entries - magic f30a, entries 8, max 340(340), depth 0(0)
      [   53.931430] jbd2_journal_bmap: journal block not found at offset 49 on sda-8
      [   53.938480] Aborting journal on device sda-8.
      
      ... but only if the system was under enough memory pressure that
      logical->physical mapping for the journal inode gets pushed out of the
      extent cache.  (This is why it wasn't noticed earlier.)
      
      Fixes: 345c0dbf ("ext4: protect journal inode's blocks using block_validity")
      Reported-by: default avatarDan Rue <dan.rue@linaro.org>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Tested-by: default avatarNaresh Kamboju <naresh.kamboju@linaro.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      97fbf573
    • Lyude Paul's avatar
      drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors · 1e88a1f8
      Lyude Paul authored
      [ Upstream commit 34ca26a9 ]
      
      It appears when testing my previous fix for some of the legacy
      modesetting issues with MST, I misattributed some kernel splats that
      started appearing on my machine after a rebase as being from upstream.
      But it appears they actually came from my patch series:
      
      [    2.980512] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Updating routing for [CONNECTOR:65:eDP-1]
      [    2.980516] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] [CONNECTOR:65:eDP-1] is not registered
      [    2.980516] ------------[ cut here ]------------
      [    2.980519] Could not determine valid watermarks for inherited state
      [    2.980553] WARNING: CPU: 3 PID: 551 at drivers/gpu/drm/i915/intel_display.c:14983 intel_modeset_init+0x14d7/0x19f0 [i915]
      [    2.980556] Modules linked in: i915(O+) i2c_algo_bit drm_kms_helper(O) syscopyarea sysfillrect sysimgblt fb_sys_fops drm(O) intel_rapl x86_pkg_temp_thermal iTCO_wdt wmi_bmof coretemp crc32_pclmul psmouse i2c_i801 mei_me mei i2c_core lpc_ich mfd_core tpm_tis tpm_tis_core wmi tpm thinkpad_acpi pcc_cpufreq video ehci_pci crc32c_intel serio_raw ehci_hcd xhci_pci xhci_hcd
      [    2.980577] CPU: 3 PID: 551 Comm: systemd-udevd Tainted: G           O      4.19.0-rc7Lyude-Test+ #1
      [    2.980579] Hardware name: LENOVO 20BWS1KY00/20BWS1KY00, BIOS JBET63WW (1.27 ) 11/10/2016
      [    2.980605] RIP: 0010:intel_modeset_init+0x14d7/0x19f0 [i915]
      [    2.980607] Code: 89 df e8 ec 27 02 00 e9 24 f2 ff ff be 03 00 00 00 48 89 df e8 da 27 02 00 e9 26 f2 ff ff 48 c7 c7 c8 d1 34 a0 e8 23 cf dc e0 <0f> 0b e9 7c fd ff ff f6 c4 04 0f 85 37 f7 ff ff 48 8b 83 60 08 00
      [    2.980611] RSP: 0018:ffffc90000287988 EFLAGS: 00010282
      [    2.980614] RAX: 0000000000000000 RBX: ffff88031b488000 RCX: 0000000000000006
      [    2.980617] RDX: 0000000000000007 RSI: 0000000000000086 RDI: ffff880321ad54d0
      [    2.980620] RBP: ffffc90000287a10 R08: 000000000000040a R09: 0000000000000065
      [    2.980623] R10: ffff88030ebb8f00 R11: ffffffff81416590 R12: ffff88031b488000
      [    2.980626] R13: ffff88031b4883a0 R14: ffffc900002879a8 R15: ffff880319099800
      [    2.980630] FS:  00007f475620d180(0000) GS:ffff880321ac0000(0000) knlGS:0000000000000000
      [    2.980633] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [    2.980636] CR2: 00007f9ef28018a0 CR3: 000000031b72c001 CR4: 00000000003606e0
      [    2.980639] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [    2.980642] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [    2.980645] Call Trace:
      [    2.980675]  i915_driver_load+0xb0e/0xdc0 [i915]
      [    2.980681]  ? kernfs_add_one+0xe7/0x130
      [    2.980709]  i915_pci_probe+0x46/0x60 [i915]
      [    2.980715]  pci_device_probe+0xd4/0x150
      [    2.980719]  really_probe+0x243/0x3b0
      [    2.980722]  driver_probe_device+0xba/0x100
      [    2.980726]  __driver_attach+0xe4/0x110
      [    2.980729]  ? driver_probe_device+0x100/0x100
      [    2.980733]  bus_for_each_dev+0x74/0xb0
      [    2.980736]  driver_attach+0x1e/0x20
      [    2.980739]  bus_add_driver+0x159/0x230
      [    2.980743]  ? 0xffffffffa0393000
      [    2.980746]  driver_register+0x70/0xc0
      [    2.980749]  ? 0xffffffffa0393000
      [    2.980753]  __pci_register_driver+0x57/0x60
      [    2.980780]  i915_init+0x55/0x58 [i915]
      [    2.980785]  do_one_initcall+0x4a/0x1c4
      [    2.980789]  ? do_init_module+0x27/0x210
      [    2.980793]  ? kmem_cache_alloc_trace+0x131/0x190
      [    2.980797]  do_init_module+0x60/0x210
      [    2.980800]  load_module+0x2063/0x22e0
      [    2.980804]  ? vfs_read+0x116/0x140
      [    2.980807]  ? vfs_read+0x116/0x140
      [    2.980811]  __do_sys_finit_module+0xbd/0x120
      [    2.980814]  ? __do_sys_finit_module+0xbd/0x120
      [    2.980818]  __x64_sys_finit_module+0x1a/0x20
      [    2.980821]  do_syscall_64+0x5a/0x110
      [    2.980824]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      [    2.980826] RIP: 0033:0x7f4754e32879
      [    2.980828] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d f7 45 2c 00 f7 d8 64 89 01 48
      [    2.980831] RSP: 002b:00007fff43fd97d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
      [    2.980834] RAX: ffffffffffffffda RBX: 0000559a44ca64f0 RCX: 00007f4754e32879
      [    2.980836] RDX: 0000000000000000 RSI: 00007f475599f4cd RDI: 0000000000000018
      [    2.980838] RBP: 00007f475599f4cd R08: 0000000000000000 R09: 0000000000000000
      [    2.980839] R10: 0000000000000018 R11: 0000000000000246 R12: 0000000000000000
      [    2.980841] R13: 0000559a44c92fd0 R14: 0000000000020000 R15: 0000000000000000
      [    2.980881] WARNING: CPU: 3 PID: 551 at drivers/gpu/drm/i915/intel_display.c:14983 intel_modeset_init+0x14d7/0x19f0 [i915]
      [    2.980884] ---[ end trace 5eb47a76277d4731 ]---
      
      The cause of this appears to be due to the fact that if there's
      pre-existing display state that was set by the BIOS when i915 loads, it
      will attempt to perform a modeset before the driver is registered with
      userspace. Since this happens before the driver's registered with
      userspace, it's connectors are also unregistered and thus-states which
      would turn on DPMS on a connector end up getting rejected since the
      connector isn't registered.
      
      These bugs managed to get past Intel's CI partially due to the fact it
      never ran a full test on my patches for some reason, but also because
      all of the tests unload the GPU once before running. Since this bug is
      only really triggered when the drivers tries to perform a modeset before
      it's been fully registered with userspace when coming from whatever
      display configuration the firmware left us with, it likely would never
      have been picked up by CI in the first place.
      
      After some discussion with vsyrjala, we decided the best course of
      action would be to just move the unregistered connector checks out of
      update_connector_routing() and into drm_atomic_set_crtc_for_connector().
      The reason for this being that legacy modesetting isn't going to be
      expecting failures anywhere (at least this is the case with X), so
      ideally we want to ensure that any DPMS changes will still work even on
      unregistered connectors. Instead, we now only reject new modesets which
      would change the current CRTC assigned to an unregistered connector
      unless no new CRTC is being assigned to replace the connector's previous
      one.
      Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Reported-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Fixes: 4d802739 ("drm/atomic_helper: Disallow new modesets on unregistered connectors")
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181009204424.21462-1-lyude@redhat.com
      (cherry picked from commit b5d29843)
      Fixes: e9655095 ("drm/atomic_helper: Disallow new modesets on unregistered connectors")
      Signed-off-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1e88a1f8
    • Halil Pasic's avatar
      virtio/s390: fix race on airq_areas[] · b1dd1d06
      Halil Pasic authored
      [ Upstream commit 4f419eb1 ]
      
      The access to airq_areas was racy ever since the adapter interrupts got
      introduced to virtio-ccw, but since commit 39c7dcb1 ("virtio/s390:
      make airq summary indicators DMA") this became an issue in practice as
      well. Namely before that commit the airq_info that got overwritten was
      still functional. After that commit however the two infos share a
      summary_indicator, which aggravates the situation. Which means
      auto-online mechanism occasionally hangs the boot with virtio_blk.
      Signed-off-by: default avatarHalil Pasic <pasic@linux.ibm.com>
      Reported-by: default avatarMarc Hartmayer <mhartmay@linux.ibm.com>
      Reviewed-by: default avatarCornelia Huck <cohuck@redhat.com>
      Cc: stable@vger.kernel.org
      Fixes: 96b14536 ("virtio-ccw: virtio-ccw adapter interrupt support.")
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b1dd1d06
    • Ville Syrjälä's avatar
      drm/i915: Make sure cdclk is high enough for DP audio on VLV/CHV · 057cdb6f
      Ville Syrjälä authored
      [ Upstream commit a8f196a0 ]
      
      On VLV/CHV there is some kind of linkage between the cdclk frequency
      and the DP link frequency. The spec says:
      "For DP audio configuration, cdclk frequency shall be set to
       meet the following requirements:
       DP Link Frequency(MHz) | Cdclk frequency(MHz)
       270                    | 320 or higher
       162                    | 200 or higher"
      
      I suspect that would more accurately be expressed as
      "cdclk >= DP link clock", and in any case we can express it like
      that in the code because of the limited set of cdclk (200, 266,
      320, 400 MHz) and link frequencies (162 and 270 MHz) we support.
      
      Without this we can end up in a situation where the cdclk
      is too low and enabling DP audio will kill the pipe. Happens
      eg. with 2560x1440 modes where the 266MHz cdclk is sufficient
      to pump the pixels (241.5 MHz dotclock) but is too low for
      the DP audio due to the link frequency being 270 MHz.
      
      v2: Spell out the cdclk and link frequencies we actually support
      
      Cc: stable@vger.kernel.org
      Tested-by: default avatarStefan Gottwald <gottwald@igel.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111149Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190717114536.22937-1-ville.syrjala@linux.intel.comAcked-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      (cherry picked from commit bffb31f7)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      057cdb6f
    • Coly Li's avatar
      bcache: fix race in btree_flush_write() · b113f984
      Coly Li authored
      [ Upstream commit 50a260e8 ]
      
      There is a race between mca_reap(), btree_node_free() and journal code
      btree_flush_write(), which results very rare and strange deadlock or
      panic and are very hard to reproduce.
      
      Let me explain how the race happens. In btree_flush_write() one btree
      node with oldest journal pin is selected, then it is flushed to cache
      device, the select-and-flush is a two steps operation. Between these two
      steps, there are something may happen inside the race window,
      - The selected btree node was reaped by mca_reap() and allocated to
        other requesters for other btree node.
      - The slected btree node was selected, flushed and released by mca
        shrink callback bch_mca_scan().
      When btree_flush_write() tries to flush the selected btree node, firstly
      b->write_lock is held by mutex_lock(). If the race happens and the
      memory of selected btree node is allocated to other btree node, if that
      btree node's write_lock is held already, a deadlock very probably
      happens here. A worse case is the memory of the selected btree node is
      released, then all references to this btree node (e.g. b->write_lock)
      will trigger NULL pointer deference panic.
      
      This race was introduced in commit cafe5635 ("bcache: A block layer
      cache"), and enlarged by commit c4dc2497 ("bcache: fix high CPU
      occupancy during journal"), which selected 128 btree nodes and flushed
      them one-by-one in a quite long time period.
      
      Such race is not easy to reproduce before. On a Lenovo SR650 server with
      48 Xeon cores, and configure 1 NVMe SSD as cache device, a MD raid0
      device assembled by 3 NVMe SSDs as backing device, this race can be
      observed around every 10,000 times btree_flush_write() gets called. Both
      deadlock and kernel panic all happened as aftermath of the race.
      
      The idea of the fix is to add a btree flag BTREE_NODE_journal_flush. It
      is set when selecting btree nodes, and cleared after btree nodes
      flushed. Then when mca_reap() selects a btree node with this bit set,
      this btree node will be skipped. Since mca_reap() only reaps btree node
      without BTREE_NODE_journal_flush flag, such race is avoided.
      
      Once corner case should be noticed, that is btree_node_free(). It might
      be called in some error handling code path. For example the following
      code piece from btree_split(),
              2149 err_free2:
              2150         bkey_put(b->c, &n2->key);
              2151         btree_node_free(n2);
              2152         rw_unlock(true, n2);
              2153 err_free1:
              2154         bkey_put(b->c, &n1->key);
              2155         btree_node_free(n1);
              2156         rw_unlock(true, n1);
      At line 2151 and 2155, the btree node n2 and n1 are released without
      mac_reap(), so BTREE_NODE_journal_flush also needs to be checked here.
      If btree_node_free() is called directly in such error handling path,
      and the selected btree node has BTREE_NODE_journal_flush bit set, just
      delay for 1 us and retry again. In this case this btree node won't
      be skipped, just retry until the BTREE_NODE_journal_flush bit cleared,
      and free the btree node memory.
      
      Fixes: cafe5635 ("bcache: A block layer cache")
      Signed-off-by: default avatarColy Li <colyli@suse.de>
      Reported-and-tested-by: default avatarkbuild test robot <lkp@intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b113f984
    • Coly Li's avatar
      bcache: add comments for mutex_lock(&b->write_lock) · f73c35d9
      Coly Li authored
      [ Upstream commit 41508bb7 ]
      
      When accessing or modifying BTREE_NODE_dirty bit, it is not always
      necessary to acquire b->write_lock. In bch_btree_cache_free() and
      mca_reap() acquiring b->write_lock is necessary, and this patch adds
      comments to explain why mutex_lock(&b->write_lock) is necessary for
      checking or clearing BTREE_NODE_dirty bit there.
      Signed-off-by: default avatarColy Li <colyli@suse.de>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f73c35d9
    • Coly Li's avatar
      bcache: only clear BTREE_NODE_dirty bit when it is set · 7989a502
      Coly Li authored
      [ Upstream commit e5ec5f47 ]
      
      In bch_btree_cache_free() and btree_node_free(), BTREE_NODE_dirty is
      always set no matter btree node is dirty or not. The code looks like
      this,
      	if (btree_node_dirty(b))
      		btree_complete_write(b, btree_current_write(b));
      	clear_bit(BTREE_NODE_dirty, &b->flags);
      
      Indeed if btree_node_dirty(b) returns false, it means BTREE_NODE_dirty
      bit is cleared, then it is unnecessary to clear the bit again.
      
      This patch only clears BTREE_NODE_dirty when btree_node_dirty(b) is
      true (the bit is set), to save a few CPU cycles.
      Signed-off-by: default avatarColy Li <colyli@suse.de>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7989a502
    • Trond Myklebust's avatar
      NFSv4: Fix delegation state recovery · 652993a5
      Trond Myklebust authored
      [ Upstream commit 5eb8d18c ]
      
      Once we clear the NFS_DELEGATED_STATE flag, we're telling
      nfs_delegation_claim_opens() that we're done recovering all open state
      for that stateid, so we really need to ensure that we test for all
      open modes that are currently cached and recover them before exiting
      nfs4_open_delegation_recall().
      
      Fixes: 24311f88 ("NFSv4: Recovery of recalled read delegations...")
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@hammerspace.com>
      Cc: stable@vger.kernel.org # v4.3+
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      652993a5
    • Arnd Bergmann's avatar
      iio: adc: gyroadc: fix uninitialized return code · 5026932a
      Arnd Bergmann authored
      [ Upstream commit 90c6260c ]
      
      gcc-9 complains about a blatant uninitialized variable use that
      all earlier compiler versions missed:
      
      drivers/iio/adc/rcar-gyroadc.c:510:5: warning: 'ret' may be used uninitialized in this function [-Wmaybe-uninitialized]
      
      Return -EINVAL instead here and a few lines above it where
      we accidentally return 0 on failure.
      
      Cc: stable@vger.kernel.org
      Fixes: 059c53b3 ("iio: adc: Add Renesas GyroADC driver")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarWolfram Sang <wsa+renesas@sang-engineering.com>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5026932a
    • Ralph Campbell's avatar
      mm/migrate.c: initialize pud_entry in migrate_vma() · 2e7e7c8f
      Ralph Campbell authored
      [ Upstream commit 7b358c6f ]
      
      When CONFIG_MIGRATE_VMA_HELPER is enabled, migrate_vma() calls
      migrate_vma_collect() which initializes a struct mm_walk but didn't
      initialize mm_walk.pud_entry.  (Found by code inspection) Use a C
      structure initialization to make sure it is set to NULL.
      
      Link: http://lkml.kernel.org/r/20190719233225.12243-1-rcampbell@nvidia.com
      Fixes: 8763cb45 ("mm/migrate: new memory migration helper for use with device memory")
      Signed-off-by: default avatarRalph Campbell <rcampbell@nvidia.com>
      Reviewed-by: default avatarJohn Hubbard <jhubbard@nvidia.com>
      Reviewed-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Cc: "Jérôme Glisse" <jglisse@redhat.com>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      2e7e7c8f
    • Michał Mirosław's avatar
      i2c: at91: fix clk_offset for sama5d2 · b8ad18a1
      Michał Mirosław authored
      [ Upstream commit b1ac6704 ]
      
      In SAMA5D2 datasheet, TWIHS_CWGR register rescription mentions clock
      offset of 3 cycles (compared to 4 in eg. SAMA5D3).
      
      Cc: stable@vger.kernel.org # 5.2.x
      [needs applying to i2c-at91.c instead for earlier kernels]
      Fixes: 0ef6f321 ("i2c: at91: add support for new alternative command mode")
      Signed-off-by: default avatarMichał Mirosław <mirq-linux@rere.qmqm.pl>
      Acked-by: default avatarLudovic Desroches <ludovic.desroches@microchip.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b8ad18a1
    • Michał Mirosław's avatar
      i2c: at91: disable TXRDY interrupt after sending data · 4c9170b5
      Michał Mirosław authored
      [ Upstream commit d12e3aae ]
      
      Driver was not disabling TXRDY interrupt after last TX byte.
      This caused interrupt storm until transfer timeouts for slow
      or broken device on the bus. The patch fixes the interrupt storm
      on my SAMA5D2-based board.
      
      Cc: stable@vger.kernel.org # 5.2.x
      [v5.2 introduced file split; the patch should apply to i2c-at91.c before the split]
      Fixes: fac368a0 ("i2c: at91: add new driver")
      Signed-off-by: default avatarMichał Mirosław <mirq-linux@rere.qmqm.pl>
      Acked-by: default avatarLudovic Desroches <ludovic.desroches@microchip.com>
      Tested-by: default avatarRaag Jadav <raagjadav@gmail.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      4c9170b5
    • Bartosz Golaszewski's avatar
      gpio: don't WARN() on NULL descs if gpiolib is disabled · c9c90711
      Bartosz Golaszewski authored
      [ Upstream commit ffe0bbab ]
      
      If gpiolib is disabled, we use the inline stubs from gpio/consumer.h
      instead of regular definitions of GPIO API. The stubs for 'optional'
      variants of gpiod_get routines return NULL in this case as if the
      relevant GPIO wasn't found. This is correct so far.
      
      Calling other (non-gpio_get) stubs from this header triggers a warning
      because the GPIO descriptor couldn't have been requested. The warning
      however is unconditional (WARN_ON(1)) and is emitted even if the passed
      descriptor pointer is NULL.
      
      We don't want to force the users of 'optional' gpio_get to check the
      returned pointer before calling e.g. gpiod_set_value() so let's only
      WARN on non-NULL descriptors.
      
      Cc: stable@vger.kernel.org
      Reported-by: default avatarClaus H. Stovgaard <cst@phaseone.com>
      Signed-off-by: default avatarBartosz Golaszewski <bgolaszewski@baylibre.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c9c90711
    • Chris Wilson's avatar
      iommu/iova: Remove stale cached32_node · a532a120
      Chris Wilson authored
      [ Upstream commit 9eed17d3 ]
      
      Since the cached32_node is allowed to be advanced above dma_32bit_pfn
      (to provide a shortcut into the limited range), we need to be careful to
      remove the to be freed node if it is the cached32_node.
      
      [   48.477773] BUG: KASAN: use-after-free in __cached_rbnode_delete_update+0x68/0x110
      [   48.477812] Read of size 8 at addr ffff88870fc19020 by task kworker/u8:1/37
      [   48.477843]
      [   48.477879] CPU: 1 PID: 37 Comm: kworker/u8:1 Tainted: G     U            5.2.0+ #735
      [   48.477915] Hardware name: Intel Corporation NUC7i5BNK/NUC7i5BNB, BIOS BNKBL357.86A.0052.2017.0918.1346 09/18/2017
      [   48.478047] Workqueue: i915 __i915_gem_free_work [i915]
      [   48.478075] Call Trace:
      [   48.478111]  dump_stack+0x5b/0x90
      [   48.478137]  print_address_description+0x67/0x237
      [   48.478178]  ? __cached_rbnode_delete_update+0x68/0x110
      [   48.478212]  __kasan_report.cold.3+0x1c/0x38
      [   48.478240]  ? __cached_rbnode_delete_update+0x68/0x110
      [   48.478280]  ? __cached_rbnode_delete_update+0x68/0x110
      [   48.478308]  __cached_rbnode_delete_update+0x68/0x110
      [   48.478344]  private_free_iova+0x2b/0x60
      [   48.478378]  iova_magazine_free_pfns+0x46/0xa0
      [   48.478403]  free_iova_fast+0x277/0x340
      [   48.478443]  fq_ring_free+0x15a/0x1a0
      [   48.478473]  queue_iova+0x19c/0x1f0
      [   48.478597]  cleanup_page_dma.isra.64+0x62/0xb0 [i915]
      [   48.478712]  __gen8_ppgtt_cleanup+0x63/0x80 [i915]
      [   48.478826]  __gen8_ppgtt_cleanup+0x42/0x80 [i915]
      [   48.478940]  __gen8_ppgtt_clear+0x433/0x4b0 [i915]
      [   48.479053]  __gen8_ppgtt_clear+0x462/0x4b0 [i915]
      [   48.479081]  ? __sg_free_table+0x9e/0xf0
      [   48.479116]  ? kfree+0x7f/0x150
      [   48.479234]  i915_vma_unbind+0x1e2/0x240 [i915]
      [   48.479352]  i915_vma_destroy+0x3a/0x280 [i915]
      [   48.479465]  __i915_gem_free_objects+0xf0/0x2d0 [i915]
      [   48.479579]  __i915_gem_free_work+0x41/0xa0 [i915]
      [   48.479607]  process_one_work+0x495/0x710
      [   48.479642]  worker_thread+0x4c7/0x6f0
      [   48.479687]  ? process_one_work+0x710/0x710
      [   48.479724]  kthread+0x1b2/0x1d0
      [   48.479774]  ? kthread_create_worker_on_cpu+0xa0/0xa0
      [   48.479820]  ret_from_fork+0x1f/0x30
      [   48.479864]
      [   48.479907] Allocated by task 631:
      [   48.479944]  save_stack+0x19/0x80
      [   48.479994]  __kasan_kmalloc.constprop.6+0xc1/0xd0
      [   48.480038]  kmem_cache_alloc+0x91/0xf0
      [   48.480082]  alloc_iova+0x2b/0x1e0
      [   48.480125]  alloc_iova_fast+0x58/0x376
      [   48.480166]  intel_alloc_iova+0x90/0xc0
      [   48.480214]  intel_map_sg+0xde/0x1f0
      [   48.480343]  i915_gem_gtt_prepare_pages+0xb8/0x170 [i915]
      [   48.480465]  huge_get_pages+0x232/0x2b0 [i915]
      [   48.480590]  ____i915_gem_object_get_pages+0x40/0xb0 [i915]
      [   48.480712]  __i915_gem_object_get_pages+0x90/0xa0 [i915]
      [   48.480834]  i915_gem_object_prepare_write+0x2d6/0x330 [i915]
      [   48.480955]  create_test_object.isra.54+0x1a9/0x3e0 [i915]
      [   48.481075]  igt_shared_ctx_exec+0x365/0x3c0 [i915]
      [   48.481210]  __i915_subtests.cold.4+0x30/0x92 [i915]
      [   48.481341]  __run_selftests.cold.3+0xa9/0x119 [i915]
      [   48.481466]  i915_live_selftests+0x3c/0x70 [i915]
      [   48.481583]  i915_pci_probe+0xe7/0x220 [i915]
      [   48.481620]  pci_device_probe+0xe0/0x180
      [   48.481665]  really_probe+0x163/0x4e0
      [   48.481710]  device_driver_attach+0x85/0x90
      [   48.481750]  __driver_attach+0xa5/0x180
      [   48.481796]  bus_for_each_dev+0xda/0x130
      [   48.481831]  bus_add_driver+0x205/0x2e0
      [   48.481882]  driver_register+0xca/0x140
      [   48.481927]  do_one_initcall+0x6c/0x1af
      [   48.481970]  do_init_module+0x106/0x350
      [   48.482010]  load_module+0x3d2c/0x3ea0
      [   48.482058]  __do_sys_finit_module+0x110/0x180
      [   48.482102]  do_syscall_64+0x62/0x1f0
      [   48.482147]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      [   48.482190]
      [   48.482224] Freed by task 37:
      [   48.482273]  save_stack+0x19/0x80
      [   48.482318]  __kasan_slab_free+0x12e/0x180
      [   48.482363]  kmem_cache_free+0x70/0x140
      [   48.482406]  __free_iova+0x1d/0x30
      [   48.482445]  fq_ring_free+0x15a/0x1a0
      [   48.482490]  queue_iova+0x19c/0x1f0
      [   48.482624]  cleanup_page_dma.isra.64+0x62/0xb0 [i915]
      [   48.482749]  __gen8_ppgtt_cleanup+0x63/0x80 [i915]
      [   48.482873]  __gen8_ppgtt_cleanup+0x42/0x80 [i915]
      [   48.482999]  __gen8_ppgtt_clear+0x433/0x4b0 [i915]
      [   48.483123]  __gen8_ppgtt_clear+0x462/0x4b0 [i915]
      [   48.483250]  i915_vma_unbind+0x1e2/0x240 [i915]
      [   48.483378]  i915_vma_destroy+0x3a/0x280 [i915]
      [   48.483500]  __i915_gem_free_objects+0xf0/0x2d0 [i915]
      [   48.483622]  __i915_gem_free_work+0x41/0xa0 [i915]
      [   48.483659]  process_one_work+0x495/0x710
      [   48.483704]  worker_thread+0x4c7/0x6f0
      [   48.483748]  kthread+0x1b2/0x1d0
      [   48.483787]  ret_from_fork+0x1f/0x30
      [   48.483831]
      [   48.483868] The buggy address belongs to the object at ffff88870fc19000
      [   48.483868]  which belongs to the cache iommu_iova of size 40
      [   48.483920] The buggy address is located 32 bytes inside of
      [   48.483920]  40-byte region [ffff88870fc19000, ffff88870fc19028)
      [   48.483964] The buggy address belongs to the page:
      [   48.484006] page:ffffea001c3f0600 refcount:1 mapcount:0 mapping:ffff8888181a91c0 index:0x0 compound_mapcount: 0
      [   48.484045] flags: 0x8000000000010200(slab|head)
      [   48.484096] raw: 8000000000010200 ffffea001c421a08 ffffea001c447e88 ffff8888181a91c0
      [   48.484141] raw: 0000000000000000 0000000000120012 00000001ffffffff 0000000000000000
      [   48.484188] page dumped because: kasan: bad access detected
      [   48.484230]
      [   48.484265] Memory state around the buggy address:
      [   48.484314]  ffff88870fc18f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [   48.484361]  ffff88870fc18f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [   48.484406] >ffff88870fc19000: fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc
      [   48.484451]                                ^
      [   48.484494]  ffff88870fc19080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [   48.484530]  ffff88870fc19100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108602
      Fixes: e60aa7b5 ("iommu/iova: Extend rbtree node caching")
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Robin Murphy <robin.murphy@arm.com>
      Cc: Joerg Roedel <jroedel@suse.de>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: <stable@vger.kernel.org> # v4.15+
      Reviewed-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a532a120
    • Suraj Jitindar Singh's avatar
      powerpc/mm: Limit rma_size to 1TB when running without HV mode · c4fc7cb9
      Suraj Jitindar Singh authored
      [ Upstream commit da0ef933 ]
      
      The virtual real mode addressing (VRMA) mechanism is used when a
      partition is using HPT (Hash Page Table) translation and performs real
      mode accesses (MSR[IR|DR] = 0) in non-hypervisor mode. In this mode
      effective address bits 0:23 are treated as zero (i.e. the access is
      aliased to 0) and the access is performed using an implicit 1TB SLB
      entry.
      
      The size of the RMA (Real Memory Area) is communicated to the guest as
      the size of the first memory region in the device tree. And because of
      the mechanism described above can be expected to not exceed 1TB. In
      the event that the host erroneously represents the RMA as being larger
      than 1TB, guest accesses in real mode to memory addresses above 1TB
      will be aliased down to below 1TB. This means that a memory access
      performed in real mode may differ to one performed in virtual mode for
      the same memory address, which would likely have unintended
      consequences.
      
      To avoid this outcome have the guest explicitly limit the size of the
      RMA to the current maximum, which is 1TB. This means that even if the
      first memory block is larger than 1TB, only the first 1TB should be
      accessed in real mode.
      
      Fixes: c610d65c ("powerpc/pseries: lift RTAS limit for hash")
      Cc: stable@vger.kernel.org # v4.16+
      Signed-off-by: default avatarSuraj Jitindar Singh <sjitindarsingh@gmail.com>
      Tested-by: default avatarSatheesh Rajendran <sathnaga@linux.vnet.ibm.com>
      Reviewed-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20190710052018.14628-1-sjitindarsingh@gmail.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      c4fc7cb9
    • Takashi Iwai's avatar
      ALSA: hda - Fix intermittent CORB/RIRB stall on Intel chips · 5b9a6ba9
      Takashi Iwai authored
      [ Upstream commit 2756d914 ]
      
      It turned out that the recent Intel HD-audio controller chips show a
      significant stall during the system PM resume intermittently.  It
      doesn't happen so often and usually it may read back successfully
      after one or more seconds, but in some rare worst cases the driver
      went into fallback mode.
      
      After trial-and-error, we found out that the communication stall seems
      covered by issuing the sync after each verb write, as already done for
      AMD and other chipsets.  So this patch enables the write-sync flag for
      the recent Intel chips, Skylake and onward, as a workaround.
      
      Also, since Broxton and co have the very same driver flags as Skylake,
      refer to the Skylake driver flags instead of defining the same
      contents again for simplification.
      
      BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=201901Reported-and-tested-by: default avatarTodd Brandt <todd.e.brandt@linux.intel.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5b9a6ba9
    • Sébastien Szymanski's avatar
      drm/panel: Add support for Armadeus ST0700 Adapt · 87c36921
      Sébastien Szymanski authored
      [ Upstream commit c479450f ]
      
      This patch adds support for the Armadeus ST0700 Adapt. It comes with a
      Santek ST0700I5Y-RBSLW 7.0" WVGA (800x480) TFT and an adapter board so
      that it can be connected on the TFT header of Armadeus Dev boards.
      
      Cc: stable@vger.kernel.org # v4.19
      Reviewed-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarSébastien Szymanski <sebastien.szymanski@armadeus.com>
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190507152713.27494-1-sebastien.szymanski@armadeus.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      87c36921
    • Mike Snitzer's avatar
      dm thin metadata: check if in fail_io mode when setting needs_check · ecf99cde
      Mike Snitzer authored
      [ Upstream commit 54fa16ee ]
      
      Check if in fail_io mode at start of dm_pool_metadata_set_needs_check().
      Otherwise dm_pool_metadata_set_needs_check()'s superblock_lock() can
      crash in dm_bm_write_lock() while accessing the block manager object
      that was previously destroyed as part of a failed
      dm_pool_abort_metadata() that ultimately set fail_io to begin with.
      
      Also, update DMERR() message to more accurately describe
      superblock_lock() failure.
      
      Cc: stable@vger.kernel.org
      Reported-by: default avatarZdenek Kabelac <zkabelac@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ecf99cde
    • Norbert Manthey's avatar
      pstore: Fix double-free in pstore_mkfile() failure path · 5e9a2ce6
      Norbert Manthey authored
      [ Upstream commit 4c6d80e1 ]
      
      The pstore_mkfile() function is passed a pointer to a struct
      pstore_record. On success it consumes this 'record' pointer and
      references it from the created inode.
      
      On failure, however, it may or may not free the record. There are even
      two different code paths which return -ENOMEM -- one of which does and
      the other doesn't free the record.
      
      Make the behaviour deterministic by never consuming and freeing the
      record when returning failure, allowing the caller to do the cleanup
      consistently.
      Signed-off-by: default avatarNorbert Manthey <nmanthey@amazon.de>
      Link: https://lore.kernel.org/r/1562331960-26198-1-git-send-email-nmanthey@amazon.de
      Fixes: 83f70f07 ("pstore: Do not duplicate record metadata")
      Fixes: 1dfff7dd ("pstore: Pass record contents instead of copying")
      Cc: stable@vger.kernel.org
      [kees: also move "private" allocation location, rename inode cleanup label]
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5e9a2ce6
    • Nadav Amit's avatar
      resource: fix locking in find_next_iomem_res() · 192b9af8
      Nadav Amit authored
      [ Upstream commit 49f17c26 ]
      
      Since resources can be removed, locking should ensure that the resource
      is not removed while accessing it.  However, find_next_iomem_res() does
      not hold the lock while copying the data of the resource.
      
      Keep holding the lock while the data is copied.  While at it, change the
      return value to a more informative value.  It is disregarded by the
      callers.
      
      [akpm@linux-foundation.org: fix find_next_iomem_res() documentation]
      Link: http://lkml.kernel.org/r/20190613045903.4922-2-namit@vmware.com
      Fixes: ff3cc952 ("resource: Add remove_resource interface")
      Signed-off-by: default avatarNadav Amit <namit@vmware.com>
      Reviewed-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Reviewed-by: default avatarDan Williams <dan.j.williams@intel.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Toshi Kani <toshi.kani@hpe.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      192b9af8
    • Bjorn Helgaas's avatar
      resource: Fix find_next_iomem_res() iteration issue · 485bcc29
      Bjorn Helgaas authored
      [ Upstream commit 010a93bf ]
      
      Previously find_next_iomem_res() used "*res" as both an input parameter for
      the range to search and the type of resource to search for, and an output
      parameter for the resource we found, which makes the interface confusing.
      
      The current callers use find_next_iomem_res() incorrectly because they
      allocate a single struct resource and use it for repeated calls to
      find_next_iomem_res().  When find_next_iomem_res() returns a resource, it
      overwrites the start, end, flags, and desc members of the struct.  If we
      call find_next_iomem_res() again, we must update or restore these fields.
      The previous code restored res.start and res.end, but not res.flags or
      res.desc.
      
      Since the callers did not restore res.flags, if they searched for flags
      IORESOURCE_MEM | IORESOURCE_BUSY and found a resource with flags
      IORESOURCE_MEM | IORESOURCE_BUSY | IORESOURCE_SYSRAM, the next search would
      incorrectly skip resources unless they were also marked as
      IORESOURCE_SYSRAM.
      
      Fix this by restructuring the interface so it takes explicit "start, end,
      flags" parameters and uses "*res" only as an output parameter.
      
      Based on a patch by Lianbo Jiang <lijiang@redhat.com>.
      
       [ bp: While at it:
         - make comments kernel-doc style.
         -
      
      Originally-by: http://lore.kernel.org/lkml/20180921073211.20097-2-lijiang@redhat.comSigned-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      CC: Andrew Morton <akpm@linux-foundation.org>
      CC: Brijesh Singh <brijesh.singh@amd.com>
      CC: Dan Williams <dan.j.williams@intel.com>
      CC: H. Peter Anvin <hpa@zytor.com>
      CC: Lianbo Jiang <lijiang@redhat.com>
      CC: Takashi Iwai <tiwai@suse.de>
      CC: Thomas Gleixner <tglx@linutronix.de>
      CC: Tom Lendacky <thomas.lendacky@amd.com>
      CC: Vivek Goyal <vgoyal@redhat.com>
      CC: Yaowei Bai <baiyaowei@cmss.chinamobile.com>
      CC: bhe@redhat.com
      CC: dan.j.williams@intel.com
      CC: dyoung@redhat.com
      CC: kexec@lists.infradead.org
      CC: mingo@redhat.com
      CC: x86-ml <x86@kernel.org>
      Link: http://lkml.kernel.org/r/153805812916.1157.177580438135143788.stgit@bhelgaas-glaptop.roam.corp.google.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      485bcc29
    • Bjorn Helgaas's avatar
      resource: Include resource end in walk_*() interfaces · 9a80dfcc
      Bjorn Helgaas authored
      [ Upstream commit a98959fd ]
      
      find_next_iomem_res() finds an iomem resource that covers part of a range
      described by "start, end".  All callers expect that range to be inclusive,
      i.e., both start and end are included, but find_next_iomem_res() doesn't
      handle the end address correctly.
      
      If it finds an iomem resource that contains exactly the end address, it
      skips it, e.g., if "start, end" is [0x0-0x10000] and there happens to be an
      iomem resource [mem 0x10000-0x10000] (the single byte at 0x10000), we skip
      it:
      
        find_next_iomem_res(...)
        {
          start = 0x0;
          end = 0x10000;
          for (p = next_resource(...)) {
            # p->start = 0x10000;
            # p->end = 0x10000;
            # we *should* return this resource, but this condition is false:
            if ((p->end >= start) && (p->start < end))
              break;
      
      Adjust find_next_iomem_res() so it allows a resource that includes the
      single byte at the end of the range.  This is a corner case that we
      probably don't see in practice.
      
      Fixes: 58c1b5b0 ("[PATCH] memory hotadd fixes: find_next_system_ram catch range fix")
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      CC: Andrew Morton <akpm@linux-foundation.org>
      CC: Brijesh Singh <brijesh.singh@amd.com>
      CC: Dan Williams <dan.j.williams@intel.com>
      CC: H. Peter Anvin <hpa@zytor.com>
      CC: Lianbo Jiang <lijiang@redhat.com>
      CC: Takashi Iwai <tiwai@suse.de>
      CC: Thomas Gleixner <tglx@linutronix.de>
      CC: Tom Lendacky <thomas.lendacky@amd.com>
      CC: Vivek Goyal <vgoyal@redhat.com>
      CC: Yaowei Bai <baiyaowei@cmss.chinamobile.com>
      CC: bhe@redhat.com
      CC: dan.j.williams@intel.com
      CC: dyoung@redhat.com
      CC: kexec@lists.infradead.org
      CC: mingo@redhat.com
      CC: x86-ml <x86@kernel.org>
      Link: http://lkml.kernel.org/r/153805812254.1157.16736368485811773752.stgit@bhelgaas-glaptop.roam.corp.google.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      9a80dfcc
    • Johannes Thumshirn's avatar
      btrfs: correctly validate compression type · 1c13c9c4
      Johannes Thumshirn authored
      [ Upstream commit aa53e3bf ]
      
      Nikolay reported the following KASAN splat when running btrfs/048:
      
      [ 1843.470920] ==================================================================
      [ 1843.471971] BUG: KASAN: slab-out-of-bounds in strncmp+0x66/0xb0
      [ 1843.472775] Read of size 1 at addr ffff888111e369e2 by task btrfs/3979
      
      [ 1843.473904] CPU: 3 PID: 3979 Comm: btrfs Not tainted 5.2.0-rc3-default #536
      [ 1843.475009] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
      [ 1843.476322] Call Trace:
      [ 1843.476674]  dump_stack+0x7c/0xbb
      [ 1843.477132]  ? strncmp+0x66/0xb0
      [ 1843.477587]  print_address_description+0x114/0x320
      [ 1843.478256]  ? strncmp+0x66/0xb0
      [ 1843.478740]  ? strncmp+0x66/0xb0
      [ 1843.479185]  __kasan_report+0x14e/0x192
      [ 1843.479759]  ? strncmp+0x66/0xb0
      [ 1843.480209]  kasan_report+0xe/0x20
      [ 1843.480679]  strncmp+0x66/0xb0
      [ 1843.481105]  prop_compression_validate+0x24/0x70
      [ 1843.481798]  btrfs_xattr_handler_set_prop+0x65/0x160
      [ 1843.482509]  __vfs_setxattr+0x71/0x90
      [ 1843.483012]  __vfs_setxattr_noperm+0x84/0x130
      [ 1843.483606]  vfs_setxattr+0xac/0xb0
      [ 1843.484085]  setxattr+0x18c/0x230
      [ 1843.484546]  ? vfs_setxattr+0xb0/0xb0
      [ 1843.485048]  ? __mod_node_page_state+0x1f/0xa0
      [ 1843.485672]  ? _raw_spin_unlock+0x24/0x40
      [ 1843.486233]  ? __handle_mm_fault+0x988/0x1290
      [ 1843.486823]  ? lock_acquire+0xb4/0x1e0
      [ 1843.487330]  ? lock_acquire+0xb4/0x1e0
      [ 1843.487842]  ? mnt_want_write_file+0x3c/0x80
      [ 1843.488442]  ? debug_lockdep_rcu_enabled+0x22/0x40
      [ 1843.489089]  ? rcu_sync_lockdep_assert+0xe/0x70
      [ 1843.489707]  ? __sb_start_write+0x158/0x200
      [ 1843.490278]  ? mnt_want_write_file+0x3c/0x80
      [ 1843.490855]  ? __mnt_want_write+0x98/0xe0
      [ 1843.491397]  __x64_sys_fsetxattr+0xba/0xe0
      [ 1843.492201]  ? trace_hardirqs_off_thunk+0x1a/0x1c
      [ 1843.493201]  do_syscall_64+0x6c/0x230
      [ 1843.493988]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [ 1843.495041] RIP: 0033:0x7fa7a8a7707a
      [ 1843.495819] Code: 48 8b 0d 21 de 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 be 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ee dd 2b 00 f7 d8 64 89 01 48
      [ 1843.499203] RSP: 002b:00007ffcb73bca38 EFLAGS: 00000202 ORIG_RAX: 00000000000000be
      [ 1843.500210] RAX: ffffffffffffffda RBX: 00007ffcb73bda9d RCX: 00007fa7a8a7707a
      [ 1843.501170] RDX: 00007ffcb73bda9d RSI: 00000000006dc050 RDI: 0000000000000003
      [ 1843.502152] RBP: 00000000006dc050 R08: 0000000000000000 R09: 0000000000000000
      [ 1843.503109] R10: 0000000000000002 R11: 0000000000000202 R12: 00007ffcb73bda91
      [ 1843.504055] R13: 0000000000000003 R14: 00007ffcb73bda82 R15: ffffffffffffffff
      
      [ 1843.505268] Allocated by task 3979:
      [ 1843.505771]  save_stack+0x19/0x80
      [ 1843.506211]  __kasan_kmalloc.constprop.5+0xa0/0xd0
      [ 1843.506836]  setxattr+0xeb/0x230
      [ 1843.507264]  __x64_sys_fsetxattr+0xba/0xe0
      [ 1843.507886]  do_syscall_64+0x6c/0x230
      [ 1843.508429]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      [ 1843.509558] Freed by task 0:
      [ 1843.510188] (stack is not available)
      
      [ 1843.511309] The buggy address belongs to the object at ffff888111e369e0
                      which belongs to the cache kmalloc-8 of size 8
      [ 1843.514095] The buggy address is located 2 bytes inside of
                      8-byte region [ffff888111e369e0, ffff888111e369e8)
      [ 1843.516524] The buggy address belongs to the page:
      [ 1843.517561] page:ffff88813f478d80 refcount:1 mapcount:0 mapping:ffff88811940c300 index:0xffff888111e373b8 compound_mapcount: 0
      [ 1843.519993] flags: 0x4404000010200(slab|head)
      [ 1843.520951] raw: 0004404000010200 ffff88813f48b008 ffff888119403d50 ffff88811940c300
      [ 1843.522616] raw: ffff888111e373b8 000000000016000f 00000001ffffffff 0000000000000000
      [ 1843.524281] page dumped because: kasan: bad access detected
      
      [ 1843.525936] Memory state around the buggy address:
      [ 1843.526975]  ffff888111e36880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [ 1843.528479]  ffff888111e36900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [ 1843.530138] >ffff888111e36980: fc fc fc fc fc fc fc fc fc fc fc fc 02 fc fc fc
      [ 1843.531877]                                                        ^
      [ 1843.533287]  ffff888111e36a00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [ 1843.534874]  ffff888111e36a80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [ 1843.536468] ==================================================================
      
      This is caused by supplying a too short compression value ('lz') in the
      test-case and comparing it to 'lzo' with strncmp() and a length of 3.
      strncmp() read past the 'lz' when looking for the 'o' and thus caused an
      out-of-bounds read.
      
      Introduce a new check 'btrfs_compress_is_valid_type()' which not only
      checks the user-supplied value against known compression types, but also
      employs checks for too short values.
      Reported-by: default avatarNikolay Borisov <nborisov@suse.com>
      Fixes: 272e5326 ("btrfs: prop: fix vanished compression property after failed set")
      CC: stable@vger.kernel.org # 5.1+
      Reviewed-by: default avatarNikolay Borisov <nborisov@suse.com>
      Signed-off-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1c13c9c4
    • Bart Van Assche's avatar
      RDMA/srp: Accept again source addresses that do not have a port number · 0ca2688b
      Bart Van Assche authored
      [ Upstream commit bcef5b72 ]
      
      The function srp_parse_in() is used both for parsing source address
      specifications and for target address specifications. Target addresses
      must have a port number. Having to specify a port number for source
      addresses is inconvenient. Make sure that srp_parse_in() supports again
      parsing addresses with no port number.
      
      Cc: <stable@vger.kernel.org>
      Fixes: c62adb7d ("IB/srp: Fix IPv6 address parsing")
      Signed-off-by: default avatarBart Van Assche <bvanassche@acm.org>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      0ca2688b
    • Bart Van Assche's avatar
      RDMA/srp: Document srp_parse_in() arguments · 95416047
      Bart Van Assche authored
      [ Upstream commit e37df2d5 ]
      
      This patch avoids that a warning is reported when building with W=1.
      
      Cc: Sergey Gorenko <sergeygo@mellanox.com>
      Cc: Max Gurtovoy <maxg@mellanox.com>
      Cc: Laurence Oberman <loberman@redhat.com>
      Signed-off-by: default avatarBart Van Assche <bvanassche@acm.org>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      95416047
    • Linus Walleij's avatar
      ARM: dts: gemini: Set DIR-685 SPI CS as active low · bab0ff2d
      Linus Walleij authored
      [ Upstream commit f90b8fda ]
      
      The SPI to the display on the DIR-685 is active low, we were
      just saved by the SPI library enforcing active low on everything
      before, so set it as active low to avoid ambiguity.
      
      Link: https://lore.kernel.org/r/20190715202101.16060-1-linus.walleij@linaro.org
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      bab0ff2d
    • Michael Neuling's avatar
      KVM: PPC: Book3S HV: Fix CR0 setting in TM emulation · 3a1b79ad
      Michael Neuling authored
      [ Upstream commit 3fefd1cd ]
      
      When emulating tsr, treclaim and trechkpt, we incorrectly set CR0. The
      code currently sets:
          CR0 <- 00 || MSR[TS]
      but according to the ISA it should be:
          CR0 <-  0 || MSR[TS] || 0
      
      This fixes the bit shift to put the bits in the correct location.
      
      This is a data integrity issue as CR0 is corrupted.
      
      Fixes: 4bb3c7a0 ("KVM: PPC: Book3S HV: Work around transactional memory bugs in POWER9")
      Cc: stable@vger.kernel.org # v4.17+
      Tested-by: default avatarSuraj Jitindar Singh <sjitindarsingh@gmail.com>
      Signed-off-by: default avatarMichael Neuling <mikey@neuling.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3a1b79ad
    • Paul Mackerras's avatar
      KVM: PPC: Use ccr field in pt_regs struct embedded in vcpu struct · 3ac71806
      Paul Mackerras authored
      [ Upstream commit fd0944ba ]
      
      When the 'regs' field was added to struct kvm_vcpu_arch, the code
      was changed to use several of the fields inside regs (e.g., gpr, lr,
      etc.) but not the ccr field, because the ccr field in struct pt_regs
      is 64 bits on 64-bit platforms, but the cr field in kvm_vcpu_arch is
      only 32 bits.  This changes the code to use the regs.ccr field
      instead of cr, and changes the assembly code on 64-bit platforms to
      use 64-bit loads and stores instead of 32-bit ones.
      Reviewed-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3ac71806
    • Wanpeng Li's avatar
      KVM: VMX: check CPUID before allowing read/write of IA32_XSS · beeeead9
      Wanpeng Li authored
      [ Upstream commit 4d763b16 ]
      
      Raise #GP when guest read/write IA32_XSS, but the CPUID bits
      say that it shouldn't exist.
      
      Fixes: 20300099 (kvm: vmx: add MSR logic for XSAVES)
      Reported-by: default avatarXiaoyao Li <xiaoyao.li@linux.intel.com>
      Reported-by: default avatarTao Xu <tao3.xu@intel.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarWanpeng Li <wanpengli@tencent.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      beeeead9
    • Sean Christopherson's avatar
      KVM: VMX: Fix handling of #MC that occurs during VM-Entry · 891011ca
      Sean Christopherson authored
      [ Upstream commit beb8d93b ]
      
      A previous fix to prevent KVM from consuming stale VMCS state after a
      failed VM-Entry inadvertantly blocked KVM's handling of machine checks
      that occur during VM-Entry.
      
      Per Intel's SDM, a #MC during VM-Entry is handled in one of three ways,
      depending on when the #MC is recognoized.  As it pertains to this bug
      fix, the third case explicitly states EXIT_REASON_MCE_DURING_VMENTRY
      is handled like any other VM-Exit during VM-Entry, i.e. sets bit 31 to
      indicate the VM-Entry failed.
      
      If a machine-check event occurs during a VM entry, one of the following occurs:
       - The machine-check event is handled as if it occurred before the VM entry:
              ...
       - The machine-check event is handled after VM entry completes:
              ...
       - A VM-entry failure occurs as described in Section 26.7. The basic
         exit reason is 41, for "VM-entry failure due to machine-check event".
      
      Explicitly handle EXIT_REASON_MCE_DURING_VMENTRY as a one-off case in
      vmx_vcpu_run() instead of binning it into vmx_complete_atomic_exit().
      Doing so allows vmx_vcpu_run() to handle VMX_EXIT_REASONS_FAILED_VMENTRY
      in a sane fashion and also simplifies vmx_complete_atomic_exit() since
      VMCS.VM_EXIT_INTR_INFO is guaranteed to be fresh.
      
      Fixes: b060ca3b ("kvm: vmx: Handle VMLAUNCH/VMRESUME failure properly")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSean Christopherson <sean.j.christopherson@intel.com>
      Reviewed-by: default avatarJim Mattson <jmattson@google.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      891011ca
    • Sean Christopherson's avatar
      KVM: VMX: Always signal #GP on WRMSR to MSR_IA32_CR_PAT with bad value · 74ce1333
      Sean Christopherson authored
      [ Upstream commit d28f4290 ]
      
      The behavior of WRMSR is in no way dependent on whether or not KVM
      consumes the value.
      
      Fixes: 4566654b ("KVM: vmx: Inject #GP on invalid PAT CR")
      Cc: stable@vger.kernel.org
      Cc: Nadav Amit <nadav.amit@gmail.com>
      Signed-off-by: default avatarSean Christopherson <sean.j.christopherson@intel.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      74ce1333
    • Paolo Bonzini's avatar
      KVM: x86: optimize check for valid PAT value · 74fd8aae
      Paolo Bonzini authored
      [ Upstream commit 674ea351 ]
      
      This check will soon be done on every nested vmentry and vmexit,
      "parallelize" it using bitwise operations.
      Reviewed-by: default avatarSean Christopherson <sean.j.christopherson@intel.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      74fd8aae
    • Yan, Zheng's avatar
      ceph: use ceph_evict_inode to cleanup inode's resource · 81281039
      Yan, Zheng authored
      [ Upstream commit 87bc5b89 ]
      
      remove_session_caps() relies on __wait_on_freeing_inode(), to wait for
      freeing inode to remove its caps. But VFS wakes freeing inode waiters
      before calling destroy_inode().
      
      Cc: stable@vger.kernel.org
      Link: https://tracker.ceph.com/issues/40102Signed-off-by: default avatar"Yan, Zheng" <zyan@redhat.com>
      Reviewed-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      81281039