1. 16 Sep, 2019 40 commits
    • Pavel Shilovsky's avatar
      CIFS: Fix error paths in writeback code · fb2dabea
      Pavel Shilovsky authored
      [ Upstream commit 9a66396f ]
      
      This patch aims to address writeback code problems related to error
      paths. In particular it respects EINTR and related error codes and
      stores and returns the first error occurred during writeback.
      Signed-off-by: default avatarPavel Shilovsky <pshilov@microsoft.com>
      Acked-by: default avatarJeff Layton <jlayton@kernel.org>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      fb2dabea
    • Ben Dooks's avatar
      drm: add __user attribute to ptr_to_compat() · e407b58c
      Ben Dooks authored
      [ Upstream commit e552f085 ]
      
      The ptr_to_compat() call takes a "void __user *", so cast
      the compat drm calls that use it to avoid the following
      warnings from sparse:
      
      drivers/gpu/drm/drm_ioc32.c:188:39: warning: incorrect type in argument 1 (different address spaces)
      drivers/gpu/drm/drm_ioc32.c:188:39:    expected void [noderef] <asn:1>*uptr
      drivers/gpu/drm/drm_ioc32.c:188:39:    got void *[addressable] [assigned] handle
      drivers/gpu/drm/drm_ioc32.c:529:41: warning: incorrect type in argument 1 (different address spaces)
      drivers/gpu/drm/drm_ioc32.c:529:41:    expected void [noderef] <asn:1>*uptr
      drivers/gpu/drm/drm_ioc32.c:529:41:    got void *[addressable] [assigned] handle
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarBen Dooks <ben.dooks@codethink.co.uk>
      Signed-off-by: default avatarSean Paul <seanpaul@chromium.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190301120046.26961-1-ben.dooks@codethink.co.ukSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      e407b58c
    • Bjorn Andersson's avatar
      PCI: qcom: Don't deassert reset GPIO during probe · e1a12c3b
      Bjorn Andersson authored
      [ Upstream commit 02b485e3 ]
      
      Acquiring the reset GPIO low means that reset is being deasserted, this
      is followed almost immediately with qcom_pcie_host_init() asserting it,
      initializing it and then finally deasserting it again, for the link to
      come up.
      
      Some PCIe devices requires a minimum time between the initial deassert
      and subsequent reset cycles. In a platform that boots with the reset
      GPIO asserted this requirement is being violated by this deassert/assert
      pulse.
      
      Acquire the reset GPIO high to prevent this situation by matching the
      state to the subsequent asserted state.
      
      Fixes: 82a82383 ("PCI: qcom: Add Qualcomm PCIe controller driver")
      Signed-off-by: default avatarBjorn Andersson <bjorn.andersson@linaro.org>
      [lorenzo.pieralisi@arm.com: updated commit log]
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Acked-by: default avatarStanimir Varbanov <svarbanov@mm-sol.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e1a12c3b
    • Bjorn Andersson's avatar
      PCI: qcom: Fix error handling in runtime PM support · be905d0f
      Bjorn Andersson authored
      [ Upstream commit 6e5da6f7 ]
      
      The driver does not cope with the fact that probe can fail in a number
      of cases after enabling runtime PM on the device; this results in
      warnings about "Unbalanced pm_runtime_enable". Furthermore if probe
      fails after invoking qcom_pcie_host_init() the power-domain will be left
      referenced.
      
      As it is not possible for the error handling in qcom_pcie_host_init() to
      handle errors happening after returning from that function the
      pm_runtime_get_sync() is moved to qcom_pcie_probe() as well.
      
      Fixes: 854b69ef ("PCI: qcom: add runtime pm support to pcie_port")
      Signed-off-by: default avatarBjorn Andersson <bjorn.andersson@linaro.org>
      [lorenzo.pieralisi@arm.com: updated commit log]
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Acked-by: default avatarStanimir Varbanov <svarbanov@mm-sol.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      be905d0f
    • Dan Robertson's avatar
      btrfs: init csum_list before possible free · 476ecc14
      Dan Robertson authored
      [ Upstream commit e49be14b ]
      
      The scrub_ctx csum_list member must be initialized before scrub_free_ctx
      is called. If the csum_list is not initialized beforehand, the
      list_empty call in scrub_free_csums will result in a null deref if the
      allocation fails in the for loop.
      
      Fixes: a2de733c ("btrfs: scrub")
      CC: stable@vger.kernel.org # 3.0+
      Reviewed-by: default avatarNikolay Borisov <nborisov@suse.com>
      Signed-off-by: default avatarDan Robertson <dan@dlrobertson.com>
      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>
      476ecc14
    • Anand Jain's avatar
      btrfs: scrub: fix circular locking dependency warning · 936690bd
      Anand Jain authored
      [ Upstream commit 1cec3f27 ]
      
      This fixes a longstanding lockdep warning triggered by
      fstests/btrfs/011.
      
      Circular locking dependency check reports warning[1], that's because the
      btrfs_scrub_dev() calls the stack #0 below with, the fs_info::scrub_lock
      held. The test case leading to this warning:
      
        $ mkfs.btrfs -f /dev/sdb
        $ mount /dev/sdb /btrfs
        $ btrfs scrub start -B /btrfs
      
      In fact we have fs_info::scrub_workers_refcnt to track if the init and destroy
      of the scrub workers are needed. So once we have incremented and decremented
      the fs_info::scrub_workers_refcnt value in the thread, its ok to drop the
      scrub_lock, and then actually do the btrfs_destroy_workqueue() part. So this
      patch drops the scrub_lock before calling btrfs_destroy_workqueue().
      
        [359.258534] ======================================================
        [359.260305] WARNING: possible circular locking dependency detected
        [359.261938] 5.0.0-rc6-default #461 Not tainted
        [359.263135] ------------------------------------------------------
        [359.264672] btrfs/20975 is trying to acquire lock:
        [359.265927] 00000000d4d32bea ((wq_completion)"%s-%s""btrfs", name){+.+.}, at: flush_workqueue+0x87/0x540
        [359.268416]
        [359.268416] but task is already holding lock:
        [359.270061] 0000000053ea26a6 (&fs_info->scrub_lock){+.+.}, at: btrfs_scrub_dev+0x322/0x590 [btrfs]
        [359.272418]
        [359.272418] which lock already depends on the new lock.
        [359.272418]
        [359.274692]
        [359.274692] the existing dependency chain (in reverse order) is:
        [359.276671]
        [359.276671] -> #3 (&fs_info->scrub_lock){+.+.}:
        [359.278187]        __mutex_lock+0x86/0x9c0
        [359.279086]        btrfs_scrub_pause+0x31/0x100 [btrfs]
        [359.280421]        btrfs_commit_transaction+0x1e4/0x9e0 [btrfs]
        [359.281931]        close_ctree+0x30b/0x350 [btrfs]
        [359.283208]        generic_shutdown_super+0x64/0x100
        [359.284516]        kill_anon_super+0x14/0x30
        [359.285658]        btrfs_kill_super+0x12/0xa0 [btrfs]
        [359.286964]        deactivate_locked_super+0x29/0x60
        [359.288242]        cleanup_mnt+0x3b/0x70
        [359.289310]        task_work_run+0x98/0xc0
        [359.290428]        exit_to_usermode_loop+0x83/0x90
        [359.291445]        do_syscall_64+0x15b/0x180
        [359.292598]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
        [359.294011]
        [359.294011] -> #2 (sb_internal#2){.+.+}:
        [359.295432]        __sb_start_write+0x113/0x1d0
        [359.296394]        start_transaction+0x369/0x500 [btrfs]
        [359.297471]        btrfs_finish_ordered_io+0x2aa/0x7c0 [btrfs]
        [359.298629]        normal_work_helper+0xcd/0x530 [btrfs]
        [359.299698]        process_one_work+0x246/0x610
        [359.300898]        worker_thread+0x3c/0x390
        [359.302020]        kthread+0x116/0x130
        [359.303053]        ret_from_fork+0x24/0x30
        [359.304152]
        [359.304152] -> #1 ((work_completion)(&work->normal_work)){+.+.}:
        [359.306100]        process_one_work+0x21f/0x610
        [359.307302]        worker_thread+0x3c/0x390
        [359.308465]        kthread+0x116/0x130
        [359.309357]        ret_from_fork+0x24/0x30
        [359.310229]
        [359.310229] -> #0 ((wq_completion)"%s-%s""btrfs", name){+.+.}:
        [359.311812]        lock_acquire+0x90/0x180
        [359.312929]        flush_workqueue+0xaa/0x540
        [359.313845]        drain_workqueue+0xa1/0x180
        [359.314761]        destroy_workqueue+0x17/0x240
        [359.315754]        btrfs_destroy_workqueue+0x57/0x200 [btrfs]
        [359.317245]        scrub_workers_put+0x2c/0x60 [btrfs]
        [359.318585]        btrfs_scrub_dev+0x336/0x590 [btrfs]
        [359.319944]        btrfs_dev_replace_by_ioctl.cold.19+0x179/0x1bb [btrfs]
        [359.321622]        btrfs_ioctl+0x28a4/0x2e40 [btrfs]
        [359.322908]        do_vfs_ioctl+0xa2/0x6d0
        [359.324021]        ksys_ioctl+0x3a/0x70
        [359.325066]        __x64_sys_ioctl+0x16/0x20
        [359.326236]        do_syscall_64+0x54/0x180
        [359.327379]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
        [359.328772]
        [359.328772] other info that might help us debug this:
        [359.328772]
        [359.330990] Chain exists of:
        [359.330990]   (wq_completion)"%s-%s""btrfs", name --> sb_internal#2 --> &fs_info->scrub_lock
        [359.330990]
        [359.334376]  Possible unsafe locking scenario:
        [359.334376]
        [359.336020]        CPU0                    CPU1
        [359.337070]        ----                    ----
        [359.337821]   lock(&fs_info->scrub_lock);
        [359.338506]                                lock(sb_internal#2);
        [359.339506]                                lock(&fs_info->scrub_lock);
        [359.341461]   lock((wq_completion)"%s-%s""btrfs", name);
        [359.342437]
        [359.342437]  *** DEADLOCK ***
        [359.342437]
        [359.343745] 1 lock held by btrfs/20975:
        [359.344788]  #0: 0000000053ea26a6 (&fs_info->scrub_lock){+.+.}, at: btrfs_scrub_dev+0x322/0x590 [btrfs]
        [359.346778]
        [359.346778] stack backtrace:
        [359.347897] CPU: 0 PID: 20975 Comm: btrfs Not tainted 5.0.0-rc6-default #461
        [359.348983] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.2-0-gf9626cc-prebuilt.qemu-project.org 04/01/2014
        [359.350501] Call Trace:
        [359.350931]  dump_stack+0x67/0x90
        [359.351676]  print_circular_bug.isra.37.cold.56+0x15c/0x195
        [359.353569]  check_prev_add.constprop.44+0x4f9/0x750
        [359.354849]  ? check_prev_add.constprop.44+0x286/0x750
        [359.356505]  __lock_acquire+0xb84/0xf10
        [359.357505]  lock_acquire+0x90/0x180
        [359.358271]  ? flush_workqueue+0x87/0x540
        [359.359098]  flush_workqueue+0xaa/0x540
        [359.359912]  ? flush_workqueue+0x87/0x540
        [359.360740]  ? drain_workqueue+0x1e/0x180
        [359.361565]  ? drain_workqueue+0xa1/0x180
        [359.362391]  drain_workqueue+0xa1/0x180
        [359.363193]  destroy_workqueue+0x17/0x240
        [359.364539]  btrfs_destroy_workqueue+0x57/0x200 [btrfs]
        [359.365673]  scrub_workers_put+0x2c/0x60 [btrfs]
        [359.366618]  btrfs_scrub_dev+0x336/0x590 [btrfs]
        [359.367594]  ? start_transaction+0xa1/0x500 [btrfs]
        [359.368679]  btrfs_dev_replace_by_ioctl.cold.19+0x179/0x1bb [btrfs]
        [359.369545]  btrfs_ioctl+0x28a4/0x2e40 [btrfs]
        [359.370186]  ? __lock_acquire+0x263/0xf10
        [359.370777]  ? kvm_clock_read+0x14/0x30
        [359.371392]  ? kvm_sched_clock_read+0x5/0x10
        [359.372248]  ? sched_clock+0x5/0x10
        [359.372786]  ? sched_clock_cpu+0xc/0xc0
        [359.373662]  ? do_vfs_ioctl+0xa2/0x6d0
        [359.374552]  do_vfs_ioctl+0xa2/0x6d0
        [359.375378]  ? do_sigaction+0xff/0x250
        [359.376233]  ksys_ioctl+0x3a/0x70
        [359.376954]  __x64_sys_ioctl+0x16/0x20
        [359.377772]  do_syscall_64+0x54/0x180
        [359.378841]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
        [359.380422] RIP: 0033:0x7f5429296a97
      
      Backporting to older kernels: scrub_nocow_workers must be freed the same
      way as the others.
      
      CC: stable@vger.kernel.org # 4.4+
      Signed-off-by: default avatarAnand Jain <anand.jain@oracle.com>
      [ update changelog ]
      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>
      936690bd
    • David Sterba's avatar
      btrfs: scrub: move scrub_setup_ctx allocation out of device_list_mutex · ff55333f
      David Sterba authored
      [ Upstream commit 0e94c4f4 ]
      
      The scrub context is allocated with GFP_KERNEL and called from
      btrfs_scrub_dev under the fs_info::device_list_mutex. This is not safe
      regarding reclaim that could try to flush filesystem data in order to
      get the memory. And the device_list_mutex is held during superblock
      commit, so this would cause a lockup.
      
      Move the alocation and initialization before any changes that require
      the mutex.
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ff55333f
    • David Sterba's avatar
      btrfs: scrub: pass fs_info to scrub_setup_ctx · 8ba3169d
      David Sterba authored
      [ Upstream commit 92f7ba43 ]
      
      We can pass fs_info directly as this is the only member of btrfs_device
      that's bing used inside scrub_setup_ctx.
      Reviewed-by: default avatarNikolay Borisov <nborisov@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8ba3169d
    • Takeshi Saito's avatar
      mmc: renesas_sdhi: Fix card initialization failure in high speed mode · df732920
      Takeshi Saito authored
      [ Upstream commit d30ae056 ]
      
      This fixes card initialization failure in high speed mode.
      
      If U-Boot uses SDR or HS200/400 mode before starting Linux and Linux
      DT does not enable SDR/HS200/HS400 mode, card initialization fails in
      high speed mode.
      
      It is necessary to initialize SCC registers during card initialization
      phase. HW reset function is registered only for a port with either of
      SDR/HS200/HS400 properties in device tree. If SDR/HS200/HS400 properties
      are not present in device tree, SCC registers will not be reset. In SoC
      that support SCC registers, HW reset function should be registered
      regardless of the configuration of device tree.
      
      Reproduction procedure:
      - Use U-Boot that support MMC HS200/400 mode.
      - Delete HS200/HS400 properties in device tree.
        (Delete mmc-hs200-1_8v and mmc-hs400-1_8v)
      - MMC port works high speed mode and all commands fail.
      Signed-off-by: default avatarTakeshi Saito <takeshi.saito.xv@renesas.com>
      Signed-off-by: default avatarMarek Vasut <marek.vasut+renesas@gmail.com>
      Cc: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
      Cc: Simon Horman <horms+renesas@verge.net.au>
      Reviewed-by: default avatarWolfram Sang <wsa+renesas@sang-engineering.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      df732920
    • Michael Ellerman's avatar
      powerpc/kvm: Save and restore host AMR/IAMR/UAMOR · 915c9d0a
      Michael Ellerman authored
      [ Upstream commit c3c7470c ]
      
      When the hash MMU is active the AMR, IAMR and UAMOR are used for
      pkeys. The AMR is directly writable by user space, and the UAMOR masks
      those writes, meaning both registers are effectively user register
      state. The IAMR is used to create an execute only key.
      
      Also we must maintain the value of at least the AMR when running in
      process context, so that any memory accesses done by the kernel on
      behalf of the process are correctly controlled by the AMR.
      
      Although we are correctly switching all registers when going into a
      guest, on returning to the host we just write 0 into all regs, except
      on Power9 where we restore the IAMR correctly.
      
      This could be observed by a user process if it writes the AMR, then
      runs a guest and we then return immediately to it without
      rescheduling. Because we have written 0 to the AMR that would have the
      effect of granting read/write permission to pages that the process was
      trying to protect.
      
      In addition, when using the Radix MMU, the AMR can prevent inadvertent
      kernel access to userspace data, writing 0 to the AMR disables that
      protection.
      
      So save and restore AMR, IAMR and UAMOR.
      
      Fixes: cf43d3b2 ("powerpc: Enable pkey subsystem")
      Cc: stable@vger.kernel.org # v4.16+
      Signed-off-by: default avatarRussell Currey <ruscur@russell.cc>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Acked-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      915c9d0a
    • Russell King's avatar
      spi: spi-gpio: fix SPI_CS_HIGH capability · b3f864b8
      Russell King authored
      [ Upstream commit b89fefda ]
      
      spi-gpio is capable of dealing with active-high chip-selects.
      Unfortunately, commit 4b859db2 ("spi: spi-gpio: add SPI_3WIRE
      support") broke this by setting master->mode_bits, which overrides
      the setting in the spi-bitbang code.  Fix this.
      
      [Fixed a trivial conflict with SPI_3WIRE_HIZ support -- broonie]
      
      Fixes: 4b859db2 ("spi: spi-gpio: add SPI_3WIRE support")
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b3f864b8
    • Pavel Tatashin's avatar
      x86/kvmclock: set offset for kvm unstable clock · 1d60902a
      Pavel Tatashin authored
      [ Upstream commit b5179ec4 ]
      
      VMs may show incorrect uptime and dmesg printk offsets on hypervisors with
      unstable clock. The problem is produced when VM is rebooted without exiting
      from qemu.
      
      The fix is to calculate clock offset not only for stable clock but for
      unstable clock as well, and use kvm_sched_clock_read() which substracts
      the offset for both clocks.
      
      This is safe, because pvclock_clocksource_read() does the right thing and
      makes sure that clock always goes forward, so once offset is calculated
      with unstable clock, we won't get new reads that are smaller than offset,
      and thus won't get negative results.
      
      Thank you Jon DeVree for helping to reproduce this issue.
      
      Fixes: 857baa87 ("sched/clock: Enable sched clock early")
      Cc: stable@vger.kernel.org
      Reported-by: default avatarDominique Martinet <asmadeus@codewreck.org>
      Signed-off-by: default avatarPavel Tatashin <pasha.tatashin@soleen.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1d60902a
    • Ihab Zhaika's avatar
      iwlwifi: add new card for 9260 series · 716b0cfa
      Ihab Zhaika authored
      [ Upstream commit 3941310c ]
      
      Add one PCI ID for 9260 series.
      
      CC: <stable@vger.kernel.org> # 4.14+
      Signed-off-by: default avatarIhab Zhaika <ihab.zhaika@intel.com>
      Signed-off-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      716b0cfa
    • Luca Coelho's avatar
      iwlwifi: fix devices with PCI Device ID 0x34F0 and 11ac RF modules · 213566a9
      Luca Coelho authored
      [ Upstream commit ab27926d ]
      
      The devices with PCI device ID 0x34F0 are part of the SoC and can be
      combined with some different external RF modules.  The configuration
      for these devices should reflect that, but are currently mixed up.  To
      avoid confusion with discrete devices, add part of the firmware to be
      used and the official name of the device to the cfg structs.
      
      This is least reorganization possible (without messing things even
      more) that could be done as a bugfix for this SoC.  Further
      reorganization of this code will be done separately.
      Signed-off-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      213566a9
    • Lyude Paul's avatar
      drm/nouveau: Don't WARN_ON VCPI allocation failures · 2b76fcb6
      Lyude Paul authored
      [ Upstream commit b513a18c ]
      
      This is much louder then we want. VCPI allocation failures are quite
      normal, since they will happen if any part of the modesetting process is
      interrupted by removing the DP MST topology in question. So just print a
      debugging message on VCPI failures instead.
      Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Fixes: f479c0ba ("drm/nouveau/kms/nv50: initial support for DP 1.2 multi-stream")
      Cc: Ben Skeggs <bskeggs@redhat.com>
      Cc: dri-devel@lists.freedesktop.org
      Cc: nouveau@lists.freedesktop.org
      Cc: <stable@vger.kernel.org> # v4.10+
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      2b76fcb6
    • Felix Fietkau's avatar
      mt76: fix corrupted software generated tx CCMP PN · 173b6557
      Felix Fietkau authored
      [ Upstream commit 906d2d3f ]
      
      Since ccmp_pn is u8 *, the second half needs to start at array index 4
      instead of 0. Fixes a connection stall after a certain amount of traffic
      
      Fixes: 23405236 ("mt76: fix transmission of encrypted management frames")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarFelix Fietkau <nbd@nbd.name>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      173b6557
    • Krzysztof Kozlowski's avatar
      iio: adc: exynos-adc: Use proper number of channels for Exynos4x12 · 0d7f329e
      Krzysztof Kozlowski authored
      [ Upstream commit 103cda6a ]
      
      Exynos4212 and Exynos4412 have only four ADC channels so using
      "samsung,exynos-adc-v1" compatible (for eight channels ADCv1) on them is
      wrong.  Add a new compatible for Exynos4x12.
      Signed-off-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      0d7f329e
    • Jonathan Bakker's avatar
      dt-bindings: iio: adc: exynos-adc: Add S5PV210 variant · 4e516b72
      Jonathan Bakker authored
      [ Upstream commit a9b0a2a7 ]
      
      Add information about new compatible for S5PV210
      Signed-off-by: default avatarJonathan Bakker <xc-racer2@live.ca>
      Signed-off-by: default avatarPaweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      4e516b72
    • Jonathan Bakker's avatar
      iio: adc: exynos-adc: Add S5PV210 variant · 7f588a72
      Jonathan Bakker authored
      [ Upstream commit 882bf52f ]
      
      S5PV210's ADC variant is almost the same as v1 except that it has 10
      channels and doesn't require the pmu register
      Signed-off-by: default avatarJonathan Bakker <xc-racer2@live.ca>
      Signed-off-by: default avatarPaweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7f588a72
    • Sean Christopherson's avatar
      KVM: VMX: Compare only a single byte for VMCS' "launched" in vCPU-run · cd490d44
      Sean Christopherson authored
      [ Upstream commit 61c08aa9 ]
      
      The vCPU-run asm blob does a manual comparison of a VMCS' launched
      status to execute the correct VM-Enter instruction, i.e. VMLAUNCH vs.
      VMRESUME.  The launched flag is a bool, which is a typedef of _Bool.
      C99 does not define an exact size for _Bool, stating only that is must
      be large enough to hold '0' and '1'.  Most, if not all, compilers use
      a single byte for _Bool, including gcc[1].
      
      Originally, 'launched' was of type 'int' and so the asm blob used 'cmpl'
      to check the launch status.  When 'launched' was moved to be stored on a
      per-VMCS basis, struct vcpu_vmx's "temporary" __launched flag was added
      in order to avoid having to pass the current VMCS into the asm blob.
      The new  '__launched' was defined as a 'bool' and not an 'int', but the
      'cmp' instruction was not updated.
      
      This has not caused any known problems, likely due to compilers aligning
      variables to 4-byte or 8-byte boundaries and KVM zeroing out struct
      vcpu_vmx during allocation.  I.e. vCPU-run accesses "junk" data, it just
      happens to always be zero and so doesn't affect the result.
      
      [1] https://gcc.gnu.org/ml/gcc-patches/2000-10/msg01127.html
      
      Fixes: d462b819 ("KVM: VMX: Keep list of loaded VMCSs, instead of vcpus")
      Cc: <stable@vger.kernel.org>
      Reviewed-by: default avatarJim Mattson <jmattson@google.com>
      Reviewed-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.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>
      cd490d44
    • Tang Junhui's avatar
      bcache: treat stale && dirty keys as bad keys · 687e470e
      Tang Junhui authored
      [ Upstream commit 58ac3230 ]
      
      Stale && dirty keys can be produced in the follow way:
      After writeback in write_dirty_finish(), dirty keys k1 will
      replace by clean keys k2
      ==>ret = bch_btree_insert(dc->disk.c, &keys, NULL, &w->key);
      ==>btree_insert_fn(struct btree_op *b_op, struct btree *b)
      ==>static int bch_btree_insert_node(struct btree *b,
             struct btree_op *op,
             struct keylist *insert_keys,
             atomic_t *journal_ref,
      Then two steps:
      A) update k1 to k2 in btree node memory;
         bch_btree_insert_keys(b, op, insert_keys, replace_key)
      B) Write the bset(contains k2) to cache disk by a 30s delay work
         bch_btree_leaf_dirty(b, journal_ref).
      But before the 30s delay work write the bset to cache device,
      these things happened:
      A) GC works, and reclaim the bucket k2 point to;
      B) Allocator works, and invalidate the bucket k2 point to,
         and increase the gen of the bucket, and place it into free_inc
         fifo;
      C) Until now, the 30s delay work still does not finish work,
         so in the disk, the key still is k1, it is dirty and stale
         (its gen is smaller than the gen of the bucket). and then the
         machine power off suddenly happens;
      D) When the machine power on again, after the btree reconstruction,
         the stale dirty key appear.
      
      In bch_extent_bad(), when expensive_debug_checks is off, it would
      treat the dirty key as good even it is stale keys, and it would
      cause bellow probelms:
      A) In read_dirty() it would cause machine crash:
         BUG_ON(ptr_stale(dc->disk.c, &w->key, 0));
      B) It could be worse when reads hits stale dirty keys, it would
         read old incorrect data.
      
      This patch tolerate the existence of these stale && dirty keys,
      and treat them as bad key in bch_extent_bad().
      
      (Coly Li: fix indent which was modified by sender's email client)
      Signed-off-by: default avatarTang Junhui <tang.junhui.linux@gmail.com>
      Cc: stable@vger.kernel.org
      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>
      687e470e
    • Coly Li's avatar
      bcache: replace hard coded number with BUCKET_GC_GEN_MAX · d1cec665
      Coly Li authored
      [ Upstream commit 149d0efa ]
      
      In extents.c:bch_extent_bad(), number 96 is used as parameter to call
      btree_bug_on(). The purpose is to check whether stale gen value exceeds
      BUCKET_GC_GEN_MAX, so it is better to use macro BUCKET_GC_GEN_MAX to
      make the code more understandable.
      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>
      d1cec665
    • Jarkko Sakkinen's avatar
      tpm: Fix some name collisions with drivers/char/tpm.h · ee30121f
      Jarkko Sakkinen authored
      [ Upstream commit 8ab547a2 ]
      
      * Rename TPM_BUFSIZE defined in drivers/char/tpm/st33zp24/st33zp24.h to
        ST33ZP24_BUFSIZE.
      * Rename TPM_BUFSIZE defined in drivers/char/tpm/tpm_i2c_infineon.c to
        TPM_I2C_INFINEON_BUFSIZE.
      * Rename TPM_RETRY in tpm_i2c_nuvoton to TPM_I2C_RETRIES.
      * Remove TPM_HEADER_SIZE from tpm_i2c_nuvoton.
      
      Cc: stable@vger.kernel.org
      Fixes: bf38b871 ("tpm/tpm_i2c_stm_st33: Split tpm_i2c_tpm_st33 in 2 layers (core + phy)")
      Fixes: aad628c1 ("char/tpm: Add new driver for Infineon I2C TIS TPM")
      Fixes: 32d33b29 ("TPM: Retry SaveState command in suspend path")
      Signed-off-by: default avatarJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ee30121f
    • Jarkko Nikula's avatar
      mfd: Kconfig: Fix I2C_DESIGNWARE_PLATFORM dependencies · c207ac66
      Jarkko Nikula authored
      [ Upstream commit 09fdc985 ]
      
      INTEL_SOC_PMIC, INTEL_SOC_PMIC_CHTWC and MFD_TPS68470 select the
      I2C_DESIGNWARE_PLATFORM without its dependencies making it possible to see
      warning and build error like below:
      
      WARNING: unmet direct dependencies detected for I2C_DESIGNWARE_PLATFORM
        Depends on [n]: I2C [=y] && HAS_IOMEM [=y] && (ACPI [=y] && COMMON_CLK [=n] || !ACPI [=y])
        Selected by [y]:
        - MFD_TPS68470 [=y] && HAS_IOMEM [=y] && ACPI [=y] && I2C [=y]=y
      
      /usr/bin/ld: drivers/i2c/busses/i2c-designware-platdrv.o: in function `dw_i2c_plat_resume':
      i2c-designware-platdrv.c:(.text+0x62): undefined reference to `i2c_dw_prepare_clk'
      /usr/bin/ld: drivers/i2c/busses/i2c-designware-platdrv.o: in function `dw_i2c_plat_suspend':
      i2c-designware-platdrv.c:(.text+0x9a): undefined reference to `i2c_dw_prepare_clk'
      /usr/bin/ld: drivers/i2c/busses/i2c-designware-platdrv.o: in function `dw_i2c_plat_probe':
      i2c-designware-platdrv.c:(.text+0x41c): undefined reference to `i2c_dw_prepare_clk'
      /usr/bin/ld: i2c-designware-platdrv.c:(.text+0x438): undefined reference to `i2c_dw_read_comp_param'
      /usr/bin/ld: i2c-designware-platdrv.c:(.text+0x545): undefined reference to `i2c_dw_probe'
      /usr/bin/ld: i2c-designware-platdrv.c:(.text+0x727): undefined reference to `i2c_dw_probe_slave'
      
      Fix this by making above options to depend on I2C_DESIGNWARE_PLATFORM
      being built-in. I2C_DESIGNWARE_PLATFORM is a visible symbol with
      dependencies so in general the select should be avoided.
      
      Fixes: acebcff9 ("mfd: intel_soc_pmic: Select designware i2c-bus driver")
      Fixes: de85d79f ("mfd: Add Cherry Trail Whiskey Cove PMIC driver")
      Fixes: 9bbf6a15 ("mfd: Add support for TPS68470 device")
      Cc: Stable <stable@vger.kernel.org> # v4.14+
      Reported-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: default avatarJarkko Nikula <jarkko.nikula@linux.intel.com>
      Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
      Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c207ac66
    • José Roberto de Souza's avatar
      drm/i915/ilk: Fix warning when reading emon_status with no output · 6fd5e50a
      José Roberto de Souza authored
      [ Upstream commit cab870b7 ]
      
      When there is no output no one will hold a runtime_pm reference
      causing a warning when trying to read emom_status in debugfs.
      
      [22.756480] ------------[ cut here ]------------
      [22.756489] RPM wakelock ref not held during HW access
      [22.756578] WARNING: CPU: 0 PID: 1058 at drivers/gpu/drm/i915/intel_drv.h:2104 gen5_read32+0x16b/0x1a0 [i915]
      [22.756580] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core e1000e snd_pcm mei_me prime_numbers mei lpc_ich
      [22.756595] CPU: 0 PID: 1058 Comm: debugfs_test Not tainted 4.20.0-rc1-CI-Trybot_3219+ #1
      [22.756597] Hardware name: Hewlett-Packard HP Compaq 8100 Elite SFF PC/304Ah, BIOS 786H1 v01.13 07/14/2011
      [22.756634] RIP: 0010:gen5_read32+0x16b/0x1a0 [i915]
      [22.756637] Code: a4 ea e0 0f 0b e9 d2 fe ff ff 80 3d a5 71 19 00 00 0f 85 d3 fe ff ff 48 c7 c7 48 d0 2d a0 c6 05 91 71 19 00 01 e8 35 a4 ea e0 <0f> 0b e9 b9 fe ff ff e8 69 c6 f2 e0 85 c0 75 92 48 c7 c2 78 d0 2d
      [22.756639] RSP: 0018:ffffc90000f1fd38 EFLAGS: 00010282
      [22.756642] RAX: 0000000000000000 RBX: ffff8801f7ab0000 RCX: 0000000000000006
      [22.756643] RDX: 0000000000000006 RSI: ffffffff8212886a RDI: ffffffff820d6d57
      [22.756645] RBP: 0000000000011020 R08: 0000000043e3d1a8 R09: 0000000000000000
      [22.756647] R10: ffffc90000f1fd80 R11: 0000000000000000 R12: 0000000000000001
      [22.756649] R13: ffff8801f7ab0068 R14: 0000000000000001 R15: ffff88020d53d188
      [22.756651] FS:  00007f2878849980(0000) GS:ffff880213a00000(0000) knlGS:0000000000000000
      [22.756653] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [22.756655] CR2: 00005638deedf028 CR3: 0000000203292001 CR4: 00000000000206f0
      [22.756657] Call Trace:
      [22.756689]  i915_mch_val+0x1b/0x60 [i915]
      [22.756721]  i915_emon_status+0x45/0xd0 [i915]
      [22.756730]  seq_read+0xdb/0x3c0
      [22.756736]  ? lockdep_hardirqs_off+0x94/0xd0
      [22.756740]  ? __slab_free+0x24e/0x510
      [22.756746]  full_proxy_read+0x52/0x90
      [22.756752]  __vfs_read+0x31/0x170
      [22.756759]  ? do_sys_open+0x13b/0x240
      [22.756763]  ? rcu_read_lock_sched_held+0x6f/0x80
      [22.756766]  vfs_read+0x9e/0x140
      [22.756770]  ksys_read+0x50/0xc0
      [22.756775]  do_syscall_64+0x55/0x190
      [22.756781]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [22.756783] RIP: 0033:0x7f28781dc34e
      [22.756786] Code: 00 00 00 00 48 8b 15 71 8c 20 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff c3 0f 1f 40 00 8b 05 ba d0 20 00 85 c0 75 16 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 5a f3 c3 0f 1f 84 00 00 00 00 00 41 54 55 49
      [22.756787] RSP: 002b:00007ffd33fa0d08 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
      [22.756790] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f28781dc34e
      [22.756792] RDX: 0000000000000200 RSI: 00007ffd33fa0d50 RDI: 0000000000000008
      [22.756794] RBP: 00007ffd33fa0f60 R08: 0000000000000000 R09: 0000000000000020
      [22.756796] R10: 0000000000000000 R11: 0000000000000246 R12: 00005638de45c2c0
      [22.756797] R13: 00007ffd33fa14b0 R14: 0000000000000000 R15: 0000000000000000
      [22.756806] irq event stamp: 47950
      [22.756811] hardirqs last  enabled at (47949): [<ffffffff810fba74>] vprintk_emit+0x124/0x320
      [22.756813] hardirqs last disabled at (47950): [<ffffffff810019b0>] trace_hardirqs_off_thunk+0x1a/0x1c
      [22.756816] softirqs last  enabled at (47518): [<ffffffff81c0033a>] __do_softirq+0x33a/0x4b9
      [22.756820] softirqs last disabled at (47479): [<ffffffff8108df29>] irq_exit+0xa9/0xc0
      [22.756858] WARNING: CPU: 0 PID: 1058 at drivers/gpu/drm/i915/intel_drv.h:2104 gen5_read32+0x16b/0x1a0 [i915]
      [22.756860] ---[ end trace bf56fa7d6a3cbf7a ]
      Signed-off-by: default avatarJosé Roberto de Souza <jose.souza@intel.com>
      Reviewed-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181119230101.32460-1-jose.souza@intel.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      6fd5e50a
    • Ville Syrjälä's avatar
      drm/vblank: Allow dynamic per-crtc max_vblank_count · 2b4f5679
      Ville Syrjälä authored
      [ Upstream commit ed20151a ]
      
      On i965gm we need to adjust max_vblank_count dynamically
      depending on whether the TV encoder is used or not. To
      that end add a per-crtc max_vblank_count that takes
      precedence over its device wide counterpart. The driver
      can now call drm_crtc_set_max_vblank_count() to configure
      the per-crtc value before calling drm_vblank_on().
      
      Also looks like there was some discussion about exynos needing
      similar treatment.
      
      v2: Drop the extra max_vblank_count!=0 check for the
          WARN(last!=current), will take care of it in i915 code (Daniel)
          WARN_ON(!inmodeset) (Daniel)
          WARN_ON(dev->max_vblank_count)
          Pimp up the docs (Daniel)
      
      Cc: stable@vger.kernel.org
      Cc: Inki Dae <inki.dae@samsung.com>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181127182004.28885-1-ville.syrjala@linux.intel.comReviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      2b4f5679
    • Gilad Ben-Yossef's avatar
      crypto: ccree - add missing inline qualifier · 71f71910
      Gilad Ben-Yossef authored
      [ Upstream commit f1071c3e ]
      
      Commit 1358c13a ("crypto: ccree - fix resume race condition on init")
      was missing a "inline" qualifier for stub function used when CONFIG_PM
      is not set causing a build warning.
      
      Fixes: 1358c13a ("crypto: ccree - fix resume race condition on init")
      Cc: stable@kernel.org # v4.20
      Signed-off-by: default avatarGilad Ben-Yossef <gilad@benyossef.com>
      Acked-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      71f71910
    • Gilad Ben-Yossef's avatar
      crypto: ccree - fix resume race condition on init · 72eec6b3
      Gilad Ben-Yossef authored
      [ Upstream commit 1358c13a ]
      
      We were enabling autosuspend, which is using data set by the
      hash module, prior to the hash module being inited, casuing
      a crash on resume as part of the startup sequence if the race
      was lost.
      
      This was never a real problem because the PM infra was using low
      res timers so we were always winning the race, until commit 8234f673
      ("PM-runtime: Switch autosuspend over to using hrtimers") changed that :-)
      
      Fix this by seperating the PM setup and enablement and doing the
      latter only at the end of the init sequence.
      Signed-off-by: default avatarGilad Ben-Yossef <gilad@benyossef.com>
      Cc: Vincent Guittot <vincent.guittot@linaro.org>
      Cc: stable@kernel.org # v4.20
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      72eec6b3
    • Yishai Hadas's avatar
      IB/uverbs: Fix OOPs upon device disassociation · f0e28655
      Yishai Hadas authored
      [ Upstream commit 425784aa ]
      
      The async_file might be freed before the disassociation has been ended,
      causing qp shutdown to use after free on it.
      
      Since uverbs_destroy_ufile_hw is not a fence, it returns if a
      disassociation is ongoing in another thread. It has to be written this way
      to avoid deadlock. However this means that the ufile FD close cannot
      destroy anything that may still be used by an active kref, such as the the
      async_file.
      
      To fix that move the kref_put() to be in ib_uverbs_release_file().
      
       BUG: unable to handle kernel paging request at ffffffffba682787
       PGD bc80e067 P4D bc80e067 PUD bc80f063 PMD 1313df163 PTE 80000000bc682061
       Oops: 0003 [#1] SMP PTI
       CPU: 1 PID: 32410 Comm: bash Tainted: G           OE 4.20.0-rc6+ #3
       Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
       RIP: 0010:__pv_queued_spin_lock_slowpath+0x1b3/0x2a0
       Code: 98 83 e2 60 49 89 df 48 8b 04 c5 80 18 72 ba 48 8d
      		ba 80 32 02 00 ba 00 80 00 00 4c 8d 65 14 41 bd 01 00 00 00 48 01 c7 85
      		d2 <48> 89 2f 48 89 fb 74 14 8b 45 08 85 c0 75 42 84 d2 74 6b f3 90 83
       RSP: 0018:ffffc1bbc064fb58 EFLAGS: 00010006
       RAX: ffffffffba65f4e7 RBX: ffff9f209c656c00 RCX: 0000000000000001
       RDX: 0000000000008000 RSI: 0000000000000000 RDI: ffffffffba682787
       RBP: ffff9f217bb23280 R08: 0000000000000001 R09: 0000000000000000
       R10: ffff9f209d2c7800 R11: ffffffffffffffe8 R12: ffff9f217bb23294
       R13: 0000000000000001 R14: 0000000000000000 R15: ffff9f209c656c00
       FS:  00007fac55aad740(0000) GS:ffff9f217bb00000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: ffffffffba682787 CR3: 000000012f8e0000 CR4: 00000000000006e0
       Call Trace:
        _raw_spin_lock_irq+0x27/0x30
        ib_uverbs_release_uevent+0x1e/0xa0 [ib_uverbs]
        uverbs_free_qp+0x7e/0x90 [ib_uverbs]
        destroy_hw_idr_uobject+0x1c/0x50 [ib_uverbs]
        uverbs_destroy_uobject+0x2e/0x180 [ib_uverbs]
        __uverbs_cleanup_ufile+0x73/0x90 [ib_uverbs]
        uverbs_destroy_ufile_hw+0x5d/0x120 [ib_uverbs]
        ib_uverbs_remove_one+0xea/0x240 [ib_uverbs]
        ib_unregister_device+0xfb/0x200 [ib_core]
        mlx5_ib_remove+0x51/0xe0 [mlx5_ib]
        mlx5_remove_device+0xc1/0xd0 [mlx5_core]
        mlx5_unregister_device+0x3d/0xb0 [mlx5_core]
        remove_one+0x2a/0x90 [mlx5_core]
        pci_device_remove+0x3b/0xc0
        device_release_driver_internal+0x16d/0x240
        unbind_store+0xb2/0x100
        kernfs_fop_write+0x102/0x180
        __vfs_write+0x36/0x1a0
        ? __alloc_fd+0xa9/0x170
        ? set_close_on_exec+0x49/0x70
        vfs_write+0xad/0x1a0
        ksys_write+0x52/0xc0
        do_syscall_64+0x5b/0x180
        entry_SYSCALL_64_after_hwframe+0x44/0xa9
       RIP: 0033:0x7fac551aac60
      
      Cc: <stable@vger.kernel.org> # 4.2
      Fixes: 036b1063 ("IB/uverbs: Enable device removal when there are active user space applications")
      Signed-off-by: default avatarYishai Hadas <yishaih@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f0e28655
    • Vineet Gupta's avatar
      ARC: mm: do_page_fault fixes #1: relinquish mmap_sem if signal arrives while handle_mm_fault · 8c6fb55a
      Vineet Gupta authored
      [ Upstream commit 4d447455 ]
      
      do_page_fault() forgot to relinquish mmap_sem if a signal came while
      handling handle_mm_fault() - due to say a ctl+c or oom etc.
      This would later cause a deadlock by acquiring it twice.
      
      This came to light when running libc testsuite tst-tls3-malloc test but
      is likely also the cause for prior seen LTP failures. Using lockdep
      clearly showed what the issue was.
      
      | # while true; do ./tst-tls3-malloc ; done
      | Didn't expect signal from child: got `Segmentation fault'
      | ^C
      | ============================================
      | WARNING: possible recursive locking detected
      | 4.17.0+ #25 Not tainted
      | --------------------------------------------
      | tst-tls3-malloc/510 is trying to acquire lock:
      | 606c7728 (&mm->mmap_sem){++++}, at: __might_fault+0x28/0x5c
      |
      |but task is already holding lock:
      |606c7728 (&mm->mmap_sem){++++}, at: do_page_fault+0x9c/0x2a0
      |
      | other info that might help us debug this:
      |  Possible unsafe locking scenario:
      |
      |       CPU0
      |       ----
      |  lock(&mm->mmap_sem);
      |  lock(&mm->mmap_sem);
      |
      | *** DEADLOCK ***
      |
      
      ------------------------------------------------------------
      What the change does is not obvious (note to myself)
      
      prior code was
      
      | do_page_fault
      |
      |   down_read()		<-- lock taken
      |   handle_mm_fault	<-- signal pending as this runs
      |   if fatal_signal_pending
      |       if VM_FAULT_ERROR
      |           up_read
      |       if user_mode
      |          return	<-- lock still held, this was the BUG
      
      New code
      
      | do_page_fault
      |
      |   down_read()		<-- lock taken
      |   handle_mm_fault	<-- signal pending as this runs
      |   if fatal_signal_pending
      |       if VM_FAULT_RETRY
      |          return       <-- not same case as above, but still OK since
      |                           core mm already relinq lock for FAULT_RETRY
      |    ...
      |
      |   < Now falls through for bug case above >
      |
      |   up_read()		<-- lock relinquished
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8c6fb55a
    • Vineet Gupta's avatar
      ARC: show_regs: lockdep: re-enable preemption · 96af7d92
      Vineet Gupta authored
      [ Upstream commit f731a8e8 ]
      
      signal handling core calls show_regs() with preemption disabled which
      on ARC takes mmap_sem for mm/vma access, causing lockdep splat.
      
      | [ARCLinux]# ./segv-null-ptr
      | potentially unexpected fatal signal 11.
      | BUG: sleeping function called from invalid context at kernel/fork.c:1011
      | in_atomic(): 1, irqs_disabled(): 0, pid: 70, name: segv-null-ptr
      | no locks held by segv-null-ptr/70.
      | CPU: 0 PID: 70 Comm: segv-null-ptr Not tainted 4.18.0+ #69
      |
      | Stack Trace:
      |  arc_unwind_core+0xcc/0x100
      |  ___might_sleep+0x17a/0x190
      |  mmput+0x16/0xb8
      |  show_regs+0x52/0x310
      |  get_signal+0x5ee/0x610
      |  do_signal+0x2c/0x218
      |  resume_user_mode_begin+0x90/0xd8
      
      Workaround by re-enabling preemption temporarily.
      
      Note that the preemption disabling in core code around show_regs()
      was introduced by commit 3a9f84d3 ("signals, debug: fix BUG: using
      smp_processor_id() in preemptible code in print_fatal_signal()")
      
      to silence a differnt lockdep seen on x86 bakc in 2009.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      96af7d92
    • Hans Verkuil's avatar
      media: vim2m: only cancel work if it is for right context · 424b75b7
      Hans Verkuil authored
      [ Upstream commit 240809ef ]
      
      cancel_delayed_work_sync() was called for any queue, but it should only
      be called for the queue that is associated with the currently running job.
      
      Otherwise, if two filehandles are streaming at the same time, then closing the
      first will cancel the work which might still be running for a job from the
      second filehandle. As a result the second filehandle will never be able to
      finish the job and an attempt to stop streaming on that second filehandle will
      stall.
      
      Fixes: 52117be6 ("media: vim2m: use cancel_delayed_work_sync instead of flush_schedule_work")
      Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      Cc: <stable@vger.kernel.org>      # for v4.20 and up
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      424b75b7
    • Qu Wenruo's avatar
      btrfs: Use real device structure to verify dev extent · be77686f
      Qu Wenruo authored
      [ Upstream commit 1b3922a8 ]
      
      [BUG]
      Linux v5.0-rc1 will fail fstests/btrfs/163 with the following kernel
      message:
      
        BTRFS error (device dm-6): dev extent devid 1 physical offset 13631488 len 8388608 is beyond device boundary 0
        BTRFS error (device dm-6): failed to verify dev extents against chunks: -117
        BTRFS error (device dm-6): open_ctree failed
      
      [CAUSE]
      Commit cf90d884 ("btrfs: Introduce mount time chunk <-> dev extent
      mapping check") introduced strict check on dev extents.
      
      We use btrfs_find_device() with dev uuid and fs uuid set to NULL, and
      only dependent on @devid to find the real device.
      
      For seed devices, we call clone_fs_devices() in open_seed_devices() to
      allow us search seed devices directly.
      
      However clone_fs_devices() just populates devices with devid and dev
      uuid, without populating other essential members, like disk_total_bytes.
      
      This makes any device returned by btrfs_find_device(fs_info, devid,
      NULL, NULL) is just a dummy, with 0 disk_total_bytes, and any dev
      extents on the seed device will not pass the device boundary check.
      
      [FIX]
      This patch will try to verify the device returned by btrfs_find_device()
      and if it's a dummy then re-search in seed devices.
      
      Fixes: cf90d884 ("btrfs: Introduce mount time chunk <-> dev extent mapping check")
      CC: stable@vger.kernel.org # 4.19+
      Reported-by: default avatarFilipe Manana <fdmanana@suse.com>
      Signed-off-by: default avatarQu Wenruo <wqu@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      be77686f
    • Qu Wenruo's avatar
      btrfs: volumes: Make sure no dev extent is beyond device boundary · a2790b99
      Qu Wenruo authored
      [ Upstream commit 05a37c48 ]
      
      Add extra dev extent end check against device boundary.
      Signed-off-by: default avatarQu Wenruo <wqu@suse.com>
      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>
      a2790b99
    • Ram Pai's avatar
      powerpc/pkeys: Fix handling of pkey state across fork() · cfbf227e
      Ram Pai authored
      [ Upstream commit 2cd4bd19 ]
      
      Protection key tracking information is not copied over to the
      mm_struct of the child during fork(). This can cause the child to
      erroneously allocate keys that were already allocated. Any allocated
      execute-only key is lost aswell.
      
      Add code; called by dup_mmap(), to copy the pkey state from parent to
      child explicitly.
      
      This problem was originally found by Dave Hansen on x86, which turns
      out to be a problem on powerpc aswell.
      
      Fixes: cf43d3b2 ("powerpc: Enable pkey subsystem")
      Cc: stable@vger.kernel.org # v4.16+
      Reviewed-by: default avatarThiago Jung Bauermann <bauerman@linux.ibm.com>
      Signed-off-by: default avatarRam Pai <linuxram@us.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      cfbf227e
    • Shivasharan S's avatar
      scsi: megaraid_sas: Use 63-bit DMA addressing · 2ad95be1
      Shivasharan S authored
      [ Upstream commit 894169db ]
      
      Although MegaRAID controllers support 64-bit DMA addressing, as per
      hardware design, DMA address with all 64-bits set
      (0xFFFFFFFF-FFFFFFFF) results in a firmware fault.
      
      Driver will set 63-bit DMA mask to ensure the above address will not be
      used.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarShivasharan S <shivasharan.srikanteshwara@broadcom.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      2ad95be1
    • Shivasharan S's avatar
      scsi: megaraid_sas: Add check for reset adapter bit · 3263f786
      Shivasharan S authored
      [ Upstream commit de93b40d ]
      
      For SAS3 and later controllers, FW sets the reset adapter bit indicating
      the driver to perform a controller reset.  Driver needs to check if this
      bit is set before doing a reset.  This reduces the driver probe failure
      time to 180seconds in case there is a faulty controller connected.
      Signed-off-by: default avatarSumit Saxena <sumit.saxena@broadcom.com>
      Signed-off-by: default avatarShivasharan S <shivasharan.srikanteshwara@broadcom.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3263f786
    • Shivasharan S's avatar
      scsi: megaraid_sas: Fix combined reply queue mode detection · dc4e3ec9
      Shivasharan S authored
      [ Upstream commit e29c3221 ]
      
      For Invader series, if FW supports more than 8 MSI-x vectors, driver needs
      to enable combined reply queue mode. For Ventura series, driver enables
      combined reply queue mode in case of more than 16 MSI-x vectors.
      Signed-off-by: default avatarSumit Saxena <sumit.saxena@broadcom.com>
      Signed-off-by: default avatarShivasharan S <shivasharan.srikanteshwara@broadcom.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      dc4e3ec9
    • Nikolay Borisov's avatar
      btrfs: Fix error handling in btrfs_cleanup_ordered_extents · eb124aaa
      Nikolay Borisov authored
      [ Upstream commit d1051d6e ]
      
      Running btrfs/124 in a loop hung up on me sporadically with the
      following call trace:
      
      	btrfs           D    0  5760   5324 0x00000000
      	Call Trace:
      	 ? __schedule+0x243/0x800
      	 schedule+0x33/0x90
      	 btrfs_start_ordered_extent+0x10c/0x1b0 [btrfs]
      	 ? wait_woken+0xa0/0xa0
      	 btrfs_wait_ordered_range+0xbb/0x100 [btrfs]
      	 btrfs_relocate_block_group+0x1ff/0x230 [btrfs]
      	 btrfs_relocate_chunk+0x49/0x100 [btrfs]
      	 btrfs_balance+0xbeb/0x1740 [btrfs]
      	 btrfs_ioctl_balance+0x2ee/0x380 [btrfs]
      	 btrfs_ioctl+0x1691/0x3110 [btrfs]
      	 ? lockdep_hardirqs_on+0xed/0x180
      	 ? __handle_mm_fault+0x8e7/0xfb0
      	 ? _raw_spin_unlock+0x24/0x30
      	 ? __handle_mm_fault+0x8e7/0xfb0
      	 ? do_vfs_ioctl+0xa5/0x6e0
      	 ? btrfs_ioctl_get_supported_features+0x30/0x30 [btrfs]
      	 do_vfs_ioctl+0xa5/0x6e0
      	 ? entry_SYSCALL_64_after_hwframe+0x3e/0xbe
      	 ksys_ioctl+0x3a/0x70
      	 __x64_sys_ioctl+0x16/0x20
      	 do_syscall_64+0x60/0x1b0
      	 entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      This happens because during page writeback it's valid for
      writepage_delalloc to instantiate a delalloc range which doesn't belong
      to the page currently being written back.
      
      The reason this case is valid is due to find_lock_delalloc_range
      returning any available range after the passed delalloc_start and
      ignoring whether the page under writeback is within that range.
      
      In turn ordered extents (OE) are always created for the returned range
      from find_lock_delalloc_range. If, however, a failure occurs while OE
      are being created then the clean up code in btrfs_cleanup_ordered_extents
      will be called.
      
      Unfortunately the code in btrfs_cleanup_ordered_extents doesn't consider
      the case of such 'foreign' range being processed and instead it always
      assumes that the range OE are created for belongs to the page. This
      leads to the first page of such foregin range to not be cleaned up since
      it's deliberately missed and skipped by the current cleaning up code.
      
      Fix this by correctly checking whether the current page belongs to the
      range being instantiated and if so adjsut the range parameters passed
      for cleaning up. If it doesn't, then just clean the whole OE range
      directly.
      
      Fixes: 52427260 ("btrfs: Handle delalloc error correctly to avoid ordered extent hang")
      CC: stable@vger.kernel.org # 4.14+
      Reviewed-by: default avatarJosef Bacik <josef@toxicpanda.com>
      Signed-off-by: default avatarNikolay Borisov <nborisov@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      eb124aaa
    • Nikolay Borisov's avatar
      btrfs: Remove extent_io_ops::fill_delalloc · 1669d1d2
      Nikolay Borisov authored
      [ Upstream commit 5eaad97a ]
      
      This callback is called only from writepage_delalloc which in turn is
      guaranteed to be called from the data page writeout path. In the end
      there is no reason to have the call to this function to be indrected via
      the extent_io_ops structure. This patch removes the callback definition,
      exports the function and calls it directly. No functional changes.
      Reviewed-by: default avatarJosef Bacik <josef@toxicpanda.com>
      Signed-off-by: default avatarNikolay Borisov <nborisov@suse.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      [ rename to btrfs_run_delalloc_range ]
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1669d1d2