commit 414510bc00a5fc954d8340c170083f518d09aa55
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Sep 6 10:21:01 2019 +0200

    Linux 4.14.142

commit e474227ad97a4d6885812777975b1e7386678277
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Sep 5 20:48:46 2019 +0200

    Revert "ASoC: Fail card instantiation if DAI format setup fails"
    
    This reverts commit a56c79efe4dc8ae560eb2c9a4b755d57c8c2e8f4 which is
    commit 40aa5383e393d72f6aa3943a4e7b1aae25a1e43b upstream.
    
    Mark Brown writes:
            I nacked this patch when Sasha posted it - it only improves
            diagnostics and might make systems that worked by accident break
            since it turns things into a hard failure, it won't make
            anything that didn't work previously work.
    
    Reported-by: Mark Brown <broonie@kernel.org>
    Cc: Ricard Wanderlof <ricardw@axis.com>
    Cc: Sasha Levin <sashal@kernel.org>
    Link: https://lore.kernel.org/lkml/20190904181027.GG4348@sirena.co.uk
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3a647417696217c5861a81ccfe5d2e6791d696ac
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Sep 4 12:27:18 2019 +0200

    x86/ptrace: fix up botched merge of spectrev1 fix
    
    I incorrectly merged commit 31a2fbb390fe ("x86/ptrace: Fix possible
    spectre-v1 in ptrace_get_debugreg()") when backporting it, as was
    graciously pointed out at
    https://grsecurity.net/teardown_of_a_failed_linux_lts_spectre_fix.php
    
    Resolve the upstream difference with the stable kernel merge to properly
    protect things.
    
    Reported-by: Brad Spengler <spender@grsecurity.net>
    Cc: Dianzhang Chen <dianzhangchen0@gmail.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: <bp@alien8.de>
    Cc: <hpa@zytor.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2b452eaa9857dae2051fef00cb77fe32ecb560ed
Author: Andrew Cooks <andrew.cooks@opengear.com>
Date:   Fri Aug 2 14:52:46 2019 +0200

    i2c: piix4: Fix port selection for AMD Family 16h Model 30h
    
    [ Upstream commit c7c06a1532f3fe106687ac82a13492c6a619ff1c ]
    
    Family 16h Model 30h SMBus controller needs the same port selection fix
    as described and fixed in commit 0fe16195f891 ("i2c: piix4: Fix SMBus port
    selection for AMD Family 17h chips")
    
    commit 6befa3fde65f ("i2c: piix4: Support alternative port selection
    register") also fixed the port selection for Hudson2, but unfortunately
    this is not the exact same device and the AMD naming and PCI Device IDs
    aren't particularly helpful here.
    
    The SMBus port selection register is common to the following Families
    and models, as documented in AMD's publicly available BIOS and Kernel
    Developer Guides:
    
     50742 - Family 15h Model 60h-6Fh (PCI_DEVICE_ID_AMD_KERNCZ_SMBUS)
     55072 - Family 15h Model 70h-7Fh (PCI_DEVICE_ID_AMD_KERNCZ_SMBUS)
     52740 - Family 16h Model 30h-3Fh (PCI_DEVICE_ID_AMD_HUDSON2_SMBUS)
    
    The Hudson2 PCI Device ID (PCI_DEVICE_ID_AMD_HUDSON2_SMBUS) is shared
    between Bolton FCH and Family 16h Model 30h, but the location of the
    SmBus0Sel port selection bits are different:
    
     51192 - Bolton Register Reference Guide
    
    We distinguish between Bolton and Family 16h Model 30h using the PCI
    Revision ID:
    
      Bolton is device 0x780b, revision 0x15
      Family 16h Model 30h is device 0x780b, revision 0x1F
      Family 15h Model 60h and 70h are both device 0x790b, revision 0x4A.
    
    The following additional public AMD BKDG documents were checked and do
    not share the same port selection register:
    
     42301 - Family 15h Model 00h-0Fh doesn't mention any
     42300 - Family 15h Model 10h-1Fh doesn't mention any
     49125 - Family 15h Model 30h-3Fh doesn't mention any
    
     48751 - Family 16h Model 00h-0Fh uses the previously supported
             index register SB800_PIIX4_PORT_IDX_ALT at 0x2e
    
    Signed-off-by: Andrew Cooks <andrew.cooks@opengear.com>
    Signed-off-by: Jean Delvare <jdelvare@suse.de>
    Cc: stable@vger.kernel.org [v4.6+]
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1a17912f93b896138f9d8b44aa11a4477a772823
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Mon Aug 12 18:04:36 2019 -0400

    NFS: Ensure O_DIRECT reports an error if the bytes read/written is 0
    
    [ Upstream commit eb2c50da9e256dbbb3ff27694440e4c1900cfef8 ]
    
    If the attempt to resend the I/O results in no bytes being read/written,
    we must ensure that we report the error.
    
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Fixes: 0a00b77b331a ("nfs: mirroring support for direct io")
    Cc: stable@vger.kernel.org # v3.20+
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e4ca24bdcea96cf5143afe197b649060b40d5fd8
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Wed Feb 13 10:39:39 2019 -0500

    NFS: Pass error information to the pgio error cleanup routine
    
    [ Upstream commit df3accb849607a86278a37c35e6b313635ccc48b ]
    
    Allow the caller to pass error information when cleaning up a failed
    I/O request so that we can conditionally take action to cancel the
    request altogether if the error turned out to be fatal.
    
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ae63bd38d03afe36ba0b6d0b6f6fea0157d79718
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Mon Aug 12 15:19:54 2019 -0400

    NFSv4/pnfs: Fix a page lock leak in nfs_pageio_resend()
    
    [ Upstream commit f4340e9314dbfadc48758945f85fc3b16612d06f ]
    
    If the attempt to resend the pages fails, we need to ensure that we
    clean up those pages that were not transmitted.
    
    Fixes: d600ad1f2bdb ("NFS41: pop some layoutget errors to application")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Cc: stable@vger.kernel.org # v4.5+
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fc26de15b5d840286dbd8dac7048897d0699f611
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Mon Feb 18 11:35:54 2019 -0500

    NFS: Clean up list moves of struct nfs_page
    
    [ Upstream commit 078b5fd92c4913dd367361db6c28568386077c89 ]
    
    In several places we're just moving the struct nfs_page from one list to
    another by first removing from the existing list, then adding to the new
    one.
    
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 712fc1c0d9758aa623b17c650912c77629691a30
Author: Marc Zyngier <maz@kernel.org>
Date:   Wed Aug 28 11:10:16 2019 +0100

    KVM: arm/arm64: vgic-v2: Handle SGI bits in GICD_I{S,C}PENDR0 as WI
    
    [ Upstream commit 82e40f558de566fdee214bec68096bbd5e64a6a4 ]
    
    A guest is not allowed to inject a SGI (or clear its pending state)
    by writing to GICD_ISPENDR0 (resp. GICD_ICPENDR0), as these bits are
    defined as WI (as per ARM IHI 0048B 4.3.7 and 4.3.8).
    
    Make sure we correctly emulate the architecture.
    
    Fixes: 96b298000db4 ("KVM: arm/arm64: vgic-new: Add PENDING registers handlers")
    Cc: stable@vger.kernel.org # 4.7+
    Reported-by: Andre Przywara <andre.przywara@arm.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit aafa2889b8fa98670e83d5f054e34ee1cbb44e96
Author: Heyi Guo <guoheyi@huawei.com>
Date:   Tue Aug 27 12:26:50 2019 +0100

    KVM: arm/arm64: vgic: Fix potential deadlock when ap_list is long
    
    [ Upstream commit d4a8061a7c5f7c27a2dc002ee4cb89b3e6637e44 ]
    
    If the ap_list is longer than 256 entries, merge_final() in list_sort()
    will call the comparison callback with the same element twice, causing
    a deadlock in vgic_irq_cmp().
    
    Fix it by returning early when irqa == irqb.
    
    Cc: stable@vger.kernel.org # 4.7+
    Fixes: 8e4447457965 ("KVM: arm/arm64: vgic-new: Add IRQ sorting")
    Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
    Signed-off-by: Heyi Guo <guoheyi@huawei.com>
    [maz: massaged commit log and patch, added Fixes and Cc-stable]
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 06ab420a84f0955360dca6c34faf2658d8cff1ce
Author: Alexey Kardashevskiy <aik@ozlabs.ru>
Date:   Tue Sep 3 16:16:27 2019 -0400

    KVM: PPC: Book3S: Fix incorrect guest-to-user-translation error handling
    
    [ Upstream commit ddfd151f3def9258397fcde7a372205a2d661903 ]
    
    H_PUT_TCE_INDIRECT handlers receive a page with up to 512 TCEs from
    a guest. Although we verify correctness of TCEs before we do anything
    with the existing tables, there is a small window when a check in
    kvmppc_tce_validate might pass and right after that the guest alters
    the page of TCEs, causing an early exit from the handler and leaving
    srcu_read_lock(&vcpu->kvm->srcu) (virtual mode) or lock_rmap(rmap)
    (real mode) locked.
    
    This fixes the bug by jumping to the common exit code with an appropriate
    unlock.
    
    Cc: stable@vger.kernel.org # v4.11+
    Fixes: 121f80ba68f1 ("KVM: PPC: VFIO: Add in-kernel acceleration for VFIO")
    Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
    Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d5054c17d9fe31596e4e7a6c008e9361f6e0f776
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Aug 1 09:30:33 2019 +0200

    mac80211: fix possible sta leak
    
    commit 5fd2f91ad483baffdbe798f8a08f1b41442d1e24 upstream.
    
    If TDLS station addition is rejected, the sta memory is leaked.
    Avoid this by moving the check before the allocation.
    
    Cc: stable@vger.kernel.org
    Fixes: 7ed5285396c2 ("mac80211: don't initiate TDLS connection if station is not associated to AP")
    Link: https://lore.kernel.org/r/20190801073033.7892-1-johannes@sipsolutions.net
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 44b39ce44fb10c2e3c3f5316aed29f0ac6c42719
Author: Hodaszi, Robert <Robert.Hodaszi@digi.com>
Date:   Fri Jun 14 13:16:01 2019 +0000

    Revert "cfg80211: fix processing world regdomain when non modular"
    
    commit 0d31d4dbf38412f5b8b11b4511d07b840eebe8cb upstream.
    
    This reverts commit 96cce12ff6e0 ("cfg80211: fix processing world
    regdomain when non modular").
    
    Re-triggering a reg_process_hint with the last request on all events,
    can make the regulatory domain fail in case of multiple WiFi modules. On
    slower boards (espacially with mdev), enumeration of the WiFi modules
    can end up in an intersected regulatory domain, and user cannot set it
    with 'iw reg set' anymore.
    
    This is happening, because:
    - 1st module enumerates, queues up a regulatory request
    - request gets processed by __reg_process_hint_driver():
      - checks if previous was set by CORE -> yes
        - checks if regulator domain changed -> yes, from '00' to e.g. 'US'
          -> sends request to the 'crda'
    - 2nd module enumerates, queues up a regulator request (which triggers
      the reg_todo() work)
    - reg_todo() -> reg_process_pending_hints() sees, that the last request
      is not processed yet, so it tries to process it again.
      __reg_process_hint driver() will run again, and:
      - checks if the last request's initiator was the core -> no, it was
        the driver (1st WiFi module)
      - checks, if the previous initiator was the driver -> yes
        - checks if the regulator domain changed -> yes, it was '00' (set by
          core, and crda call did not return yet), and should be changed to 'US'
    
    ------> __reg_process_hint_driver calls an intersect
    
    Besides, the reg_process_hint call with the last request is meaningless
    since the crda call has a timeout work. If that timeout expires, the
    first module's request will lost.
    
    Cc: stable@vger.kernel.org
    Fixes: 96cce12ff6e0 ("cfg80211: fix processing world regdomain when non modular")
    Signed-off-by: Robert Hodaszi <robert.hodaszi@digi.com>
    Link: https://lore.kernel.org/r/20190614131600.GA13897@a1-hr
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d204cf4f3169e33111f1b1e51000988108558fe9
Author: Gary R Hook <gary.hook@amd.com>
Date:   Mon Aug 19 22:23:27 2019 +0000

    crypto: ccp - Ignore unconfigured CCP device on suspend/resume
    
    commit 5871cd93692c8071fb9358daccb715b5081316ac upstream.
    
    If a CCP is unconfigured (e.g. there are no available queues) then
    there will be no data structures allocated for the device. Thus, we
    must check for validity of a pointer before trying to access structure
    members.
    
    Fixes: 720419f01832f ("crypto: ccp - Introduce the AMD Secure Processor device")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Gary R Hook <gary.hook@amd.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 573710846402a868f56fea58be26b313f28ccf07
Author: Nadav Amit <namit@vmware.com>
Date:   Tue Aug 20 13:26:38 2019 -0700

    VMCI: Release resource if the work is already queued
    
    commit ba03a9bbd17b149c373c0ea44017f35fc2cd0f28 upstream.
    
    Francois reported that VMware balloon gets stuck after a balloon reset,
    when the VMCI doorbell is removed. A similar error can occur when the
    balloon driver is removed with the following splat:
    
    [ 1088.622000] INFO: task modprobe:3565 blocked for more than 120 seconds.
    [ 1088.622035]       Tainted: G        W         5.2.0 #4
    [ 1088.622087] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    [ 1088.622205] modprobe        D    0  3565   1450 0x00000000
    [ 1088.622210] Call Trace:
    [ 1088.622246]  __schedule+0x2a8/0x690
    [ 1088.622248]  schedule+0x2d/0x90
    [ 1088.622250]  schedule_timeout+0x1d3/0x2f0
    [ 1088.622252]  wait_for_completion+0xba/0x140
    [ 1088.622320]  ? wake_up_q+0x80/0x80
    [ 1088.622370]  vmci_resource_remove+0xb9/0xc0 [vmw_vmci]
    [ 1088.622373]  vmci_doorbell_destroy+0x9e/0xd0 [vmw_vmci]
    [ 1088.622379]  vmballoon_vmci_cleanup+0x6e/0xf0 [vmw_balloon]
    [ 1088.622381]  vmballoon_exit+0x18/0xcc8 [vmw_balloon]
    [ 1088.622394]  __x64_sys_delete_module+0x146/0x280
    [ 1088.622408]  do_syscall_64+0x5a/0x130
    [ 1088.622410]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [ 1088.622415] RIP: 0033:0x7f54f62791b7
    [ 1088.622421] Code: Bad RIP value.
    [ 1088.622421] RSP: 002b:00007fff2a949008 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
    [ 1088.622426] RAX: ffffffffffffffda RBX: 000055dff8b55d00 RCX: 00007f54f62791b7
    [ 1088.622426] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 000055dff8b55d68
    [ 1088.622427] RBP: 000055dff8b55d00 R08: 00007fff2a947fb1 R09: 0000000000000000
    [ 1088.622427] R10: 00007f54f62f5cc0 R11: 0000000000000206 R12: 000055dff8b55d68
    [ 1088.622428] R13: 0000000000000001 R14: 000055dff8b55d68 R15: 00007fff2a94a3f0
    
    The cause for the bug is that when the "delayed" doorbell is invoked, it
    takes a reference on the doorbell entry and schedules work that is
    supposed to run the appropriate code and drop the doorbell entry
    reference. The code ignores the fact that if the work is already queued,
    it will not be scheduled to run one more time. As a result one of the
    references would not be dropped. When the code waits for the reference
    to get to zero, during balloon reset or module removal, it gets stuck.
    
    Fix it. Drop the reference if schedule_work() indicates that the work is
    already queued.
    
    Note that this bug got more apparent (or apparent at all) due to
    commit ce664331b248 ("vmw_balloon: VMCI_DOORBELL_SET does not check status").
    
    Fixes: 83e2ec765be03 ("VMCI: doorbell implementation.")
    Reported-by: Francois Rigault <rigault.francois@gmail.com>
    Cc: Jorgen Hansen <jhansen@vmware.com>
    Cc: Adit Ranadive <aditr@vmware.com>
    Cc: Alexios Zavras <alexios.zavras@intel.com>
    Cc: Vishnu DASA <vdasa@vmware.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Nadav Amit <namit@vmware.com>
    Reviewed-by: Vishnu Dasa <vdasa@vmware.com>
    Link: https://lore.kernel.org/r/20190820202638.49003-1-namit@vmware.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fdd176296f35c8810bb45b8a8c1e5df93f01fbd4
Author: Xiong Zhang <xiong.y.zhang@intel.com>
Date:   Tue Aug 20 13:46:17 2019 +0800

    drm/i915: Don't deballoon unused ggtt drm_mm_node in linux guest
    
    commit 0a3dfbb5cd9033752639ef33e319c2f2863c713a upstream.
    
    The following call trace may exist in linux guest dmesg when guest i915
    driver is unloaded.
    [   90.776610] [drm:vgt_deballoon_space.isra.0 [i915]] deballoon space: range [0x0 - 0x0] 0 KiB.
    [   90.776621] BUG: unable to handle kernel NULL pointer dereference at 00000000000000c0
    [   90.776691] IP: drm_mm_remove_node+0x4d/0x320 [drm]
    [   90.776718] PGD 800000012c7d0067 P4D 800000012c7d0067 PUD 138e4c067 PMD 0
    [   90.777091] task: ffff9adab60f2f00 task.stack: ffffaf39c0fe0000
    [   90.777142] RIP: 0010:drm_mm_remove_node+0x4d/0x320 [drm]
    [   90.777573] Call Trace:
    [   90.777653]  intel_vgt_deballoon+0x4c/0x60 [i915]
    [   90.777729]  i915_ggtt_cleanup_hw+0x121/0x190 [i915]
    [   90.777792]  i915_driver_unload+0x145/0x180 [i915]
    [   90.777856]  i915_pci_remove+0x15/0x20 [i915]
    [   90.777890]  pci_device_remove+0x3b/0xc0
    [   90.777916]  device_release_driver_internal+0x157/0x220
    [   90.777945]  driver_detach+0x39/0x70
    [   90.777967]  bus_remove_driver+0x51/0xd0
    [   90.777990]  pci_unregister_driver+0x23/0x90
    [   90.778019]  SyS_delete_module+0x1da/0x240
    [   90.778045]  entry_SYSCALL_64_fastpath+0x24/0x87
    [   90.778072] RIP: 0033:0x7f34312af067
    [   90.778092] RSP: 002b:00007ffdea3da0d8 EFLAGS: 00000206
    [   90.778297] RIP: drm_mm_remove_node+0x4d/0x320 [drm] RSP: ffffaf39c0fe3dc0
    [   90.778344] ---[ end trace f4b1bc8305fc59dd ]---
    
    Four drm_mm_node are used to reserve guest ggtt space, but some of them
    may be skipped and not initialised due to space constraints in
    intel_vgt_balloon(). If drm_mm_remove_node() is called with
    uninitialized drm_mm_node, the above call trace occurs.
    
    This patch check drm_mm_node's validity before calling
    drm_mm_remove_node().
    
    Fixes: ff8f797557c7("drm/i915: return the correct usable aperture size under gvt environment")
    Cc: stable@vger.kernel.org
    Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
    Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com>
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Link: https://patchwork.freedesktop.org/patch/msgid/1566279978-9659-1-git-send-email-xiong.y.zhang@intel.com
    (cherry picked from commit 4776f3529d6b1e47f02904ad1d264d25ea22b27b)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 64ba640e1a08f9070b73753400c4a55c520884d8
Author: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Date:   Wed Aug 21 10:49:55 2019 +0300

    intel_th: pci: Add Tiger Lake support
    
    commit 9c78255fdde45c6b9a1ee30f652f7b34c727f5c7 upstream.
    
    This adds support for the Trace Hub in Tiger Lake PCH.
    
    Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: stable@vger.kernel.org # v4.14+
    Link: https://lore.kernel.org/r/20190821074955.3925-5-alexander.shishkin@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bdc19c85fef3131c78f083108dc37468da1d0392
Author: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Date:   Wed Aug 21 10:49:54 2019 +0300

    intel_th: pci: Add support for another Lewisburg PCH
    
    commit 164eb56e3b64f3a816238d410c9efec7567a82ef upstream.
    
    Add support for the Trace Hub in another Lewisburg PCH.
    
    Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: stable@vger.kernel.org # v4.14+
    Link: https://lore.kernel.org/r/20190821074955.3925-4-alexander.shishkin@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9a0b3fbf6bfc484c34a8762625388d5d81d0d9d4
Author: Ding Xiang <dingxiang@cmss.chinamobile.com>
Date:   Wed Aug 21 10:49:52 2019 +0300

    stm class: Fix a double free of stm_source_device
    
    commit 961b6ffe0e2c403b09a8efe4a2e986b3c415391a upstream.
    
    In the error path of stm_source_register_device(), the kfree is
    unnecessary, as the put_device() before it ends up calling
    stm_source_device_release() to free stm_source_device, leading to
    a double free at the outer kfree() call. Remove it.
    
    Signed-off-by: Ding Xiang <dingxiang@cmss.chinamobile.com>
    Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Fixes: 7bd1d4093c2fa ("stm class: Introduce an abstraction for System Trace Module devices")
    Link: https://lore.kernel.org/linux-arm-kernel/1563354988-23826-1-git-send-email-dingxiang@cmss.chinamobile.com/
    Cc: stable@vger.kernel.org # v4.4+
    Link: https://lore.kernel.org/r/20190821074955.3925-2-alexander.shishkin@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 514b98a686c519454a60c26e674689dbb656e73e
Author: Ulf Hansson <ulf.hansson@linaro.org>
Date:   Tue Aug 27 10:10:43 2019 +0200

    mmc: core: Fix init of SD cards reporting an invalid VDD range
    
    commit 72741084d903e65e121c27bd29494d941729d4a1 upstream.
    
    The OCR register defines the supported range of VDD voltages for SD cards.
    However, it has turned out that some SD cards reports an invalid voltage
    range, for example having bit7 set.
    
    When a host supports MMC_CAP2_FULL_PWR_CYCLE and some of the voltages from
    the invalid VDD range, this triggers the core to run a power cycle of the
    card to try to initialize it at the lowest common supported voltage.
    Obviously this fails, since the card can't support it.
    
    Let's fix this problem, by clearing invalid bits from the read OCR register
    for SD cards, before proceeding with the VDD voltage negotiation.
    
    Cc: stable@vger.kernel.org
    Reported-by: Philip Langdale <philipl@overt.org>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Reviewed-by: Philip Langdale <philipl@overt.org>
    Tested-by: Philip Langdale <philipl@overt.org>
    Tested-by: Manuel Presnitz <mail@mpy.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bafd1f6c9c7ffced5fa20b7bc04cbd179c563374
Author: Eugen Hristev <eugen.hristev@microchip.com>
Date:   Thu Aug 8 08:35:40 2019 +0000

    mmc: sdhci-of-at91: add quirk for broken HS200
    
    commit 7871aa60ae0086fe4626abdf5ed13eeddf306c61 upstream.
    
    HS200 is not implemented in the driver, but the controller claims it
    through caps. Remove it via a quirk, to make sure the mmc core do not try
    to enable HS200, as it causes the eMMC initialization to fail.
    
    Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
    Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Fixes: bb5f8ea4d514 ("mmc: sdhci-of-at91: introduce driver for the Atmel SDMMC")
    Cc: stable@vger.kernel.org # v4.4+
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b72e73cb47a48cb2460c00b77b6760849afee256
Author: Sebastian Mayr <me@sam.st>
Date:   Sun Jul 28 17:26:17 2019 +0200

    uprobes/x86: Fix detection of 32-bit user mode
    
    [ Upstream commit 9212ec7d8357ea630031e89d0d399c761421c83b ]
    
    32-bit processes running on a 64-bit kernel are not always detected
    correctly, causing the process to crash when uretprobes are installed.
    
    The reason for the crash is that in_ia32_syscall() is used to determine the
    process's mode, which only works correctly when called from a syscall.
    
    In the case of uretprobes, however, the function is called from a exception
    and always returns 'false' on a 64-bit kernel. In consequence this leads to
    corruption of the process's return address.
    
    Fix this by using user_64bit_mode() instead of in_ia32_syscall(), which
    is correct in any situation.
    
    [ tglx: Add a comment and the following historical info ]
    
    This should have been detected by the rename which happened in commit
    
      abfb9498ee13 ("x86/entry: Rename is_{ia32,x32}_task() to in_{ia32,x32}_syscall()")
    
    which states in the changelog:
    
        The is_ia32_task()/is_x32_task() function names are a big misnomer: they
        suggests that the compat-ness of a system call is a task property, which
        is not true, the compatness of a system call purely depends on how it
        was invoked through the system call layer.
        .....
    
    and then it went and blindly renamed every call site.
    
    Sadly enough this was already mentioned here:
    
       8faaed1b9f50 ("uprobes/x86: Introduce sizeof_long(), cleanup adjust_ret_addr() and
    arch_uretprobe_hijack_return_addr()")
    
    where the changelog says:
    
        TODO: is_ia32_task() is not what we actually want, TS_COMPAT does
        not necessarily mean 32bit. Fortunately syscall-like insns can't be
        probed so it actually works, but it would be better to rename and
        use is_ia32_frame().
    
    and goes all the way back to:
    
        0326f5a94dde ("uprobes/core: Handle breakpoint and singlestep exceptions")
    
    Oh well. 7+ years until someone actually tried a uretprobe on a 32bit
    process on a 64bit kernel....
    
    Fixes: 0326f5a94dde ("uprobes/core: Handle breakpoint and singlestep exceptions")
    Signed-off-by: Sebastian Mayr <me@sam.st>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Dmitry Safonov <dsafonov@virtuozzo.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190728152617.7308-1-me@sam.st
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2bf4cd128fec2bee4ace778b107adc3820bf18b9
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Wed Aug 28 01:34:50 2019 +0800

    USB: storage: ums-realtek: Whitelist auto-delink support
    
    commit 1902a01e2bcc3abd7c9a18dc05e78c7ab4a53c54 upstream.
    
    Auto-delink requires writing special registers to ums-realtek devices.
    Unconditionally enable auto-delink may break newer devices.
    
    So only enable auto-delink by default for the original three IDs,
    0x0138, 0x0158 and 0x0159.
    
    Realtek is working on a patch to properly support auto-delink for other
    IDs.
    
    BugLink: https://bugs.launchpad.net/bugs/1838886
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20190827173450.13572-2-kai.heng.feng@canonical.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 611836fcab119d894df63fc3db936da66428ec56
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Wed Aug 28 01:34:49 2019 +0800

    USB: storage: ums-realtek: Update module parameter description for auto_delink_en
    
    commit f6445b6b2f2bb1745080af4a0926049e8bca2617 upstream.
    
    The option named "auto_delink_en" is a bit misleading, as setting it to
    false doesn't really disable auto-delink but let auto-delink be firmware
    controlled.
    
    Update the description to reflect the real usage of this parameter.
    
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20190827173450.13572-1-kai.heng.feng@canonical.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b2f9ecf5d2c0d1aadead91b25bb11b205487772
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Tue Aug 27 14:51:12 2019 +0200

    usb: host: xhci: rcar: Fix typo in compatible string matching
    
    commit 636bd02a7ba9025ff851d0cfb92768c8fa865859 upstream.
    
    It's spelled "renesas", not "renensas".
    
    Due to this typo, RZ/G1M and RZ/G1N were not covered by the check.
    
    Fixes: 2dc240a3308b ("usb: host: xhci: rcar: retire use of xhci_plat_type_is()")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Cc: stable <stable@vger.kernel.org>
    Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Link: https://lore.kernel.org/r/20190827125112.12192-1-geert+renesas@glider.be
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8e7ca9eecdc9e8afd3700e64685d1817234b5b71
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date:   Tue Aug 27 12:51:50 2019 +0900

    usb: host: ohci: fix a race condition between shutdown and irq
    
    commit a349b95d7ca0cea71be4a7dac29830703de7eb62 upstream.
    
    This patch fixes an issue that the following error is
    possible to happen when ohci hardware causes an interruption
    and the system is shutting down at the same time.
    
    [   34.851754] usb 2-1: USB disconnect, device number 2
    [   35.166658] irq 156: nobody cared (try booting with the "irqpoll" option)
    [   35.173445] CPU: 0 PID: 22 Comm: kworker/0:1 Not tainted 5.3.0-rc5 #85
    [   35.179964] Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT)
    [   35.187886] Workqueue: usb_hub_wq hub_event
    [   35.192063] Call trace:
    [   35.194509]  dump_backtrace+0x0/0x150
    [   35.198165]  show_stack+0x14/0x20
    [   35.201475]  dump_stack+0xa0/0xc4
    [   35.204785]  __report_bad_irq+0x34/0xe8
    [   35.208614]  note_interrupt+0x2cc/0x318
    [   35.212446]  handle_irq_event_percpu+0x5c/0x88
    [   35.216883]  handle_irq_event+0x48/0x78
    [   35.220712]  handle_fasteoi_irq+0xb4/0x188
    [   35.224802]  generic_handle_irq+0x24/0x38
    [   35.228804]  __handle_domain_irq+0x5c/0xb0
    [   35.232893]  gic_handle_irq+0x58/0xa8
    [   35.236548]  el1_irq+0xb8/0x180
    [   35.239681]  __do_softirq+0x94/0x23c
    [   35.243253]  irq_exit+0xd0/0xd8
    [   35.246387]  __handle_domain_irq+0x60/0xb0
    [   35.250475]  gic_handle_irq+0x58/0xa8
    [   35.254130]  el1_irq+0xb8/0x180
    [   35.257268]  kernfs_find_ns+0x5c/0x120
    [   35.261010]  kernfs_find_and_get_ns+0x3c/0x60
    [   35.265361]  sysfs_unmerge_group+0x20/0x68
    [   35.269454]  dpm_sysfs_remove+0x2c/0x68
    [   35.273284]  device_del+0x80/0x370
    [   35.276683]  hid_destroy_device+0x28/0x60
    [   35.280686]  usbhid_disconnect+0x4c/0x80
    [   35.284602]  usb_unbind_interface+0x6c/0x268
    [   35.288867]  device_release_driver_internal+0xe4/0x1b0
    [   35.293998]  device_release_driver+0x14/0x20
    [   35.298261]  bus_remove_device+0x110/0x128
    [   35.302350]  device_del+0x148/0x370
    [   35.305832]  usb_disable_device+0x8c/0x1d0
    [   35.309921]  usb_disconnect+0xc8/0x2d0
    [   35.313663]  hub_event+0x6e0/0x1128
    [   35.317146]  process_one_work+0x1e0/0x320
    [   35.321148]  worker_thread+0x40/0x450
    [   35.324805]  kthread+0x124/0x128
    [   35.328027]  ret_from_fork+0x10/0x18
    [   35.331594] handlers:
    [   35.333862] [<0000000079300c1d>] usb_hcd_irq
    [   35.338126] [<0000000079300c1d>] usb_hcd_irq
    [   35.342389] Disabling IRQ #156
    
    ohci_shutdown() disables all the interrupt and rh_state is set to
    OHCI_RH_HALTED. In other hand, ohci_irq() is possible to enable
    OHCI_INTR_SF and OHCI_INTR_MIE on ohci_irq(). Note that OHCI_INTR_SF
    is possible to be set by start_ed_unlink() which is called:
     ohci_irq()
      -> process_done_list()
       -> takeback_td()
        -> start_ed_unlink()
    
    So, ohci_irq() has the following condition, the issue happens by
    &ohci->regs->intrenable = OHCI_INTR_MIE | OHCI_INTR_SF and
    ohci->rh_state = OHCI_RH_HALTED:
    
            /* interrupt for some other device? */
            if (ints == 0 || unlikely(ohci->rh_state == OHCI_RH_HALTED))
                    return IRQ_NOTMINE;
    
    To fix the issue, ohci_shutdown() holds the spin lock while disabling
    the interruption and changing the rh_state flag to prevent reenable
    the OHCI_INTR_MIE unexpectedly. Note that io_watchdog_func() also
    calls the ohci_shutdown() and it already held the spin lock, so that
    the patch makes a new function as _ohci_shutdown().
    
    This patch is inspired by a Renesas R-Car Gen3 BSP patch
    from Tho Vu.
    
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Cc: stable <stable@vger.kernel.org>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Link: https://lore.kernel.org/r/1566877910-6020-1-git-send-email-yoshihiro.shimoda.uh@renesas.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2590118de92bb3cb7dcedc633f853681d6aac7ef
Author: Peter Chen <peter.chen@nxp.com>
Date:   Tue Aug 20 02:07:58 2019 +0000

    usb: chipidea: udc: don't do hardware access if gadget has stopped
    
    commit cbe85c88ce80fb92956a0793518d415864dcead8 upstream.
    
    After _gadget_stop_activity is executed, we can consider the hardware
    operation for gadget has finished, and the udc can be stopped and enter
    low power mode. So, any later hardware operations (from usb_ep_ops APIs
    or usb_gadget_ops APIs) should be considered invalid, any deinitializatons
    has been covered at _gadget_stop_activity.
    
    I meet this problem when I plug out usb cable from PC using mass_storage
    gadget, my callstack like: vbus interrupt->.vbus_session->
    composite_disconnect ->pm_runtime_put_sync(&_gadget->dev),
    the composite_disconnect will call fsg_disable, but fsg_disable calls
    usb_ep_disable using async way, there are register accesses for
    usb_ep_disable. So sometimes, I get system hang due to visit register
    without clock, sometimes not.
    
    The Linux Kernel USB maintainer Alan Stern suggests this kinds of solution.
    See: http://marc.info/?l=linux-usb&m=138541769810983&w=2.
    
    Cc: <stable@vger.kernel.org> #v4.9+
    Signed-off-by: Peter Chen <peter.chen@nxp.com>
    Link: https://lore.kernel.org/r/20190820020503.27080-2-peter.chen@nxp.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f5b3d76a68fde6b148768a088f96c758aebb9753
Author: Oliver Neukum <oneukum@suse.com>
Date:   Tue Aug 27 12:34:36 2019 +0200

    USB: cdc-wdm: fix race between write and disconnect due to flag abuse
    
    commit 1426bd2c9f7e3126e2678e7469dca9fd9fc6dd3e upstream.
    
    In case of a disconnect an ongoing flush() has to be made fail.
    Nevertheless we cannot be sure that any pending URB has already
    finished, so although they will never succeed, they still must
    not be touched.
    The clean solution for this is to check for WDM_IN_USE
    and WDM_DISCONNECTED in flush(). There is no point in ever
    clearing WDM_IN_USE, as no further writes make sense.
    
    The issue is as old as the driver.
    
    Fixes: afba937e540c9 ("USB: CDC WDM driver")
    Reported-by: syzbot+d232cca6ec42c2edb3fc@syzkaller.appspotmail.com
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20190827103436.21143-1-oneukum@suse.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e2f523b4cf1e6ef0d5bc1b6fd06451bb4fd84c65
Author: Henk van der Laan <opensource@henkvdlaan.com>
Date:   Fri Aug 16 22:08:47 2019 +0200

    usb-storage: Add new JMS567 revision to unusual_devs
    
    commit 08d676d1685c2a29e4d0e1b0242324e564d4589e upstream.
    
    Revision 0x0117 suffers from an identical issue to earlier revisions,
    therefore it should be added to the quirks list.
    
    Signed-off-by: Henk van der Laan <opensource@henkvdlaan.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20190816200847.21366-1-opensource@henkvdlaan.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 04497185f67dd571121e1a44b252229493406558
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Fri Aug 30 16:30:01 2019 -0400

    ftrace: Check for empty hash and comment the race with registering probes
    
    commit 372e0d01da71c84dcecf7028598a33813b0d5256 upstream.
    
    The race between adding a function probe and reading the probes that exist
    is very subtle. It needs a comment. Also, the issue can also happen if the
    probe has has the EMPTY_HASH as its func_hash.
    
    Cc: stable@vger.kernel.org
    Fixes: 7b60f3d876156 ("ftrace: Dynamically create the probe ftrace_ops for the trace_array")
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ab9a7cf6500391b32f77302883e4a59539e4eee7
Author: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Date:   Thu Jul 4 20:04:42 2019 +0530

    ftrace: Check for successful allocation of hash
    
    commit 5b0022dd32b7c2e15edf1827ba80aa1407edf9ff upstream.
    
    In register_ftrace_function_probe(), we are not checking the return
    value of alloc_and_copy_ftrace_hash(). The subsequent call to
    ftrace_match_records() may end up dereferencing the same. Add a check to
    ensure this doesn't happen.
    
    Link: http://lkml.kernel.org/r/26e92574f25ad23e7cafa3cf5f7a819de1832cbe.1562249521.git.naveen.n.rao@linux.vnet.ibm.com
    
    Cc: stable@vger.kernel.org
    Fixes: 1ec3a81a0cf42 ("ftrace: Have each function probe use its own ftrace_ops")
    Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fccb7937380eb58fd2810603bc4ab37e58d5b921
Author: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Date:   Thu Jul 4 20:04:41 2019 +0530

    ftrace: Fix NULL pointer dereference in t_probe_next()
    
    commit 7bd46644ea0f6021dc396a39a8bfd3a58f6f1f9f upstream.
    
    LTP testsuite on powerpc results in the below crash:
    
      Unable to handle kernel paging request for data at address 0x00000000
      Faulting instruction address: 0xc00000000029d800
      Oops: Kernel access of bad area, sig: 11 [#1]
      LE SMP NR_CPUS=2048 NUMA PowerNV
      ...
      CPU: 68 PID: 96584 Comm: cat Kdump: loaded Tainted: G        W
      NIP:  c00000000029d800 LR: c00000000029dac4 CTR: c0000000001e6ad0
      REGS: c0002017fae8ba10 TRAP: 0300   Tainted: G        W
      MSR:  9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE>  CR: 28022422  XER: 20040000
      CFAR: c00000000029d90c DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 0
      ...
      NIP [c00000000029d800] t_probe_next+0x60/0x180
      LR [c00000000029dac4] t_mod_start+0x1a4/0x1f0
      Call Trace:
      [c0002017fae8bc90] [c000000000cdbc40] _cond_resched+0x10/0xb0 (unreliable)
      [c0002017fae8bce0] [c0000000002a15b0] t_start+0xf0/0x1c0
      [c0002017fae8bd30] [c0000000004ec2b4] seq_read+0x184/0x640
      [c0002017fae8bdd0] [c0000000004a57bc] sys_read+0x10c/0x300
      [c0002017fae8be30] [c00000000000b388] system_call+0x5c/0x70
    
    The test (ftrace_set_ftrace_filter.sh) is part of ftrace stress tests
    and the crash happens when the test does 'cat
    $TRACING_PATH/set_ftrace_filter'.
    
    The address points to the second line below, in t_probe_next(), where
    filter_hash is dereferenced:
      hash = iter->probe->ops.func_hash->filter_hash;
      size = 1 << hash->size_bits;
    
    This happens due to a race with register_ftrace_function_probe(). A new
    ftrace_func_probe is created and added into the func_probes list in
    trace_array under ftrace_lock. However, before initializing the filter,
    we drop ftrace_lock, and re-acquire it after acquiring regex_lock. If
    another process is trying to read set_ftrace_filter, it will be able to
    acquire ftrace_lock during this window and it will end up seeing a NULL
    filter_hash.
    
    Fix this by just checking for a NULL filter_hash in t_probe_next(). If
    the filter_hash is NULL, then this probe is just being added and we can
    simply return from here.
    
    Link: http://lkml.kernel.org/r/05e021f757625cbbb006fad41380323dbe4e3b43.1562249521.git.naveen.n.rao@linux.vnet.ibm.com
    
    Cc: stable@vger.kernel.org
    Fixes: 7b60f3d876156 ("ftrace: Dynamically create the probe ftrace_ops for the trace_array")
    Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8f86b0bf18f7278631200a7837df33d706856503
Author: Bandan Das <bsd@redhat.com>
Date:   Mon Aug 26 06:15:13 2019 -0400

    x86/apic: Include the LDR when clearing out APIC registers
    
    commit 558682b5291937a70748d36fd9ba757fb25b99ae upstream.
    
    Although APIC initialization will typically clear out the LDR before
    setting it, the APIC cleanup code should reset the LDR.
    
    This was discovered with a 32-bit KVM guest jumping into a kdump
    kernel. The stale bits in the LDR triggered a bug in the KVM APIC
    implementation which caused the destination mapping for VCPUs to be
    corrupted.
    
    Note that this isn't intended to paper over the KVM APIC bug. The kernel
    has to clear the LDR when resetting the APIC registers except when X2APIC
    is enabled.
    
    This lacks a Fixes tag because missing to clear LDR goes way back into pre
    git history.
    
    [ tglx: Made x2apic_enabled a function call as required ]
    
    Signed-off-by: Bandan Das <bsd@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190826101513.5080-3-bsd@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit de8ff18c1ced087cf0d6272c315c017ddd5cbc7a
Author: Bandan Das <bsd@redhat.com>
Date:   Mon Aug 26 06:15:12 2019 -0400

    x86/apic: Do not initialize LDR and DFR for bigsmp
    
    commit bae3a8d3308ee69a7dbdf145911b18dfda8ade0d upstream.
    
    Legacy apic init uses bigsmp for smp systems with 8 and more CPUs. The
    bigsmp APIC implementation uses physical destination mode, but it
    nevertheless initializes LDR and DFR. The LDR even ends up incorrectly with
    multiple bit being set.
    
    This does not cause a functional problem because LDR and DFR are ignored
    when physical destination mode is active, but it triggered a problem on a
    32-bit KVM guest which jumps into a kdump kernel.
    
    The multiple bits set unearthed a bug in the KVM APIC implementation. The
    code which creates the logical destination map for VCPUs ignores the
    disabled state of the APIC and ends up overwriting an existing valid entry
    and as a result, APIC calibration hangs in the guest during kdump
    initialization.
    
    Remove the bogus LDR/DFR initialization.
    
    This is not intended to work around the KVM APIC bug. The LDR/DFR
    ininitalization is wrong on its own.
    
    The issue goes back into the pre git history. The fixes tag is the commit
    in the bitkeeper import which introduced bigsmp support in 2003.
    
      git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
    
    Fixes: db7b9e9f26b8 ("[PATCH] Clustered APIC setup for >8 CPU systems")
    Suggested-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Bandan Das <bsd@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190826101513.5080-2-bsd@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 27060d456fda9d1859cf4630034511f3eb6cbe34
Author: Sean Christopherson <sean.j.christopherson@intel.com>
Date:   Fri Aug 23 13:55:44 2019 -0700

    KVM: x86: Don't update RIP or do single-step on faulting emulation
    
    commit 75ee23b30dc712d80d2421a9a547e7ab6e379b44 upstream.
    
    Don't advance RIP or inject a single-step #DB if emulation signals a
    fault.  This logic applies to all state updates that are conditional on
    clean retirement of the emulation instruction, e.g. updating RFLAGS was
    previously handled by commit 38827dbd3fb85 ("KVM: x86: Do not update
    EFLAGS on faulting emulation").
    
    Not advancing RIP is likely a nop, i.e. ctxt->eip isn't updated with
    ctxt->_eip until emulation "retires" anyways.  Skipping #DB injection
    fixes a bug reported by Andy Lutomirski where a #UD on SYSCALL due to
    invalid state with EFLAGS.TF=1 would loop indefinitely due to emulation
    overwriting the #UD with #DB and thus restarting the bad SYSCALL over
    and over.
    
    Cc: Nadav Amit <nadav.amit@gmail.com>
    Cc: stable@vger.kernel.org
    Reported-by: Andy Lutomirski <luto@kernel.org>
    Fixes: 663f4c61b803 ("KVM: x86: handle singlestep during emulation")
    Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
    Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 879c573333f47d95f96494c13e44e7536c16f3ba
Author: Radim Krcmar <rkrcmar@redhat.com>
Date:   Tue Aug 13 23:37:37 2019 -0400

    kvm: x86: skip populating logical dest map if apic is not sw enabled
    
    commit b14c876b994f208b6b95c222056e1deb0a45de0e upstream.
    
    recalculate_apic_map does not santize ldr and it's possible that
    multiple bits are set. In that case, a previous valid entry
    can potentially be overwritten by an invalid one.
    
    This condition is hit when booting a 32 bit, >8 CPU, RHEL6 guest and then
    triggering a crash to boot a kdump kernel. This is the sequence of
    events:
    1. Linux boots in bigsmp mode and enables PhysFlat, however, it still
    writes to the LDR which probably will never be used.
    2. However, when booting into kdump, the stale LDR values remain as
    they are not cleared by the guest and there isn't a apic reset.
    3. kdump boots with 1 cpu, and uses Logical Destination Mode but the
    logical map has been overwritten and points to an inactive vcpu.
    
    Signed-off-by: Radim Krcmar <rkrcmar@redhat.com>
    Signed-off-by: Bandan Das <bsd@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ed2d2a172c5f4ab32bdf92e4e5a9f033a75f7b6b
Author: Takashi Iwai <tiwai@suse.de>
Date:   Sun Aug 25 09:21:44 2019 +0200

    ALSA: seq: Fix potential concurrent access to the deleted pool
    
    commit 75545304eba6a3d282f923b96a466dc25a81e359 upstream.
    
    The input pool of a client might be deleted via the resize ioctl, the
    the access to it should be covered by the proper locks.  Currently the
    only missing place is the call in snd_seq_ioctl_get_client_pool(), and
    this patch papers over it.
    
    Reported-by: syzbot+4a75454b9ca2777f35c7@syzkaller.appspotmail.com
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0cb49ca2dc8bf9ee50d1b2ceb42a86bb6c8dc15d
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Aug 21 20:00:02 2019 +0200

    ALSA: line6: Fix memory leak at line6_init_pcm() error path
    
    commit 1bc8d18c75fef3b478dbdfef722aae09e2a9fde7 upstream.
    
    I forgot to release the allocated object at the early error path in
    line6_init_pcm().  For addressing it, slightly shuffle the code so
    that the PCM destructor (pcm->private_free) is assigned properly
    before all error paths.
    
    Fixes: 3450121997ce ("ALSA: line6: Fix write on zero-sized buffer")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bf147673368d1e60d3e94a7df517c848cda0ba33
Author: Andrew Morton <akpm@linux-foundation.org>
Date:   Fri Aug 30 16:04:35 2019 -0700

    mm/zsmalloc.c: fix build when CONFIG_COMPACTION=n
    
    commit 441e254cd40dc03beec3c650ce6ce6074bc6517f upstream.
    
    Fixes: 701d678599d0c1 ("mm/zsmalloc.c: fix race condition in zs_destroy_pool")
    Link: http://lkml.kernel.org/r/201908251039.5oSbEEUT%25lkp@intel.com
    Reported-by: kbuild test robot <lkp@intel.com>
    Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
    Cc: Henry Burns <henrywolfeburns@gmail.com>
    Cc: Minchan Kim <minchan@kernel.org>
    Cc: Shakeel Butt <shakeelb@google.com>
    Cc: Jonathan Adams <jwadams@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 564e2b87491c615a95d9a200fb4ad267e403db4d
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Aug 16 21:26:22 2019 -0700

    tcp: make sure EPOLLOUT wont be missed
    
    [ Upstream commit ef8d8ccdc216f797e66cb4a1372f5c4c285ce1e4 ]
    
    As Jason Baron explained in commit 790ba4566c1a ("tcp: set SOCK_NOSPACE
    under memory pressure"), it is crucial we properly set SOCK_NOSPACE
    when needed.
    
    However, Jason patch had a bug, because the 'nonblocking' status
    as far as sk_stream_wait_memory() is concerned is governed
    by MSG_DONTWAIT flag passed at sendmsg() time :
    
        long timeo = sock_sndtimeo(sk, flags & MSG_DONTWAIT);
    
    So it is very possible that tcp sendmsg() calls sk_stream_wait_memory(),
    and that sk_stream_wait_memory() returns -EAGAIN with SOCK_NOSPACE
    cleared, if sk->sk_sndtimeo has been set to a small (but not zero)
    value.
    
    This patch removes the 'noblock' variable since we must always
    set SOCK_NOSPACE if -EAGAIN is returned.
    
    It also renames the do_nonblock label since we might reach this
    code path even if we were in blocking mode.
    
    Fixes: 790ba4566c1a ("tcp: set SOCK_NOSPACE under memory pressure")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Jason Baron <jbaron@akamai.com>
    Reported-by: Vladimir Rutsky  <rutsky@google.com>
    Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Acked-by: Jason Baron <jbaron@akamai.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d29c08a2ad6cf1f6b2904a3ee62464394bd8adb
Author: Jason Baron <jbaron@akamai.com>
Date:   Mon Aug 19 14:36:01 2019 -0400

    net/smc: make sure EPOLLOUT is raised
    
    [ Upstream commit 4651d1802f7063e4d8c0bcad957f46ece0c04024 ]
    
    Currently, we are only explicitly setting SOCK_NOSPACE on a write timeout
    for non-blocking sockets. Epoll() edge-trigger mode relies on SOCK_NOSPACE
    being set when -EAGAIN is returned to ensure that EPOLLOUT is raised.
    Expand the setting of SOCK_NOSPACE to non-blocking sockets as well that can
    use SO_SNDTIMEO to adjust their write timeout. This mirrors the behavior
    that Eric Dumazet introduced for tcp sockets.
    
    Signed-off-by: Jason Baron <jbaron@akamai.com>
    Cc: Eric Dumazet <edumazet@google.com>
    Cc: Ursula Braun <ubraun@linux.ibm.com>
    Cc: Karsten Graul <kgraul@linux.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 96b0e80b6d5fb88c4f5b1e9d5224f2aa56395926
Author: Hui Peng <benquike@gmail.com>
Date:   Tue Aug 13 22:34:04 2019 -0400

    ALSA: usb-audio: Fix an OOB bug in parse_audio_mixer_unit
    
    commit daac07156b330b18eb5071aec4b3ddca1c377f2c upstream.
    
    The `uac_mixer_unit_descriptor` shown as below is read from the
    device side. In `parse_audio_mixer_unit`, `baSourceID` field is
    accessed from index 0 to `bNrInPins` - 1, the current implementation
    assumes that descriptor is always valid (the length  of descriptor
    is no shorter than 5 + `bNrInPins`). If a descriptor read from
    the device side is invalid, it may trigger out-of-bound memory
    access.
    
    ```
    struct uac_mixer_unit_descriptor {
            __u8 bLength;
            __u8 bDescriptorType;
            __u8 bDescriptorSubtype;
            __u8 bUnitID;
            __u8 bNrInPins;
            __u8 baSourceID[];
    }
    ```
    
    This patch fixes the bug by add a sanity check on the length of
    the descriptor.
    
    Reported-by: Hui Peng <benquike@gmail.com>
    Reported-by: Mathias Payer <mathias.payer@nebelwelt.net>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Hui Peng <benquike@gmail.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6e1a602dfd51709538fc371d053708934909e3ba
Author: Hui Peng <benquike@gmail.com>
Date:   Thu Aug 15 00:31:34 2019 -0400

    ALSA: usb-audio: Fix a stack buffer overflow bug in check_input_term
    
    commit 19bce474c45be69a284ecee660aa12d8f1e88f18 upstream.
    
    `check_input_term` recursively calls itself with input from
    device side (e.g., uac_input_terminal_descriptor.bCSourceID)
    as argument (id). In `check_input_term`, if `check_input_term`
    is called with the same `id` argument as the caller, it triggers
    endless recursive call, resulting kernel space stack overflow.
    
    This patch fixes the bug by adding a bitmap to `struct mixer_build`
    to keep track of the checked ids and stop the execution if some id
    has been checked (similar to how parse_audio_unit handles unitid
    argument).
    
    Reported-by: Hui Peng <benquike@gmail.com>
    Reported-by: Mathias Payer <mathias.payer@nebelwelt.net>
    Signed-off-by: Hui Peng <benquike@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e5df4baea324d3c21dc48f86ad24e5d9aed67c65
Author: Tim Froidcoeur <tim.froidcoeur@tessares.net>
Date:   Sat Aug 24 08:03:51 2019 +0200

    tcp: fix tcp_rtx_queue_tail in case of empty retransmit queue
    
    Commit 8c3088f895a0 ("tcp: be more careful in tcp_fragment()")
    triggers following stack trace:
    
    [25244.848046] kernel BUG at ./include/linux/skbuff.h:1406!
    [25244.859335] RIP: 0010:skb_queue_prev+0x9/0xc
    [25244.888167] Call Trace:
    [25244.889182]  <IRQ>
    [25244.890001]  tcp_fragment+0x9c/0x2cf
    [25244.891295]  tcp_write_xmit+0x68f/0x988
    [25244.892732]  __tcp_push_pending_frames+0x3b/0xa0
    [25244.894347]  tcp_data_snd_check+0x2a/0xc8
    [25244.895775]  tcp_rcv_established+0x2a8/0x30d
    [25244.897282]  tcp_v4_do_rcv+0xb2/0x158
    [25244.898666]  tcp_v4_rcv+0x692/0x956
    [25244.899959]  ip_local_deliver_finish+0xeb/0x169
    [25244.901547]  __netif_receive_skb_core+0x51c/0x582
    [25244.903193]  ? inet_gro_receive+0x239/0x247
    [25244.904756]  netif_receive_skb_internal+0xab/0xc6
    [25244.906395]  napi_gro_receive+0x8a/0xc0
    [25244.907760]  receive_buf+0x9a1/0x9cd
    [25244.909160]  ? load_balance+0x17a/0x7b7
    [25244.910536]  ? vring_unmap_one+0x18/0x61
    [25244.911932]  ? detach_buf+0x60/0xfa
    [25244.913234]  virtnet_poll+0x128/0x1e1
    [25244.914607]  net_rx_action+0x12a/0x2b1
    [25244.915953]  __do_softirq+0x11c/0x26b
    [25244.917269]  ? handle_irq_event+0x44/0x56
    [25244.918695]  irq_exit+0x61/0xa0
    [25244.919947]  do_IRQ+0x9d/0xbb
    [25244.921065]  common_interrupt+0x85/0x85
    [25244.922479]  </IRQ>
    
    tcp_rtx_queue_tail() (called by tcp_fragment()) can call
    tcp_write_queue_prev() on the first packet in the queue, which will trigger
    the BUG in tcp_write_queue_prev(), because there is no previous packet.
    
    This happens when the retransmit queue is empty, for example in case of a
    zero window.
    
    Commit 8c3088f895a0 ("tcp: be more careful in tcp_fragment()") was not a
    simple cherry-pick of the original one from master (b617158dc096)
    because there is a specific TCP rtx queue only since v4.15. For more
    details, please see the commit message of b617158dc096 ("tcp: be more
    careful in tcp_fragment()").
    
    The BUG() is hit due to the specific code added to versions older than
    v4.15. The comment in skb_queue_prev() (include/linux/skbuff.h:1406),
    just before the BUG_ON() somehow suggests to add a check before using
    it, what Tim did.
    
    In master, this code path causing the issue will not be taken because
    the implementation of tcp_rtx_queue_tail() is different:
    
        tcp_fragment() → tcp_rtx_queue_tail() → tcp_write_queue_prev() →
    skb_queue_prev() → BUG_ON()
    
    Fixes: 8c3088f895a0 ("tcp: be more careful in tcp_fragment()")
    Signed-off-by: Tim Froidcoeur <tim.froidcoeur@tessares.net>
    Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
    Reviewed-by: Christoph Paasch <cpaasch@apple.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0d9b9e89ae5a1aa20141fe41c3709149113c4b02
Author: Jyri Sarha <jsarha@ti.com>
Date:   Wed Dec 12 19:26:32 2018 +0200

    drm/tilcdc: Register cpufreq notifier after we have initialized crtc
    
    [ Upstream commit 432973fd3a20102840d5f7e61af9f1a03c217a4c ]
    
    Register cpufreq notifier after we have initialized the crtc and
    unregister it before we remove the ctrc. Receiving a cpufreq notify
    without crtc causes a crash.
    
    Reported-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
    Signed-off-by: Jyri Sarha <jsarha@ti.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 99ab76dd3cc573315b7f4c287592ebd371daed38
Author: Pedro Sousa <sousa@synopsys.com>
Date:   Thu Apr 18 21:13:34 2019 +0200

    scsi: ufs: Fix RX_TERMINATION_FORCE_ENABLE define value
    
    [ Upstream commit ebcb8f8508c5edf428f52525cec74d28edea7bcb ]
    
    Fix RX_TERMINATION_FORCE_ENABLE define value from 0x0089 to 0x00A9
    according to MIPI Alliance MPHY specification.
    
    Fixes: e785060ea3a1 ("ufs: definitions for phy interface")
    Signed-off-by: Pedro Sousa <sousa@synopsys.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d262e6a81729dcf6f6100bb6b5ae87b19050d5d4
Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
Date:   Mon Jun 10 16:57:38 2019 +0300

    drm/bridge: tfp410: fix memleak in get_modes()
    
    [ Upstream commit c08f99c39083ab55a9c93b3e93cef48711294dad ]
    
    We don't free the edid blob allocated by the call to drm_get_edid(),
    causing a memleak. Fix this by calling kfree(edid) at the end of the
    get_modes().
    
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190610135739.6077-1-tomi.valkeinen@ti.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3c48e5715813f851207f496a014ebf7a41673386
Author: Stefan Wahren <wahrenst@gmx.net>
Date:   Wed May 15 19:14:18 2019 +0200

    watchdog: bcm2835_wdt: Fix module autoload
    
    [ Upstream commit 215e06f0d18d5d653d6ea269e4dfc684854d48bf ]
    
    The commit 5e6acc3e678e ("bcm2835-pm: Move bcm2835-watchdog's DT probe
    to an MFD.") broke module autoloading on Raspberry Pi. So add a
    module alias this fix this.
    
    Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3f3da9ef2a37c8c848f645429a5b15c0f96d02af
Author: Adrian Vladu <avladu@cloudbasesolutions.com>
Date:   Mon May 6 16:50:58 2019 +0000

    tools: hv: fix KVP and VSS daemons exit code
    
    [ Upstream commit b0995156071b0ff29a5902964a9dc8cfad6f81c0 ]
    
    HyperV KVP and VSS daemons should exit with 0 when the '--help'
    or '-h' flags are used.
    
    Signed-off-by: Adrian Vladu <avladu@cloudbasesolutions.com>
    
    Cc: "K. Y. Srinivasan" <kys@microsoft.com>
    Cc: Haiyang Zhang <haiyangz@microsoft.com>
    Cc: Stephen Hemminger <sthemmin@microsoft.com>
    Cc: Sasha Levin <sashal@kernel.org>
    Cc: Alessandro Pilotti <apilotti@cloudbasesolutions.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8e32498a18f8238d71ccd5c0b0585f8867b4f8a2
Author: Hans Ulli Kroll <ulli.kroll@googlemail.com>
Date:   Sat Aug 10 17:04:58 2019 +0200

    usb: host: fotg2: restart hcd after port reset
    
    [ Upstream commit 777758888ffe59ef754cc39ab2f275dc277732f4 ]
    
    On the Gemini SoC the FOTG2 stalls after port reset
    so restart the HCD after each port reset.
    
    Signed-off-by: Hans Ulli Kroll <ulli.kroll@googlemail.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Link: https://lore.kernel.org/r/20190810150458.817-1-linus.walleij@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5938612e6f461ee30ab5ccc416dd609ae1b74b95
Author: Y.C. Chen <yc_chen@aspeedtech.com>
Date:   Wed Apr 11 09:27:39 2018 +0800

    drm/ast: Fixed reboot test may cause system hanged
    
    [ Upstream commit 05b439711f6ff8700e8660f97a1179650778b9cb ]
    
    There is another thread still access standard VGA I/O while loading drm driver.
    Disable standard VGA I/O decode to avoid this issue.
    
    Signed-off-by: Y.C. Chen <yc_chen@aspeedtech.com>
    Reviewed-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/1523410059-18415-1-git-send-email-yc_chen@aspeedtech.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1605b1503b95c6c6e866bd390b69e88ea5da219b
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Thu Aug 8 21:54:17 2019 +0200

    i2c: emev2: avoid race when unregistering slave client
    
    [ Upstream commit d7437fc0d8291181debe032671a289b6bd93f46f ]
    
    After we disabled interrupts, there might still be an active one
    running. Sync before clearing the pointer to the slave device.
    
    Fixes: c31d0a00021d ("i2c: emev2: add slave support")
    Reported-by: Krzysztof Adamski <krzysztof.adamski@nokia.com>
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Reviewed-by: Krzysztof Adamski <krzysztof.adamski@nokia.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 72cbbaa9079ca55456084b6bf35df53b5add0467
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Thu Aug 8 21:39:10 2019 +0200

    i2c: rcar: avoid race when unregistering slave client
    
    [ Upstream commit 7b814d852af6944657c2961039f404c4490771c0 ]
    
    After we disabled interrupts, there might still be an active one
    running. Sync before clearing the pointer to the slave device.
    
    Fixes: de20d1857dd6 ("i2c: rcar: add slave support")
    Reported-by: Krzysztof Adamski <krzysztof.adamski@nokia.com>
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Reviewed-by: Krzysztof Adamski <krzysztof.adamski@nokia.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 82d31c50aff90f2c7be4ac2a644368223971f431
Author: Wenwen Wang <wenwen@cs.uga.edu>
Date:   Sun Aug 11 12:23:22 2019 -0500

    xen/blkback: fix memory leaks
    
    [ Upstream commit ae78ca3cf3d9e9f914bfcd0bc5c389ff18b9c2e0 ]
    
    In read_per_ring_refs(), after 'req' and related memory regions are
    allocated, xen_blkif_map() is invoked to map the shared frame, irq, and
    etc. However, if this mapping process fails, no cleanup is performed,
    leading to memory leaks. To fix this issue, invoke the cleanup before
    returning the error.
    
    Acked-by: Roger Pau Monné <roger.pau@citrix.com>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c946f1306aaf9f0727b4e194d1b37b94ec292592
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date:   Fri Jul 26 14:59:04 2019 +1000

    usb: gadget: mass_storage: Fix races between fsg_disable and fsg_set_alt
    
    [ Upstream commit 4a56a478a525d6427be90753451c40e1327caa1a ]
    
    If fsg_disable() and fsg_set_alt() are called too closely to each
    other (for example due to a quick reset/reconnect), what can happen
    is that fsg_set_alt sets common->new_fsg from an interrupt while
    handle_exception is trying to process the config change caused by
    fsg_disable():
    
            fsg_disable()
            ...
            handle_exception()
                    sets state back to FSG_STATE_NORMAL
                    hasn't yet called do_set_interface()
                    or is inside it.
    
     ---> interrupt
            fsg_set_alt
                    sets common->new_fsg
                    queues a new FSG_STATE_CONFIG_CHANGE
     <---
    
    Now, the first handle_exception can "see" the updated
    new_fsg, treats it as if it was a fsg_set_alt() response,
    call usb_composite_setup_continue() etc...
    
    But then, the thread sees the second FSG_STATE_CONFIG_CHANGE,
    and goes back down the same path, wipes and reattaches a now
    active fsg, and .. calls usb_composite_setup_continue() which
    at this point is wrong.
    
    Not only we get a backtrace, but I suspect the second set_interface
    wrecks some state causing the host to get upset in my case.
    
    This fixes it by replacing "new_fsg" by a "state argument" (same
    principle) which is set in the same lock section as the state
    update, and retrieved similarly.
    
    That way, there is never any discrepancy between the dequeued
    state and the observed value of it. We keep the ability to have
    the latest reconfig operation take precedence, but we guarantee
    that once "dequeued" the argument (new_fsg) will not be clobbered
    by any new event.
    
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e95debe397986f68d38c6075b7ef89bf81316b5b
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date:   Fri Jul 26 14:59:03 2019 +1000

    usb: gadget: composite: Clear "suspended" on reset/disconnect
    
    [ Upstream commit 602fda17c7356bb7ae98467d93549057481d11dd ]
    
    In some cases, one can get out of suspend with a reset or
    a disconnect followed by a reconnect. Previously we would
    leave a stale suspended flag set.
    
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b441242b28637c7e37973d8b82dbbee30d872df2
Author: Robin Murphy <robin.murphy@arm.com>
Date:   Mon Jul 29 17:46:00 2019 +0100

    iommu/dma: Handle SG length overflow better
    
    [ Upstream commit ab2cbeb0ed301a9f0460078e91b09f39958212ef ]
    
    Since scatterlist dimensions are all unsigned ints, in the relatively
    rare cases where a device's max_segment_size is set to UINT_MAX, then
    the "cur_len + s_length <= max_len" check in __finalise_sg() will always
    return true. As a result, the corner case of such a device mapping an
    excessively large scatterlist which is mergeable to or beyond a total
    length of 4GB can lead to overflow and a bogus truncated dma_length in
    the resulting segment.
    
    As we already assume that any single segment must be no longer than
    max_len to begin with, this can easily be addressed by reshuffling the
    comparison.
    
    Fixes: 809eac54cdd6 ("iommu/dma: Implement scatterlist segment merging")
    Reported-by: Nicolin Chen <nicoleotsuka@gmail.com>
    Tested-by: Nicolin Chen <nicoleotsuka@gmail.com>
    Signed-off-by: Robin Murphy <robin.murphy@arm.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4455bacd144e5df9ffc7f4c5874310f92f355b31
Author: zhengbin <zhengbin13@huawei.com>
Date:   Mon Jul 8 20:42:18 2019 +0800

    auxdisplay: panel: need to delete scan_timer when misc_register fails in panel_attach
    
    [ Upstream commit b33d567560c1aadf3033290d74d4fd67af47aa61 ]
    
    In panel_attach, if misc_register fails, we need to delete scan_timer,
    which was setup in keypad_init->init_scan_timer.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: zhengbin <zhengbin13@huawei.com>
    Signed-off-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ac439a219aeb592e813d83b96ecda23328e1a817
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Jul 12 11:13:30 2019 +0200

    dmaengine: ste_dma40: fix unneeded variable warning
    
    [ Upstream commit 5d6fb560729a5d5554e23db8d00eb57cd0021083 ]
    
    clang-9 points out that there are two variables that depending on the
    configuration may only be used in an ARRAY_SIZE() expression but not
    referenced:
    
    drivers/dma/ste_dma40.c:145:12: error: variable 'd40_backup_regs' is not needed and will not be emitted [-Werror,-Wunneeded-internal-declaration]
    static u32 d40_backup_regs[] = {
               ^
    drivers/dma/ste_dma40.c:214:12: error: variable 'd40_backup_regs_chan' is not needed and will not be emitted [-Werror,-Wunneeded-internal-declaration]
    static u32 d40_backup_regs_chan[] = {
    
    Mark these __maybe_unused to shut up the warning.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Link: https://lore.kernel.org/r/20190712091357.744515-1-arnd@arndb.de
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>