commit ddef1e8e3f6eb26034833b7255e3fa584d54a230
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Oct 29 09:17:49 2019 +0100

    Linux 4.14.151

commit 1db19d6805d9dc5c79f8a19dddde324dbf0a33f9
Author: Greg KH <gregkh@linuxfoundation.org>
Date:   Tue Oct 1 18:56:11 2019 +0200

    RDMA/cxgb4: Do not dma memory off of the stack
    
    commit 3840c5b78803b2b6cc1ff820100a74a092c40cbb upstream.
    
    Nicolas pointed out that the cxgb4 driver is doing dma off of the stack,
    which is generally considered a very bad thing.  On some architectures it
    could be a security problem, but odds are none of them actually run this
    driver, so it's just a "normal" bug.
    
    Resolve this by allocating the memory for a message off of the heap
    instead of the stack.  kmalloc() always will give us a proper memory
    location that DMA will work correctly from.
    
    Link: https://lore.kernel.org/r/20191001165611.GA3542072@kroah.com
    Reported-by: Nicolas Waisman <nico@semmle.com>
    Tested-by: Potnuri Bharat Teja <bharat@chelsio.com>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b425d011e83d220d3be0a19561d6b33d11358fa5
Author: Jim Mattson <jmattson@google.com>
Date:   Wed May 9 16:56:05 2018 -0400

    kvm: vmx: Basic APIC virtualization controls have three settings
    
    commit 8d860bbeedef97fe981d28fa7b71d77f3b29563f upstream.
    
    Previously, we toggled between SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE
    and SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES, depending on whether or
    not the EXTD bit was set in MSR_IA32_APICBASE. However, if the local
    APIC is disabled, we should not set either of these APIC
    virtualization control bits.
    
    Signed-off-by: Jim Mattson <jmattson@google.com>
    Signed-off-by: Krish Sadhukhan <krish.sadhukhan@oracle.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Cc: "Jitindar SIngh, Suraj" <surajjs@amazon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f5ae861d9ad8c7834a255ceaee39fc9cb0e56163
Author: Junaid Shahid <junaids@google.com>
Date:   Thu Apr 26 13:09:50 2018 -0700

    kvm: apic: Flush TLB after APIC mode/address change if VPIDs are in use
    
    commit a468f2dbf921d02f5107378501693137a812999b upstream.
    
    Currently, KVM flushes the TLB after a change to the APIC access page
    address or the APIC mode when EPT mode is enabled. However, even in
    shadow paging mode, a TLB flush is needed if VPIDs are being used, as
    specified in the Intel SDM Section 29.4.5.
    
    So replace vmx_flush_tlb_ept_only() with vmx_flush_tlb(), which will
    flush if either EPT or VPIDs are in use.
    
    Signed-off-by: Junaid Shahid <junaids@google.com>
    Reviewed-by: Jim Mattson <jmattson@google.com>
    Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
    Cc: "Jitindar SIngh, Suraj" <surajjs@amazon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 060065111a71922ab2126ed46f44668d53510665
