commit 54354bc5e2a599518c25769b56d76eabe94e67c9
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Feb 10 09:21:09 2021 +0100

    Linux 4.19.175
    
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Igor Matheus Andrade Torrente <igormtorrente@gmail.com>
    Tested-by: Jason Self <jason@bluehome.net>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Ross Schmidt <ross.schm.dev@gmail.com>
    Link: https://lore.kernel.org/r/20210208145806.141056364@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ffecc05dd3e8d4f7bb9706ca4fffa50b4653f51e
Author: DENG Qingfang <dqfext@gmail.com>
Date:   Sat Jan 30 21:43:34 2021 +0800

    net: dsa: mv88e6xxx: override existent unicast portvec in port_fdb_add
    
    commit f72f2fb8fb6be095b98af5d740ac50cffd0b0cae upstream.
    
    Having multiple destination ports for a unicast address does not make
    sense.
    Make port_db_load_purge override existent unicast portvec instead of
    adding a new port bit.
    
    Fixes: 884729399260 ("net: dsa: mv88e6xxx: handle multiple ports in ATU")
    Signed-off-by: DENG Qingfang <dqfext@gmail.com>
    Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
    Link: https://lore.kernel.org/r/20210130134334.10243-1-dqfext@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9c7b01fc3e22c49466c1fd0a9024bfda6b76440e
Author: Vadim Fedorenko <vfedorenko@novek.ru>
Date:   Sat Jan 30 01:27:47 2021 +0300

    net: ip_tunnel: fix mtu calculation
    
    commit 28e104d00281ade30250b24e098bf50887671ea4 upstream.
    
    dev->hard_header_len for tunnel interface is set only when header_ops
    are set too and already contains full overhead of any tunnel encapsulation.
    That's why there is not need to use this overhead twice in mtu calc.
    
    Fixes: fdafed459998 ("ip_gre: set dev->hard_header_len and dev->needed_headroom properly")
    Reported-by: Slava Bacherikov <mail@slava.cc>
    Signed-off-by: Vadim Fedorenko <vfedorenko@novek.ru>
    Link: https://lore.kernel.org/r/1611959267-20536-1-git-send-email-vfedorenko@novek.ru
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ada82f9940e92650221b677a46afd086632ed1c7
Author: Xiao Ni <xni@redhat.com>
Date:   Thu Dec 10 14:33:32 2020 +0800

    md: Set prev_flush_start and flush_bio in an atomic way
    
    commit dc5d17a3c39b06aef866afca19245a9cfb533a79 upstream.
    
    One customer reports a crash problem which causes by flush request. It
    triggers a warning before crash.
    
            /* new request after previous flush is completed */
            if (ktime_after(req_start, mddev->prev_flush_start)) {
                    WARN_ON(mddev->flush_bio);
                    mddev->flush_bio = bio;
                    bio = NULL;
            }
    
    The WARN_ON is triggered. We use spin lock to protect prev_flush_start and
    flush_bio in md_flush_request. But there is no lock protection in
    md_submit_flush_data. It can set flush_bio to NULL first because of
    compiler reordering write instructions.
    
    For example, flush bio1 sets flush bio to NULL first in
    md_submit_flush_data. An interrupt or vmware causing an extended stall
    happen between updating flush_bio and prev_flush_start. Because flush_bio
    is NULL, flush bio2 can get the lock and submit to underlayer disks. Then
    flush bio1 updates prev_flush_start after the interrupt or extended stall.
    
    Then flush bio3 enters in md_flush_request. The start time req_start is
    behind prev_flush_start. The flush_bio is not NULL(flush bio2 hasn't
    finished). So it can trigger the WARN_ON now. Then it calls INIT_WORK
    again. INIT_WORK() will re-initialize the list pointers in the
    work_struct, which then can result in a corrupted work list and the
    work_struct queued a second time. With the work list corrupted, it can
    lead in invalid work items being used and cause a crash in
    process_one_work.
    
    We need to make sure only one flush bio can be handled at one same time.
    So add spin lock in md_submit_flush_data to protect prev_flush_start and
    flush_bio in an atomic way.
    
    Reviewed-by: David Jeffery <djeffery@redhat.com>
    Signed-off-by: Xiao Ni <xni@redhat.com>
    Signed-off-by: Song Liu <songliubraving@fb.com>
    Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f3d2d57e6c717db4b17055ab7e636d91ff4e259a