Author: Jim Mattson <jmattson@google.com>
Date:   Wed May 9 16:56:04 2018 -0400

    kvm: vmx: Introduce lapic_mode enumeration
    
    commit 588716494258899389206fa50426e78cc9df89b9 upstream.
    
    The local APIC can be in one of three modes: disabled, xAPIC or
    x2APIC. (A fourth mode, "invalid," is included for completeness.)
    
    Using the new enumeration can make some of the APIC mode logic easier
    to read. In kvm_set_apic_base, for instance, it is clear that one
    cannot transition directly from x2APIC mode to xAPIC mode or directly
    from APIC disabled to x2APIC mode.
    
    Signed-off-by: Jim Mattson <jmattson@google.com>
    Signed-off-by: Krish Sadhukhan <krish.sadhukhan@oracle.com>
    [Check invalid bits even if msr_info->host_initiated.  Reported by
     Wanpeng Li. - Paolo]
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Cc: "Jitindar SIngh, Suraj" <surajjs@amazon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9e223bdc1cf7da5c98f852225e347574e669950f
Author: Wanpeng Li <wanpeng.li@hotmail.com>
Date:   Tue Dec 12 17:33:03 2017 -0800

    KVM: X86: introduce invalidate_gpa argument to tlb flush
    
    commit c2ba05ccfde2f069a66c0462e5b5ef8a517dcc9c upstream.
    
    Introduce a new bool invalidate_gpa argument to kvm_x86_ops->tlb_flush,
    it will be used by later patches to just flush guest tlb.
    
    For VMX, this will use INVVPID instead of INVEPT, which will invalidate
    combined mappings while keeping guest-physical mappings.
    
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Radim Krčmář <rkrcmar@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: "Jitindar SIngh, Suraj" <surajjs@amazon.com>
    Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 47ed959d13a4a2154e0f537f85af88ab14a8dcd4
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Mon Oct 14 13:25:00 2019 +0200

    PCI: PM: Fix pci_power_up()
    
    commit 45144d42f299455911cc29366656c7324a3a7c97 upstream.
    
    There is an arbitrary difference between the system resume and
    runtime resume code paths for PCI devices regarding the delay to
    apply when switching the devices from D3cold to D0.
    
    Namely, pci_restore_standard_config() used in the runtime resume
    code path calls pci_set_power_state() which in turn invokes
    __pci_start_power_transition() to power up the device through the
    platform firmware and that function applies the transition delay
    (as per PCI Express Base Specification Revision 2.0, Section 6.6.1).
    However, pci_pm_default_resume_early() used in the system resume
    code path calls pci_power_up() which doesn't apply the delay at
    all and that causes issues to occur during resume from
    suspend-to-idle on some systems where the delay is required.
    
    Since there is no reason for that difference to exist, modify
    pci_power_up() to follow pci_set_power_state() more closely and
    invoke __pci_start_power_transition() from there to call the
    platform firmware to power up the device (in case that's necessary).
    
    Fixes: db288c9c5f9d ("PCI / PM: restore the original behavior of pci_set_power_state()")
    Reported-by: Daniel Drake <drake@endlessm.com>
    Tested-by: Daniel Drake <drake@endlessm.com>
    Link: https://lore.kernel.org/linux-pm/CAD8Lp44TYxrMgPLkHCqF9hv6smEurMXvmmvmtyFhZ6Q4SE+dig@mail.gmail.com/T/#m21be74af263c6a34f36e0fc5c77c5449d9406925
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Acked-by: Bjorn Helgaas <bhelgaas@google.com>
    Cc: 3.10+ <stable@vger.kernel.org> # 3.10+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aae4447e36bc4926a86d0bd8ca7f7a4cb2b1182d
Author: Juergen Gross <jgross@suse.com>
Date:   Fri Oct 18 09:45:49 2019 +0200

    xen/netback: fix error path of xenvif_connect_data()
    
    commit 3d5c1a037d37392a6859afbde49be5ba6a70a6b3 upstream.
    
    xenvif_connect_data() calls module_put() in case of error. This is
    wrong as there is no related module_get().
    
    Remove the superfluous module_put().
    
    Fixes: 279f438e36c0a7 ("xen-netback: Don't destroy the netdev until the vif is shut down")
    Cc: <stable@vger.kernel.org> # 3.12
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Reviewed-by: Paul Durrant <paul@xen.org>
    Reviewed-by: Wei Liu <wei.liu@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5f466713989250938624afa79dc33bae20920700
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Wed Oct 9 01:29:10 2019 +0200

    cpufreq: Avoid cpufreq_suspend() deadlock on system shutdown
    
    commit 65650b35133ff20f0c9ef0abd5c3c66dbce3ae57 upstream.
    
    It is incorrect to set the cpufreq syscore shutdown callback pointer
    to cpufreq_suspend(), because that function cannot be run in the
    syscore stage of system shutdown for two reasons: (a) it may attempt
    to carry out actions depending on devices that have already been shut
    down at that point and (b) the RCU synchronization carried out by it
    may not be able to make progress then.
    
    The latter issue has been present since commit 45975c7d21a1 ("rcu:
    Define RCU-sched API in terms of RCU for Tree RCU PREEMPT builds"),
    but the former one has been there since commit 90de2a4aa9f3 ("cpufreq:
    suspend cpufreq governors on shutdown") regardless.
    
    Fix that by dropping cpufreq_syscore_ops altogether and making
    device_shutdown() call cpufreq_suspend() directly before shutting
    down devices, which is along the lines of what system-wide power
    management does.
    
    Fixes: 45975c7d21a1 ("rcu: Define RCU-sched API in terms of RCU for Tree RCU PREEMPT builds")
    Fixes: 90de2a4aa9f3 ("cpufreq: suspend cpufreq governors on shutdown")
    Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Cc: 4.0+ <stable@vger.kernel.org> # 4.0+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0d70b3a0e34719e9e31d0ab39dc3820f815a78b1
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Oct 5 13:21:01 2019 +0200

    memstick: jmb38x_ms: Fix an error handling path in 'jmb38x_ms_probe()'
    
    commit 28c9fac09ab0147158db0baeec630407a5e9b892 upstream.
    
    If 'jmb38x_ms_count_slots()' returns 0, we must undo the previous
    'pci_request_regions()' call.
    
    Goto 'err_out_int' to fix it.
    
    Fixes: 60fdd931d577 ("memstick: add support for JMicron jmb38x MemoryStick host controller")
    Cc: stable@vger.kernel.org
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e06e89fe9a2e6ef5394f28685d07ae4dd3e6ce66
Author: Qu Wenruo <wqu@suse.com>
Date:   Thu Oct 10 10:39:26 2019 +0800

    btrfs: block-group: Fix a memory leak due to missing btrfs_put_block_group()
    
    commit 4b654acdae850f48b8250b9a578a4eaa518c7a6f upstream.
    
    In btrfs_read_block_groups(), if we have an invalid block group which
    has mixed type (DATA|METADATA) while the fs doesn't have MIXED_GROUPS
    feature, we error out without freeing the block group cache.
    
    This patch will add the missing btrfs_put_block_group() to prevent
    memory leak.
    
    Note for stable backports: the file to patch in versions <= 5.3 is
    fs/btrfs/extent-tree.c
    
    Fixes: 49303381f19a ("Btrfs: bail out if block group has different mixed flag")
    CC: stable@vger.kernel.org # 4.9+
    Reviewed-by: Anand Jain <anand.jain@oracle.com>
    Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
    Signed-off-by: Qu Wenruo <wqu@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2b9a35e61261c6fa9d15967a8fec9c36efc6ceab
Author: Patrick Williams <alpawi@amazon.com>
Date:   Tue Oct 1 10:51:38 2019 -0500

    pinctrl: armada-37xx: swap polarity on LED group
    
    commit b835d6953009dc350d61402a854b5a7178d8c615 upstream.
    
    The configuration registers for the LED group have inverted
    polarity, which puts the GPIO into open-drain state when used in
    GPIO mode.  Switch to '0' for GPIO and '1' for LED modes.
    
    Fixes: 87466ccd9401 ("pinctrl: armada-37xx: Add pin controller support for Armada 37xx")
    Signed-off-by: Patrick Williams <alpawi@amazon.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20191001155154.99710-1-alpawi@amazon.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 135230fc32ebad7186ed49da8845db1d61e5881f
Author: Patrick Williams <alpawi@amazon.com>
Date:   Tue Oct 1 10:46:31 2019 -0500

    pinctrl: armada-37xx: fix control of pins 32 and up
    
    commit 20504fa1d2ffd5d03cdd9dc9c9dd4ed4579b97ef upstream.
    
    The 37xx configuration registers are only 32 bits long, so
    pins 32-35 spill over into the next register.  The calculation
    for the register address was done, but the bitmask was not, so
    any configuration to pin 32 or above resulted in a bitmask that
    overflowed and performed no action.
    
    Fix the register / offset calculation to also adjust the offset.
    
    Fixes: 5715092a458c ("pinctrl: armada-37xx: Add gpio support")
    Signed-off-by: Patrick Williams <alpawi@amazon.com>
    Acked-by: Gregory CLEMENT <gregory.clement@bootlin.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20191001154634.96165-1-alpawi@amazon.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 74825dbefb8db903818b96dc1c7e767c3d6d295b
Author: Steve Wahl <steve.wahl@hpe.com>
Date:   Tue Sep 24 16:03:55 2019 -0500

    x86/boot/64: Make level2_kernel_pgt pages invalid outside kernel area
    
    commit 2aa85f246c181b1fa89f27e8e20c5636426be624 upstream.
    
    Our hardware (UV aka Superdome Flex) has address ranges marked
    reserved by the BIOS. Access to these ranges is caught as an error,
    causing the BIOS to halt the system.
    
    Initial page tables mapped a large range of physical addresses that
    were not checked against the list of BIOS reserved addresses, and
    sometimes included reserved addresses in part of the mapped range.
    Including the reserved range in the map allowed processor speculative
    accesses to the reserved range, triggering a BIOS halt.
    
    Used early in booting, the page table level2_kernel_pgt addresses 1
    GiB divided into 2 MiB pages, and it was set up to linearly map a full
     1 GiB of physical addresses that included the physical address range
    of the kernel image, as chosen by KASLR.  But this also included a
    large range of unused addresses on either side of the kernel image.
    And unlike the kernel image's physical address range, this extra
    mapped space was not checked against the BIOS tables of usable RAM
    addresses.  So there were times when the addresses chosen by KASLR
    would result in processor accessible mappings of BIOS reserved
    physical addresses.
    
    The kernel code did not directly access any of this extra mapped
    space, but having it mapped allowed the processor to issue speculative
    accesses into reserved memory, causing system halts.
    
    This was encountered somewhat rarely on a normal system boot, and much
    more often when starting the crash kernel if "crashkernel=512M,high"
    was specified on the command line (this heavily restricts the physical
    address of the crash kernel, in our case usually within 1 GiB of
    reserved space).
    
    The solution is to invalidate the pages of this table outside the kernel
    image's space before the page table is activated. It fixes this problem
    on our hardware.
    
     [ bp: Touchups. ]
    
    Signed-off-by: Steve Wahl <steve.wahl@hpe.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
    Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Cc: Baoquan He <bhe@redhat.com>
    Cc: Brijesh Singh <brijesh.singh@amd.com>
    Cc: dimitri.sivanich@hpe.com
    Cc: Feng Tang <feng.tang@intel.com>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jordan Borgner <mail@jordan-borgner.de>
    Cc: Juergen Gross <jgross@suse.com>
    Cc: mike.travis@hpe.com
    Cc: russ.anderson@hpe.com
    Cc: stable@vger.kernel.org
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: x86-ml <x86@kernel.org>
    Cc: Zhenzhong Duan <zhenzhong.duan@oracle.com>
    Link: https://lkml.kernel.org/r/9c011ee51b081534a7a15065b1681d200298b530.1569358539.git.steve.wahl@hpe.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 34b3ce218aebc0025f8fa07d4b718c90ef630991
Author: Roberto Bergantinos Corpas <rbergant@redhat.com>
Date:   Mon Oct 14 10:59:23 2019 +0200

    CIFS: avoid using MID 0xFFFF
    
    commit 03d9a9fe3f3aec508e485dd3dcfa1e99933b4bdb upstream.
    
    According to MS-CIFS specification MID 0xFFFF should not be used by the
    CIFS client, but we actually do. Besides, this has proven to cause races
    leading to oops between SendReceive2/cifs_demultiplex_thread. On SMB1,
    MID is a 2 byte value easy to reach in CurrentMid which may conflict with
    an oplock break notification request coming from server
    
    Signed-off-by: Roberto Bergantinos Corpas <rbergant@redhat.com>
    Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
    Reviewed-by: Aurelien Aptel <aaptel@suse.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    CC: Stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4b0bd39cc8618efdd8e44bea0f67cd6b2040335c
Author: Helge Deller <deller@gmx.de>
Date:   Fri Oct 4 19:23:37 2019 +0200

    parisc: Fix vmap memory leak in ioremap()/iounmap()
    
    commit 513f7f747e1cba81f28a436911fba0b485878ebd upstream.
    
    Sven noticed that calling ioremap() and iounmap() multiple times leads
    to a vmap memory leak:
            vmap allocation for size 4198400 failed:
            use vmalloc=<size> to increase size
    
    It seems we missed calling vunmap() in iounmap().
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Noticed-by: Sven Schnelle <svens@stackframe.org>
    Cc: <stable@vger.kernel.org> # v3.16+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bfa25cba54e4d3c4d0168167aca23dc8b6cbe2b8
Author: Max Filippov <jcmvbkbc@gmail.com>
Date:   Mon Oct 14 15:48:19 2019 -0700

    xtensa: drop EXPORT_SYMBOL for outs*/ins*
    
    commit 8b39da985194aac2998dd9e3a22d00b596cebf1e upstream.
    
    Custom outs*/ins* implementations are long gone from the xtensa port,
    remove matching EXPORT_SYMBOLs.
    This fixes the following build warnings issued by modpost since commit
    15bfc2348d54 ("modpost: check for static EXPORT_SYMBOL* functions"):
    
      WARNING: "insb" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "insw" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "insl" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "outsb" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "outsw" [vmlinux] is a static EXPORT_SYMBOL
      WARNING: "outsl" [vmlinux] is a static EXPORT_SYMBOL
    
    Cc: stable@vger.kernel.org
    Fixes: d38efc1f150f ("xtensa: adopt generic io routines")
    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5e76d606661c22e1b7f011163800ff4ceb0f398c
Author: David Hildenbrand <david@redhat.com>
Date:   Fri Oct 18 20:20:05 2019 -0700

    hugetlbfs: don't access uninitialized memmaps in pfn_range_valid_gigantic()
    
    commit f231fe4235e22e18d847e05cbe705deaca56580a upstream.
    
    Uninitialized memmaps contain garbage and in the worst case trigger
    kernel BUGs, especially with CONFIG_PAGE_POISONING.  They should not get
    touched.
    
    Let's make sure that we only consider online memory (managed by the
    buddy) that has initialized memmaps.  ZONE_DEVICE is not applicable.
    
    page_zone() will call page_to_nid(), which will trigger
    VM_BUG_ON_PGFLAGS(PagePoisoned(page), page) with CONFIG_PAGE_POISONING
    and CONFIG_DEBUG_VM_PGFLAGS when called on uninitialized memmaps.  This
    can be the case when an offline memory block (e.g., never onlined) is
    spanned by a zone.
    
    Note: As explained by Michal in [1], alloc_contig_range() will verify
    the range.  So it boils down to the wrong access in this function.
    
    [1] http://lkml.kernel.org/r/20180423000943.GO17484@dhcp22.suse.cz
    
    Link: http://lkml.kernel.org/r/20191015120717.4858-1-david@redhat.com
    Fixes: f1dd2cd13c4b ("mm, memory_hotplug: do not associate hotadded memory to zones until online")      [visible after d0dc12e86b319]
    Signed-off-by: David Hildenbrand <david@redhat.com>
    Reported-by: Michal Hocko <mhocko@kernel.org>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
    Cc: Anshuman Khandual <anshuman.khandual@arm.com>
    Cc: <stable@vger.kernel.org>    [4.13+]
    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 13e9cf786d03cbabd24f3e0bffb6151d17c6029b
Author: Qian Cai <cai@lca.pw>
Date:   Fri Oct 18 20:19:29 2019 -0700

    mm/page_owner: don't access uninitialized memmaps when reading /proc/pagetypeinfo
    
    commit a26ee565b6cd8dc2bf15ff6aa70bbb28f928b773 upstream.
    
    Uninitialized memmaps contain garbage and in the worst case trigger
    kernel BUGs, especially with CONFIG_PAGE_POISONING.  They should not get
    touched.
    
    For example, when not onlining a memory block that is spanned by a zone
    and reading /proc/pagetypeinfo with CONFIG_DEBUG_VM_PGFLAGS and
    CONFIG_PAGE_POISONING, we can trigger a kernel BUG:
    
      :/# echo 1 > /sys/devices/system/memory/memory40/online
      :/# echo 1 > /sys/devices/system/memory/memory42/online
      :/# cat /proc/pagetypeinfo > test.file
       page:fffff2c585200000 is uninitialized and poisoned
       raw: ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff
       raw: ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff
       page dumped because: VM_BUG_ON_PAGE(PagePoisoned(p))
       There is not page extension available.
       ------------[ cut here ]------------
       kernel BUG at include/linux/mm.h:1107!
       invalid opcode: 0000 [#1] SMP NOPTI
    
    Please note that this change does not affect ZONE_DEVICE, because
    pagetypeinfo_showmixedcount_print() is called from
    mm/vmstat.c:pagetypeinfo_showmixedcount() only for populated zones, and
    ZONE_DEVICE is never populated (zone->present_pages always 0).
    
    [david@redhat.com: move check to outer loop, add comment, rephrase description]
    Link: http://lkml.kernel.org/r/20191011140638.8160-1-david@redhat.com
    Fixes: f1dd2cd13c4b ("mm, memory_hotplug: do not associate hotadded memory to zones until online") # visible after d0dc12e86b319
    Signed-off-by: Qian Cai <cai@lca.pw>
    Signed-off-by: David Hildenbrand <david@redhat.com>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Acked-by: Vlastimil Babka <vbabka@suse.cz>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
    Cc: Miles Chen <miles.chen@mediatek.com>
    Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
    Cc: Qian Cai <cai@lca.pw>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: <stable@vger.kernel.org>    [4.13+]
    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 504593dd854f66d808f578783959dbcb97a520a2
Author: Qian Cai <cai@lca.pw>
Date:   Mon Oct 14 14:11:51 2019 -0700

    mm/slub: fix a deadlock in show_slab_objects()
    
    commit e4f8e513c3d353c134ad4eef9fd0bba12406c7c8 upstream.
    
    A long time ago we fixed a similar deadlock in show_slab_objects() [1].
    However, it is apparently due to the commits like 01fb58bcba63 ("slab:
    remove synchronous synchronize_sched() from memcg cache deactivation
    path") and 03afc0e25f7f ("slab: get_online_mems for
    kmem_cache_{create,destroy,shrink}"), this kind of deadlock is back by
    just reading files in /sys/kernel/slab which will generate a lockdep
    splat below.
    
    Since the "mem_hotplug_lock" here is only to obtain a stable online node
    mask while racing with NUMA node hotplug, in the worst case, the results
    may me miscalculated while doing NUMA node hotplug, but they shall be
    corrected by later reads of the same files.
    
      WARNING: possible circular locking dependency detected
      ------------------------------------------------------
      cat/5224 is trying to acquire lock:
      ffff900012ac3120 (mem_hotplug_lock.rw_sem){++++}, at:
      show_slab_objects+0x94/0x3a8
    
      but task is already holding lock:
      b8ff009693eee398 (kn->count#45){++++}, at: kernfs_seq_start+0x44/0xf0
    
      which lock already depends on the new lock.
    
      the existing dependency chain (in reverse order) is:
    
      -> #2 (kn->count#45){++++}:
             lock_acquire+0x31c/0x360
             __kernfs_remove+0x290/0x490
             kernfs_remove+0x30/0x44
             sysfs_remove_dir+0x70/0x88
             kobject_del+0x50/0xb0
             sysfs_slab_unlink+0x2c/0x38
             shutdown_cache+0xa0/0xf0
             kmemcg_cache_shutdown_fn+0x1c/0x34
             kmemcg_workfn+0x44/0x64
             process_one_work+0x4f4/0x950
             worker_thread+0x390/0x4bc
             kthread+0x1cc/0x1e8
             ret_from_fork+0x10/0x18
    
      -> #1 (slab_mutex){+.+.}:
             lock_acquire+0x31c/0x360
             __mutex_lock_common+0x16c/0xf78
             mutex_lock_nested+0x40/0x50
             memcg_create_kmem_cache+0x38/0x16c
             memcg_kmem_cache_create_func+0x3c/0x70
             process_one_work+0x4f4/0x950
             worker_thread+0x390/0x4bc
             kthread+0x1cc/0x1e8
             ret_from_fork+0x10/0x18
    
      -> #0 (mem_hotplug_lock.rw_sem){++++}:
             validate_chain+0xd10/0x2bcc
             __lock_acquire+0x7f4/0xb8c
             lock_acquire+0x31c/0x360
             get_online_mems+0x54/0x150
             show_slab_objects+0x94/0x3a8
             total_objects_show+0x28/0x34
             slab_attr_show+0x38/0x54
             sysfs_kf_seq_show+0x198/0x2d4
             kernfs_seq_show+0xa4/0xcc
             seq_read+0x30c/0x8a8
             kernfs_fop_read+0xa8/0x314
             __vfs_read+0x88/0x20c
             vfs_read+0xd8/0x10c
             ksys_read+0xb0/0x120
             __arm64_sys_read+0x54/0x88
             el0_svc_handler+0x170/0x240
             el0_svc+0x8/0xc
    
      other info that might help us debug this:
    
      Chain exists of:
        mem_hotplug_lock.rw_sem --> slab_mutex --> kn->count#45
    
       Possible unsafe locking scenario:
    
             CPU0                    CPU1
             ----                    ----
        lock(kn->count#45);
                                     lock(slab_mutex);
                                     lock(kn->count#45);
        lock(mem_hotplug_lock.rw_sem);
    
       *** DEADLOCK ***
    
      3 locks held by cat/5224:
       #0: 9eff00095b14b2a0 (&p->lock){+.+.}, at: seq_read+0x4c/0x8a8
       #1: 0eff008997041480 (&of->mutex){+.+.}, at: kernfs_seq_start+0x34/0xf0
       #2: b8ff009693eee398 (kn->count#45){++++}, at:
      kernfs_seq_start+0x44/0xf0
    
      stack backtrace:
      Call trace:
       dump_backtrace+0x0/0x248
       show_stack+0x20/0x2c
       dump_stack+0xd0/0x140
       print_circular_bug+0x368/0x380
       check_noncircular+0x248/0x250
       validate_chain+0xd10/0x2bcc
       __lock_acquire+0x7f4/0xb8c
       lock_acquire+0x31c/0x360
       get_online_mems+0x54/0x150
       show_slab_objects+0x94/0x3a8
       total_objects_show+0x28/0x34
       slab_attr_show+0x38/0x54
       sysfs_kf_seq_show+0x198/0x2d4
       kernfs_seq_show+0xa4/0xcc
       seq_read+0x30c/0x8a8
       kernfs_fop_read+0xa8/0x314
       __vfs_read+0x88/0x20c
       vfs_read+0xd8/0x10c
       ksys_read+0xb0/0x120
       __arm64_sys_read+0x54/0x88
       el0_svc_handler+0x170/0x240
       el0_svc+0x8/0xc
    
    I think it is important to mention that this doesn't expose the
    show_slab_objects to use-after-free.  There is only a single path that
    might really race here and that is the slab hotplug notifier callback
    __kmem_cache_shrink (via slab_mem_going_offline_callback) but that path
    doesn't really destroy kmem_cache_node data structures.
    
    [1] http://lkml.iu.edu/hypermail/linux/kernel/1101.0/02850.html
    
    [akpm@linux-foundation.org: add comment explaining why we don't need mem_hotplug_lock]
    Link: http://lkml.kernel.org/r/1570192309-10132-1-git-send-email-cai@lca.pw
    Fixes: 01fb58bcba63 ("slab: remove synchronous synchronize_sched() from memcg cache deactivation path")
    Fixes: 03afc0e25f7f ("slab: get_online_mems for kmem_cache_{create,destroy,shrink}")
    Signed-off-by: Qian Cai <cai@lca.pw>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Cc: Christoph Lameter <cl@linux.com>
    Cc: Pekka Enberg <penberg@kernel.org>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
    Cc: Tejun Heo <tj@kernel.org>
    Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
    Cc: Roman Gushchin <guro@fb.com>
    Cc: <stable@vger.kernel.org>
    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 e2e84418dec6eb784fa7f5b0a118457d88857dcf
Author: Steffen Maier <maier@linux.ibm.com>
Date:   Tue Oct 1 12:49:49 2019 +0200

    scsi: zfcp: fix reaction on bit error threshold notification
    
    [ Upstream commit 2190168aaea42c31bff7b9a967e7b045f07df095 ]
    
    On excessive bit errors for the FCP channel ingress fibre path, the channel
    notifies us.  Previously, we only emitted a kernel message and a trace
    record.  Since performance can become suboptimal with I/O timeouts due to
    bit errors, we now stop using an FCP device by default on channel
    notification so multipath on top can timely failover to other paths.  A new
    module parameter zfcp.ber_stop can be used to get zfcp old behavior.
    
    User explanation of new kernel message:
    
     * Description:
     * The FCP channel reported that its bit error threshold has been exceeded.
     * These errors might result from a problem with the physical components
     * of the local fibre link into the FCP channel.
     * The problem might be damage or malfunction of the cable or
     * cable connection between the FCP channel and
     * the adjacent fabric switch port or the point-to-point peer.
     * Find details about the errors in the HBA trace for the FCP device.
     * The zfcp device driver closed down the FCP device
     * to limit the performance impact from possible I/O command timeouts.
     * User action:
     * Check for problems on the local fibre link, ensure that fibre optics are
     * clean and functional, and all cables are properly plugged.
     * After the repair action, you can manually recover the FCP device by
     * writing "0" into its "failed" sysfs attribute.
     * If recovery through sysfs is not possible, set the CHPID of the device
     * offline and back online on the service element.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: <stable@vger.kernel.org> #2.6.30+
    Link: https://lore.kernel.org/r/20191001104949.42810-1-maier@linux.ibm.com
    Reviewed-by: Jens Remus <jremus@linux.ibm.com>
    Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
    Signed-off-by: Steffen Maier <maier@linux.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 80b9274e3fc2b64a2634a121fc9a7ea512a52d2d
Author: David Hildenbrand <david@redhat.com>
Date:   Fri Oct 18 20:19:20 2019 -0700

    fs/proc/page.c: don't access uninitialized memmaps in fs/proc/page.c
    
    commit aad5f69bc161af489dbb5934868bd347282f0764 upstream.
    
    There are three places where we access uninitialized memmaps, namely:
    - /proc/kpagecount
    - /proc/kpageflags
    - /proc/kpagecgroup
    
    We have initialized memmaps either when the section is online or when the
    page was initialized to the ZONE_DEVICE.  Uninitialized memmaps contain
    garbage and in the worst case trigger kernel BUGs, especially with
    CONFIG_PAGE_POISONING.
    
    For example, not onlining a DIMM during boot and calling /proc/kpagecount
    with CONFIG_PAGE_POISONING:
    
      :/# cat /proc/kpagecount > tmp.test
      BUG: unable to handle page fault for address: fffffffffffffffe
      #PF: supervisor read access in kernel mode
      #PF: error_code(0x0000) - not-present page
      PGD 114616067 P4D 114616067 PUD 114618067 PMD 0
      Oops: 0000 [#1] SMP NOPTI
      CPU: 0 PID: 469 Comm: cat Not tainted 5.4.0-rc1-next-20191004+ #11
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.4
      RIP: 0010:kpagecount_read+0xce/0x1e0
      Code: e8 09 83 e0 3f 48 0f a3 02 73 2d 4c 89 e7 48 c1 e7 06 48 03 3d ab 51 01 01 74 1d 48 8b 57 08 480
      RSP: 0018:ffffa14e409b7e78 EFLAGS: 00010202
      RAX: fffffffffffffffe RBX: 0000000000020000 RCX: 0000000000000000
      RDX: 0000000000000001 RSI: 00007f76b5595000 RDI: fffff35645000000
      RBP: 00007f76b5595000 R08: 0000000000000001 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000140000
      R13: 0000000000020000 R14: 00007f76b5595000 R15: ffffa14e409b7f08
      FS:  00007f76b577d580(0000) GS:ffff8f41bd400000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: fffffffffffffffe CR3: 0000000078960000 CR4: 00000000000006f0
      Call Trace:
       proc_reg_read+0x3c/0x60
       vfs_read+0xc5/0x180
       ksys_read+0x68/0xe0
       do_syscall_64+0x5c/0xa0
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
    
    For now, let's drop support for ZONE_DEVICE from the three pseudo files
    in order to fix this.  To distinguish offline memory (with garbage
    memmap) from ZONE_DEVICE memory with properly initialized memmaps, we
    would have to check get_dev_pagemap() and pfn_zone_device_reserved()
    right now.  The usage of both (especially, special casing devmem) is
    frowned upon and needs to be reworked.
    
    The fundamental issue we have is:
    
            if (pfn_to_online_page(pfn)) {
                    /* memmap initialized */
            } else if (pfn_valid(pfn)) {
                    /*
                     * ???
                     * a) offline memory. memmap garbage.
                     * b) devmem: memmap initialized to ZONE_DEVICE.
                     * c) devmem: reserved for driver. memmap garbage.
                     * (d) devmem: memmap currently initializing - garbage)
                     */
            }
    
    We'll leave the pfn_zone_device_reserved() check in stable_page_flags()
    in place as that function is also used from memory failure.  We now no
    longer dump information about pages that are not in use anymore -
    offline.
    
    Link: http://lkml.kernel.org/r/20191009142435.3975-2-david@redhat.com
    Fixes: f1dd2cd13c4b ("mm, memory_hotplug: do not associate hotadded memory to zones until online")      [visible after d0dc12e86b319]
    Signed-off-by: David Hildenbrand <david@redhat.com>
    Reported-by: Qian Cai <cai@lca.pw>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Cc: Dan Williams <dan.j.williams@intel.com>
    Cc: Alexey Dobriyan <adobriyan@gmail.com>
    Cc: Stephen Rothwell <sfr@canb.auug.org.au>
    Cc: Toshiki Fukasawa <t-fukasawa@vx.jp.nec.com>
    Cc: Pankaj gupta <pagupta@redhat.com>
    Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
    Cc: Anthony Yznaga <anthony.yznaga@oracle.com>
    Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
    Cc: <stable@vger.kernel.org>    [4.13+]
    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 872f16e35f53c8d3fb296051016cf761f718a31a
Author: David Hildenbrand <david@redhat.com>
Date:   Fri Oct 18 20:19:16 2019 -0700

    drivers/base/memory.c: don't access uninitialized memmaps in soft_offline_page_store()
    
    commit 641fe2e9387a36f9ee01d7c69382d1fe147a5e98 upstream.
    
    Uninitialized memmaps contain garbage and in the worst case trigger kernel
    BUGs, especially with CONFIG_PAGE_POISONING.  They should not get touched.
    
    Right now, when trying to soft-offline a PFN that resides on a memory
    block that was never onlined, one gets a misleading error with
    CONFIG_PAGE_POISONING:
    
      :/# echo 5637144576 > /sys/devices/system/memory/soft_offline_page
      [   23.097167] soft offline: 0x150000 page already poisoned
    
    But the actual result depends on the garbage in the memmap.
    
    soft_offline_page() can only work with online pages, it returns -EIO in
    case of ZONE_DEVICE.  Make sure to only forward pages that are online
    (iow, managed by the buddy) and, therefore, have an initialized memmap.
    
    Add a check against pfn_to_online_page() and similarly return -EIO.
    
    Link: http://lkml.kernel.org/r/20191010141200.8985-1-david@redhat.com
    Fixes: f1dd2cd13c4b ("mm, memory_hotplug: do not associate hotadded memory to zones until online")      [visible after d0dc12e86b319]
    Signed-off-by: David Hildenbrand <david@redhat.com>
    Acked-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: "Rafael J. Wysocki" <rafael@kernel.org>
    Cc: <stable@vger.kernel.org>    [4.13+]
    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 df984262a4bcd76f0ef7071ee73329b0fc430d59
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Thu Oct 10 18:28:17 2019 +0200

    drm/amdgpu: Bail earlier when amdgpu.cik_/si_support is not set to 1
    
    commit 984d7a929ad68b7be9990fc9c5cfa5d5c9fc7942 upstream.
    
    Bail from the pci_driver probe function instead of from the drm_driver
    load function.
    
    This avoid /dev/dri/card0 temporarily getting registered and then
    unregistered again, sending unwanted add / remove udev events to
    userspace.
    
    Specifically this avoids triggering the (userspace) bug fixed by this
    plymouth merge-request:
    https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/59
    
    Note that despite that being a userspace bug, not sending unnecessary
    udev events is a good idea in general.
    
    BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1490490
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f991b1fa0ded689f980cc25312b5003f35add8bf
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Tue Apr 2 11:30:37 2019 +0800

    drm/edid: Add 6 bpc quirk for SDC panel in Lenovo G50
    
    commit 11bcf5f78905b90baae8fb01e16650664ed0cb00 upstream.
    
    Another panel that needs 6BPC quirk.
    
    BugLink: https://bugs.launchpad.net/bugs/1819968
    Cc: <stable@vger.kernel.org> # v4.8+
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190402033037.21877-1-kai.heng.feng@canonical.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7a19f258f811f14e4e9b14b057dd606d03c7a586
Author: Will Deacon <will@kernel.org>
Date:   Fri Oct 4 10:51:31 2019 +0100

    mac80211: Reject malformed SSID elements
    
    commit 4152561f5da3fca92af7179dd538ea89e248f9d0 upstream.
    
    Although this shouldn't occur in practice, it's a good idea to bounds
    check the length field of the SSID element prior to using it for things
    like allocations or memcpy operations.
    
    Cc: <stable@vger.kernel.org>
    Cc: Kees Cook <keescook@chromium.org>
    Reported-by: Nicolas Waisman <nico@semmle.com>
    Signed-off-by: Will Deacon <will@kernel.org>
    Link: https://lore.kernel.org/r/20191004095132.15777-1-will@kernel.org
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 63eb9c2849bc377c6bbf491f752c6cc6b9b75bca
Author: Will Deacon <will@kernel.org>
Date:   Fri Oct 4 10:51:32 2019 +0100

    cfg80211: wext: avoid copying malformed SSIDs
    
    commit 4ac2813cc867ae563a1ba5a9414bfb554e5796fa upstream.
    
    Ensure the SSID element is bounds-checked prior to invoking memcpy()
    with its length field, when copying to userspace.
    
    Cc: <stable@vger.kernel.org>
    Cc: Kees Cook <keescook@chromium.org>
    Reported-by: Nicolas Waisman <nico@semmle.com>
    Signed-off-by: Will Deacon <will@kernel.org>
    Link: https://lore.kernel.org/r/20191004095132.15777-2-will@kernel.org
    [adjust commit log a bit]
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b20d0e89a6e3bd53b539cae97405f317774e3d50
Author: Junya Monden <jmonden@jp.adit-jv.com>
Date:   Wed Oct 16 14:42:55 2019 +0200

    ASoC: rsnd: Reinitialize bit clock inversion flag for every format setting
    
    commit 22e58665a01006d05f0239621f7d41cacca96cc4 upstream.
    
    Unlike other format-related DAI parameters, rdai->bit_clk_inv flag
    is not properly re-initialized when setting format for new stream
    processing. The inversion, if requested, is then applied not to default,
    but to a previous value, which leads to SCKP bit in SSICR register being
    set incorrectly.
    Fix this by re-setting the flag to its initial value, determined by format.
    
    Fixes: 1a7889ca8aba3 ("ASoC: rsnd: fixup SND_SOC_DAIFMT_xB_xF behavior")
    Cc: Andrew Gabbasov <andrew_gabbasov@mentor.com>
    Cc: Jiada Wang <jiada_wang@mentor.com>
    Cc: Timo Wischer <twischer@de.adit-jv.com>
    Cc: stable@vger.kernel.org # v3.17+
    Signed-off-by: Junya Monden <jmonden@jp.adit-jv.com>
    Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
    Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
    Link: https://lore.kernel.org/r/20191016124255.7442-1-erosca@de.adit-jv.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7b9f7a928255a232012be55cb95db30e963b83a7
Author: Evan Green <evgreen@chromium.org>
Date:   Fri Oct 11 17:22:09 2019 -0700

    Input: synaptics-rmi4 - avoid processing unknown IRQs
    
    commit 363c53875aef8fce69d4a2d0873919ccc7d9e2ad upstream.
    
    rmi_process_interrupt_requests() calls handle_nested_irq() for
    each interrupt status bit it finds. If the irq domain mapping for
    this bit had not yet been set up, then it ends up calling
    handle_nested_irq(0), which causes a NULL pointer dereference.
    
    There's already code that masks the irq_status bits coming out of the
    hardware with current_irq_mask, presumably to avoid this situation.
    However current_irq_mask seems to more reflect the actual mask set
    in the hardware rather than the IRQs software has set up and registered
    for. For example, in rmi_driver_reset_handler(), the current_irq_mask
    is initialized based on what is read from the hardware. If the reset
    value of this mask enables IRQs that Linux has not set up yet, then
    we end up in this situation.
    
    There appears to be a third unused bitmask that used to serve this
    purpose, fn_irq_bits. Use that bitmask instead of current_irq_mask
    to avoid calling handle_nested_irq() on IRQs that have not yet been
    set up.
    
    Signed-off-by: Evan Green <evgreen@chromium.org>
    Reviewed-by: Andrew Duggan <aduggan@synaptics.com>
    Link: https://lore.kernel.org/r/20191008223657.163366-1-evgreen@chromium.org
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1c725772e6f23698d3ee414637a3426e752bbd20
Author: Marco Felsch <m.felsch@pengutronix.de>
Date:   Mon Sep 16 12:45:48 2019 -0700

    Input: da9063 - fix capability and drop KEY_SLEEP
    
    commit afce285b859cea91c182015fc9858ea58c26cd0e upstream.
    
    Since commit f889beaaab1c ("Input: da9063 - report KEY_POWER instead of
    KEY_SLEEP during power key-press") KEY_SLEEP isn't supported anymore. This
    caused input device to not generate any events if "dlg,disable-key-power"
    is set.
    
    Fix this by unconditionally setting KEY_POWER capability, and not
    declaring KEY_SLEEP.
    
    Fixes: f889beaaab1c ("Input: da9063 - report KEY_POWER instead of KEY_SLEEP during power key-press")
    Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a7f64a34fa1b39a22fbf8cffa6aa1624182d9a81
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Wed Oct 9 10:35:36 2019 -0700

    scsi: ch: Make it possible to open a ch device multiple times again
    
    commit 6a0990eaa768dfb7064f06777743acc6d392084b upstream.
    
    Clearing ch->device in ch_release() is wrong because that pointer must
    remain valid until ch_remove() is called. This patch fixes the following
    crash the second time a ch device is opened:
    
    BUG: kernel NULL pointer dereference, address: 0000000000000790
    RIP: 0010:scsi_device_get+0x5/0x60
    Call Trace:
     ch_open+0x4c/0xa0 [ch]
     chrdev_open+0xa2/0x1c0
     do_dentry_open+0x13a/0x380
     path_openat+0x591/0x1470
     do_filp_open+0x91/0x100
     do_sys_open+0x184/0x220
     do_syscall_64+0x5f/0x1a0
     entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    Fixes: 085e56766f74 ("scsi: ch: add refcounting")
    Cc: Hannes Reinecke <hare@suse.de>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20191009173536.247889-1-bvanassche@acm.org
    Reported-by: Rob Turk <robtu@rtist.nl>
    Suggested-by: Rob Turk <robtu@rtist.nl>
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a5bb723f80e004c3e64c60da68158b21152c4636
Author: Yufen Yu <yuyufen@huawei.com>
Date:   Tue Oct 15 21:05:56 2019 +0800

    scsi: core: try to get module before removing device
    
    commit 77c301287ebae86cc71d03eb3806f271cb14da79 upstream.
    
    We have a test case like block/001 in blktests, which will create a scsi
    device by loading scsi_debug module and then try to delete the device by
    sysfs interface. At the same time, it may remove the scsi_debug module.
    
    And getting a invalid paging request BUG_ON as following:
    
    [   34.625854] BUG: unable to handle page fault for address: ffffffffa0016bb8
    [   34.629189] Oops: 0000 [#1] SMP PTI
    [   34.629618] CPU: 1 PID: 450 Comm: bash Tainted: G        W         5.4.0-rc3+ #473
    [   34.632524] RIP: 0010:scsi_proc_hostdir_rm+0x5/0xa0
    [   34.643555] CR2: ffffffffa0016bb8 CR3: 000000012cd88000 CR4: 00000000000006e0
    [   34.644545] Call Trace:
    [   34.644907]  scsi_host_dev_release+0x6b/0x1f0
    [   34.645511]  device_release+0x74/0x110
    [   34.646046]  kobject_put+0x116/0x390
    [   34.646559]  put_device+0x17/0x30
    [   34.647041]  scsi_target_dev_release+0x2b/0x40
    [   34.647652]  device_release+0x74/0x110
    [   34.648186]  kobject_put+0x116/0x390
    [   34.648691]  put_device+0x17/0x30
    [   34.649157]  scsi_device_dev_release_usercontext+0x2e8/0x360
    [   34.649953]  execute_in_process_context+0x29/0x80
    [   34.650603]  scsi_device_dev_release+0x20/0x30
    [   34.651221]  device_release+0x74/0x110
    [   34.651732]  kobject_put+0x116/0x390
    [   34.652230]  sysfs_unbreak_active_protection+0x3f/0x50
    [   34.652935]  sdev_store_delete.cold.4+0x71/0x8f
    [   34.653579]  dev_attr_store+0x1b/0x40
    [   34.654103]  sysfs_kf_write+0x3d/0x60
    [   34.654603]  kernfs_fop_write+0x174/0x250
    [   34.655165]  __vfs_write+0x1f/0x60
    [   34.655639]  vfs_write+0xc7/0x280
    [   34.656117]  ksys_write+0x6d/0x140
    [   34.656591]  __x64_sys_write+0x1e/0x30
    [   34.657114]  do_syscall_64+0xb1/0x400
    [   34.657627]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [   34.658335] RIP: 0033:0x7f156f337130
    
    During deleting scsi target, the scsi_debug module have been removed. Then,
    sdebug_driver_template belonged to the module cannot be accessd, resulting
    in scsi_proc_hostdir_rm() BUG_ON.
    
    To fix the bug, we add scsi_device_get() in sdev_store_delete() to try to
    increase refcount of module, avoiding the module been removed.
    
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20191015130556.18061-1-yuyufen@huawei.com
    Signed-off-by: Yufen Yu <yuyufen@huawei.com>
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1e8260fd7fe5e87002e2485ab97cd1d96eaccc9e
Author: Damien Le Moal <damien.lemoal@wdc.com>
Date:   Tue Oct 1 16:48:39 2019 +0900

    scsi: core: save/restore command resid for error handling
    
    commit 8f8fed0cdbbd6cdbf28d9ebe662f45765d2f7d39 upstream.
    
    When a non-passthrough command is terminated with CHECK CONDITION, request
    sense is executed by hijacking the command descriptor. Since
    scsi_eh_prep_cmnd() and scsi_eh_restore_cmnd() do not save/restore the
    original command resid, the value returned on failure of the original
    command is lost and replaced with the value set by the execution of the
    request sense command. This value may in many instances be unaligned to the
    device sector size, causing sd_done() to print a warning message about the
    incorrect unaligned resid before the command is retried.
    
    Fix this problem by saving the original command residual in struct
    scsi_eh_save using scsi_eh_prep_cmnd() and restoring it in
    scsi_eh_restore_cmnd(). In addition, to make sure that the request sense
    command is executed with a correctly initialized command structure, also
    reset the residual to 0 in scsi_eh_prep_cmnd() after saving the original
    command value in struct scsi_eh_save.
    
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20191001074839.1994-1-damien.lemoal@wdc.com
    Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5550eabaae33311e26919f3b140e6bb7c3b74319
Author: Oliver Neukum <oneukum@suse.com>
Date:   Tue Sep 3 12:18:39 2019 +0200

    scsi: sd: Ignore a failure to sync cache due to lack of authorization
    
    commit 21e3d6c81179bbdfa279efc8de456c34b814cfd2 upstream.
    
    I've got a report about a UAS drive enclosure reporting back Sense: Logical
    unit access not authorized if the drive it holds is password protected.
    While the drive is obviously unusable in that state as a mass storage
    device, it still exists as a sd device and when the system is asked to
    perform a suspend of the drive, it will be sent a SYNCHRONIZE CACHE. If
    that fails due to password protection, the error must be ignored.
    
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20190903101840.16483-1-oneukum@suse.com
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 928289ae23aa06fdc0fcfd26d03ed1bea689838f
Author: Colin Ian King <colin.king@canonical.com>
Date:   Mon Oct 14 12:02:01 2019 +0100

    staging: wlan-ng: fix exit return when sme->key_idx >= NUM_WEPKEYS
    
    commit 153c5d8191c26165dbbd2646448ca7207f7796d0 upstream.
    
    Currently the exit return path when sme->key_idx >= NUM_WEPKEYS is via
    label 'exit' and this checks if result is non-zero, however result has
    not been initialized and contains garbage.  Fix this by replacing the
    goto with a return with the error code.
    
    Addresses-Coverity: ("Uninitialized scalar variable")
    Fixes: 0ca6d8e74489 ("Staging: wlan-ng: replace switch-case statements with macro")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20191014110201.9874-1-colin.king@canonical.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 00b36385c534be1d51240dfbcb522d790e384f5c
Author: Paul Burton <paulburton@kernel.org>
Date:   Fri Oct 18 15:38:48 2019 -0700

    MIPS: tlbex: Fix build_restore_pagemask KScratch restore
    
    commit b42aa3fd5957e4daf4b69129e5ce752a2a53e7d6 upstream.
    
    build_restore_pagemask() will restore the value of register $1/$at when
    its restore_scratch argument is non-zero, and aims to do so by filling a
    branch delay slot. Commit 0b24cae4d535 ("MIPS: Add missing EHB in mtc0
    -> mfc0 sequence.") added an EHB instruction (Execution Hazard Barrier)
    prior to restoring $1 from a KScratch register, in order to resolve a
    hazard that can result in stale values of the KScratch register being
    observed. In particular, P-class CPUs from MIPS with out of order
    execution pipelines such as the P5600 & P6600 are affected.
    
    Unfortunately this EHB instruction was inserted in the branch delay slot
    causing the MFC0 instruction which performs the restoration to no longer
    execute along with the branch. The result is that the $1 register isn't
    actually restored, ie. the TLB refill exception handler clobbers it -
    which is exactly the problem the EHB is meant to avoid for the P-class
    CPUs.
    
    Similarly build_get_pgd_vmalloc() will restore the value of $1/$at when
    its mode argument equals refill_scratch, and suffers from the same
    problem.
    
    Fix this by in both cases moving the EHB earlier in the emitted code.
    There's no reason it needs to immediately precede the MFC0 - it simply
    needs to be between the MTC0 & MFC0.
    
    This bug only affects Cavium Octeon systems which use
    build_fast_tlb_refill_handler().
    
    Signed-off-by: Paul Burton <paulburton@kernel.org>
    Fixes: 0b24cae4d535 ("MIPS: Add missing EHB in mtc0 -> mfc0 sequence.")
    Cc: Dmitry Korotin <dkorotin@wavecomp.com>
    Cc: stable@vger.kernel.org # v3.15+
    Cc: linux-mips@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5fff7a398c266c8c202a24e573327ba2c1566524
Author: Josh Poimboeuf <jpoimboe@redhat.com>
Date:   Thu Oct 24 14:48:33 2019 +0200

    arm64/speculation: Support 'mitigations=' cmdline option
    
    [ Upstream commit a111b7c0f20e13b54df2fa959b3dc0bdf1925ae6 ]
    
    Configure arm64 runtime CPU speculation bug mitigations in accordance
    with the 'mitigations=' cmdline option.  This affects Meltdown, Spectre
    v2, and Speculative Store Bypass.
    
    The default behavior is unchanged.
    
    Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
    [will: reorder checks so KASLR implies KPTI and SSBS is affected by cmdline]
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cd91a0fcab932f31f0dcc42f321131974813e567
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Thu Oct 24 14:48:32 2019 +0200

    arm64: Use firmware to detect CPUs that are not affected by Spectre-v2
    
    [ Upstream commit 517953c2c47f9c00a002f588ac856a5bc70cede3 ]
    
    The SMCCC ARCH_WORKAROUND_1 service can indicate that although the
    firmware knows about the Spectre-v2 mitigation, this particular
    CPU is not vulnerable, and it is thus not necessary to call
    the firmware on this CPU.
    
    Let's use this information to our benefit.
    
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
    Reviewed-by: Andre Przywara <andre.przywara@arm.com>
    Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
    Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cdf5048e996d09e079932e2f6fa8a75fa19b7b96
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Thu Oct 24 14:48:31 2019 +0200

    arm64: Force SSBS on context switch
    
    [ Upstream commit cbdf8a189a66001c36007bf0f5c975d0376c5c3a ]
    
    On a CPU that doesn't support SSBS, PSTATE[12] is RES0.  In a system
    where only some of the CPUs implement SSBS, we end-up losing track of
    the SSBS bit across task migration.
    
    To address this issue, let's force the SSBS bit on context switch.
    
    Fixes: 8f04e8e6e29c ("arm64: ssbd: Add support for PSTATE.SSBS rather than trapping to EL3")
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    [will: inverted logic and added comments]
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 19cb87c3c13583cd2b23deeda19505cb10cd880d
Author: Will Deacon <will.deacon@arm.com>
Date:   Thu Oct 24 14:48:30 2019 +0200

    arm64: ssbs: Don't treat CPUs with SSBS as unaffected by SSB
    
    [ Upstream commit eb337cdfcd5dd3b10522c2f34140a73a4c285c30 ]
    
    SSBS provides a relatively cheap mitigation for SSB, but it is still a
    mitigation and its presence does not indicate that the CPU is unaffected
    by the vulnerability.
    
    Tweak the mitigation logic so that we report the correct string in sysfs.
    
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 325758118d72e0723f5eae6eb01844101f8505b3
Author: Jeremy Linton <jeremy.linton@arm.com>
Date:   Thu Oct 24 14:48:29 2019 +0200

    arm64: add sysfs vulnerability show for speculative store bypass
    
    [ Upstream commit 526e065dbca6df0b5a130b84b836b8b3c9f54e21 ]
    
    Return status based on ssbd_state and __ssb_safe. If the
    mitigation is disabled, or the firmware isn't responding then
    return the expected machine state based on a whitelist of known
    good cores.
    
    Given a heterogeneous machine, the overall machine vulnerability
    defaults to safe but is reset to unsafe when we miss the whitelist
    and the firmware doesn't explicitly tell us the core is safe.
    In order to make that work we delay transitioning to vulnerable
    until we know the firmware isn't responding to avoid a case
    where we miss the whitelist, but the firmware goes ahead and
    reports the core is not vulnerable. If all the cores in the
    machine have SSBS, then __ssb_safe will remain true.
    
    Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
    Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 04da7c4665c0b02f124e80888b23d3bfde86a99a
Author: Jeremy Linton <jeremy.linton@arm.com>
Date:   Thu Oct 24 14:48:28 2019 +0200

    arm64: add sysfs vulnerability show for spectre-v2
    
    [ Upstream commit d2532e27b5638bb2e2dd52b80b7ea2ec65135377 ]
    
    Track whether all the cores in the machine are vulnerable to Spectre-v2,
    and whether all the vulnerable cores have been mitigated. We then expose
    this information to userspace via sysfs.
    
    Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
    Reviewed-by: Andre Przywara <andre.przywara@arm.com>
    Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
    Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3e91f3eacc91d9d6116ed56ea339f858958ba3ee
Author: Jeremy Linton <jeremy.linton@arm.com>
Date:   Thu Oct 24 14:48:27 2019 +0200

    arm64: Always enable spectre-v2 vulnerability detection
    
    [ Upstream commit 8c1e3d2bb44cbb998cb28ff9a18f105fee7f1eb3 ]
    
    Ensure we are always able to detect whether or not the CPU is affected
    by Spectre-v2, so that we can later advertise this to userspace.
    
    Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
    Reviewed-by: Andre Przywara <andre.przywara@arm.com>
    Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
    Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 806ac9a792672cca6e506af0a2d020b9230f10ce
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Thu Oct 24 14:48:26 2019 +0200

    arm64: Advertise mitigation of Spectre-v2, or lack thereof
    
    [ Upstream commit 73f38166095947f3b86b02fbed6bd592223a7ac8 ]
    
    We currently have a list of CPUs affected by Spectre-v2, for which
    we check that the firmware implements ARCH_WORKAROUND_1. It turns
    out that not all firmwares do implement the required mitigation,
    and that we fail to let the user know about it.
    
    Instead, let's slightly revamp our checks, and rely on a whitelist
    of cores that are known to be non-vulnerable, and let the user know
    the status of the mitigation in the kernel log.
    
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
    Reviewed-by: Andre Przywara <andre.przywara@arm.com>
    Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
    Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 02fd5d7f6d027912901a68d671c0449295966cd7
Author: Jeremy Linton <jeremy.linton@arm.com>
Date:   Thu Oct 24 14:48:25 2019 +0200

    arm64: Provide a command line to disable spectre_v2 mitigation
    
    [ Upstream commit e5ce5e7267ddcbe13ab9ead2542524e1b7993e5a ]
    
    There are various reasons, such as benchmarking, to disable spectrev2
    mitigation on a machine. Provide a command-line option to do so.
    
    Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
    Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Reviewed-by: Andre Przywara <andre.przywara@arm.com>
    Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
    Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: linux-doc@vger.kernel.org
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit be5a03c9c98259f6d3837171bb33a61120da6716
Author: Jeremy Linton <jeremy.linton@arm.com>
Date:   Thu Oct 24 14:48:24 2019 +0200

    arm64: Always enable ssb vulnerability detection
    
    [ Upstream commit d42281b6e49510f078ace15a8ea10f71e6262581 ]
    
    Ensure we are always able to detect whether or not the CPU is affected
    by SSB, so that we can later advertise this to userspace.
    
    Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
    Reviewed-by: Andre Przywara <andre.przywara@arm.com>
    Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
    Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
    [will: Use IS_ENABLED instead of #ifdef]
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 88ba8b6d41a3803c18a1efbd79d9b2f95199d42c
Author: Mian Yousaf Kaukab <ykaukab@suse.de>
Date:   Thu Oct 24 14:48:23 2019 +0200

    arm64: enable generic CPU vulnerabilites support
    
    [ Upstream commit 61ae1321f06c4489c724c803e9b8363dea576da3 ]
    
    Enable CPU vulnerabilty show functions for spectre_v1, spectre_v2,
    meltdown and store-bypass.
    
    Signed-off-by: Mian Yousaf Kaukab <ykaukab@suse.de>
    Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
    Reviewed-by: Andre Przywara <andre.przywara@arm.com>
    Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
    Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8fda007949a8f8bf7dc761c3053c8d4750a9c3ec
Author: Jeremy Linton <jeremy.linton@arm.com>
Date:   Thu Oct 24 14:48:22 2019 +0200

    arm64: add sysfs vulnerability show for meltdown
    
    [ Upstream commit 1b3ccf4be0e7be8c4bd8522066b6cbc92591e912 ]
    
    We implement page table isolation as a mitigation for meltdown.
    Report this to userspace via sysfs.
    
    Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
    Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Reviewed-by: Andre Przywara <andre.przywara@arm.com>
    Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
    Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b863eee5bbcd03c816be66c656db99a428244ff7
Author: Mian Yousaf Kaukab <ykaukab@suse.de>
Date:   Thu Oct 24 14:48:21 2019 +0200

    arm64: Add sysfs vulnerability show for spectre-v1
    
    [ Upstream commit 3891ebccace188af075ce143d8b072b65e90f695 ]
    
    spectre-v1 has been mitigated and the mitigation is always active.
    Report this to userspace via sysfs
    
    Signed-off-by: Mian Yousaf Kaukab <ykaukab@suse.de>
    Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
    Reviewed-by: Andre Przywara <andre.przywara@arm.com>
    Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
    Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
    Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 985d934b2e97743c5b65e28f923cf6c4eedbfeb7
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Thu Oct 24 14:48:20 2019 +0200

    arm64: fix SSBS sanitization
    
    [ Upstream commit f54dada8274643e3ff4436df0ea124aeedc43cae ]
    
    In valid_user_regs() we treat SSBS as a RES0 bit, and consequently it is
    unexpectedly cleared when we restore a sigframe or fiddle with GPRs via
    ptrace.
    
    This patch fixes valid_user_regs() to account for this, updating the
    function to refer to the latest ARM ARM (ARM DDI 0487D.a). For AArch32
    tasks, SSBS appears in bit 23 of SPSR_EL1, matching its position in the
    AArch32-native PSR format, and we don't need to translate it as we have
    to for DIT.
    
    There are no other bit assignments that we need to account for today.
    As the recent documentation describes the DIT bit, we can drop our
    comment regarding DIT.
    
    While removing SSBS from the RES0 masks, existing inconsistent
    whitespace is corrected.
    
    Fixes: d71be2b6c0e19180 ("arm64: cpufeature: Detect SSBS and advertise to userspace")
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
    Cc: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5bed8225f130e7cab41b87f9baf5e5a5fba79211
Author: Will Deacon <will.deacon@arm.com>
Date:   Thu Oct 24 14:48:19 2019 +0200

    KVM: arm64: Set SCTLR_EL2.DSSBS if SSBD is forcefully disabled and !vhe
    
    [ Upstream commit 7c36447ae5a090729e7b129f24705bb231a07e0b ]
    
    When running without VHE, it is necessary to set SCTLR_EL2.DSSBS if SSBD
    has been forcefully disabled on the kernel command-line.
    
    Acked-by: Christoffer Dall <christoffer.dall@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8a235006cd422ad1c8ad1e3c2cfde1281ac52e48
Author: Will Deacon <will.deacon@arm.com>
Date:   Thu Oct 24 14:48:18 2019 +0200

    arm64: ssbd: Add support for PSTATE.SSBS rather than trapping to EL3
    
    [ Upstream commit 8f04e8e6e29c93421a95b61cad62e3918425eac7 ]
    
    On CPUs with support for PSTATE.SSBS, the kernel can toggle the SSBD
    state without needing to call into firmware.
    
    This patch hooks into the existing SSBD infrastructure so that SSBS is
    used on CPUs that support it, but it's all made horribly complicated by
    the very real possibility of big/little systems that don't uniformly
    provide the new capability.
    
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    [ardb: add #include of asm/compat.h]
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7ec258d023de4f118c942fe57647acbb89c8d863
Author: Will Deacon <will.deacon@arm.com>
Date:   Thu Oct 24 14:48:17 2019 +0200

    arm64: cpufeature: Detect SSBS and advertise to userspace
    
    [ Upstream commit d71be2b6c0e19180b5f80a6d42039cc074a693a2 ]
    
    Armv8.5 introduces a new PSTATE bit known as Speculative Store Bypass
    Safe (SSBS) which can be used as a mitigation against Spectre variant 4.
    
    Additionally, a CPU may provide instructions to manipulate PSTATE.SSBS
    directly, so that userspace can toggle the SSBS control without trapping
    to the kernel.
    
    This patch probes for the existence of SSBS and advertise the new instructions
    to userspace if they exist.
    
    Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 36e5ae4d22973ea8534aaff7f75d42eae343bb60
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Thu Oct 24 14:48:16 2019 +0200

    arm64: Get rid of __smccc_workaround_1_hvc_*
    
    [ Upstream commit 22765f30dbaf1118c6ff0fcb8b99c9f2b4d396d5 ]
    
    The very existence of __smccc_workaround_1_hvc_* is a thinko, as
    KVM will never use a HVC call to perform the branch prediction
    invalidation. Even as a nested hypervisor, it would use an SMC
    instruction.
    
    Let's get rid of it.
    
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 31ee977f709d28be1b62f47295e15cc464bab808
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Thu Oct 24 14:48:15 2019 +0200

    arm64: don't zero DIT on signal return
    
    [ Upstream commit 1265132127b63502d34e0f58c8bdef3a4dc927c2 ]
    
    Currently valid_user_regs() treats SPSR_ELx.DIT as a RES0 bit, causing
    it to be zeroed upon exception return, rather than preserved. Thus, code
    relying on DIT will not function as expected, and may expose an
    unexpected timing sidechannel.
    
    Let's remove DIT from the set of RES0 bits, such that it is preserved.
    At the same time, the related comment is updated to better describe the
    situation, and to take into account the most recent documentation of
    SPSR_ELx, in ARM DDI 0487C.a.
    
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Fixes: 7206dc93a58fb764 ("arm64: Expose Arm v8.4 features")
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
    Cc: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b65b0eb466bc157e0d3d50cfb77d97dba0076201
Author: Shanker Donthineni <shankerd@codeaurora.org>
Date:   Thu Oct 24 14:48:14 2019 +0200

    arm64: KVM: Use SMCCC_ARCH_WORKAROUND_1 for Falkor BP hardening
    
    [ Upstream commit 4bc352ffb39e4eec253e70f8c076f2f48a6c1926 ]
    
    The function SMCCC_ARCH_WORKAROUND_1 was introduced as part of SMC
    V1.1 Calling Convention to mitigate CVE-2017-5715. This patch uses
    the standard call SMCCC_ARCH_WORKAROUND_1 for Falkor chips instead
    of Silicon provider service ID 0xC2001700.
    
    Cc: <stable@vger.kernel.org> # 4.14+
    Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org>
    [maz: reworked errata framework integration]
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 197a83aaa821bb51f64a1d97a7a1146341801bb5
Author: Suzuki K Poulose <suzuki.poulose@arm.com>
Date:   Thu Oct 24 14:48:13 2019 +0200

    arm64: capabilities: Add support for checks based on a list of MIDRs
    
    [ Upstream commit be5b299830c63ed76e0357473c4218c85fb388b3 ]
    
    Add helpers for detecting an errata on list of midr ranges
    of affected CPUs, with the same work around.
    
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Reviewed-by: Dave Martin <dave.martin@arm.com>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    [ardb: add Cortex-A35 to kpti_safe_list[] as well]
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8a82aee7bdfd5bfcabdc741b1051dae98b576f9c
Author: Suzuki K Poulose <suzuki.poulose@arm.com>
Date:   Thu Oct 24 14:48:12 2019 +0200

    arm64: Add MIDR encoding for Arm Cortex-A55 and Cortex-A35
    
    [ Upstream commit 6e616864f21160d8d503523b60a53a29cecc6f24 ]
    
    Update the MIDR encodings for the Cortex-A55 and Cortex-A35
    
    Cc: Mark Rutland <mark.rutland@arm.com>
    Reviewed-by: Dave Martin <dave.martin@arm.com>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5a5e2f938e2e4c7b89d1f64f436ecdad547d122e
Author: Suzuki K Poulose <suzuki.poulose@arm.com>
Date:   Thu Oct 24 14:48:11 2019 +0200

    arm64: Add helpers for checking CPU MIDR against a range
    
    [ Upstream commit 1df310505d6d544802016f6bae49aab836ae8510 ]
    
    Add helpers for checking if the given CPU midr falls in a range
    of variants/revisions for a given model.
    
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Reviewed-by: Dave Martin <dave.martin@arm.com>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 41b3073644e3b694439ff737e92decb670aceda2
Author: Suzuki K Poulose <suzuki.poulose@arm.com>
Date:   Thu Oct 24 14:48:10 2019 +0200

    arm64: capabilities: Clean up midr range helpers
    
    [ Upstream commit 5e7951ce19abf4113645ae789c033917356ee96f ]
    
    We are about to introduce generic MIDR range helpers. Clean
    up the existing helpers in erratum handling, preparing them
    to use generic version.
    
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Reviewed-by: Dave Martin <dave.martin@arm.com>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ee0ccd259b4c4e362a75e382dae26b69560429a1
Author: Suzuki K Poulose <suzuki.poulose@arm.com>
Date:   Thu Oct 24 14:48:09 2019 +0200

    arm64: capabilities: Change scope of VHE to Boot CPU feature
    
    [ Upstream commit 830dcc9f9a7cd26a812522a26efaacf7df6fc365 ]
    
    We expect all CPUs to be running at the same EL inside the kernel
    with or without VHE enabled and we have strict checks to ensure
    that any mismatch triggers a kernel panic. If VHE is enabled,
    we use the feature based on the boot CPU and all other CPUs
    should follow. This makes it a perfect candidate for a capability
    based on the boot CPU,  which should be matched by all the CPUs
    (both when is ON and OFF). This saves us some not-so-pretty
    hooks and special code, just for verifying the conflict.
    
    The patch also makes the VHE capability entry depend on
    CONFIG_ARM64_VHE.
    
    Cc: Marc Zyngier <marc.zyngier@arm.com>
    Cc: Will Deacon <will.deacon@arm.com>
    Reviewed-by: Dave Martin <dave.martin@arm.com>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6527925caa7fe97a3a78e51a0681d15c9bc00d17
Author: Suzuki K Poulose <suzuki.poulose@arm.com>
Date:   Thu Oct 24 14:48:08 2019 +0200

    arm64: capabilities: Add support for features enabled early
    
    [ Upstream commit fd9d63da17daf09c0099e3d5e3f0c0f03d9b251b ]
    
    The kernel detects and uses some of the features based on the boot
    CPU and expects that all the following CPUs conform to it. e.g,
    with VHE and the boot CPU running at EL2, the kernel decides to
    keep the kernel running at EL2. If another CPU is brought up without
    this capability, we use custom hooks (via check_early_cpu_features())
    to handle it. To handle such capabilities add support for detecting
    and enabling capabilities based on the boot CPU.
    
    A bit is added to indicate if the capability should be detected
    early on the boot CPU. The infrastructure then ensures that such
    capabilities are probed and "enabled" early on in the boot CPU
    and, enabled on the subsequent CPUs.
    
    Cc: Julien Thierry <julien.thierry@arm.com>
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Marc Zyngier <marc.zyngier@arm.com>
    Reviewed-by: Dave Martin <dave.martin@arm.com>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 808ab828e638efdc5bfe62b8481aef0882f35eab
Author: Suzuki K Poulose <suzuki.poulose@arm.com>
Date:   Thu Oct 24 14:48:07 2019 +0200

    arm64: capabilities: Restrict KPTI detection to boot-time CPUs
    
    [ Upstream commit d3aec8a28be3b88bf75442e7c24fd9da8d69a6df ]
    
    KPTI is treated as a system wide feature and is only detected if all
    the CPUs in the sysetm needs the defense, unless it is forced via kernel
    command line. This leaves a system with a mix of CPUs with and without
    the defense vulnerable. Also, if a late CPU needs KPTI but KPTI was not
    activated at boot time, the CPU is currently allowed to boot, which is a
    potential security vulnerability.
    This patch ensures that the KPTI is turned on if at least one CPU detects
    the capability (i.e, change scope to SCOPE_LOCAL_CPU). Also rejetcs a late
    CPU, if it requires the defense, when the system hasn't enabled it,
    
    Cc: Will Deacon <will.deacon@arm.com>
    Reviewed-by: Dave Martin <dave.martin@arm.com>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 32354dd01c29c97b68b00e9816617d50b7f3659f
Author: Suzuki K Poulose <suzuki.poulose@arm.com>
Date:   Thu Oct 24 14:48:06 2019 +0200

    arm64: capabilities: Introduce weak features based on local CPU
    
    [ Upstream commit 5c137714dd8cae464dbd5f028c07af149e6d09fc ]
    
    Now that we have the flexibility of defining system features based
    on individual CPUs, introduce CPU feature type that can be detected
    on a local SCOPE and ignores the conflict on late CPUs. This is
    applicable for ARM64_HAS_NO_HW_PREFETCH, where it is fine for
    the system to have CPUs without hardware prefetch turning up
    later. We only suffer a performance penalty, nothing fatal.
    
    Cc: Will Deacon <will.deacon@arm.com>
    Reviewed-by: Dave Martin <dave.martin@arm.com>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f1696036165b7369ef73f96953c15d495ff60497
Author: Suzuki K Poulose <suzuki.poulose@arm.com>
Date:   Thu Oct 24 14:48:05 2019 +0200

    arm64: capabilities: Group handling of features and errata workarounds
    
    [ Upstream commit ed478b3f9e4ac97fdbe07007fb2662415de8fe25 ]
    
    Now that the features and errata workarounds have the same
    rules and flow, group the handling of the tables.
    
    Reviewed-by: Dave Martin <dave.martin@arm.com>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 33236e444f1c84b23ac265687578d2176640b2ba
Author: Suzuki K Poulose <suzuki.poulose@arm.com>
Date:   Thu Oct 24 14:48:04 2019 +0200

    arm64: capabilities: Allow features based on local CPU scope
    
    [ Upstream commit fbd890b9b8497bab04c1d338bd97579a7bc53fab ]
    
    So far we have treated the feature capabilities as system wide
    and this wouldn't help with features that could be detected locally
    on one or more CPUs (e.g, KPTI, Software prefetch). This patch
    splits the feature detection to two phases :
    
     1) Local CPU features are checked on all boot time active CPUs.
     2) System wide features are checked only once after all CPUs are
        active.
    
    Reviewed-by: Dave Martin <dave.martin@arm.com>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0a599aa7daca84b95335667162f530292e91e3d1
Author: Suzuki K Poulose <suzuki.poulose@arm.com>
Date:   Thu Oct 24 14:48:03 2019 +0200

    arm64: capabilities: Split the processing of errata work arounds
    
    [ Upstream commit d69fe9a7e7214d49fe157ec20889892388d0fe23 ]
    
    Right now we run through the errata workarounds check on all boot
    active CPUs, with SCOPE_ALL. This wouldn't help for detecting erratum
    workarounds with a SYSTEM_SCOPE. There are none yet, but we plan to
    introduce some: let us clean this up so that such workarounds can be
    detected and enabled correctly.
    
    So, we run the checks with SCOPE_LOCAL_CPU on all CPUs and SCOPE_SYSTEM
    checks are run only once after all the boot time CPUs are active.
    
    Reviewed-by: Dave Martin <dave.martin@arm.com>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 59118c737b4716cca063a9f35b4f4131774eaac5
Author: Suzuki K Poulose <suzuki.poulose@arm.com>
Date:   Thu Oct 24 14:48:02 2019 +0200

    arm64: capabilities: Prepare for grouping features and errata work arounds
    
    [ Upstream commit 600b9c919c2f4d07a7bf67864086aa3432224674 ]
    
    We are about to group the handling of all capabilities (features
    and errata workarounds). This patch open codes the wrapper routines
    to make it easier to merge the handling.
    
    Reviewed-by: Dave Martin <dave.martin@arm.com>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9e3fa8a15596061620b2e1cb203ef403e77fa8da
Author: Suzuki K Poulose <suzuki.poulose@arm.com>
Date:   Thu Oct 24 14:48:01 2019 +0200

    arm64: capabilities: Filter the entries based on a given mask
    
    [ Upstream commit cce360b54ce6ca1bcf4b0a870ec076d83606775e ]
    
    While processing the list of capabilities, it is useful to
    filter out some of the entries based on the given mask for the
    scope of the capabilities to allow better control. This can be
    used later for handling LOCAL vs SYSTEM wide capabilities and more.
    All capabilities should have their scope set to either LOCAL_CPU or
    SYSTEM. No functional/flow change.
    
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Reviewed-by: Dave Martin <dave.martin@arm.com>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a531333099332495a6222952dc2604f76bc0ba4
Author: Suzuki K Poulose <suzuki.poulose@arm.com>
Date:   Thu Oct 24 14:48:00 2019 +0200

    arm64: capabilities: Unify the verification
    
    [ Upstream commit eaac4d83daa50fc1b9b7850346e9a62adfd4647e ]
    
    Now that each capability describes how to treat the conflicts
    of CPU cap state vs System wide cap state, we can unify the
    verification logic to a single place.
    
    Reviewed-by: Dave Martin <dave.martin@arm.com>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 185b632259e87823a949373324ba1555b5e2b955
Author: Suzuki K Poulose <suzuki.poulose@arm.com>
Date:   Thu Oct 24 14:47:59 2019 +0200

    arm64: capabilities: Add flags to handle the conflicts on late CPU
    
    [ Upstream commit 5b4747c5dce7a873e1e7fe1608835825f714267a ]
    
    When a CPU is brought up, it is checked against the caps that are
    known to be enabled on the system (via verify_local_cpu_capabilities()).
    Based on the state of the capability on the CPU vs. that of System we
    could have the following combinations of conflict.
    
            x-----------------------------x
            | Type  | System   | Late CPU |
            |-----------------------------|
            |  a    |   y      |    n     |
            |-----------------------------|
            |  b    |   n      |    y     |
            x-----------------------------x
    
    Case (a) is not permitted for caps which are system features, which the
    system expects all the CPUs to have (e.g VHE). While (a) is ignored for
    all errata work arounds. However, there could be exceptions to the plain
    filtering approach. e.g, KPTI is an optional feature for a late CPU as
    long as the system already enables it.
    
    Case (b) is not permitted for errata work arounds that cannot be activated
    after the kernel has finished booting.And we ignore (b) for features. Here,
    yet again, KPTI is an exception, where if a late CPU needs KPTI we are too
    late to enable it (because we change the allocation of ASIDs etc).
    
    Add two different flags to indicate how the conflict should be handled.
    
     ARM64_CPUCAP_PERMITTED_FOR_LATE_CPU - CPUs may have the capability
     ARM64_CPUCAP_OPTIONAL_FOR_LATE_CPU - CPUs may not have the cappability.
    
    Now that we have the flags to describe the behavior of the errata and
    the features, as we treat them, define types for ERRATUM and FEATURE.
    
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Reviewed-by: Dave Martin <dave.martin@arm.com>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c21fc25e9b0d86f5f4ac5d3d549d6b611dd3541
Author: Suzuki K Poulose <suzuki.poulose@arm.com>
Date:   Thu Oct 24 14:47:58 2019 +0200

    arm64: capabilities: Prepare for fine grained capabilities
    
    [ Upstream commit 143ba05d867af34827faf99e0eed4de27106c7cb ]
    
    We use arm64_cpu_capabilities to represent CPU ELF HWCAPs exposed
    to the userspace and the CPU hwcaps used by the kernel, which
    include cpu features and CPU errata work arounds. Capabilities
    have some properties that decide how they should be treated :
    
     1) Detection, i.e scope : A cap could be "detected" either :
        - if it is present on at least one CPU (SCOPE_LOCAL_CPU)
            Or
        - if it is present on all the CPUs (SCOPE_SYSTEM)
    
     2) When is it enabled ? - A cap is treated as "enabled" when the
      system takes some action based on whether the capability is detected or
      not. e.g, setting some control register, patching the kernel code.
      Right now, we treat all caps are enabled at boot-time, after all
      the CPUs are brought up by the kernel. But there are certain caps,
      which are enabled early during the boot (e.g, VHE, GIC_CPUIF for NMI)
      and kernel starts using them, even before the secondary CPUs are brought
      up. We would need a way to describe this for each capability.
    
     3) Conflict on a late CPU - When a CPU is brought up, it is checked
      against the caps that are known to be enabled on the system (via
      verify_local_cpu_capabilities()). Based on the state of the capability
      on the CPU vs. that of System we could have the following combinations
      of conflict.
    
            x-----------------------------x
            | Type  | System   | Late CPU |
            ------------------------------|
            |  a    |   y      |    n     |
            ------------------------------|
            |  b    |   n      |    y     |
            x-----------------------------x
    
      Case (a) is not permitted for caps which are system features, which the
      system expects all the CPUs to have (e.g VHE). While (a) is ignored for
      all errata work arounds. However, there could be exceptions to the plain
      filtering approach. e.g, KPTI is an optional feature for a late CPU as
      long as the system already enables it.
    
      Case (b) is not permitted for errata work arounds which requires some
      work around, which cannot be delayed. And we ignore (b) for features.
      Here, yet again, KPTI is an exception, where if a late CPU needs KPTI we
      are too late to enable it (because we change the allocation of ASIDs
      etc).
    
    So this calls for a lot more fine grained behavior for each capability.
    And if we define all the attributes to control their behavior properly,
    we may be able to use a single table for the CPU hwcaps (which cover
    errata and features, not the ELF HWCAPs). This is a prepartory step
    to get there. More bits would be added for the properties listed above.
    
    We are going to use a bit-mask to encode all the properties of a
    capabilities. This patch encodes the "SCOPE" of the capability.
    
    As such there is no change in how the capabilities are treated.
    
    Cc: Mark Rutland <mark.rutland@arm.com>
    Reviewed-by: Dave Martin <dave.martin@arm.com>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e89e2a26f9969d1c8e422c7a288ee76c27d20a53
Author: Suzuki K Poulose <suzuki.poulose@arm.com>
Date:   Thu Oct 24 14:47:57 2019 +0200

    arm64: capabilities: Move errata processing code
    
    [ Upstream commit 1e89baed5d50d2b8d9fd420830902570270703f1 ]
    
    We have errata work around processing code in cpu_errata.c,
    which calls back into helpers defined in cpufeature.c. Now
    that we are going to make the handling of capabilities
    generic, by adding the information to each capability,
    move the errata work around specific processing code.
    No functional changes.
    
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: Marc Zyngier <marc.zyngier@arm.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Andre Przywara <andre.przywara@arm.com>
    Reviewed-by: Dave Martin <dave.martin@arm.com>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d56e7aa4116720bc4de761110f1bc9da6e5394c9
Author: Suzuki K Poulose <suzuki.poulose@arm.com>
Date:   Thu Oct 24 14:47:56 2019 +0200

    arm64: capabilities: Move errata work around check on boot CPU
    
    [ Upstream commit 5e91107b06811f0ca147cebbedce53626c9c4443 ]
    
    We trigger CPU errata work around check on the boot CPU from
    smp_prepare_boot_cpu() to make sure that we run the checks only
    after the CPU feature infrastructure is initialised. While this
    is correct, we can also do this from init_cpu_features() which
    initilises the infrastructure, and is called only on the
    Boot CPU. This helps to consolidate the CPU capability handling
    to cpufeature.c. No functional changes.
    
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Reviewed-by: Dave Martin <dave.martin@arm.com>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e606f018d76973b8c8d2b682eddf2633d825e25
Author: Dave Martin <dave.martin@arm.com>
Date:   Thu Oct 24 14:47:55 2019 +0200

    arm64: capabilities: Update prototype for enable call back
    
    [ Upstream commit c0cda3b8ee6b4b6851b2fd8b6db91fd7b0e2524a ]
    
    We issue the enable() call back for all CPU hwcaps capabilities
    available on the system, on all the CPUs. So far we have ignored
    the argument passed to the call back, which had a prototype to
    accept a "void *" for use with on_each_cpu() and later with
    stop_machine(). However, with commit 0a0d111d40fd1
    ("arm64: cpufeature: Pass capability structure to ->enable callback"),
    there are some users of the argument who wants the matching capability
    struct pointer where there are multiple matching criteria for a single
    capability. Clean up the declaration of the call back to make it clear.
    
     1) Renamed to cpu_enable(), to imply taking necessary actions on the
        called CPU for the entry.
     2) Pass const pointer to the capability, to allow the call back to
        check the entry. (e.,g to check if any action is needed on the CPU)
     3) We don't care about the result of the call back, turning this to
        a void.
    
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Andre Przywara <andre.przywara@arm.com>
    Cc: James Morse <james.morse@arm.com>
    Acked-by: Robin Murphy <robin.murphy@arm.com>
    Reviewed-by: Julien Thierry <julien.thierry@arm.com>
    Signed-off-by: Dave Martin <dave.martin@arm.com>
    [suzuki: convert more users, rename call back and drop results]
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1d0ee40ec243f516d8be09ae0d901566eff3ad8d
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Thu Oct 24 14:47:54 2019 +0200

    arm64: Introduce sysreg_clear_set()
    
    [ Upstream commit 6ebdf4db8fa564a150f46d32178af0873eb5abbb ]
    
    Currently we have a couple of helpers to manipulate bits in particular
    sysregs:
    
     * config_sctlr_el1(u32 clear, u32 set)
    
     * change_cpacr(u64 val, u64 mask)
    
    The parameters of these differ in naming convention, order, and size,
    which is unfortunate. They also differ slightly in behaviour, as
    change_cpacr() skips the sysreg write if the bits are unchanged, which
    is a useful optimization when sysreg writes are expensive.
    
    Before we gain yet another sysreg manipulation function, let's
    unify these with a common helper, providing a consistent order for
    clear/set operands, and the write skipping behaviour from
    change_cpacr(). Code will be migrated to the new helper in subsequent
    patches.
    
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Reviewed-by: Dave Martin <dave.martin@arm.com>
    Acked-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2fa1fc1f20b1e66cdefc567cf08b2b6ae900cc24
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Thu Oct 24 14:47:53 2019 +0200

    arm64: add PSR_AA32_* definitions
    
    [ Upstream commit 25086263425641c74123f9387426c23072b299ea ]
    
    The AArch32 CPSR/SPSR format is *almost* identical to the AArch64
    SPSR_ELx format for exceptions taken from AArch32, but the two have
    diverged with the addition of DIT, and we need to treat the two as
    logically distinct.
    
    This patch adds new definitions for the SPSR_ELx format for exceptions
    taken from AArch32, with a consistent PSR_AA32_ prefix. The existing
    COMPAT_PSR_ definitions will be used for the PSR format as seen from
    AArch32.
    
    Definitions of DIT are provided for both, and inline functions are
    provided to map between the two formats. Note that for SPSR_ELx, the
    (RES0) J bit has been re-allocated as the DIT bit.
    
    Once users of the COMPAT_PSR definitions have been migrated over to the
    PSR_AA32 definitions, the (majority of) the former will be removed, so
    no efforts is made to avoid duplication until then.
    
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Christoffer Dall <christoffer.dall@arm.com>
    Cc: Marc Zyngier <marc.zyngier@arm.com>
    Cc: Suzuki Poulose <suzuki.poulose@arm.com>
    Cc: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 31693d2f4efaf31f67410b6b3ed5afe6e46f7679
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Thu Oct 24 14:47:52 2019 +0200

    arm64: move SCTLR_EL{1,2} assertions to <asm/sysreg.h>
    
    [ Upstream commit 1c312e84c2d71da4101754fa6118f703f7473e01 ]
    
    Currently we assert that the SCTLR_EL{1,2}_{SET,CLEAR} bits are
    self-consistent with an assertion in config_sctlr_el1(). This is a bit
    unusual, since config_sctlr_el1() doesn't make use of these definitions,
    and is far away from the definitions themselves.
    
    We can use the CPP #error directive to have equivalent assertions in
    <asm/sysreg.h>, next to the definitions of the set/clear bits, which is
    a bit clearer and simpler.
    
    At the same time, lets fill in the upper 32 bits for both registers in
    their respective RES0 definitions. This could be a little nicer with
    GENMASK_ULL(63, 32), but this currently lives in <linux/bitops.h>, which
    cannot safely be included from assembly, as <asm/sysreg.h> can.
    
    Note the when the preprocessor evaluates an expression for an #if
    directive, all signed or unsigned values are treated as intmax_t or
    uintmax_t respectively. To avoid ambiguity, we define explicitly define
    the mask of all 64 bits.
    
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Acked-by: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Dave Martin <dave.martin@arm.com>
    Cc: James Morse <james.morse@arm.com>
    Cc: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 053cdffad3dd5e4a9330433ba2b400956f33bd2b
Author: Suzuki K Poulose <suzuki.poulose@arm.com>
Date:   Thu Oct 24 14:47:51 2019 +0200

    arm64: Expose Arm v8.4 features
    
    [ Upstream commit 7206dc93a58fb76421c4411eefa3c003337bcb2d ]
    
    Expose the new features introduced by Arm v8.4 extensions to
    Arm v8-A profile.
    
    These include :
    
     1) Data indpendent timing of instructions. (DIT, exposed as HWCAP_DIT)
     2) Unaligned atomic instructions and Single-copy atomicity of loads
        and stores. (AT, expose as HWCAP_USCAT)
     3) LDAPR and STLR instructions with immediate offsets (extension to
        LRCPC, exposed as HWCAP_ILRCPC)
     4) Flag manipulation instructions (TS, exposed as HWCAP_FLAGM).
    
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Reviewed-by: Dave Martin <dave.martin@arm.com>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    [ardb: fix up context for missing SVE]
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb952c6bce53b5389c41ffc3698594cb43b5aeb9
Author: Suzuki K Poulose <suzuki.poulose@arm.com>
Date:   Thu Oct 24 14:47:50 2019 +0200

    arm64: Documentation: cpu-feature-registers: Remove RES0 fields
    
    [ Upstream commit 847ecd3fa311cde0f10a1b66c572abb136742b1d ]
    
    Remove the invisible RES0 field entries from the table, listing
    fields in CPU ID feature registers, as :
     1) We are only interested in the user visible fields.
     2) The field description may not be up-to-date, as the
        field could be assigned a new meaning.
     3) We already explain the rules of the fields which are not
        visible.
    
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Will Deacon <will.deacon@arm.com>
    Acked-by: Mark Rutland <mark.rutland@arm.com>
    Reviewed-by: Dave Martin <dave.martin@arm.com>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    [ardb: fix up for missing SVE in context]
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1caa4f72dfc4a0401ec7fad210cfb0ed73d06b4d
Author: Dongjiu Geng <gengdongjiu@huawei.com>
Date:   Thu Oct 24 14:47:49 2019 +0200

    arm64: v8.4: Support for new floating point multiplication instructions
    
    [ Upstream commit 3b3b681097fae73b7f5dcdd42db6cfdf32943d4c ]
    
    ARM v8.4 extensions add new neon instructions for performing a
    multiplication of each FP16 element of one vector with the corresponding
    FP16 element of a second vector, and to add or subtract this without an
    intermediate rounding to the corresponding FP32 element in a third vector.
    
    This patch detects this feature and let the userspace know about it via a
    HWCAP bit and MRS emulation.
    
    Cc: Dave Martin <Dave.Martin@arm.com>
    Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
    Reviewed-by: Dave Martin <Dave.Martin@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    [ardb: fix up for missing SVE in context]
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit edcad64ed659810345a080e2aa16a16062a5e3ac
Author: Suzuki K Poulose <suzuki.poulose@arm.com>
Date:   Thu Oct 24 14:47:48 2019 +0200

    arm64: Fix the feature type for ID register fields
    
    [ Upstream commit 5bdecb7971572a1aef828df507558e7a4dfe25ec ]
    
    Now that the ARM ARM clearly specifies the rules for inferring
    the values of the ID register fields, fix the types of the
    feature bits we have in the kernel.
    
    As per ARM ARM DDI0487B.b, section D10.1.4 "Principles of the
    ID scheme for fields in ID registers" lists the registers to
    which the scheme applies along with the exceptions.
    
    This patch changes the relevant feature bits from FTR_EXACT
    to FTR_LOWER_SAFE to select the safer value. This will enable
    an older kernel running on a new CPU detect the safer option
    rather than completely disabling the feature.
    
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Dave Martin <dave.martin@arm.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5f005c7e4d37213a76a1d64ed558fe7e1ff138b6
Author: Suzuki K Poulose <suzuki.poulose@arm.com>
Date:   Thu Oct 24 14:47:47 2019 +0200

    arm64: Expose support for optional ARMv8-A features
    
    [ Upstream commit f5e035f8694c3bdddc66ea46ecda965ee6853718 ]
    
    ARMv8-A adds a few optional features for ARMv8.2 and ARMv8.3.
    Expose them to the userspace via HWCAPs and mrs emulation.
    
    SHA2-512  - Instruction support for SHA512 Hash algorithm (e.g SHA512H,
                SHA512H2, SHA512U0, SHA512SU1)
    SHA3      - SHA3 crypto instructions (EOR3, RAX1, XAR, BCAX).
    SM3       - Instruction support for Chinese cryptography algorithm SM3
    SM4       - Instruction support for Chinese cryptography algorithm SM4
    DP        - Dot Product instructions (UDOT, SDOT).
    
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Dave Martin <dave.martin@arm.com>
    Cc: Marc Zyngier <marc.zyngier@arm.com>
    Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec347012bbecf256764bafaa1a38931d6549a2ad
Author: James Morse <james.morse@arm.com>
Date:   Thu Oct 24 14:47:46 2019 +0200

    arm64: sysreg: Move to use definitions for all the SCTLR bits
    
    [ Upstream commit 7a00d68ebe5f07cb1db17e7fedfd031f0d87e8bb ]
    
    __cpu_setup() configures SCTLR_EL1 using some hard coded hex masks,
    and el2_setup() duplicates some this when setting RES1 bits.
    
    Lets make this the same as KVM's hyp_init, which uses named bits.
    
    First, we add definitions for all the SCTLR_EL{1,2} bits, the RES{1,0}
    bits, and those we want to set or clear.
    
    Add a build_bug checks to ensures all bits are either set or clear.
    This means we don't need to preserve endian-ness configuration
    generated elsewhere.
    
    Finally, move the head.S and proc.S users of these hard-coded masks
    over to the macro versions.
    
    Signed-off-by: James Morse <james.morse@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 312ab599be611fbd8995fbf0f9746e9b0bb686de
Author: Johan Hovold <johan@kernel.org>
Date:   Fri Oct 18 17:19:54 2019 +0200

    USB: ldusb: fix read info leaks
    
    commit 7a6f22d7479b7a0b68eadd308a997dd64dda7dae upstream.
    
    Fix broken read implementation, which could be used to trigger slab info
    leaks.
    
    The driver failed to check if the custom ring buffer was still empty
    when waking up after having waited for more data. This would happen on
    every interrupt-in completion, even if no data had been added to the
    ring buffer (e.g. on disconnect events).
    
    Due to missing sanity checks and uninitialised (kmalloced) ring-buffer
    entries, this meant that huge slab info leaks could easily be triggered.
    
    Note that the empty-buffer check after wakeup is enough to fix the info
    leak on disconnect, but let's clear the buffer on allocation and add a
    sanity check to read() to prevent further leaks.
    
    Fixes: 2824bd250f0b ("[PATCH] USB: add ldusb driver")
    Cc: stable <stable@vger.kernel.org>     # 2.6.13
    Reported-by: syzbot+6fe95b826644f7f12b0b@syzkaller.appspotmail.com
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://lore.kernel.org/r/20191018151955.25135-2-johan@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 05e3ff801c1b0ed86721661dd87c7171a29d5376
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Oct 15 19:55:22 2019 +0200

    USB: usblp: fix use-after-free on disconnect
    
    commit 7a759197974894213621aa65f0571b51904733d6 upstream.
    
    A recent commit addressing a runtime PM use-count regression, introduced
    a use-after-free by not making sure we held a reference to the struct
    usb_interface for the lifetime of the driver data.
    
    Fixes: 9a31535859bf ("USB: usblp: fix runtime PM after driver unbind")
    Cc: stable <stable@vger.kernel.org>
    Reported-by: syzbot+cd24df4d075c319ebfc5@syzkaller.appspotmail.com
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://lore.kernel.org/r/20191015175522.18490-1-johan@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8a927cbaf361e57671ea822b44048adf251d62a9
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Oct 10 14:58:34 2019 +0200

    USB: ldusb: fix memleak on disconnect
    
    commit b14a39048c1156cfee76228bf449852da2f14df8 upstream.
    
    If disconnect() races with release() after a process has been
    interrupted, release() could end up returning early and the driver would
    fail to free its driver data.
    
    Fixes: 2824bd250f0b ("[PATCH] USB: add ldusb driver")
    Cc: stable <stable@vger.kernel.org>     # 2.6.13
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://lore.kernel.org/r/20191010125835.27031-2-johan@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a1f27405201eb6268f82bf9f00631a3350ae2786
Author: Johan Hovold <johan@kernel.org>
Date:   Fri Oct 11 11:57:35 2019 +0200

    USB: serial: ti_usb_3410_5052: fix port-close races
    
    commit 6f1d1dc8d540a9aa6e39b9cb86d3a67bbc1c8d8d upstream.
    
    Fix races between closing a port and opening or closing another port on
    the same device which could lead to a failure to start or stop the
    shared interrupt URB. The latter could potentially cause a
    use-after-free or worse in the completion handler on driver unbind.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e90c15a897d29d8482b53f9cede6da7b42cb7d32