Author: Nadav Amit <namit@vmware.com>
Date:   Wed Jan 27 09:53:17 2021 -0800

    iommu/vt-d: Do not use flush-queue when caching-mode is on
    
    commit 29b32839725f8c89a41cb6ee054c85f3116ea8b5 upstream.
    
    When an Intel IOMMU is virtualized, and a physical device is
    passed-through to the VM, changes of the virtual IOMMU need to be
    propagated to the physical IOMMU. The hypervisor therefore needs to
    monitor PTE mappings in the IOMMU page-tables. Intel specifications
    provide "caching-mode" capability that a virtual IOMMU uses to report
    that the IOMMU is virtualized and a TLB flush is needed after mapping to
    allow the hypervisor to propagate virtual IOMMU mappings to the physical
    IOMMU. To the best of my knowledge no real physical IOMMU reports
    "caching-mode" as turned on.
    
    Synchronizing the virtual and the physical IOMMU tables is expensive if
    the hypervisor is unaware which PTEs have changed, as the hypervisor is
    required to walk all the virtualized tables and look for changes.
    Consequently, domain flushes are much more expensive than page-specific
    flushes on virtualized IOMMUs with passthrough devices. The kernel
    therefore exploited the "caching-mode" indication to avoid domain
    flushing and use page-specific flushing in virtualized environments. See
    commit 78d5f0f500e6 ("intel-iommu: Avoid global flushes with caching
    mode.")
    
    This behavior changed after commit 13cf01744608 ("iommu/vt-d: Make use
    of iova deferred flushing"). Now, when batched TLB flushing is used (the
    default), full TLB domain flushes are performed frequently, requiring
    the hypervisor to perform expensive synchronization between the virtual
    TLB and the physical one.
    
    Getting batched TLB flushes to use page-specific invalidations again in
    such circumstances is not easy, since the TLB invalidation scheme
    assumes that "full" domain TLB flushes are performed for scalability.
    
    Disable batched TLB flushes when caching-mode is on, as the performance
    benefit from using batched TLB invalidations is likely to be much
    smaller than the overhead of the virtual-to-physical IOMMU page-tables
    synchronization.
    
    Fixes: 13cf01744608 ("iommu/vt-d: Make use of iova deferred flushing")
    Signed-off-by: Nadav Amit <namit@vmware.com>
    Cc: David Woodhouse <dwmw2@infradead.org>
    Cc: Lu Baolu <baolu.lu@linux.intel.com>
    Cc: Joerg Roedel <joro@8bytes.org>
    Cc: Will Deacon <will@kernel.org>
    Cc: stable@vger.kernel.org
    Acked-by: Lu Baolu <baolu.lu@linux.intel.com>
    Link: https://lore.kernel.org/r/20210127175317.1600473-1-namit@vmware.com
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Nadav Amit <namit@vmware.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 95c113fdc3bf19d8591971b7eda6913473f0c417
Author: Benjamin Valentin <benpicco@googlemail.com>
Date:   Thu Jan 21 19:24:17 2021 -0800

    Input: xpad - sync supported devices with fork on GitHub
    
    commit 9bbd77d5bbc9aff8cb74d805c31751f5f0691ba8 upstream.
    
    There is a fork of this driver on GitHub [0] that has been updated
    with new device IDs.
    
    Merge those into the mainline driver, so the out-of-tree fork is not
    needed for users of those devices anymore.
    
    [0] https://github.com/paroj/xpad
    
    Signed-off-by: Benjamin Valentin <benpicco@googlemail.com>
    Link: https://lore.kernel.org/r/20210121142523.1b6b050f@rechenknecht2k11
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b6b562ea32d9a705926c0ad93d1533dd49c35aa1
Author: Dave Hansen <dave.hansen@linux.intel.com>
Date:   Thu Mar 5 09:47:08 2020 -0800

    x86/apic: Add extra serialization for non-serializing MSRs
    
    commit 25a068b8e9a4eb193d755d58efcb3c98928636e0 upstream.
    
    Jan Kiszka reported that the x2apic_wrmsr_fence() function uses a plain
    MFENCE while the Intel SDM (10.12.3 MSR Access in x2APIC Mode) calls for
    MFENCE; LFENCE.
    
    Short summary: we have special MSRs that have weaker ordering than all
    the rest. Add fencing consistent with current SDM recommendations.
    
    This is not known to cause any issues in practice, only in theory.
    
    Longer story below:
    
    The reason the kernel uses a different semantic is that the SDM changed
    (roughly in late 2017). The SDM changed because folks at Intel were
    auditing all of the recommended fences in the SDM and realized that the
    x2apic fences were insufficient.
    
    Why was the pain MFENCE judged insufficient?
    
    WRMSR itself is normally a serializing instruction. No fences are needed
    because the instruction itself serializes everything.
    
    But, there are explicit exceptions for this serializing behavior written
    into the WRMSR instruction documentation for two classes of MSRs:
    IA32_TSC_DEADLINE and the X2APIC MSRs.
    
    Back to x2apic: WRMSR is *not* serializing in this specific case.
    But why is MFENCE insufficient? MFENCE makes writes visible, but
    only affects load/store instructions. WRMSR is unfortunately not a
    load/store instruction and is unaffected by MFENCE. This means that a
    non-serializing WRMSR could be reordered by the CPU to execute before
    the writes made visible by the MFENCE have even occurred in the first
    place.
    
    This means that an x2apic IPI could theoretically be triggered before
    there is any (visible) data to process.
    
    Does this affect anything in practice? I honestly don't know. It seems
    quite possible that by the time an interrupt gets to consume the (not
    yet) MFENCE'd data, it has become visible, mostly by accident.
    
    To be safe, add the SDM-recommended fences for all x2apic WRMSRs.
    
    This also leaves open the question of the _other_ weakly-ordered WRMSR:
    MSR_IA32_TSC_DEADLINE. While it has the same ordering architecture as
    the x2APIC MSRs, it seems substantially less likely to be a problem in
    practice. While writes to the in-memory Local Vector Table (LVT) might
    theoretically be reordered with respect to a weakly-ordered WRMSR like
    TSC_DEADLINE, the SDM has this to say:
    
      In x2APIC mode, the WRMSR instruction is used to write to the LVT
      entry. The processor ensures the ordering of this write and any
      subsequent WRMSR to the deadline; no fencing is required.
    
    But, that might still leave xAPIC exposed. The safest thing to do for
    now is to add the extra, recommended LFENCE.
    
     [ bp: Massage commit message, fix typos, drop accidentally added
       newline to tools/arch/x86/include/asm/barrier.h. ]
    
    Reported-by: Jan Kiszka <jan.kiszka@siemens.com>
    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Acked-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: <stable@vger.kernel.org>
    Link: https://lkml.kernel.org/r/20200305174708.F77040DD@viggo.jf.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 27b99a1a7bec9454af4c7fbedea2d1ff5105dcee
Author: Josh Poimboeuf <jpoimboe@redhat.com>
Date:   Thu Jan 28 15:52:19 2021 -0600

    x86/build: Disable CET instrumentation in the kernel
    
    commit 20bf2b378729c4a0366a53e2018a0b70ace94bcd upstream.
    
    With retpolines disabled, some configurations of GCC, and specifically
    the GCC versions 9 and 10 in Ubuntu will add Intel CET instrumentation
    to the kernel by default. That breaks certain tracing scenarios by
    adding a superfluous ENDBR64 instruction before the fentry call, for
    functions which can be called indirectly.
    
    CET instrumentation isn't currently necessary in the kernel, as CET is
    only supported in user space. Disable it unconditionally and move it
    into the x86's Makefile as CET/CFI... enablement should be a per-arch
    decision anyway.
    
     [ bp: Massage and extend commit message. ]
    
    Fixes: 29be86d7f9cb ("kbuild: add -fcf-protection=none when using retpoline flags")
    Reported-by: Nikolay Borisov <nborisov@suse.com>
    Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Reviewed-by: Nikolay Borisov <nborisov@suse.com>
    Tested-by: Nikolay Borisov <nborisov@suse.com>
    Cc: <stable@vger.kernel.org>
    Cc: Seth Forshee <seth.forshee@canonical.com>
    Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
    Link: https://lkml.kernel.org/r/20210128215219.6kct3h2eiustncws@treble
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 081438440a6e0787d0e4c933bc9e447ac5d217bb
Author: Hugh Dickins <hughd@google.com>
Date:   Thu Feb 4 18:32:31 2021 -0800

    mm: thp: fix MADV_REMOVE deadlock on shmem THP
    
    commit 1c2f67308af4c102b4e1e6cd6f69819ae59408e0 upstream.
    
    Sergey reported deadlock between kswapd correctly doing its usual
    lock_page(page) followed by down_read(page->mapping->i_mmap_rwsem), and
    madvise(MADV_REMOVE) on an madvise(MADV_HUGEPAGE) area doing
    down_write(page->mapping->i_mmap_rwsem) followed by lock_page(page).
    
    This happened when shmem_fallocate(punch hole)'s unmap_mapping_range()
    reaches zap_pmd_range()'s call to __split_huge_pmd().  The same deadlock
    could occur when partially truncating a mapped huge tmpfs file, or using
    fallocate(FALLOC_FL_PUNCH_HOLE) on it.
    
    __split_huge_pmd()'s page lock was added in 5.8, to make sure that any
    concurrent use of reuse_swap_page() (holding page lock) could not catch
    the anon THP's mapcounts and swapcounts while they were being split.
    
    Fortunately, reuse_swap_page() is never applied to a shmem or file THP
    (not even by khugepaged, which checks PageSwapCache before calling), and
    anonymous THPs are never created in shmem or file areas: so that
    __split_huge_pmd()'s page lock can only be necessary for anonymous THPs,
    on which there is no risk of deadlock with i_mmap_rwsem.
    
    Link: https://lkml.kernel.org/r/alpine.LSU.2.11.2101161409470.2022@eggly.anvils
    Fixes: c444eb564fb1 ("mm: thp: make the THP mapcount atomic against __split_huge_pmd_locked()")
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Reported-by: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
    Reviewed-by: Andrea Arcangeli <aarcange@redhat.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 6bf5461ae968b870f81c813a880e0e3a2684dfc1
Author: Muchun Song <songmuchun@bytedance.com>
Date:   Thu Feb 4 18:32:13 2021 -0800

    mm: hugetlb: remove VM_BUG_ON_PAGE from page_huge_active
    
    commit ecbf4724e6061b4b01be20f6d797d64d462b2bc8 upstream.
    
    The page_huge_active() can be called from scan_movable_pages() which do
    not hold a reference count to the HugeTLB page.  So when we call
    page_huge_active() from scan_movable_pages(), the HugeTLB page can be
    freed parallel.  Then we will trigger a BUG_ON which is in the
    page_huge_active() when CONFIG_DEBUG_VM is enabled.  Just remove the
    VM_BUG_ON_PAGE.
    
    Link: https://lkml.kernel.org/r/20210115124942.46403-6-songmuchun@bytedance.com
    Fixes: 7e1f049efb86 ("mm: hugetlb: cleanup using paeg_huge_active()")
    Signed-off-by: Muchun Song <songmuchun@bytedance.com>
    Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Reviewed-by: Oscar Salvador <osalvador@suse.de>
    Cc: David Hildenbrand <david@redhat.com>
    Cc: Yang Shi <shy828301@gmail.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 532574ae2586940729419253fd2defd9c9880490
Author: Muchun Song <songmuchun@bytedance.com>
Date:   Thu Feb 4 18:32:10 2021 -0800

    mm: hugetlb: fix a race between isolating and freeing page
    
    commit 0eb2df2b5629794020f75e94655e1994af63f0d4 upstream.
    
    There is a race between isolate_huge_page() and __free_huge_page().
    
      CPU0:                                     CPU1:
    
      if (PageHuge(page))
                                                put_page(page)
                                                  __free_huge_page(page)
                                                      spin_lock(&hugetlb_lock)
                                                      update_and_free_page(page)
                                                        set_compound_page_dtor(page,
                                                          NULL_COMPOUND_DTOR)
                                                      spin_unlock(&hugetlb_lock)
        isolate_huge_page(page)
          // trigger BUG_ON
          VM_BUG_ON_PAGE(!PageHead(page), page)
          spin_lock(&hugetlb_lock)
          page_huge_active(page)
            // trigger BUG_ON
            VM_BUG_ON_PAGE(!PageHuge(page), page)
          spin_unlock(&hugetlb_lock)
    
    When we isolate a HugeTLB page on CPU0.  Meanwhile, we free it to the
    buddy allocator on CPU1.  Then, we can trigger a BUG_ON on CPU0, because
    it is already freed to the buddy allocator.
    
    Link: https://lkml.kernel.org/r/20210115124942.46403-5-songmuchun@bytedance.com
    Fixes: c8721bbbdd36 ("mm: memory-hotplug: enable memory hotplug to handle hugepage")
    Signed-off-by: Muchun Song <songmuchun@bytedance.com>
    Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Reviewed-by: Oscar Salvador <osalvador@suse.de>
    Cc: David Hildenbrand <david@redhat.com>
    Cc: Yang Shi <shy828301@gmail.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 db510d8f98c38a953ae5d3b51b01f435740729b4
Author: Muchun Song <songmuchun@bytedance.com>
Date:   Thu Feb 4 18:32:06 2021 -0800

    mm: hugetlb: fix a race between freeing and dissolving the page
    
    commit 7ffddd499ba6122b1a07828f023d1d67629aa017 upstream.
    
    There is a race condition between __free_huge_page()
    and dissolve_free_huge_page().
    
      CPU0:                         CPU1:
    
      // page_count(page) == 1
      put_page(page)
        __free_huge_page(page)
                                    dissolve_free_huge_page(page)
                                      spin_lock(&hugetlb_lock)
                                      // PageHuge(page) && !page_count(page)
                                      update_and_free_page(page)
                                      // page is freed to the buddy
                                      spin_unlock(&hugetlb_lock)
          spin_lock(&hugetlb_lock)
          clear_page_huge_active(page)
          enqueue_huge_page(page)
          // It is wrong, the page is already freed
          spin_unlock(&hugetlb_lock)
    
    The race window is between put_page() and dissolve_free_huge_page().
    
    We should make sure that the page is already on the free list when it is
    dissolved.
    
    As a result __free_huge_page would corrupt page(s) already in the buddy
    allocator.
    
    Link: https://lkml.kernel.org/r/20210115124942.46403-4-songmuchun@bytedance.com
    Fixes: c8721bbbdd36 ("mm: memory-hotplug: enable memory hotplug to handle hugepage")
    Signed-off-by: Muchun Song <songmuchun@bytedance.com>
    Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
    Reviewed-by: Oscar Salvador <osalvador@suse.de>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Cc: David Hildenbrand <david@redhat.com>
    Cc: Yang Shi <shy828301@gmail.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 b6e04c19c5b2060c91b07acec5d650a1beb6855f
Author: Muchun Song <songmuchun@bytedance.com>
Date:   Thu Feb 4 18:32:03 2021 -0800

    mm: hugetlbfs: fix cannot migrate the fallocated HugeTLB page
    
    commit 585fc0d2871c9318c949fbf45b1f081edd489e96 upstream.
    
    If a new hugetlb page is allocated during fallocate it will not be
    marked as active (set_page_huge_active) which will result in a later
    isolate_huge_page failure when the page migration code would like to
    move that page.  Such a failure would be unexpected and wrong.
    
    Only export set_page_huge_active, just leave clear_page_huge_active as
    static.  Because there are no external users.
    
    Link: https://lkml.kernel.org/r/20210115124942.46403-3-songmuchun@bytedance.com
    Fixes: 70c3547e36f5 (hugetlbfs: add hugetlbfs_fallocate())
    Signed-off-by: Muchun Song <songmuchun@bytedance.com>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
    Reviewed-by: Oscar Salvador <osalvador@suse.de>
    Cc: David Hildenbrand <david@redhat.com>
    Cc: Yang Shi <shy828301@gmail.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 e06c6b69774f8607b98cd141ad26366434daf624
Author: Russell King <rmk+kernel@armlinux.org.uk>
Date:   Sun Oct 18 09:39:21 2020 +0100

    ARM: footbridge: fix dc21285 PCI configuration accessors
    
    commit 39d3454c3513840eb123b3913fda6903e45ce671 upstream.
    
    Building with gcc 4.9.2 reveals a latent bug in the PCI accessors
    for Footbridge platforms, which causes a fatal alignment fault
    while accessing IO memory. Fix this by making the assembly volatile.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d7a349a4c69ce8288a4b500f85a5370dad75d55d
Author: Sean Christopherson <seanjc@google.com>
Date:   Tue Feb 2 13:20:17 2021 -0800

    KVM: SVM: Treat SVM as unsupported when running as an SEV guest
    
    commit ccd85d90ce092bdb047a7f6580f3955393833b22 upstream.
    
    Don't let KVM load when running as an SEV guest, regardless of what
    CPUID says.  Memory is encrypted with a key that is not accessible to
    the host (L0), thus it's impossible for L0 to emulate SVM, e.g. it'll
    see garbage when reading the VMCB.
    
    Technically, KVM could decrypt all memory that needs to be accessible to
    the L0 and use shadow paging so that L0 does not need to shadow NPT, but
    exposing such information to L0 largely defeats the purpose of running as
    an SEV guest.  This can always be revisited if someone comes up with a
    use case for running VMs inside SEV guests.
    
    Note, VMLOAD, VMRUN, etc... will also #GP on GPAs with C-bit set, i.e. KVM
    is doomed even if the SEV guest is debuggable and the hypervisor is willing
    to decrypt the VMCB.  This may or may not be fixed on CPUs that have the
    SVME_ADDR_CHK fix.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20210202212017.2486595-1-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5d71e4a6e44157a75689353cc8c475e6498c3d88
Author: Thorsten Leemhuis <linux@leemhuis.info>
Date:   Fri Jan 29 06:24:42 2021 +0100

    nvme-pci: avoid the deepest sleep state on Kingston A2000 SSDs
    
    commit 538e4a8c571efdf131834431e0c14808bcfb1004 upstream.
    
    Some Kingston A2000 NVMe SSDs sooner or later get confused and stop
    working when they use the deepest APST sleep while running Linux. The
    system then crashes and one has to cold boot it to get the SSD working
    again.
    
    Kingston seems to known about this since at least mid-September 2020:
    https://bbs.archlinux.org/viewtopic.php?pid=1926994#p1926994
    
    Someone working for a German company representing Kingston to the German
    press confirmed to me Kingston engineering is aware of the issue and
    investigating; the person stated that to their current knowledge only
    the deepest APST sleep state causes trouble. Therefore, make Linux avoid
    it for now by applying the NVME_QUIRK_NO_DEEPEST_PS to this SSD.
    
    I have two such SSDs, but it seems the problem doesn't occur with them.
    I hence couldn't verify if this patch really fixes the problem, but all
    the data in front of me suggests it should.
    
    This patch can easily be reverted or improved upon if a better solution
    surfaces.
    
    FWIW, there are many reports about the issue scattered around the web;
    most of the users disabled APST completely to make things work, some
    just made Linux avoid the deepest sleep state:
    
    https://bugzilla.kernel.org/show_bug.cgi?id=195039#c65
    https://bugzilla.kernel.org/show_bug.cgi?id=195039#c73
    https://bugzilla.kernel.org/show_bug.cgi?id=195039#c74
    https://bugzilla.kernel.org/show_bug.cgi?id=195039#c78
    https://bugzilla.kernel.org/show_bug.cgi?id=195039#c79
    https://bugzilla.kernel.org/show_bug.cgi?id=195039#c80
    https://askubuntu.com/questions/1222049/nvmekingston-a2000-sometimes-stops-giving-response-in-ubuntu-18-04dell-inspir
    https://community.acer.com/en/discussion/604326/m-2-nvme-ssd-aspire-517-51g-issue-compatibility-kingston-a2000-linux-ubuntu
    
    For the record, some data from 'nvme id-ctrl /dev/nvme0'
    
    NVME Identify Controller:
    vid       : 0x2646
    ssvid     : 0x2646
    mn        : KINGSTON SA2000M81000G
    fr        : S5Z42105
    [...]
    ps    0 : mp:9.00W operational enlat:0 exlat:0 rrt:0 rrl:0
              rwt:0 rwl:0 idle_power:- active_power:-
    ps    1 : mp:4.60W operational enlat:0 exlat:0 rrt:1 rrl:1
              rwt:1 rwl:1 idle_power:- active_power:-
    ps    2 : mp:3.80W operational enlat:0 exlat:0 rrt:2 rrl:2
              rwt:2 rwl:2 idle_power:- active_power:-
    ps    3 : mp:0.0450W non-operational enlat:2000 exlat:2000 rrt:3 rrl:3
              rwt:3 rwl:3 idle_power:- active_power:-
    ps    4 : mp:0.0040W non-operational enlat:15000 exlat:15000 rrt:4 rrl:4
              rwt:4 rwl:4 idle_power:- active_power:-
    
    Cc: stable@vger.kernel.org # 4.14+
    Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 366e087253a96eab710f547fa6aadbeefda1e4c9
Author: Fengnan Chang <fengnanchang@gmail.com>
Date:   Sat Jan 23 11:32:31 2021 +0800

    mmc: core: Limit retries when analyse of SDIO tuples fails
    
    commit f92e04f764b86e55e522988e6f4b6082d19a2721 upstream.
    
    When analysing tuples fails we may loop indefinitely to retry. Let's avoid
    this by using a 10s timeout and bail if not completed earlier.
    
    Signed-off-by: Fengnan Chang <fengnanchang@gmail.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210123033230.36442-1-fengnanchang@gmail.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8c323163303d9923927c176977abdbe998f217ff
Author: Gustavo A. R. Silva <gustavoars@kernel.org>
Date:   Mon Feb 1 20:36:54 2021 -0600

    smb3: Fix out-of-bounds bug in SMB2_negotiate()
    
    commit 8d8d1dbefc423d42d626cf5b81aac214870ebaab upstream.
    
    While addressing some warnings generated by -Warray-bounds, I found this
    bug that was introduced back in 2017:
    
      CC [M]  fs/cifs/smb2pdu.o
    fs/cifs/smb2pdu.c: In function ‘SMB2_negotiate’:
    fs/cifs/smb2pdu.c:822:16: warning: array subscript 1 is above array bounds
    of ‘__le16[1]’ {aka ‘short unsigned int[1]’} [-Warray-bounds]
      822 |   req->Dialects[1] = cpu_to_le16(SMB30_PROT_ID);
          |   ~~~~~~~~~~~~~^~~
    fs/cifs/smb2pdu.c:823:16: warning: array subscript 2 is above array bounds
    of ‘__le16[1]’ {aka ‘short unsigned int[1]’} [-Warray-bounds]
      823 |   req->Dialects[2] = cpu_to_le16(SMB302_PROT_ID);
          |   ~~~~~~~~~~~~~^~~
    fs/cifs/smb2pdu.c:824:16: warning: array subscript 3 is above array bounds
    of ‘__le16[1]’ {aka ‘short unsigned int[1]’} [-Warray-bounds]
      824 |   req->Dialects[3] = cpu_to_le16(SMB311_PROT_ID);
          |   ~~~~~~~~~~~~~^~~
    fs/cifs/smb2pdu.c:816:16: warning: array subscript 1 is above array bounds
    of ‘__le16[1]’ {aka ‘short unsigned int[1]’} [-Warray-bounds]
      816 |   req->Dialects[1] = cpu_to_le16(SMB302_PROT_ID);
          |   ~~~~~~~~~~~~~^~~
    
    At the time, the size of array _Dialects_ was changed from 1 to 3 in struct
    validate_negotiate_info_req, and then in 2019 it was changed from 3 to 4,
    but those changes were never made in struct smb2_negotiate_req, which has
    led to a 3 and a half years old out-of-bounds bug in function
    SMB2_negotiate() (fs/cifs/smb2pdu.c).
    
    Fix this by increasing the size of array _Dialects_ in struct
    smb2_negotiate_req to 4.
    
    Fixes: 9764c02fcbad ("SMB3: Add support for multidialect negotiate (SMB2.1 and later)")
    Fixes: d5c7076b772a ("smb3: add smb3.1.1 to default dialect list")
    Cc: stable@vger.kernel.org
    Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 613fa1fb62c82e6b9c170b7de6f8c8c850624f5a
Author: Aurelien Aptel <aaptel@suse.com>
Date:   Fri Feb 5 15:42:48 2021 +0100

    cifs: report error instead of invalid when revalidating a dentry fails
    
    commit 21b200d091826a83aafc95d847139b2b0582f6d1 upstream.
    
    Assuming
    - //HOST/a is mounted on /mnt
    - //HOST/b is mounted on /mnt/b
    
    On a slow connection, running 'df' and killing it while it's
    processing /mnt/b can make cifs_get_inode_info() returns -ERESTARTSYS.
    
    This triggers the following chain of events:
    => the dentry revalidation fail
    => dentry is put and released
    => superblock associated with the dentry is put
    => /mnt/b is unmounted
    
    This patch makes cifs_d_revalidate() return the error instead of 0
    (invalid) when cifs_revalidate_dentry() fails, except for ENOENT (file
    deleted) and ESTALE (file recreated).
    
    Signed-off-by: Aurelien Aptel <aaptel@suse.com>
    Suggested-by: Shyam Prasad N <nspmangalore@gmail.com>
    Reviewed-by: Shyam Prasad N <nspmangalore@gmail.com>
    CC: stable@vger.kernel.org
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b521088eb1ee5930e5b1d73449e0e7ce3c9806b9
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Wed Feb 3 13:37:02 2021 +0200

    xhci: fix bounce buffer usage for non-sg list case
    
    commit d4a610635400ccc382792f6be69427078541c678 upstream.
    
    xhci driver may in some special cases need to copy small amounts
    of payload data to a bounce buffer in order to meet the boundary
    and alignment restrictions set by the xHCI specification.
    
    In the majority of these cases the data is in a sg list, and
    driver incorrectly assumed data is always in urb->sg when using
    the bounce buffer.
    
    If data instead is contiguous, and in urb->transfer_buffer, we may still
    need to bounce buffer a small part if data starts very close (less than
    packet size) to a 64k boundary.
    
    Check if sg list is used before copying data to/from it.
    
    Fixes: f9c589e142d0 ("xhci: TD-fragment, align the unsplittable case with a bounce buffer")
    Cc: stable@vger.kernel.org
    Reported-by: Andreas Hartmann <andihartmann@01019freenet.de>
    Tested-by: Andreas Hartmann <andihartmann@01019freenet.de>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20210203113702.436762-2-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2bc9ccf2cdfdbd1e2bcab4114d44a09b61d59a7a
Author: Marc Zyngier <maz@kernel.org>
Date:   Sat Jan 23 12:27:59 2021 +0000

    genirq/msi: Activate Multi-MSI early when MSI_FLAG_ACTIVATE_EARLY is set
    
    commit 4c457e8cb75eda91906a4f89fc39bde3f9a43922 upstream.
    
    When MSI_FLAG_ACTIVATE_EARLY is set (which is the case for PCI),
    __msi_domain_alloc_irqs() performs the activation of the interrupt (which
    in the case of PCI results in the endpoint being programmed) as soon as the
    interrupt is allocated.
    
    But it appears that this is only done for the first vector, introducing an
    inconsistent behaviour for PCI Multi-MSI.
    
    Fix it by iterating over the number of vectors allocated to each MSI
    descriptor. This is easily achieved by introducing a new
    "for_each_msi_vector" iterator, together with a tiny bit of refactoring.
    
    Fixes: f3b0946d629c ("genirq/msi: Make sure PCI MSIs are activated early")
    Reported-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210123122759.1781359-1-maz@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e0d7f2f9d11c441f060da4d7509f42a8ce6bf5bc
Author: Wang ShaoBo <bobo.shaobowang@huawei.com>
Date:   Thu Jan 28 20:44:27 2021 +0800

    kretprobe: Avoid re-registration of the same kretprobe earlier
    
    commit 0188b87899ffc4a1d36a0badbe77d56c92fd91dc upstream.
    
    Our system encountered a re-init error when re-registering same kretprobe,
    where the kretprobe_instance in rp->free_instances is illegally accessed
    after re-init.
    
    Implementation to avoid re-registration has been introduced for kprobe
    before, but lags for register_kretprobe(). We must check if kprobe has
    been re-registered before re-initializing kretprobe, otherwise it will
    destroy the data struct of kretprobe registered, which can lead to memory
    leak, system crash, also some unexpected behaviors.
    
    We use check_kprobe_rereg() to check if kprobe has been re-registered
    before running register_kretprobe()'s body, for giving a warning message
    and terminate registration process.
    
    Link: https://lkml.kernel.org/r/20210128124427.2031088-1-bobo.shaobowang@huawei.com
    
    Cc: stable@vger.kernel.org
    Fixes: 1f0ab40976460 ("kprobes: Prevent re-registration of the same kprobe")
    [ The above commit should have been done for kretprobes too ]
    Acked-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
    Acked-by: Ananth N Mavinakayanahalli <ananth@linux.ibm.com>
    Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
    Signed-off-by: Wang ShaoBo <bobo.shaobowang@huawei.com>
    Signed-off-by: Cheng Jian <cj.chengjian@huawei.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1d3a84f92f75bb0c2f981a75f507f55afed12f2c
Author: Felix Fietkau <nbd@nbd.name>
Date:   Mon Feb 1 09:33:24 2021 +0100

    mac80211: fix station rate table updates on assoc
    
    commit 18fe0fae61252b5ae6e26553e2676b5fac555951 upstream.
    
    If the driver uses .sta_add, station entries are only uploaded after the sta
    is in assoc state. Fix early station rate table updates by deferring them
    until the sta has been uploaded.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Link: https://lore.kernel.org/r/20210201083324.3134-1-nbd@nbd.name
    [use rcu_access_pointer() instead since we won't dereference here]
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 307aa80243fd0e5e3197f89c9e464baedc01d377
Author: Liangyan <liangyan.peng@linux.alibaba.com>
Date:   Tue Dec 22 11:06:26 2020 +0800

    ovl: fix dentry leak in ovl_get_redirect
    
    commit e04527fefba6e4e66492f122cf8cc6314f3cf3bf upstream.
    
    We need to lock d_parent->d_lock before dget_dlock, or this may
    have d_lockref updated parallelly like calltrace below which will
    cause dentry->d_lockref leak and risk a crash.
    
         CPU 0                                CPU 1
    ovl_set_redirect                       lookup_fast
      ovl_get_redirect                       __d_lookup
        dget_dlock
          //no lock protection here            spin_lock(&dentry->d_lock)
          dentry->d_lockref.count++            dentry->d_lockref.count++
    
    [   49.799059] PGD 800000061fed7067 P4D 800000061fed7067 PUD 61fec5067 PMD 0
    [   49.799689] Oops: 0002 [#1] SMP PTI
    [   49.800019] CPU: 2 PID: 2332 Comm: node Not tainted 4.19.24-7.20.al7.x86_64 #1
    [   49.800678] Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 8a46cfe 04/01/2014
    [   49.801380] RIP: 0010:_raw_spin_lock+0xc/0x20
    [   49.803470] RSP: 0018:ffffac6fc5417e98 EFLAGS: 00010246
    [   49.803949] RAX: 0000000000000000 RBX: ffff93b8da3446c0 RCX: 0000000a00000000
    [   49.804600] RDX: 0000000000000001 RSI: 000000000000000a RDI: 0000000000000088
    [   49.805252] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffff993cf040
    [   49.805898] R10: ffff93b92292e580 R11: ffffd27f188a4b80 R12: 0000000000000000
    [   49.806548] R13: 00000000ffffff9c R14: 00000000fffffffe R15: ffff93b8da3446c0
    [   49.807200] FS:  00007ffbedffb700(0000) GS:ffff93b927880000(0000) knlGS:0000000000000000
    [   49.807935] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   49.808461] CR2: 0000000000000088 CR3: 00000005e3f74006 CR4: 00000000003606a0
    [   49.809113] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [   49.809758] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [   49.810410] Call Trace:
    [   49.810653]  d_delete+0x2c/0xb0
    [   49.810951]  vfs_rmdir+0xfd/0x120
    [   49.811264]  do_rmdir+0x14f/0x1a0
    [   49.811573]  do_syscall_64+0x5b/0x190
    [   49.811917]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [   49.812385] RIP: 0033:0x7ffbf505ffd7
    [   49.814404] RSP: 002b:00007ffbedffada8 EFLAGS: 00000297 ORIG_RAX: 0000000000000054
    [   49.815098] RAX: ffffffffffffffda RBX: 00007ffbedffb640 RCX: 00007ffbf505ffd7
    [   49.815744] RDX: 0000000004449700 RSI: 0000000000000000 RDI: 0000000006c8cd50
    [   49.816394] RBP: 00007ffbedffaea0 R08: 0000000000000000 R09: 0000000000017d0b
    [   49.817038] R10: 0000000000000000 R11: 0000000000000297 R12: 0000000000000012
    [   49.817687] R13: 00000000072823d8 R14: 00007ffbedffb700 R15: 00000000072823d8
    [   49.818338] Modules linked in: pvpanic cirrusfb button qemu_fw_cfg atkbd libps2 i8042
    [   49.819052] CR2: 0000000000000088
    [   49.819368] ---[ end trace 4e652b8aa299aa2d ]---
    [   49.819796] RIP: 0010:_raw_spin_lock+0xc/0x20
    [   49.821880] RSP: 0018:ffffac6fc5417e98 EFLAGS: 00010246
    [   49.822363] RAX: 0000000000000000 RBX: ffff93b8da3446c0 RCX: 0000000a00000000
    [   49.823008] RDX: 0000000000000001 RSI: 000000000000000a RDI: 0000000000000088
    [   49.823658] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffff993cf040
    [   49.825404] R10: ffff93b92292e580 R11: ffffd27f188a4b80 R12: 0000000000000000
    [   49.827147] R13: 00000000ffffff9c R14: 00000000fffffffe R15: ffff93b8da3446c0
    [   49.828890] FS:  00007ffbedffb700(0000) GS:ffff93b927880000(0000) knlGS:0000000000000000
    [   49.830725] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   49.832359] CR2: 0000000000000088 CR3: 00000005e3f74006 CR4: 00000000003606a0
    [   49.834085] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [   49.835792] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    
    Cc: <stable@vger.kernel.org>
    Fixes: a6c606551141 ("ovl: redirect on rename-dir")
    Signed-off-by: Liangyan <liangyan.peng@linux.alibaba.com>
    Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
    Suggested-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0bd7046e42448e974b564d297d59ea29b2cf222f
Author: Gary Bisson <gary.bisson@boundarydevices.com>
Date:   Mon Jan 25 17:19:34 2021 +0100

    usb: dwc3: fix clock issue during resume in OTG mode
    
    commit 0e5a3c8284a30f4c43fd81d7285528ece74563b5 upstream.
    
    Commit fe8abf332b8f ("usb: dwc3: support clocks and resets for DWC3
    core") introduced clock support and a new function named
    dwc3_core_init_for_resume() which enables the clock before calling
    dwc3_core_init() during resume as clocks get disabled during suspend.
    
    Unfortunately in this commit the DWC3_GCTL_PRTCAP_OTG case was forgotten
    and therefore during resume, a platform could call dwc3_core_init()
    without re-enabling the clocks first, preventing to resume properly.
    
    So update the resume path to call dwc3_core_init_for_resume() as it
    should.
    
    Fixes: fe8abf332b8f ("usb: dwc3: support clocks and resets for DWC3 core")
    Cc: stable@vger.kernel.org
    Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
    Link: https://lore.kernel.org/r/20210125161934.527820-1-gary.bisson@boundarydevices.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e5fc959f1a4ba4b6ba9d9c1d045017fa6a6b3ac7
Author: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Date:   Wed Jan 27 11:39:19 2021 +0100

    usb: dwc2: Fix endpoint direction check in ep_from_windex
    
    commit f670e9f9c8cac716c3506c6bac9e997b27ad441a upstream.
    
    dwc2_hsotg_process_req_status uses ep_from_windex() to retrieve
    the endpoint for the index provided in the wIndex request param.
    
    In a test-case with a rndis gadget running and sending a malformed
    packet to it like:
        dev.ctrl_transfer(
            0x82,      # bmRequestType
            0x00,       # bRequest
            0x0000,     # wValue
            0x0001,     # wIndex
            0x00       # wLength
        )
    it is possible to cause a crash:
    
    [  217.533022] dwc2 ff300000.usb: dwc2_hsotg_process_req_status: USB_REQ_GET_STATUS
    [  217.559003] Unable to handle kernel read from unreadable memory at virtual address 0000000000000088
    ...
    [  218.313189] Call trace:
    [  218.330217]  ep_from_windex+0x3c/0x54
    [  218.348565]  usb_gadget_giveback_request+0x10/0x20
    [  218.368056]  dwc2_hsotg_complete_request+0x144/0x184
    
    This happens because ep_from_windex wants to compare the endpoint
    direction even if index_to_ep() didn't return an endpoint due to
    the direction not matching.
    
    The fix is easy insofar that the actual direction check is already
    happening when calling index_to_ep() which will return NULL if there
    is no endpoint for the targeted direction, so the offending check
    can go away completely.
    
    Fixes: c6f5c050e2a7 ("usb: dwc2: gadget: add bi-directional endpoint support")
    Cc: stable@vger.kernel.org
    Reported-by: Gerhard Klostermeier <gerhard.klostermeier@syss.de>
    Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
    Link: https://lore.kernel.org/r/20210127103919.58215-1-heiko@sntech.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a028b7c0962d356f20841ffa2e7ed83baf55aca1
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date:   Mon Feb 1 21:47:20 2021 +0900

    usb: renesas_usbhs: Clear pipe running flag in usbhs_pkt_pop()
    
    commit 9917f0e3cdba7b9f1a23f70e3f70b1a106be54a8 upstream.
    
    Should clear the pipe running flag in usbhs_pkt_pop(). Otherwise,
    we cannot use this pipe after dequeue was called while the pipe was
    running.
    
    Fixes: 8355b2b3082d ("usb: renesas_usbhs: fix the behavior of some usbhs_pkt_handle")
    Reported-by: Tho Vu <tho.vu.wh@renesas.com>
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Link: https://lore.kernel.org/r/1612183640-8898-1-git-send-email-yoshihiro.shimoda.uh@renesas.com
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7048a23f4c9ff99fdd2658255c5d979b8ba94e2e
Author: Jeremy Figgins <kernel@jeremyfiggins.com>
Date:   Sat Jan 23 18:21:36 2021 -0600

    USB: usblp: don't call usb_set_interface if there's a single alt
    
    commit d8c6edfa3f4ee0d45d7ce5ef18d1245b78774b9d upstream.
    
    Some devices, such as the Winbond Electronics Corp. Virtual Com Port
    (Vendor=0416, ProdId=5011), lockup when usb_set_interface() or
    usb_clear_halt() are called. This device has only a single
    altsetting, so it should not be necessary to call usb_set_interface().
    
    Acked-by: Pete Zaitcev <zaitcev@redhat.com>
    Signed-off-by: Jeremy Figgins <kernel@jeremyfiggins.com>
    Link: https://lore.kernel.org/r/YAy9kJhM/rG8EQXC@watson
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 94bf4b88d5b83d07c65085e67b9e342e562c11c0
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Jan 28 12:33:42 2021 +0300

    USB: gadget: legacy: fix an error code in eth_bind()
    
    commit 3e1f4a2e1184ae6ad7f4caf682ced9554141a0f4 upstream.
    
    This code should return -ENOMEM if the allocation fails but it currently
    returns success.
    
    Fixes: 9b95236eebdb ("usb: gadget: ether: allocate and init otg descriptor by otg capabilities")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Link: https://lore.kernel.org/r/YBKE9rqVuJEOUWpW@mwanda
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 50b2181099c0b66e80bbb940c22881f2552ce7be
Author: Roman Gushchin <guro@fb.com>
Date:   Thu Feb 4 18:32:36 2021 -0800

    memblock: do not start bottom-up allocations with kernel_end
    
    [ Upstream commit 2dcb3964544177c51853a210b6ad400de78ef17d ]
    
    With kaslr the kernel image is placed at a random place, so starting the
    bottom-up allocation with the kernel_end can result in an allocation
    failure and a warning like this one:
    
      hugetlb_cma: reserve 2048 MiB, up to 2048 MiB per node
      ------------[ cut here ]------------
      memblock: bottom-up allocation failed, memory hotremove may be affected
      WARNING: CPU: 0 PID: 0 at mm/memblock.c:332 memblock_find_in_range_node+0x178/0x25a
      Modules linked in:
      CPU: 0 PID: 0 Comm: swapper Not tainted 5.10.0+ #1169
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014
      RIP: 0010:memblock_find_in_range_node+0x178/0x25a
      Code: e9 6d ff ff ff 48 85 c0 0f 85 da 00 00 00 80 3d 9b 35 df 00 00 75 15 48 c7 c7 c0 75 59 88 c6 05 8b 35 df 00 01 e8 25 8a fa ff <0f> 0b 48 c7 44 24 20 ff ff ff ff 44 89 e6 44 89 ea 48 c7 c1 70 5c
      RSP: 0000:ffffffff88803d18 EFLAGS: 00010086 ORIG_RAX: 0000000000000000
      RAX: 0000000000000000 RBX: 0000000240000000 RCX: 00000000ffffdfff
      RDX: 00000000ffffdfff RSI: 00000000ffffffea RDI: 0000000000000046
      RBP: 0000000100000000 R08: ffffffff88922788 R09: 0000000000009ffb
      R10: 00000000ffffe000 R11: 3fffffffffffffff R12: 0000000000000000
      R13: 0000000000000000 R14: 0000000080000000 R15: 00000001fb42c000
      FS:  0000000000000000(0000) GS:ffffffff88f71000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: ffffa080fb401000 CR3: 00000001fa80a000 CR4: 00000000000406b0
      Call Trace:
        memblock_alloc_range_nid+0x8d/0x11e
        cma_declare_contiguous_nid+0x2c4/0x38c
        hugetlb_cma_reserve+0xdc/0x128
        flush_tlb_one_kernel+0xc/0x20
        native_set_fixmap+0x82/0xd0
        flat_get_apic_id+0x5/0x10
        register_lapic_address+0x8e/0x97
        setup_arch+0x8a5/0xc3f
        start_kernel+0x66/0x547
        load_ucode_bsp+0x4c/0xcd
        secondary_startup_64_no_verify+0xb0/0xbb
      random: get_random_bytes called from __warn+0xab/0x110 with crng_init=0
      ---[ end trace f151227d0b39be70 ]---
    
    At the same time, the kernel image is protected with memblock_reserve(),
    so we can just start searching at PAGE_SIZE.  In this case the bottom-up
    allocation has the same chances to success as a top-down allocation, so
    there is no reason to fallback in the case of a failure.  All together it
    simplifies the logic.
    
    Link: https://lkml.kernel.org/r/20201217201214.3414100-2-guro@fb.com
    Fixes: 8fabc623238e ("powerpc: Ensure that swiotlb buffer is allocated from low memory")
    Signed-off-by: Roman Gushchin <guro@fb.com>
    Reviewed-by: Mike Rapoport <rppt@linux.ibm.com>
    Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
    Cc: Michal Hocko <mhocko@kernel.org>
    Cc: Rik van Riel <riel@surriel.com>
    Cc: Wonhyuk Yang <vvghjk1234@gmail.com>
    Cc: Thiago Jung Bauermann <bauerman@linux.ibm.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 86d05ee593d1a20b0967fd180dd8b44fbbe80ddd
Author: Stefan Chulski <stefanc@marvell.com>
Date:   Mon Feb 1 11:35:39 2021 +0200

    net: mvpp2: TCAM entry enable should be written after SRAM data
    
    [ Upstream commit 43f4a20a1266d393840ce010f547486d14cc0071 ]
    
    Last TCAM data contains TCAM enable bit.
    It should be written after SRAM data before entry enabled.
    
    Fixes: 3f518509dedc ("ethernet: Add new driver for Marvell Armada 375 network unit")
    Signed-off-by: Stefan Chulski <stefanc@marvell.com>
    Link: https://lore.kernel.org/r/1612172139-28343-1-git-send-email-stefanc@marvell.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8b8e0d0b718bd5c99bb3545c8f9c3302ce79b349
Author: Xie He <xie.he.0141@gmail.com>
Date:   Sun Jan 31 21:57:06 2021 -0800

    net: lapb: Copy the skb before sending a packet
    
    [ Upstream commit 88c7a9fd9bdd3e453f04018920964c6f848a591a ]
    
    When sending a packet, we will prepend it with an LAPB header.
    This modifies the shared parts of a cloned skb, so we should copy the
    skb rather than just clone it, before we prepend the header.
    
    In "Documentation/networking/driver.rst" (the 2nd point), it states
    that drivers shouldn't modify the shared parts of a cloned skb when
    transmitting.
    
    The "dev_queue_xmit_nit" function in "net/core/dev.c", which is called
    when an skb is being sent, clones the skb and sents the clone to
    AF_PACKET sockets. Because the LAPB drivers first remove a 1-byte
    pseudo-header before handing over the skb to us, if we don't copy the
    skb before prepending the LAPB header, the first byte of the packets
    received on AF_PACKET sockets can be corrupted.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Xie He <xie.he.0141@gmail.com>
    Acked-by: Martin Schiller <ms@dev.tdt.de>
    Link: https://lore.kernel.org/r/20210201055706.415842-1-xie.he.0141@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 37605bb23b36949bc62da030fe4b7daa69f2a863
Author: Zyta Szpak <zr@semihalf.com>
Date:   Thu Jan 21 16:52:37 2021 +0100

    arm64: dts: ls1046a: fix dcfg address range
    
    [ Upstream commit aa880c6f3ee6dbd0d5ab02026a514ff8ea0a3328 ]
    
    Dcfg was overlapping with clockgen address space which resulted
    in failure in memory allocation for dcfg. According regs description
    dcfg size should not be bigger than 4KB.
    
    Signed-off-by: Zyta Szpak <zr@semihalf.com>
    Fixes: 8126d88162a5 ("arm64: dts: add QorIQ LS1046A SoC support")
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d154251980f49177abdca20230116d120ef0b215
Author: David Howells <dhowells@redhat.com>
Date:   Fri Jan 29 23:53:50 2021 +0000

    rxrpc: Fix deadlock around release of dst cached on udp tunnel
    
    [ Upstream commit 5399d52233c47905bbf97dcbaa2d7a9cc31670ba ]
    
    AF_RXRPC sockets use UDP ports in encap mode.  This causes socket and dst
    from an incoming packet to get stolen and attached to the UDP socket from
    whence it is leaked when that socket is closed.
    
    When a network namespace is removed, the wait for dst records to be cleaned
    up happens before the cleanup of the rxrpc and UDP socket, meaning that the
    wait never finishes.
    
    Fix this by moving the rxrpc (and, by dependence, the afs) private
    per-network namespace registrations to the device group rather than subsys
    group.  This allows cached rxrpc local endpoints to be cleared and their
    UDP sockets closed before we try waiting for the dst records.
    
    The symptom is that lines looking like the following:
    
            unregister_netdevice: waiting for lo to become free
    
    get emitted at regular intervals after running something like the
    referenced syzbot test.
    
    Thanks to Vadim for tracking this down and work out the fix.
    
    Reported-by: syzbot+df400f2f24a1677cd7e0@syzkaller.appspotmail.com
    Reported-by: Vadim Fedorenko <vfedorenko@novek.ru>
    Fixes: 5271953cad31 ("rxrpc: Use the UDP encap_rcv hook")
    Signed-off-by: David Howells <dhowells@redhat.com>
    Acked-by: Vadim Fedorenko <vfedorenko@novek.ru>
    Link: https://lore.kernel.org/r/161196443016.3868642.5577440140646403533.stgit@warthog.procyon.org.uk
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e923e82dfaeb304d061923698522b982d7c297ed
Author: Alexey Dobriyan <adobriyan@gmail.com>
Date:   Sun Jan 3 17:59:51 2021 -0800

    Input: i8042 - unbreak Pegatron C15B
    
    [ Upstream commit a3a9060ecad030e2c7903b2b258383d2c716b56c ]
    
    g++ reports
    
            drivers/input/serio/i8042-x86ia64io.h:225:3: error: ‘.matches’ designator used multiple times in the same initializer list
    
    C99 semantics is that last duplicated initialiser wins,
    so DMI entry gets overwritten.
    
    Fixes: a48491c65b51 ("Input: i8042 - add ByteSpeed touchpad to noloop table")
    Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
    Acked-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
    Link: https://lore.kernel.org/r/20201228072335.GA27766@localhost.localdomain
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2a6e9df11190aba32113d4e8122d7da6422b5044
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Dec 11 13:36:46 2020 -0800

    elfcore: fix building with clang
    
    commit 6e7b64b9dd6d96537d816ea07ec26b7dedd397b9 upstream.
    
    kernel/elfcore.c only contains weak symbols, which triggers a bug with
    clang in combination with recordmcount:
    
      Cannot find symbol for section 2: .text.
      kernel/elfcore.o: failed
    
    Move the empty stubs into linux/elfcore.h as inline functions.  As only
    two architectures use these, just use the architecture specific Kconfig
    symbols to key off the declaration.
    
    Link: https://lkml.kernel.org/r/20201204165742.3815221-2-arnd@kernel.org
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Cc: Nathan Chancellor <natechancellor@gmail.com>
    Cc: Nick Desaulniers <ndesaulniers@google.com>
    Cc: Barret Rhoden <brho@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ae9aff4a09036c1f34afc41d459194770da09031
Author: Christoph Schemmel <christoph.schemmel@gmail.com>
Date:   Wed Jan 27 20:58:46 2021 +0100

    USB: serial: option: Adding support for Cinterion MV31
    
    commit e478d6029dca9d8462f426aee0d32896ef64f10f upstream.
    
    Adding support for Cinterion device MV31 for enumeration with
    PID 0x00B3 and 0x00B7.
    
    usb-devices output for 0x00B3
    T:  Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  6 Spd=5000 MxCh= 0
    D:  Ver= 3.20 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs=  1
    P:  Vendor=1e2d ProdID=00b3 Rev=04.14
    S:  Manufacturer=Cinterion
    S:  Product=Cinterion PID 0x00B3 USB Mobile Broadband
    S:  SerialNumber=b3246eed
    C:  #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=896mA
    I:  If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
    I:  If#=0x1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    I:  If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#=0x3 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=cdc_wdm
    I:  If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#=0x5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    
    usb-devices output for 0x00B7
    T:  Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  5 Spd=5000 MxCh= 0
    D:  Ver= 3.20 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs=  1
    P:  Vendor=1e2d ProdID=00b7 Rev=04.14
    S:  Manufacturer=Cinterion
    S:  Product=Cinterion PID 0x00B3 USB Mobile Broadband
    S:  SerialNumber=b3246eed
    C:  #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=896mA
    I:  If#=0x0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
    I:  If#=0x1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#=0x3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    
    Signed-off-by: Christoph Schemmel <christoph.schemmel@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e2e37943670ff079397062b27ecfcc7b1b8ac28c
Author: Chenxin Jin <bg4akv@hotmail.com>
Date:   Wed Jan 13 16:59:05 2021 +0800

    USB: serial: cp210x: add new VID/PID for supporting Teraoka AD2000
    
    commit 43377df70480f82919032eb09832e9646a8a5efb upstream.
    
    Teraoka AD2000 uses the CP210x driver, but the chip VID/PID is
    customized with 0988/0578. We need the driver to support the new
    VID/PID.
    
    Signed-off-by: Chenxin Jin <bg4akv@hotmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f8609939e6c7f5d484d3af086b424612f2f73db3
Author: Pho Tran <Pho.Tran@silabs.com>
Date:   Mon Jan 25 09:26:54 2021 +0000

    USB: serial: cp210x: add pid/vid for WSDA-200-USB
    
    commit 3c4f6ecd93442f4376a58b38bb40ee0b8c46e0e6 upstream.
    
    Information pid/vid of WSDA-200-USB, Lord corporation company:
    vid: 199b
    pid: ba30
    
    Signed-off-by: Pho Tran <pho.tran@silabs.com>
    [ johan: amend comment with product name ]
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>