Author: Gustavo A. R. Silva <gustavo@embeddedor.com>
Date:   Mon Oct 14 14:18:30 2019 -0500

    usb: udc: lpc32xx: fix bad bit shift operation
    
    commit b987b66ac3a2bc2f7b03a0ba48a07dc553100c07 upstream.
    
    It seems that the right variable to use in this case is *i*, instead of
    *n*, otherwise there is an undefined behavior when right shifiting by more
    than 31 bits when multiplying n by 8; notice that *n* can take values
    equal or greater than 4 (4, 8, 16, ...).
    
    Also, notice that under the current conditions (bl = 3), we are skiping
    the handling of bytes 3, 7, 31... So, fix this by updating this logic
    and limit *bl* up to 4 instead of up to 3.
    
    This fix is based on function udc_stuff_fifo().
    
    Addresses-Coverity-ID: 1454834 ("Bad bit shift operation")
    Fixes: 24a28e428351 ("USB: gadget driver for LPC32xx")
    Cc: stable@vger.kernel.org
    Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
    Link: https://lore.kernel.org/r/20191014191830.GA10721@embeddedor
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ffe87d720053202713f9f2a02bb888e8d97015bc
Author: Kailang Yang <kailang@realtek.com>
Date:   Thu May 2 16:03:26 2019 +0800

    ALSA: hda/realtek - Add support for ALC711
    
    commit 83629532ce45ef9df1f297b419b9ea112045685d upstream.
    
    Support new codec ALC711.
    
    Signed-off-by: Kailang Yang <kailang@realtek.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ddc87ec6918baf53962077123875acb015d8c41c
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Oct 10 14:58:35 2019 +0200

    USB: legousbtower: fix memleak on disconnect
    
    commit b6c03e5f7b463efcafd1ce141bd5a8fc4e583ae2 upstream.
    
    If disconnect() races with release() after a process has been
    interrupted, release() could end up returning early and the driver would
    fail to free its driver data.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://lore.kernel.org/r/20191010125835.27031-3-johan@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 391d4ee568b546c9900cc058b82d290e2f71a99c
Author: Matthew Wilcox (Oracle) <willy@infradead.org>
Date:   Fri Oct 25 09:58:35 2019 -0700

    memfd: Fix locking when tagging pins
    
    The RCU lock is insufficient to protect the radix tree iteration as
    a deletion from the tree can occur before we take the spinlock to
    tag the entry.  In 4.19, this has manifested as a bug with the following
    trace:
    
    kernel BUG at lib/radix-tree.c:1429!
    invalid opcode: 0000 [#1] SMP KASAN PTI
    CPU: 7 PID: 6935 Comm: syz-executor.2 Not tainted 4.19.36 #25
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
    RIP: 0010:radix_tree_tag_set+0x200/0x2f0 lib/radix-tree.c:1429
    Code: 00 00 5b 5d 41 5c 41 5d 41 5e 41 5f c3 48 89 44 24 10 e8 a3 29 7e fe 48 8b 44 24 10 48 0f ab 03 e9 d2 fe ff ff e8 90 29 7e fe <0f> 0b 48 c7 c7 e0 5a 87 84 e8 f0 e7 08 ff 4c 89 ef e8 4a ff ac fe
    RSP: 0018:ffff88837b13fb60 EFLAGS: 00010016
    RAX: 0000000000040000 RBX: ffff8883c5515d58 RCX: ffffffff82cb2ef0
    RDX: 0000000000000b72 RSI: ffffc90004cf2000 RDI: ffff8883c5515d98
    RBP: ffff88837b13fb98 R08: ffffed106f627f7e R09: ffffed106f627f7e
    R10: 0000000000000001 R11: ffffed106f627f7d R12: 0000000000000004
    R13: ffffea000d7fea80 R14: 1ffff1106f627f6f R15: 0000000000000002
    FS:  00007fa1b8df2700(0000) GS:ffff8883e2fc0000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007fa1b8df1db8 CR3: 000000037d4d2001 CR4: 0000000000160ee0
    Call Trace:
     memfd_tag_pins mm/memfd.c:51 [inline]
     memfd_wait_for_pins+0x2c5/0x12d0 mm/memfd.c:81
     memfd_add_seals mm/memfd.c:215 [inline]
     memfd_fcntl+0x33d/0x4a0 mm/memfd.c:247
     do_fcntl+0x589/0xeb0 fs/fcntl.c:421
     __do_sys_fcntl fs/fcntl.c:463 [inline]
     __se_sys_fcntl fs/fcntl.c:448 [inline]
     __x64_sys_fcntl+0x12d/0x180 fs/fcntl.c:448
     do_syscall_64+0xc8/0x580 arch/x86/entry/common.c:293
    
    The problem does not occur in mainline due to the XArray rewrite which
    changed the locking to exclude modification of the tree during iteration.
    At the time, nobody realised this was a bugfix.  Backport the locking
    changes to stable.
    
    Cc: stable@vger.kernel.org
    Reported-by: zhong jiang <zhongjiang@huawei.com>
    Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 48a8f3c2081e83fcaa0ff7c4340f955eb9c55409
Author: Alessio Balsini <balsini@android.com>
Date:   Wed Oct 23 18:17:36 2019 +0100

    loop: Add LOOP_SET_DIRECT_IO to compat ioctl
    
    [ Upstream commit fdbe4eeeb1aac219b14f10c0ed31ae5d1123e9b8 ]
    
    Enabling Direct I/O with loop devices helps reducing memory usage by
    avoiding double caching.  32 bit applications running on 64 bits systems
    are currently not able to request direct I/O because is missing from the
    lo_compat_ioctl.
    
    This patch fixes the compatibility issue mentioned above by exporting
    LOOP_SET_DIRECT_IO as additional lo_compat_ioctl() entry.
    The input argument for this ioctl is a single long converted to a 1-bit
    boolean, so compatibility is preserved.
    
    Cc: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Alessio Balsini <balsini@android.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eccfa2109a545a16f0feace4b60da881b3a23082
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Oct 14 11:22:30 2019 -0700

    net: avoid potential infinite loop in tc_ctl_action()
    
    [ Upstream commit 39f13ea2f61b439ebe0060393e9c39925c9ee28c ]
    
    tc_ctl_action() has the ability to loop forever if tcf_action_add()
    returns -EAGAIN.
    
    This special case has been done in case a module needed to be loaded,
    but it turns out that tcf_add_notify() could also return -EAGAIN
    if the socket sk_rcvbuf limit is hit.
    
    We need to separate the two cases, and only loop for the module
    loading case.
    
    While we are at it, add a limit of 10 attempts since unbounded
    loops are always scary.
    
    syzbot repro was something like :
    
    socket(PF_NETLINK, SOCK_RAW|SOCK_NONBLOCK, NETLINK_ROUTE) = 3
    write(3, ..., 38) = 38
    setsockopt(3, SOL_SOCKET, SO_RCVBUF, [0], 4) = 0
    sendmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{..., 388}], msg_controllen=0, msg_flags=0x10}, ...)
    
    NMI backtrace for cpu 0
    CPU: 0 PID: 1054 Comm: khungtaskd Not tainted 5.4.0-rc1+ #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Call Trace:
     __dump_stack lib/dump_stack.c:77 [inline]
     dump_stack+0x172/0x1f0 lib/dump_stack.c:113
     nmi_cpu_backtrace.cold+0x70/0xb2 lib/nmi_backtrace.c:101
     nmi_trigger_cpumask_backtrace+0x23b/0x28b lib/nmi_backtrace.c:62
     arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
     trigger_all_cpu_backtrace include/linux/nmi.h:146 [inline]
     check_hung_uninterruptible_tasks kernel/hung_task.c:205 [inline]
     watchdog+0x9d0/0xef0 kernel/hung_task.c:289
     kthread+0x361/0x430 kernel/kthread.c:255
     ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
    Sending NMI from CPU 0 to CPUs 1:
    NMI backtrace for cpu 1
    CPU: 1 PID: 8859 Comm: syz-executor910 Not tainted 5.4.0-rc1+ #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    RIP: 0010:arch_local_save_flags arch/x86/include/asm/paravirt.h:751 [inline]
    RIP: 0010:lockdep_hardirqs_off+0x1df/0x2e0 kernel/locking/lockdep.c:3453
    Code: 5c 08 00 00 5b 41 5c 41 5d 5d c3 48 c7 c0 58 1d f3 88 48 ba 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c 10 00 0f 85 d3 00 00 00 <48> 83 3d 21 9e 99 07 00 0f 84 b9 00 00 00 9c 58 0f 1f 44 00 00 f6
    RSP: 0018:ffff8880a6f3f1b8 EFLAGS: 00000046
    RAX: 1ffffffff11e63ab RBX: ffff88808c9c6080 RCX: 0000000000000000
    RDX: dffffc0000000000 RSI: 0000000000000000 RDI: ffff88808c9c6914
    RBP: ffff8880a6f3f1d0 R08: ffff88808c9c6080 R09: fffffbfff16be5d1
    R10: fffffbfff16be5d0 R11: 0000000000000003 R12: ffffffff8746591f
    R13: ffff88808c9c6080 R14: ffffffff8746591f R15: 0000000000000003
    FS:  00000000011e4880(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: ffffffffff600400 CR3: 00000000a8920000 CR4: 00000000001406e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     trace_hardirqs_off+0x62/0x240 kernel/trace/trace_preemptirq.c:45
     __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline]
     _raw_spin_lock_irqsave+0x6f/0xcd kernel/locking/spinlock.c:159
     __wake_up_common_lock+0xc8/0x150 kernel/sched/wait.c:122
     __wake_up+0xe/0x10 kernel/sched/wait.c:142
     netlink_unlock_table net/netlink/af_netlink.c:466 [inline]
     netlink_unlock_table net/netlink/af_netlink.c:463 [inline]
     netlink_broadcast_filtered+0x705/0xb80 net/netlink/af_netlink.c:1514
     netlink_broadcast+0x3a/0x50 net/netlink/af_netlink.c:1534
     rtnetlink_send+0xdd/0x110 net/core/rtnetlink.c:714
     tcf_add_notify net/sched/act_api.c:1343 [inline]
     tcf_action_add+0x243/0x370 net/sched/act_api.c:1362
     tc_ctl_action+0x3b5/0x4bc net/sched/act_api.c:1410
     rtnetlink_rcv_msg+0x463/0xb00 net/core/rtnetlink.c:5386
     netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477
     rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5404
     netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline]
     netlink_unicast+0x531/0x710 net/netlink/af_netlink.c:1328
     netlink_sendmsg+0x8a5/0xd60 net/netlink/af_netlink.c:1917
     sock_sendmsg_nosec net/socket.c:637 [inline]
     sock_sendmsg+0xd7/0x130 net/socket.c:657
     ___sys_sendmsg+0x803/0x920 net/socket.c:2311
     __sys_sendmsg+0x105/0x1d0 net/socket.c:2356
     __do_sys_sendmsg net/socket.c:2365 [inline]
     __se_sys_sendmsg net/socket.c:2363 [inline]
     __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2363
     do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290
     entry_SYSCALL_64_after_hwframe+0x49/0xbe
    RIP: 0033:0x440939
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot+cf0adbb9c28c8866c788@syzkaller.appspotmail.com
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dce4350a1dd4a71ec52e463043aca2f446064507
Author: Xin Long <lucien.xin@gmail.com>
Date:   Tue Oct 15 15:24:38 2019 +0800

    sctp: change sctp_prot .no_autobind with true
    
    [ Upstream commit 63dfb7938b13fa2c2fbcb45f34d065769eb09414 ]
    
    syzbot reported a memory leak:
    
      BUG: memory leak, unreferenced object 0xffff888120b3d380 (size 64):
      backtrace:
    
        [...] slab_alloc mm/slab.c:3319 [inline]
        [...] kmem_cache_alloc+0x13f/0x2c0 mm/slab.c:3483
        [...] sctp_bucket_create net/sctp/socket.c:8523 [inline]
        [...] sctp_get_port_local+0x189/0x5a0 net/sctp/socket.c:8270
        [...] sctp_do_bind+0xcc/0x200 net/sctp/socket.c:402
        [...] sctp_bindx_add+0x4b/0xd0 net/sctp/socket.c:497
        [...] sctp_setsockopt_bindx+0x156/0x1b0 net/sctp/socket.c:1022
        [...] sctp_setsockopt net/sctp/socket.c:4641 [inline]
        [...] sctp_setsockopt+0xaea/0x2dc0 net/sctp/socket.c:4611
        [...] sock_common_setsockopt+0x38/0x50 net/core/sock.c:3147
        [...] __sys_setsockopt+0x10f/0x220 net/socket.c:2084
        [...] __do_sys_setsockopt net/socket.c:2100 [inline]
    
    It was caused by when sending msgs without binding a port, in the path:
    inet_sendmsg() -> inet_send_prepare() -> inet_autobind() ->
    .get_port/sctp_get_port(), sp->bind_hash will be set while bp->port is
    not. Later when binding another port by sctp_setsockopt_bindx(), a new
    bucket will be created as bp->port is not set.
    
    sctp's autobind is supposed to call sctp_autobind() where it does all
    things including setting bp->port. Since sctp_autobind() is called in
    sctp_sendmsg() if the sk is not yet bound, it should have skipped the
    auto bind.
    
    THis patch is to avoid calling inet_autobind() in inet_send_prepare()
    by changing sctp_prot .no_autobind with true, also remove the unused
    .get_port.
    
    Reported-by: syzbot+d44f7bbebdea49dbc84a@syzkaller.appspotmail.com
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 80a0e5d378f8ad8cb086d4018389ebec75f45fb2
Author: Biao Huang <biao.huang@mediatek.com>
Date:   Tue Oct 15 11:24:44 2019 +0800

    net: stmmac: disable/enable ptp_ref_clk in suspend/resume flow
    
    [ Upstream commit e497c20e203680aba9ccf7bb475959595908ca7e ]
    
    disable ptp_ref_clk in suspend flow, and enable it in resume flow.
    
    Fixes: f573c0b9c4e0 ("stmmac: move stmmac_clk, pclk, clk_ptp_ref and stmmac_rst to platform structure")
    Signed-off-by: Biao Huang <biao.huang@mediatek.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e354aa381a670805996481b748d2f86106f9bbe4
Author: Thomas Bogendoerfer <tbogendoerfer@suse.de>
Date:   Tue Oct 15 16:42:45 2019 +0200

    net: i82596: fix dma_alloc_attr for sni_82596
    
    [ Upstream commit 61c1d33daf7b5146f44d4363b3322f8cda6a6c43 ]
    
    Commit 7f683b920479 ("i825xx: switch to switch to dma_alloc_attrs")
    switched dma allocation over to dma_alloc_attr, but didn't convert
    the SNI part to request consistent DMA memory. This broke sni_82596
    since driver doesn't do dma_cache_sync for performance reasons.
    Fix this by using different DMA_ATTRs for lasi_82596 and sni_82596.
    
    Fixes: 7f683b920479 ("i825xx: switch to switch to dma_alloc_attrs")
    Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0f99c6bbe277bfb6836d9345630a8f23d3aeac9e
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Fri Oct 11 12:53:49 2019 -0700

    net: bcmgenet: Set phydev->dev_flags only for internal PHYs
    
    [ Upstream commit 92696286f3bb37ba50e4bd8d1beb24afb759a799 ]
    
    phydev->dev_flags is entirely dependent on the PHY device driver which
    is going to be used, setting the internal GENET PHY revision in those
    bits only makes sense when drivers/net/phy/bcm7xxx.c is the PHY driver
    being used.
    
    Fixes: 487320c54143 ("net: bcmgenet: communicate integrated PHY revision to PHY driver")
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Acked-by: Doug Berger <opendmb@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 46ecabab8d82a851971e3b9ccf1fe3f629248ad3
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Tue Oct 15 10:45:47 2019 -0700

    net: bcmgenet: Fix RGMII_MODE_EN value for GENET v1/2/3
    
    [ Upstream commit efb86fede98cdc70b674692ff617b1162f642c49 ]
    
    The RGMII_MODE_EN bit value was 0 for GENET versions 1 through 3, and
    became 6 for GENET v4 and above, account for that difference.
    
    Fixes: aa09677cba42 ("net: bcmgenet: add MDIO routines")
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Acked-by: Doug Berger <opendmb@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 41e506d842f8edcec933fddfc6c49e08aea77ab9
Author: Stefano Brivio <sbrivio@redhat.com>
Date:   Wed Oct 16 20:52:09 2019 +0200

    ipv4: Return -ENETUNREACH if we can't create route but saddr is valid
    
    [ Upstream commit 595e0651d0296bad2491a4a29a7a43eae6328b02 ]
    
    ...instead of -EINVAL. An issue was found with older kernel versions
    while unplugging a NFS client with pending RPCs, and the wrong error
    code here prevented it from recovering once link is back up with a
    configured address.
    
    Incidentally, this is not an issue anymore since commit 4f8943f80883
    ("SUNRPC: Replace direct task wakeups from softirq context"), included
    in 5.2-rc7, had the effect of decoupling the forwarding of this error
    by using SO_ERROR in xs_wake_error(), as pointed out by Benjamin
    Coddington.
    
    To the best of my knowledge, this isn't currently causing any further
    issue, but the error code doesn't look appropriate anyway, and we
    might hit this in other paths as well.
    
    In detail, as analysed by Gonzalo Siero, once the route is deleted
    because the interface is down, and can't be resolved and we return
    -EINVAL here, this ends up, courtesy of inet_sk_rebuild_header(),
    as the socket error seen by tcp_write_err(), called by
    tcp_retransmit_timer().
    
    In turn, tcp_write_err() indirectly calls xs_error_report(), which
    wakes up the RPC pending tasks with a status of -EINVAL. This is then
    seen by call_status() in the SUN RPC implementation, which aborts the
    RPC call calling rpc_exit(), instead of handling this as a
    potentially temporary condition, i.e. as a timeout.
    
    Return -EINVAL only if the input parameters passed to
    ip_route_output_key_hash_rcu() are actually invalid (this is the case
    if the specified source address is multicast, limited broadcast or
    all zeroes), but return -ENETUNREACH in all cases where, at the given
    moment, the given source address doesn't allow resolving the route.
    
    While at it, drop the initialisation of err to -ENETUNREACH, which
    was added to __ip_route_output_key() back then by commit
    0315e3827048 ("net: Fix behaviour of unreachable, blackhole and
    prohibit routes"), but actually had no effect, as it was, and is,
    overwritten by the fib_lookup() return code assignment, and anyway
    ignored in all other branches, including the if (fl4->saddr) one:
    I find this rather confusing, as it would look like -ENETUNREACH is
    the "default" error, while that statement has no effect.
    
    Also note that after commit fc75fc8339e7 ("ipv4: dont create routes
    on down devices"), we would get -ENETUNREACH if the device is down,
    but -EINVAL if the source address is specified and we can't resolve
    the route, and this appears to be rather inconsistent.
    
    Reported-by: Stefan Walter <walteste@inf.ethz.ch>
    Analysed-by: Benjamin Coddington <bcodding@redhat.com>
    Analysed-by: Gonzalo Siero <gsierohu@redhat.com>
    Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 777b3745558a8a308d23719bfa9ec124a75b649b
Author: Yi Li <yilikernel@gmail.com>
Date:   Fri Oct 18 20:20:08 2019 -0700

    ocfs2: fix panic due to ocfs2_wq is null
    
    commit b918c43021baaa3648de09e19a4a3dd555a45f40 upstream.
    
    mount.ocfs2 failed when reading ocfs2 filesystem superblock encounters
    an error.  ocfs2_initialize_super() returns before allocating ocfs2_wq.
    ocfs2_dismount_volume() triggers the following panic.
    
      Oct 15 16:09:27 cnwarekv-205120 kernel: On-disk corruption discovered.Please run fsck.ocfs2 once the filesystem is unmounted.
      Oct 15 16:09:27 cnwarekv-205120 kernel: (mount.ocfs2,22804,44): ocfs2_read_locked_inode:537 ERROR: status = -30
      Oct 15 16:09:27 cnwarekv-205120 kernel: (mount.ocfs2,22804,44): ocfs2_init_global_system_inodes:458 ERROR: status = -30
      Oct 15 16:09:27 cnwarekv-205120 kernel: (mount.ocfs2,22804,44): ocfs2_init_global_system_inodes:491 ERROR: status = -30
      Oct 15 16:09:27 cnwarekv-205120 kernel: (mount.ocfs2,22804,44): ocfs2_initialize_super:2313 ERROR: status = -30
      Oct 15 16:09:27 cnwarekv-205120 kernel: (mount.ocfs2,22804,44): ocfs2_fill_super:1033 ERROR: status = -30
      ------------[ cut here ]------------
      Oops: 0002 [#1] SMP NOPTI
      CPU: 1 PID: 11753 Comm: mount.ocfs2 Tainted: G  E
            4.14.148-200.ckv.x86_64 #1
      Hardware name: Sugon H320-G30/35N16-US, BIOS 0SSDX017 12/21/2018
      task: ffff967af0520000 task.stack: ffffa5f05484000
      RIP: 0010:mutex_lock+0x19/0x20
      Call Trace:
        flush_workqueue+0x81/0x460
        ocfs2_shutdown_local_alloc+0x47/0x440 [ocfs2]
        ocfs2_dismount_volume+0x84/0x400 [ocfs2]
        ocfs2_fill_super+0xa4/0x1270 [ocfs2]
        ? ocfs2_initialize_super.isa.211+0xf20/0xf20 [ocfs2]
        mount_bdev+0x17f/0x1c0
        mount_fs+0x3a/0x160
    
    Link: http://lkml.kernel.org/r/1571139611-24107-1-git-send-email-yili@winhong.com
    Signed-off-by: Yi Li <yilikernel@gmail.com>
    Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
    Cc: Mark Fasheh <mark@fasheh.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Junxiao Bi <junxiao.bi@oracle.com>
    Cc: Changwei Ge <gechangwei@live.cn>
    Cc: Gang He <ghe@suse.com>
    Cc: Jun Piao <piaojun@huawei.com>
    Cc: <stable@vger.kernel.org>
    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 2e18e22063986658f0ebfb90f742ab1f6e378f33
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed Oct 9 13:12:37 2019 -0500

    Revert "drm/radeon: Fix EEH during kexec"
    
    [ Upstream commit 8d13c187c42e110625d60094668a8f778c092879 ]
    
    This reverts commit 6f7fe9a93e6c09bf988c5059403f5f88e17e21e6.
    
    This breaks some boards.  Maybe just enable this on PPC for
    now?
    
    Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205147
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5f58cb078e2ecf7c1cac0b9ef4f1cb78f6c6a515
Author: Song Liu <songliubraving@fb.com>
Date:   Mon Oct 14 16:58:35 2019 -0700

    md/raid0: fix warning message for parameter default_layout
    
    [ Upstream commit 3874d73e06c9b9dc15de0b7382fc223986d75571 ]
    
    The message should match the parameter, i.e. raid0.default_layout.
    
    Fixes: c84a1372df92 ("md/raid0: avoid RAID0 data corruption due to layout confusion.")
    Cc: NeilBrown <neilb@suse.de>
    Reported-by: Ivan Topolsky <doktor.yak@gmail.com>
    Signed-off-by: Song Liu <songliubraving@fb.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bf08b7689097e8aea1769d2e4679bbf2d333b76a
Author: Jacob Keller <jacob.e.keller@intel.com>
Date:   Fri Sep 27 16:30:27 2019 -0700

    namespace: fix namespace.pl script to support relative paths
    
    [ Upstream commit 82fdd12b95727640c9a8233c09d602e4518e71f7 ]
    
    The namespace.pl script does not work properly if objtree is not set to
    an absolute path. The do_nm function is run from within the find
    function, which changes directories.
    
    Because of this, appending objtree, $File::Find::dir, and $source, will
    return a path which is not valid from the current directory.
    
    This used to work when objtree was set to an absolute path when using
    "make namespacecheck". It appears to have not worked when calling
    ./scripts/namespace.pl directly.
    
    This behavior was changed in 7e1c04779efd ("kbuild: Use relative path
    for $(objtree)", 2014-05-14)
    
    Rather than fixing the Makefile to set objtree to an absolute path, just
    fix namespace.pl to work when srctree and objtree are relative. Also fix
    the script to use an absolute path for these by default.
    
    Use the File::Spec module for this purpose. It's been part of perl
    5 since 5.005.
    
    The curdir() function is used to get the current directory when the
    objtree and srctree aren't set in the environment.
    
    rel2abs() is used to convert possibly relative objtree and srctree
    environment variables to absolute paths.
    
    Finally, the catfile() function is used instead of string appending
    paths together, since this is more robust when joining paths together.
    
    Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
    Acked-by: Randy Dunlap <rdunlap@infradead.org>
    Tested-by: Randy Dunlap <rdunlap@infradead.org>
    Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e74a4dc8f2dbcf7819a0c3209db9147a63d82e99
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Fri Oct 4 20:51:04 2019 +0800

    r8152: Set macpassthru in reset_resume callback
    
    [ Upstream commit a54cdeeb04fc719e4c7f19d6e28dba7ea86cee5b ]
    
    r8152 may fail to establish network connection after resume from system
    suspend.
    
    If the USB port connects to r8152 lost its power during system suspend,
    the MAC address was written before is lost. The reason is that The MAC
    address doesn't get written again in its reset_resume callback.
    
    So let's set MAC address again in reset_resume callback. Also remove
    unnecessary lock as no other locking attempt will happen during
    reset_resume.
    
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 875adfc28894262bead3e1c230c1dabcac0b63b5
Author: Yizhuo <yzhai003@ucr.edu>
Date:   Tue Oct 1 13:24:39 2019 -0700

    net: hisilicon: Fix usage of uninitialized variable in function mdio_sc_cfg_reg_write()
    
    [ Upstream commit 53de429f4e88f538f7a8ec2b18be8c0cd9b2c8e1 ]
    
    In function mdio_sc_cfg_reg_write(), variable "reg_value" could be
    uninitialized if regmap_read() fails. However, "reg_value" is used
    to decide the control flow later in the if statement, which is
    potentially unsafe.
    
    Signed-off-by: Yizhuo <yzhai003@ucr.edu>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4f6ba331e558372ede14b96c34f845b434fc3126
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Tue Sep 10 05:59:07 2019 +0200

    mips: Loongson: Fix the link time qualifier of 'serial_exit()'
    
    [ Upstream commit 25b69a889b638b0b7e51e2c4fe717a66bec0e566 ]
    
    'exit' functions should be marked as __exit, not __init.
    
    Fixes: 85cc028817ef ("mips: make loongsoon serial driver explicitly modular")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Paul Burton <paul.burton@mips.com>
    Cc: chenhc@lemote.com
    Cc: ralf@linux-mips.org
    Cc: jhogan@kernel.org
    Cc: linux-mips@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Cc: kernel-janitors@vger.kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2f431407aba68d77b6baa5dab044b074fb6cfc4a
Author: Miaoqing Pan <miaoqing@codeaurora.org>
Date:   Fri Sep 27 10:03:16 2019 +0800

    mac80211: fix txq null pointer dereference
    
    [ Upstream commit 8ed31a264065ae92058ce54aa3cc8da8d81dc6d7 ]
    
    If the interface type is P2P_DEVICE or NAN, read the file of
    '/sys/kernel/debug/ieee80211/phyx/netdev:wlanx/aqm' will get a
    NULL pointer dereference. As for those interface type, the
    pointer sdata->vif.txq is NULL.
    
    Unable to handle kernel NULL pointer dereference at virtual address 00000011
    CPU: 1 PID: 30936 Comm: cat Not tainted 4.14.104 #1
    task: ffffffc0337e4880 task.stack: ffffff800cd20000
    PC is at ieee80211_if_fmt_aqm+0x34/0xa0 [mac80211]
    LR is at ieee80211_if_fmt_aqm+0x34/0xa0 [mac80211]
    [...]
    Process cat (pid: 30936, stack limit = 0xffffff800cd20000)
    [...]
    [<ffffff8000b7cd00>] ieee80211_if_fmt_aqm+0x34/0xa0 [mac80211]
    [<ffffff8000b7c414>] ieee80211_if_read+0x60/0xbc [mac80211]
    [<ffffff8000b7ccc4>] ieee80211_if_read_aqm+0x28/0x30 [mac80211]
    [<ffffff80082eff94>] full_proxy_read+0x2c/0x48
    [<ffffff80081eef00>] __vfs_read+0x2c/0xd4
    [<ffffff80081ef084>] vfs_read+0x8c/0x108
    [<ffffff80081ef494>] SyS_read+0x40/0x7c
    
    Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
    Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>
    Link: https://lore.kernel.org/r/1569549796-8223-1-git-send-email-miaoqing@codeaurora.org
    [trim useless data from commit message]
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5ccdcbeb3107e9c00180e8ddbbbcb9147f157adf
Author: Miaoqing Pan <miaoqing@codeaurora.org>
Date:   Thu Sep 26 16:16:50 2019 +0800

    nl80211: fix null pointer dereference
    
    [ Upstream commit b501426cf86e70649c983c52f4c823b3c40d72a3 ]
    
    If the interface is not in MESH mode, the command 'iw wlanx mpath del'
    will cause kernel panic.
    
    The root cause is null pointer access in mpp_flush_by_proxy(), as the
    pointer 'sdata->u.mesh.mpp_paths' is NULL for non MESH interface.
    
    Unable to handle kernel NULL pointer dereference at virtual address 00000068
    [...]
    PC is at _raw_spin_lock_bh+0x20/0x5c
    LR is at mesh_path_del+0x1c/0x17c [mac80211]
    [...]
    Process iw (pid: 4537, stack limit = 0xd83e0238)
    [...]
    [<c021211c>] (_raw_spin_lock_bh) from [<bf8c7648>] (mesh_path_del+0x1c/0x17c [mac80211])
    [<bf8c7648>] (mesh_path_del [mac80211]) from [<bf6cdb7c>] (extack_doit+0x20/0x68 [compat])
    [<bf6cdb7c>] (extack_doit [compat]) from [<c05c309c>] (genl_rcv_msg+0x274/0x30c)
    [<c05c309c>] (genl_rcv_msg) from [<c05c25d8>] (netlink_rcv_skb+0x58/0xac)
    [<c05c25d8>] (netlink_rcv_skb) from [<c05c2e14>] (genl_rcv+0x20/0x34)
    [<c05c2e14>] (genl_rcv) from [<c05c1f90>] (netlink_unicast+0x11c/0x204)
    [<c05c1f90>] (netlink_unicast) from [<c05c2420>] (netlink_sendmsg+0x30c/0x370)
    [<c05c2420>] (netlink_sendmsg) from [<c05886d0>] (sock_sendmsg+0x70/0x84)
    [<c05886d0>] (sock_sendmsg) from [<c0589f4c>] (___sys_sendmsg.part.3+0x188/0x228)
    [<c0589f4c>] (___sys_sendmsg.part.3) from [<c058add4>] (__sys_sendmsg+0x4c/0x70)
    [<c058add4>] (__sys_sendmsg) from [<c0208c80>] (ret_fast_syscall+0x0/0x44)
    Code: e2822c02 e2822001 e5832004 f590f000 (e1902f9f)
    ---[ end trace bbd717600f8f884d ]---
    
    Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
    Link: https://lore.kernel.org/r/1569485810-761-1-git-send-email-miaoqing@codeaurora.org
    [trim useless data from commit message]
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cfb7eab6cab9f96f888c82ebed019163de53b872
Author: Ross Lagerwall <ross.lagerwall@citrix.com>
Date:   Fri Sep 27 16:49:20 2019 +0100

    xen/efi: Set nonblocking callbacks
    
    [ Upstream commit df359f0d09dc029829b66322707a2f558cb720f7 ]
    
    Other parts of the kernel expect these nonblocking EFI callbacks to
    exist and crash when running under Xen. Since the implementations of
    xen_efi_set_variable() and xen_efi_query_variable_info() do not take any
    locks, use them for the nonblocking callbacks too.
    
    Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2f327a23a93c5d5da73f80ae6f5131868d509b97
Author: Oleksij Rempel <o.rempel@pengutronix.de>
Date:   Mon Sep 30 11:39:52 2019 +0200

    MIPS: dts: ar9331: fix interrupt-controller size
    
    [ Upstream commit 0889d07f3e4b171c453b2aaf2b257f9074cdf624 ]
    
    It is two registers each of 4 byte.
    
    Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Signed-off-by: Paul Burton <paul.burton@mips.com>
    Cc: Rob Herring <robh+dt@kernel.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: James Hogan <jhogan@kernel.org>
    Cc: devicetree@vger.kernel.org
    Cc: linux-mips@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2a21025504e7494932f0b3c926b1bafb0eb75ba3
Author: Michal Vokáč <michal.vokac@ysoft.com>
Date:   Thu Sep 26 10:59:17 2019 +0200

    net: dsa: qca8k: Use up to 7 ports for all operations
    
    [ Upstream commit 7ae6d93c8f052b7a77ba56ed0f654e22a2876739 ]
    
    The QCA8K family supports up to 7 ports. So use the existing
    QCA8K_NUM_PORTS define to allocate the switch structure and limit all
    operations with the switch ports.
    
    This was not an issue until commit 0394a63acfe2 ("net: dsa: enable and
    disable all ports") disabled all unused ports. Since the unused ports 7-11
    are outside of the correct register range on this switch some registers
    were rewritten with invalid content.
    
    Fixes: 6b93fb46480a ("net-next: dsa: add new driver for qca8xxx family")
    Fixes: a0c02161ecfc ("net: dsa: variable number of ports")
    Fixes: 0394a63acfe2 ("net: dsa: enable and disable all ports")
    Signed-off-by: Michal Vokáč <michal.vokac@ysoft.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5e55d6c5a15cd70f1ececb6c5546a91273aad683
Author: Peter Ujfalusi <peter.ujfalusi@ti.com>
Date:   Mon Sep 30 11:54:50 2019 +0300

    ARM: dts: am4372: Set memory bandwidth limit for DISPC
    
    [ Upstream commit f90ec6cdf674248dcad85bf9af6e064bf472b841 ]
    
    Set memory bandwidth limit to filter out resolutions above 720p@60Hz to
    avoid underflow errors due to the bandwidth needs of higher resolutions.
    
    am43xx can not provide enough bandwidth to DISPC to correctly handle
    'high' resolutions.
    
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0cafebaf5719dc84361e39f3f3874721ec95d1af
Author: Navid Emamdoost <navid.emamdoost@gmail.com>
Date:   Tue Sep 17 17:47:12 2019 -0500

    ieee802154: ca8210: prevent memory leak
    
    [ Upstream commit 6402939ec86eaf226c8b8ae00ed983936b164908 ]
    
    In ca8210_probe the allocated pdata needs to be assigned to
    spi_device->dev.platform_data before calling ca8210_get_platform_data.
    Othrwise when ca8210_get_platform_data fails pdata cannot be released.
    
    Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
    Link: https://lore.kernel.org/r/20190917224713.26371-1-navid.emamdoost@gmail.com
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c800252b3a2b46144c0f09f0d42f09cf5e237629
Author: Tony Lindgren <tony@atomide.com>
Date:   Tue Sep 24 09:25:52 2019 -0700

    ARM: OMAP2+: Fix missing reset done flag for am3 and am43
    
    [ Upstream commit 8ad8041b98c665b6147e607b749586d6e20ba73a ]
    
    For ti,sysc-omap4 compatible devices with no sysstatus register, we do have
    reset done status available in the SOFTRESET bit that clears when the reset
    is done. This is documented for example in am437x TRM for DMTIMER_TIOCP_CFG
    register. The am335x TRM just says that SOFTRESET bit value 1 means reset is
    ongoing, but it behaves the same way clearing after reset is done.
    
    With the ti-sysc driver handling this automatically based on no sysstatus
    register defined, we see warnings if SYSC_HAS_RESET_STATUS is missing in the
    legacy platform data:
    
    ti-sysc 48042000.target-module: sysc_flags 00000222 != 00000022
    ti-sysc 48044000.target-module: sysc_flags 00000222 != 00000022
    ti-sysc 48046000.target-module: sysc_flags 00000222 != 00000022
    ...
    
    Let's fix these warnings by adding SYSC_HAS_RESET_STATUS. Let's also
    remove the useless parentheses while at it.
    
    If it turns out we do have ti,sysc-omap4 compatible devices without a
    working SOFTRESET bit we can set up additional quirk handling for it.
    
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1c9b9e5b6b29b48d46c380d78322ecc51c2b367d
Author: Quinn Tran <qutran@marvell.com>
Date:   Thu Sep 12 11:09:06 2019 -0700

    scsi: qla2xxx: Fix unbound sleep in fcport delete path.
    
    [ Upstream commit c3b6a1d397420a0fdd97af2f06abfb78adc370df ]
    
    There are instances, though rare, where a LOGO request cannot be sent out
    and the thread in free session done can wait indefinitely. Fix this by
    putting an upper bound to sleep.
    
    Link: https://lore.kernel.org/r/20190912180918.6436-3-hmadhani@marvell.com
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Himanshu Madhani <hmadhani@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 00cee7e535fd30e537cfcf2b9340b6bfcf716488
Author: Xiang Chen <chenxiang66@hisilicon.com>
Date:   Sat Sep 7 09:07:30 2019 +0800

    scsi: megaraid: disable device when probe failed after enabled device
    
    [ Upstream commit 70054aa39a013fa52eff432f2223b8bd5c0048f8 ]
    
    For pci device, need to disable device when probe failed after enabled
    device.
    
    Link: https://lore.kernel.org/r/1567818450-173315-1-git-send-email-chenxiang66@hisilicon.com
    Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com>
    Reviewed-by: John Garry <john.garry@huawei.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7a5ba8ee796d5149299e070cc8a05313621e70b5
Author: Stanley Chu <stanley.chu@mediatek.com>
Date:   Wed Sep 18 12:20:38 2019 +0800

    scsi: ufs: skip shutdown if hba is not powered
    
    [ Upstream commit f51913eef23f74c3bd07899dc7f1ed6df9e521d8 ]
    
    In some cases, hba may go through shutdown flow without successful
    initialization and then make system hang.
    
    For example, if ufshcd_change_power_mode() gets error and leads to
    ufshcd_hba_exit() to release resources of the host, future shutdown flow
    may hang the system since the host register will be accessed in unpowered
    state.
    
    To solve this issue, simply add checking to skip shutdown for above kind of
    situation.
    
    Link: https://lore.kernel.org/r/1568780438-28753-1-git-send-email-stanley.chu@mediatek.com
    Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
    Acked-by: Bean Huo <beanhuo@micron.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>