commit 1c54d3c15afacf179c07ce6c57a0d43f412f1b3a
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Jul 9 09:37:57 2020 +0200

    Linux 5.4.51

commit 8ba1913cd6ba24f171055958934afd69d0bfd9e0
Author: Peter Jones <pjones@redhat.com>
Date:   Mon Jun 15 16:24:08 2020 -0400

    efi: Make it possible to disable efivar_ssdt entirely
    
    commit 435d1a471598752446a72ad1201b3c980526d869 upstream.
    
    In most cases, such as CONFIG_ACPI_CUSTOM_DSDT and
    CONFIG_ACPI_TABLE_UPGRADE, boot-time modifications to firmware tables
    are tied to specific Kconfig options.  Currently this is not the case
    for modifying the ACPI SSDT via the efivar_ssdt kernel command line
    option and associated EFI variable.
    
    This patch adds CONFIG_EFI_CUSTOM_SSDT_OVERLAYS, which defaults
    disabled, in order to allow enabling or disabling that feature during
    the build.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Peter Jones <pjones@redhat.com>
    Link: https://lore.kernel.org/r/20200615202408.2242614-1-pjones@redhat.com
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 43986c32ee00fa66df143746b2b614e62ca7017b
Author: Hou Tao <houtao1@huawei.com>
Date:   Mon Jun 15 11:33:23 2020 +0800

    dm zoned: assign max_io_len correctly
    
    commit 7b2377486767503d47265e4d487a63c651f6b55d upstream.
    
    The unit of max_io_len is sector instead of byte (spotted through
    code review), so fix it.
    
    Fixes: 3b1a94c88b79 ("dm zoned: drive-managed zoned block device target")
    Cc: stable@vger.kernel.org
    Signed-off-by: Hou Tao <houtao1@huawei.com>
    Reviewed-by: Damien Le Moal <damien.lemoal@wdc.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 215e562251bbac9227c89496bcab13a4ed4e2bd1
Author: Babu Moger <babu.moger@amd.com>
Date:   Thu Jun 4 14:45:16 2020 -0500

    x86/resctrl: Fix memory bandwidth counter width for AMD
    
    commit 2c18bd525c47f882f033b0a813ecd09c93e1ecdf upstream.
    
    Memory bandwidth is calculated reading the monitoring counter
    at two intervals and calculating the delta. It is the software’s
    responsibility to read the count often enough to avoid having
    the count roll over _twice_ between reads.
    
    The current code hardcodes the bandwidth monitoring counter's width
    to 24 bits for AMD. This is due to default base counter width which
    is 24. Currently, AMD does not implement the CPUID 0xF.[ECX=1]:EAX
    to adjust the counter width. But, the AMD hardware supports much
    wider bandwidth counter with the default width of 44 bits.
    
    Kernel reads these monitoring counters every 1 second and adjusts the
    counter value for overflow. With 24 bits and scale value of 64 for AMD,
    it can only measure up to 1GB/s without overflowing. For the rates
    above 1GB/s this will fail to measure the bandwidth.
    
    Fix the issue setting the default width to 44 bits by adjusting the
    offset.
    
    AMD future products will implement CPUID 0xF.[ECX=1]:EAX.
    
     [ bp: Let the line stick out and drop {}-brackets around a single
       statement. ]
    
    Fixes: 4d05bf71f157 ("x86/resctrl: Introduce AMD QOS feature")
    Signed-off-by: Babu Moger <babu.moger@amd.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Link: https://lkml.kernel.org/r/159129975546.62538.5656031125604254041.stgit@naples-babu.amd.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d827fe702e0726b43b5087fe76c8f556f8f77505
Author: Vlastimil Babka <vbabka@suse.cz>
Date:   Thu Jun 25 20:29:24 2020 -0700

    mm, compaction: make capture control handling safe wrt interrupts
    
    commit b9e20f0da1f5c9c68689450a8cb436c9486434c8 upstream.
    
    Hugh reports:
    
     "While stressing compaction, one run oopsed on NULL capc->cc in
      __free_one_page()'s task_capc(zone): compact_zone_order() had been
      interrupted, and a page was being freed in the return from interrupt.
    
      Though you would not expect it from the source, both gccs I was using
      (4.8.1 and 7.5.0) had chosen to compile compact_zone_order() with the
      ".cc = &cc" implemented by mov %rbx,-0xb0(%rbp) immediately before
      callq compact_zone - long after the "current->capture_control =
      &capc". An interrupt in between those finds capc->cc NULL (zeroed by
      an earlier rep stos).
    
      This could presumably be fixed by a barrier() before setting
      current->capture_control in compact_zone_order(); but would also need
      more care on return from compact_zone(), in order not to risk leaking
      a page captured by interrupt just before capture_control is reset.
    
      Maybe that is the preferable fix, but I felt safer for task_capc() to
      exclude the rather surprising possibility of capture at interrupt
      time"
    
    I have checked that gcc10 also behaves the same.
    
    The advantage of fix in compact_zone_order() is that we don't add
    another test in the page freeing hot path, and that it might prevent
    future problems if we stop exposing pointers to uninitialized structures
    in current task.
    
    So this patch implements the suggestion for compact_zone_order() with
    barrier() (and WRITE_ONCE() to prevent store tearing) for setting
    current->capture_control, and prevents page leaking with
    WRITE_ONCE/READ_ONCE in the proper order.
    
    Link: http://lkml.kernel.org/r/20200616082649.27173-1-vbabka@suse.cz
    Fixes: 5e1f0f098b46 ("mm, compaction: capture a page under direct compaction")
    Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
    Reported-by: Hugh Dickins <hughd@google.com>
    Suggested-by: Hugh Dickins <hughd@google.com>
    Acked-by: Hugh Dickins <hughd@google.com>
    Cc: Alex Shi <alex.shi@linux.alibaba.com>
    Cc: Li Wang <liwang@redhat.com>
    Cc: Mel Gorman <mgorman@techsingularity.net>
    Cc: <stable@vger.kernel.org>    [5.1+]
    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 64a94c550c4440dc9d61d681145382f92968266c
Author: Vlastimil Babka <vbabka@suse.cz>
Date:   Wed Apr 1 21:10:35 2020 -0700

    mm, compaction: fully assume capture is not NULL in compact_zone_order()
    
    commit 6467552ca64c4ddd2b83ed73192107d7145f533b upstream.
    
    Dan reports:
    
    The patch 5e1f0f098b46: "mm, compaction: capture a page under direct
    compaction" from Mar 5, 2019, leads to the following Smatch complaint:
    
        mm/compaction.c:2321 compact_zone_order()
         error: we previously assumed 'capture' could be null (see line 2313)
    
    mm/compaction.c
      2288  static enum compact_result compact_zone_order(struct zone *zone, int order,
      2289                  gfp_t gfp_mask, enum compact_priority prio,
      2290                  unsigned int alloc_flags, int classzone_idx,
      2291                  struct page **capture)
                                          ^^^^^^^
    
      2313          if (capture)
                        ^^^^^^^
    Check for NULL
    
      2314                  current->capture_control = &capc;
      2315
      2316          ret = compact_zone(&cc, &capc);
      2317
      2318          VM_BUG_ON(!list_empty(&cc.freepages));
      2319          VM_BUG_ON(!list_empty(&cc.migratepages));
      2320
      2321          *capture = capc.page;
                    ^^^^^^^^
    Unchecked dereference.
    
      2322          current->capture_control = NULL;
      2323
    
    In practice this is not an issue, as the only caller path passes non-NULL
    capture:
    
    __alloc_pages_direct_compact()
      struct page *page = NULL;
      try_to_compact_pages(capture = &page);
        compact_zone_order(capture = capture);
    
    So let's remove the unnecessary check, which should also make Smatch happy.
    
    Fixes: 5e1f0f098b46 ("mm, compaction: capture a page under direct compaction")
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Suggested-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
    Acked-by: Mel Gorman <mgorman@techsingularity.net>
    Link: http://lkml.kernel.org/r/18b0df3c-0589-d96c-23fa-040798fee187@suse.cz
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a9278ac9c5515b372fbc831d7b0702096dc3127
Author: Marc Zyngier <maz@kernel.org>
Date:   Sun Jun 21 14:43:15 2020 +0100

    irqchip/gic: Atomically update affinity
    
    commit 005c34ae4b44f085120d7f371121ec7ded677761 upstream.
    
    The GIC driver uses a RMW sequence to update the affinity, and
    relies on the gic_lock_irqsave/gic_unlock_irqrestore sequences
    to update it atomically.
    
    But these sequences only expand into anything meaningful if
    the BL_SWITCHER option is selected, which almost never happens.
    
    It also turns out that using a RMW and locks is just as silly,
    as the GIC distributor supports byte accesses for the GICD_TARGETRn
    registers, which when used make the update atomic by definition.
    
    Drop the terminally broken code and replace it by a byte write.
    
    Fixes: 04c8b0f82c7d ("irqchip/gic: Make locking a BL_SWITCHER only feature")
    Cc: stable@vger.kernel.org
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7ba23593cbc53aec35535c7dca3e9354d819bafe
Author: Sumit Semwal <sumit.semwal@linaro.org>
Date:   Thu Jun 11 17:14:18 2020 +0530

    dma-buf: Move dma_buf_release() from fops to dentry_ops
    
    commit 4ab59c3c638c6c8952bf07739805d20eb6358a4d upstream.
    
    Charan Teja reported a 'use-after-free' in dmabuffs_dname [1], which
    happens if the dma_buf_release() is called while the userspace is
    accessing the dma_buf pseudo fs's dmabuffs_dname() in another process,
    and dma_buf_release() releases the dmabuf object when the last reference
    to the struct file goes away.
    
    I discussed with Arnd Bergmann, and he suggested that rather than tying
    the dma_buf_release() to the file_operations' release(), we can tie it to
    the dentry_operations' d_release(), which will be called when the last ref
    to the dentry is removed.
    
    The path exercised by __fput() calls f_op->release() first, and then calls
    dput, which eventually calls d_op->d_release().
    
    In the 'normal' case, when no userspace access is happening via dma_buf
    pseudo fs, there should be exactly one fd, file, dentry and inode, so
    closing the fd will kill of everything right away.
    
    In the presented case, the dentry's d_release() will be called only when
    the dentry's last ref is released.
    
    Therefore, lets move dma_buf_release() from fops->release() to
    d_ops->d_release()
    
    Many thanks to Arnd for his FS insights :)
    
    [1]: https://lore.kernel.org/patchwork/patch/1238278/
    
    Fixes: bb2bb9030425 ("dma-buf: add DMA_BUF_SET_NAME ioctls")
    Reported-by: syzbot+3643a18836bce555bff6@syzkaller.appspotmail.com
    Cc: <stable@vger.kernel.org> [5.3+]
    Cc: Arnd Bergmann <arnd@arndb.de>
    Reported-by: Charan Teja Reddy <charante@codeaurora.org>
    Reviewed-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
    Tested-by: Charan Teja Reddy <charante@codeaurora.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20200611114418.19852-1-sumit.semwal@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4ae695a055166c164306b2633a8f82d16b13f405
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Jun 25 17:55:57 2020 -0400

    drm/amdgpu/atomfirmware: fix vram_info fetching for renoir
    
    commit d7a6634a4cfba073ff6a526cb4265d6e58ece234 upstream.
    
    Renoir uses integrated_system_info table v12.  The table
    has the same layout as v11 with respect to this data.  Just
    reuse the existing code for v12 for stable.
    
    Fixes incorrectly reported vram info in the driver output.
    
    Acked-by: Evan Quan <evan.quan@amd.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 2b8c0876bf710e6ba38bd68c42bfe30faf7d1f0d
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed Jul 1 12:00:08 2020 -0400

    drm/amdgpu: use %u rather than %d for sclk/mclk
    
    commit beaf10efca64ac824240838ab1f054dfbefab5e6 upstream.
    
    Large clock values may overflow and show up as negative.
    
    Reported by prOMiNd on IRC.
    
    Acked-by: Nirmoy Das <nirmoy.das@amd.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 94de85d16b0c46671ddf9695fdeb9d081e5a5ffe
Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Date:   Mon Jun 29 13:03:52 2020 -0400

    drm/amd/display: Only revalidate bandwidth on medium and fast updates
    
    commit 6eb3cf2e06d22b2b08e6b0ab48cb9c05a8e1a107 upstream.
    
    [Why]
    Changes that are fast don't require updating DLG parameters making
    this call unnecessary. Considering this is an expensive call it should
    not be done on every flip.
    
    DML touches clocks, p-state support, DLG params and a few other DC
    internal flags and these aren't expected during fast. A hang has been
    reported with this change when called on every flip which suggests that
    modifying these fields is not recommended behavior on fast updates.
    
    [How]
    Guard the validation to only happen if update type isn't FAST.
    
    Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1191
    Fixes: a24eaa5c51255b ("drm/amd/display: Revalidate bandwidth before commiting DC updates")
    Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Reviewed-by: Roman Li <Roman.Li@amd.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 032343ed6927735be70b20e5facbf74ab5589690
Author: Hauke Mehrtens <hauke@hauke-m.de>
Date:   Fri Jul 3 00:53:34 2020 +0200

    MIPS: Add missing EHB in mtc0 -> mfc0 sequence for DSPen
    
    commit fcec538ef8cca0ad0b84432235dccd9059c8e6f8 upstream.
    
    This resolves the hazard between the mtc0 in the change_c0_status() and
    the mfc0 in configure_exception_vector(). Without resolving this hazard
    configure_exception_vector() could read an old value and would restore
    this old value again. This would revert the changes change_c0_status()
    did. I checked this by printing out the read_c0_status() at the end of
    per_cpu_trap_init() and the ST0_MX is not set without this patch.
    
    The hazard is documented in the MIPS Architecture Reference Manual Vol.
    III: MIPS32/microMIPS32 Privileged Resource Architecture (MD00088), rev
    6.03 table 8.1 which includes:
    
       Producer | Consumer | Hazard
      ----------|----------|----------------------------
       mtc0     | mfc0     | any coprocessor 0 register
    
    I saw this hazard on an Atheros AR9344 rev 2 SoC with a MIPS 74Kc CPU.
    There the change_c0_status() function would activate the DSPen by
    setting ST0_MX in the c0_status register. This was reverted and then the
    system got a DSP exception when the DSP registers were saved in
    save_dsp() in the first process switch. The crash looks like this:
    
    [    0.089999] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
    [    0.097796] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
    [    0.107070] Kernel panic - not syncing: Unexpected DSP exception
    [    0.113470] Rebooting in 1 seconds..
    
    We saw this problem in OpenWrt only on the MIPS 74Kc based Atheros SoCs,
    not on the 24Kc based SoCs. We only saw it with kernel 5.4 not with
    kernel 4.19, in addition we had to use GCC 8.4 or 9.X, with GCC 8.3 it
    did not happen.
    
    In the kernel I bisected this problem to commit 9012d011660e ("compiler:
    allow all arches to enable CONFIG_OPTIMIZE_INLINING"), but when this was
    reverted it also happened after commit 172dcd935c34b ("MIPS: Always
    allocate exception vector for MIPSr2+").
    
    Commit 0b24cae4d535 ("MIPS: Add missing EHB in mtc0 -> mfc0 sequence.")
    does similar changes to a different file. I am not sure if there are
    more places affected by this problem.
    
    Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2e859b14da39928afda969656213ca37dd20caab
Author: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Date:   Sun Jun 7 15:10:23 2020 +0200

    MIPS: lantiq: xway: sysctrl: fix the GPHY clock alias names
    
    commit 03e62fd67d3ab33f39573fc8787d89dc9b4d7255 upstream.
    
    The dt-bindings for the GSWIP describe that the node should be named
    "switch". Use the same name in sysctrl.c so the GSWIP driver can
    actually find the "gphy0" and "gphy1" clocks.
    
    Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
    Cc: stable@vger.kernel.org
    Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 71a20b798da3964b669f51f22cd0b3856549a571
Author: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Date:   Sun Jun 28 21:06:38 2020 -0400

    cifs: Fix the target file was deleted when rename failed.
    
    commit 9ffad9263b467efd8f8dc7ae1941a0a655a2bab2 upstream.
    
    When xfstest generic/035, we found the target file was deleted
    if the rename return -EACESS.
    
    In cifs_rename2, we unlink the positive target dentry if rename
    failed with EACESS or EEXIST, even if the target dentry is positived
    before rename. Then the existing file was deleted.
    
    We should just delete the target file which created during the
    rename.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Reviewed-by: Aurelien Aptel <aaptel@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 49dae9bed7dda969e538e09ebae68f1dc70df8d5
Author: Paul Aurich <paul@darkrain42.org>
Date:   Fri Jun 26 12:58:08 2020 -0700

    SMB3: Honor 'handletimeout' flag for multiuser mounts
    
    commit 6b356f6cf941d5054d7fab072cae4a5f8658e3db upstream.
    
    Fixes: ca567eb2b3f0 ("SMB3: Allow persistent handle timeout to be configurable on mount")
    Signed-off-by: Paul Aurich <paul@darkrain42.org>
    CC: Stable <stable@vger.kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Reviewed-by: Aurelien Aptel <aaptel@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7ab27439fec73ae24ab7f5e61fb574ac1a537721
Author: Paul Aurich <paul@darkrain42.org>
Date:   Fri Jun 26 12:58:07 2020 -0700

    SMB3: Honor lease disabling for multiuser mounts
    
    commit ad35f169db6cd5a4c5c0a5a42fb0cad3efeccb83 upstream.
    
    Fixes: 3e7a02d47872 ("smb3: allow disabling requesting leases")
    Signed-off-by: Paul Aurich <paul@darkrain42.org>
    CC: Stable <stable@vger.kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Reviewed-by: Aurelien Aptel <aaptel@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0d5824aea7a07697cb11e7782e38f3a7e24a07a4
Author: Paul Aurich <paul@darkrain42.org>
Date:   Fri Jun 26 12:58:06 2020 -0700

    SMB3: Honor persistent/resilient handle flags for multiuser mounts
    
    commit 00dfbc2f9c61185a2e662f27c45a0bb29b2a134f upstream.
    
    Without this:
    
    - persistent handles will only be enabled for per-user tcons if the
      server advertises the 'Continuous Availabity' capability
    - resilient handles would never be enabled for per-user tcons
    
    Signed-off-by: Paul Aurich <paul@darkrain42.org>
    CC: Stable <stable@vger.kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Reviewed-by: Aurelien Aptel <aaptel@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d56787683c611791c1b4720c74cee0075d4e1452
Author: Paul Aurich <paul@darkrain42.org>
Date:   Fri Jun 26 12:58:05 2020 -0700

    SMB3: Honor 'seal' flag for multiuser mounts
    
    commit cc15461c73d7d044d56c47e869a215e49bd429c8 upstream.
    
    Ensure multiuser SMB3 mounts use encryption for all users' tcons if the
    mount options are configured to require encryption. Without this, only
    the primary tcon and IPC tcons are guaranteed to be encrypted. Per-user
    tcons would only be encrypted if the server was configured to require
    encryption.
    
    Signed-off-by: Paul Aurich <paul@darkrain42.org>
    CC: Stable <stable@vger.kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Reviewed-by: Aurelien Aptel <aaptel@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e0ed5a36fb3ab9e7b9ee45cd17f09f6d5f594360
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Jul 7 14:42:38 2020 +0200

    Revert "ALSA: usb-audio: Improve frames size computation"
    
    This reverts commit aba41867dd66939d336fdf604e4d73b805d8039f which is
    commit f0bd62b64016508938df9babe47f65c2c727d25c upstream.
    
    It causes a number of reported issues and a fix for it has not hit
    Linus's tree yet.  Revert this to resolve those problems.
    
    Cc: Alexander Tsoy <alexander@tsoy.me>
    Cc: Takashi Iwai <tiwai@suse.de>
    Cc: Sasha Levin <sashal@kernel.org>
    Cc: Hans de Goede <jwrdegoede@fedoraproject.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe05e114d0fde7f644ac9ab5edfce3fa65650875
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Tue Jun 16 16:43:18 2020 -0400

    nfsd: apply umask on fs without ACL support
    
    commit 22cf8419f1319ff87ec759d0ebdff4cbafaee832 upstream.
    
    The server is failing to apply the umask when creating new objects on
    filesystems without ACL support.
    
    To reproduce this, you need to use NFSv4.2 and a client and server
    recent enough to support umask, and you need to export a filesystem that
    lacks ACL support (for example, ext4 with the "noacl" mount option).
    
    Filesystems with ACL support are expected to take care of the umask
    themselves (usually by calling posix_acl_create).
    
    For filesystems without ACL support, this is up to the caller of
    vfs_create(), vfs_mknod(), or vfs_mkdir().
    
    Reported-by: Elliott Mitchell <ehem+debian@m5p.com>
    Reported-by: Salvatore Bonaccorso <carnil@debian.org>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Fixes: 47057abde515 ("nfsd: add support for the umask attribute")
    Cc: stable@vger.kernel.org
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4ee7f1d2f1c9aa6fe6583a6f42820126c52bde46
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Mon Jun 22 13:05:42 2020 +0200

    spi: spi-fsl-dspi: Fix external abort on interrupt in resume or exit paths
    
    commit 3d87b613d6a3c6f0980e877ab0895785a2dde581 upstream.
    
    If shared interrupt comes late, during probe error path or device remove
    (could be triggered with CONFIG_DEBUG_SHIRQ), the interrupt handler
    dspi_interrupt() will access registers with the clock being disabled.
    This leads to external abort on non-linefetch on Toradex Colibri VF50
    module (with Vybrid VF5xx):
    
        $ echo 4002d000.spi > /sys/devices/platform/soc/40000000.bus/4002d000.spi/driver/unbind
    
        Unhandled fault: external abort on non-linefetch (0x1008) at 0x8887f02c
        Internal error: : 1008 [#1] ARM
        Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree)
        Backtrace:
          (regmap_mmio_read32le)
          (regmap_mmio_read)
          (_regmap_bus_reg_read)
          (_regmap_read)
          (regmap_read)
          (dspi_interrupt)
          (free_irq)
          (devm_irq_release)
          (release_nodes)
          (devres_release_all)
          (device_release_driver_internal)
    
    The resource-managed framework should not be used for shared interrupt
    handling, because the interrupt handler might be called after releasing
    other resources and disabling clocks.
    
    Similar bug could happen during suspend - the shared interrupt handler
    could be invoked after suspending the device.  Each device sharing this
    interrupt line should disable the IRQ during suspend so handler will be
    invoked only in following cases:
    1. None suspended,
    2. All devices resumed.
    
    Fixes: 349ad66c0ab0 ("spi:Add Freescale DSPI driver for Vybrid VF610 platform")
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200622110543.5035-3-krzk@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9d60af5c3bb3f7fca9fbffaf5eaa0f0514058594
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Sun Jun 28 13:52:44 2020 +0200

    i2c: mlxcpld: check correct size of maximum RECV_LEN packet
    
    [ Upstream commit 597911287fcd13c3a4b4aa3e0a52b33d431e0a8e ]
    
    I2C_SMBUS_BLOCK_MAX defines already the maximum number as defined in the
    SMBus 2.0 specs. I don't see a reason to add 1 here. Also, fix the errno
    to what is suggested for this error.
    
    Fixes: c9bfdc7c16cb ("i2c: mlxcpld: Add support for smbus block read transaction")
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Reviewed-by: Michael Shych <michaelsh@mellanox.com>
    Tested-by: Michael Shych <michaelsh@mellanox.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b460fc9d0525a1dbab068acf498a73db89695468
Author: Chris Packham <chris.packham@alliedtelesis.co.nz>
Date:   Thu Jul 2 10:39:11 2020 +1200

    i2c: algo-pca: Add 0x78 as SCL stuck low status for PCA9665
    
    [ Upstream commit cd217f2300793a106b49c7dfcbfb26e348bc7593 ]
    
    The PCA9665 datasheet says that I2CSTA = 78h indicates that SCL is stuck
    low, this differs to the PCA9564 which uses 90h for this indication.
    Treat either 0x78 or 0x90 as an indication that the SCL line is stuck.
    
    Based on looking through the PCA9564 and PCA9665 datasheets this should
    be safe for both chips. The PCA9564 should not return 0x78 for any valid
    state and the PCA9665 should not return 0x90.
    
    Fixes: eff9ec95efaa ("i2c-algo-pca: Add PCA9665 support")
    Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a632f91f7a9c96593f50605f550654ccc575d330
Author: Kees Cook <keescook@chromium.org>
Date:   Fri Jul 3 15:15:21 2020 -0700

    samples/vfs: avoid warning in statx override
    
    [ Upstream commit c3eeaae9fd736b7f2afbda8d3cbb1cbae06decf3 ]
    
    Something changed recently to uncover this warning:
    
      samples/vfs/test-statx.c:24:15: warning: `struct foo' declared inside parameter list will not be visible outside of this definition or declaration
         24 | #define statx foo
            |               ^~~
    
    Which is due the use of "struct statx" (here, "struct foo") in a function
    prototype argument list before it has been defined:
    
     int
     # 56 "/usr/include/x86_64-linux-gnu/bits/statx-generic.h"
        foo
     # 56 "/usr/include/x86_64-linux-gnu/bits/statx-generic.h" 3 4
              (int __dirfd, const char *__restrict __path, int __flags,
                unsigned int __mask, struct
     # 57 "/usr/include/x86_64-linux-gnu/bits/statx-generic.h"
                                           foo
     # 57 "/usr/include/x86_64-linux-gnu/bits/statx-generic.h" 3 4
                                                 *__restrict __buf)
       __attribute__ ((__nothrow__ , __leaf__)) __attribute__ ((__nonnull__ (2, 5)));
    
    Add explicit struct before #include to avoid warning.
    
    Fixes: f1b5618e013a ("vfs: Add a sample program for the new mount API")
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Miklos Szeredi <mszeredi@redhat.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: David Howells <dhowells@redhat.com>
    Link: http://lkml.kernel.org/r/202006282213.C516EA6@keescook
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cd62eeb31512441860d221440d23d82cf8b9a6ff
Author: Christoph Hellwig <hch@lst.de>
Date:   Mon Jun 29 16:30:19 2020 +0200

    nvme: fix a crash in nvme_mpath_add_disk
    
    [ Upstream commit 72d447113bb751ded97b2e2c38f886e4a4139082 ]
    
    For private namespaces ns->head_disk is NULL, so add a NULL check
    before updating the BDI capabilities.
    
    Fixes: b2ce4d90690b ("nvme-multipath: set bdi capabilities once")
    Reported-by: Avinash M N <Avinash.M.N@wdc.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Reviewed-by: Max Gurtovoy <maxg@mellanox.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c64141c68f725068440fbc13eb63dbb283e99168
Author: Sagi Grimberg <sagi@grimberg.me>
Date:   Fri Jun 26 10:46:29 2020 -0700

    nvme: fix identify error status silent ignore
    
    [ Upstream commit ea43d9709f727e728e933a8157a7a7ca1a868281 ]
    
    Commit 59c7c3caaaf8 intended to only silently ignore non retry-able
    errors (DNR bit set) such that we can still identify misbehaving
    controllers, and in the other hand propagate retry-able errors (DNR bit
    cleared) so we don't wrongly abandon a namespace just because it happens
    to be temporarily inaccessible.
    
    The goal remains the same as the original commit where this was
    introduced but unfortunately had the logic backwards.
    
    Fixes: 59c7c3caaaf8 ("nvme: fix possible hang when ns scanning fails during error recovery")
    Reported-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
    Reviewed-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7d3f489e61b6d265dac19190392805c3560a83a0
Author: Paul Aurich <paul@darkrain42.org>
Date:   Fri Jun 26 12:58:09 2020 -0700

    SMB3: Honor 'posix' flag for multiuser mounts
    
    [ Upstream commit 5391b8e1b7b7e5cfa2dd4ffdc4b8c6b64dfd1866 ]
    
    The flag from the primary tcon needs to be copied into the volume info
    so that cifs_get_tcon will try to enable extensions on the per-user
    tcon. At that point, since posix extensions must have already been
    enabled on the superblock, don't try to needlessly adjust the mount
    flags.
    
    Fixes: ce558b0e17f8 ("smb3: Add posix create context for smb3.11 posix mounts")
    Fixes: b326614ea215 ("smb3: allow "posix" mount option to enable new SMB311 protocol extensions")
    Signed-off-by: Paul Aurich <paul@darkrain42.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Reviewed-by: Aurelien Aptel <aaptel@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8964c93436ad95456f930e4994242da474ba8f7b
Author: Hou Tao <houtao1@huawei.com>
Date:   Mon Jun 15 12:14:59 2020 +0800

    virtio-blk: free vblk-vqs in error path of virtblk_probe()
    
    [ Upstream commit e7eea44eefbdd5f0345a0a8b80a3ca1c21030d06 ]
    
    Else there will be memory leak if alloc_disk() fails.
    
    Fixes: 6a27b656fc02 ("block: virtio-blk: support multi virt queues per virtio-blk device")
    Signed-off-by: Hou Tao <houtao1@huawei.com>
    Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
    Reviewed-by: Ming Lei <ming.lei@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f795a88eade59463e842a506936003b5945e1db2
Author: Chen-Yu Tsai <wens@csie.org>
Date:   Mon Jun 29 14:00:32 2020 +0800

    drm: sun4i: hdmi: Remove extra HPD polling
    
    [ Upstream commit bda8eaa6dee7525f4dac950810a85a88bf6c2ba0 ]
    
    The HPD sense mechanism in Allwinner's old HDMI encoder hardware is more
    or less an input-only GPIO. Other GPIO-based HPD implementations
    directly return the current state, instead of polling for a specific
    state and returning the other if that times out.
    
    Remove the I/O polling from sun4i_hdmi_connector_detect() and directly
    return a known state based on the current reading. This also gets rid
    of excessive CPU usage by kworker as reported on Stack Exchange [1] and
    Armbian forums [2].
    
     [1] https://superuser.com/questions/1515001/debian-10-buster-on-cubietruck-with-bug-in-sun4i-drm-hdmi
     [2] https://forum.armbian.com/topic/14282-headless-systems-and-sun4i_drm_hdmi-a10a20/
    
    Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
    Signed-off-by: Chen-Yu Tsai <wens@csie.org>
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Link: https://patchwork.freedesktop.org/patch/msgid/20200629060032.24134-1-wens@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c84138b3c162636ad43e5dd3b8e21aef4fff8013
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Tue Jun 23 21:01:19 2020 -0400

    nfsd: fix nfsdfs inode reference count leak
    
    [ Upstream commit bf2654017e0268cc83dc88d56f0e67ff4406631d ]
    
    I don't understand this code well, but  I'm seeing a warning about a
    still-referenced inode on unmount, and every other similar filesystem
    does a dput() here.
    
    Fixes: e8a79fb14f6b ("nfsd: add nfsd/clients directory")
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2571e1735602d950c0b11dfed1d2e53cdc64000f
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Tue Jun 23 16:00:33 2020 -0400

    nfsd4: fix nfsdfs reference count loop
    
    [ Upstream commit 681370f4b00af0fcc65bbfb9f82de526ab7ceb0a ]
    
    We don't drop the reference on the nfsdfs filesystem with
    mntput(nn->nfsd_mnt) until nfsd_exit_net(), but that won't be called
    until the nfsd module's unloaded, and we can't unload the module as long
    as there's a reference on nfsdfs.  So this prevents module unloading.
    
    Fixes: 2c830dd7209b ("nfsd: persist nfsd filesystem across mounts")
    Reported-and-Tested-by:  Luo Xiaogang <lxgrxd@163.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 31ec38ec9cd523e9448163962cdaae2c7f2662b5
Author: Dien Pham <dien.pham.ry@renesas.com>
Date:   Thu Jun 25 20:38:19 2020 +0900

    thermal/drivers/rcar_gen3: Fix undefined temperature if negative
    
    [ Upstream commit 5f8f06425a0dcdad7bedbb77e67f5c65ab4dacfc ]
    
    As description for DIV_ROUND_CLOSEST in file include/linux/kernel.h.
      "Result is undefined for negative divisors if the dividend variable
       type is unsigned and for negative dividends if the divisor variable
       type is unsigned."
    
    In current code, the FIXPT_DIV uses DIV_ROUND_CLOSEST but has not
    checked sign of divisor before using. It makes undefined temperature
    value in case the value is negative.
    
    This patch fixes to satisfy DIV_ROUND_CLOSEST description
    and fix bug too. Note that the variable name "reg" is not good
    because it should be the same type as rcar_gen3_thermal_read().
    However, it's better to rename the "reg" in a further patch as
    cleanup.
    
    Signed-off-by: Van Do <van.do.xw@renesas.com>
    Signed-off-by: Dien Pham <dien.pham.ry@renesas.com>
    [shimoda: minor fixes, add Fixes tag]
    Fixes: 564e73d283af ("thermal: rcar_gen3_thermal: Add R-Car Gen3 thermal driver")
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Reviewed-by: Niklas Soderlund <niklas.soderlund+renesas@ragnatech.se>
    Tested-by: Niklas Soderlund <niklas.soderlund+renesas@ragnatech.se>
    Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Link: https://lore.kernel.org/r/1593085099-2057-1-git-send-email-yoshihiro.shimoda.uh@renesas.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a65bde0010088abdb431758d241fddb795731f9b
Author: Michael Kao <michael.kao@mediatek.com>
Date:   Mon Mar 23 20:15:35 2020 +0800

    thermal/drivers/mediatek: Fix bank number settings on mt8183
    
    [ Upstream commit 14533a5a6c12e8d7de79d309d4085bf186058fe1 ]
    
    MT8183_NUM_ZONES should be set to 1
    because MT8183 doesn't have multiple banks.
    
    Fixes: a4ffe6b52d27 ("thermal: mediatek: add support for MT8183")
    Signed-off-by: Michael Kao <michael.kao@mediatek.com>
    Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Link: https://lore.kernel.org/r/20200323121537.22697-6-michael.kao@mediatek.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c9426817eac7fffc7561c080e135c516aa5c8a65
Author: Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>
Date:   Thu Jun 25 13:32:42 2020 +0900

    hwmon: (acpi_power_meter) Fix potential memory leak in acpi_power_meter_add()
    
    [ Upstream commit 8b97f9922211c44a739c5cbd9502ecbb9f17f6d1 ]
    
    Although it rarely happens, we should call free_capabilities()
    if error happens after read_capabilities() to free allocated strings.
    
    Fixes: de584afa5e188 ("hwmon driver for ACPI 4.0 power meters")
    Signed-off-by: Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>
    Link: https://lore.kernel.org/r/20200625043242.31175-1-misono.tomohiro@jp.fujitsu.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3e7bd7e10639dbf02892d3b0ee0bc6ff45c601d4
Author: Chu Lin <linchuyuan@google.com>
Date:   Tue Jun 23 22:13:08 2020 +0000

    hwmon: (max6697) Make sure the OVERT mask is set correctly
    
    [ Upstream commit 016983d138cbe99a5c0aaae0103ee88f5300beb3 ]
    
    Per the datasheet for max6697, OVERT mask and ALERT mask are different.
    For example, the 7th bit of OVERT is the local channel but for alert
    mask, the 6th bit is the local channel. Therefore, we can't apply the
    same mask for both registers. In addition to that, the max6697 driver
    is supposed to be compatibale with different models. I manually went over
    all the listed chips and made sure all chip types have the same layout.
    
    Testing;
        mask value of 0x9 should map to 0x44 for ALERT and 0x84 for OVERT.
        I used iotool to read the reg value back to verify. I only tested this
        change on max6581.
    
    Reference:
    https://datasheets.maximintegrated.com/en/ds/MAX6581.pdf
    https://datasheets.maximintegrated.com/en/ds/MAX6697.pdf
    https://datasheets.maximintegrated.com/en/ds/MAX6699.pdf
    
    Signed-off-by: Chu Lin <linchuyuan@google.com>
    Fixes: 5372d2d71c46e ("hwmon: Driver for Maxim MAX6697 and compatibles")
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0465f54c5cc43daa6f09e4aefcac7bf8d6f7ff30
Author: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Date:   Wed Jun 24 01:51:37 2020 +0530

    cxgb4: fix SGE queue dump destination buffer context
    
    [ Upstream commit 1992ded5d111997877a9a25205976d8d03c46814 ]
    
    The data in destination buffer is expected to be be parsed in big
    endian. So, use the right context.
    
    Fixes following sparse warning:
    cudbg_lib.c:2041:44: warning: incorrect type in assignment (different
    base types)
    cudbg_lib.c:2041:44:    expected unsigned long long [usertype]
    cudbg_lib.c:2041:44:    got restricted __be64 [usertype]
    
    Fixes: 736c3b94474e ("cxgb4: collect egress and ingress SGE queue contexts")
    Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6bcb00d08361b4e2f8891c9a1f7bee6a5504ad2a
Author: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Date:   Wed Jun 24 01:51:36 2020 +0530

    cxgb4: use correct type for all-mask IP address comparison
    
    [ Upstream commit f286dd8eaad5a2758750f407ab079298e0bcc8a5 ]
    
    Use correct type to check for all-mask exact match IP addresses.
    
    Fixes following sparse warnings due to big endian value checks
    against 0xffffffff in is_addr_all_mask():
    cxgb4_filter.c:977:25: warning: restricted __be32 degrades to integer
    cxgb4_filter.c:983:37: warning: restricted __be32 degrades to integer
    cxgb4_filter.c:984:37: warning: restricted __be32 degrades to integer
    cxgb4_filter.c:985:37: warning: restricted __be32 degrades to integer
    cxgb4_filter.c:986:37: warning: restricted __be32 degrades to integer
    
    Fixes: 3eb8b62d5a26 ("cxgb4: add support to create hash-filters via tc-flower offload")
    Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f68bda7726393cf2862a3bce2649faf1b9e3a937
Author: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Date:   Wed Jun 24 01:51:35 2020 +0530

    cxgb4: fix endian conversions for L4 ports in filters
    
    [ Upstream commit 63b53b0b99cd5f2d9754a21eda2ed8e706646cc9 ]
    
    The source and destination L4 ports in filter offload need to be
    in CPU endian. They will finally be converted to Big Endian after
    all operations are done and before giving them to hardware. The
    L4 ports for NAT are expected to be passed as a byte stream TCB.
    So, treat them as such.
    
    Fixes following sparse warnings in several places:
    cxgb4_tc_flower.c:159:33: warning: cast from restricted __be16
    cxgb4_tc_flower.c:159:33: warning: incorrect type in argument 1 (different
    base types)
    cxgb4_tc_flower.c:159:33:    expected unsigned short [usertype] val
    cxgb4_tc_flower.c:159:33:    got restricted __be16 [usertype] dst
    
    Fixes: dca4faeb812f ("cxgb4: Add LE hash collision bug fix path in LLD driver")
    Fixes: 62488e4b53ae ("cxgb4: add basic tc flower offload support")
    Fixes: 557ccbf9dfa8 ("cxgb4: add tc flower support for L3/L4 rewrite")
    Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 180fbf10a26d7c8dc50f40f3f50705d31202d7b2
Author: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Date:   Wed Jun 24 01:51:34 2020 +0530

    cxgb4: parse TC-U32 key values and masks natively
    
    [ Upstream commit 27f78cb245abdb86735529c13b0a579f57829e71 ]
    
    TC-U32 passes all keys values and masks in __be32 format. The parser
    already expects this and hence pass the value and masks in __be32
    natively to the parser.
    
    Fixes following sparse warnings in several places:
    cxgb4_tc_u32.c:57:21: warning: incorrect type in assignment (different base
    types)
    cxgb4_tc_u32.c:57:21:    expected unsigned int [usertype] val
    cxgb4_tc_u32.c:57:21:    got restricted __be32 [usertype] val
    cxgb4_tc_u32_parse.h:48:24: warning: cast to restricted __be32
    
    Fixes: 2e8aad7bf203 ("cxgb4: add parser to translate u32 filters to internal spec")
    Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0dc4dd433b94b4ebf9429d871efac43ad792f112
Author: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Date:   Wed Jun 24 01:51:33 2020 +0530

    cxgb4: use unaligned conversion for fetching timestamp
    
    [ Upstream commit 589b1c9c166dce120e27b32a83a78f55464a7ef9 ]
    
    Use get_unaligned_be64() to fetch the timestamp needed for ns_to_ktime()
    conversion.
    
    Fixes following sparse warning:
    sge.c:3282:43: warning: cast to restricted __be64
    
    Fixes: a456950445a0 ("cxgb4: time stamping interface for PTP")
    Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8a1b8e64204e8ec9e80402f0f05e30f3ba4cd402
Author: Mark Zhang <markz@mellanox.com>
Date:   Sun Jun 21 14:00:00 2020 +0300

    RDMA/counter: Query a counter before release
    
    [ Upstream commit c1d869d64a1955817c4d6fff08ecbbe8e59d36f8 ]
    
    Query a dynamically-allocated counter before release it, to update it's
    hwcounters and log all of them into history data. Otherwise all values of
    these hwcounters will be lost.
    
    Fixes: f34a55e497e8 ("RDMA/core: Get sum value of all counters when perform a sysfs stat read")
    Link: https://lore.kernel.org/r/20200621110000.56059-1-leon@kernel.org
    Signed-off-by: Mark Zhang <markz@mellanox.com>
    Reviewed-by: Maor Gottlieb <maorg@mellanox.com>
    Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 53e9b62672f78d4eed4f2445c41908af23289233
Author: David Howells <dhowells@redhat.com>
Date:   Wed Jun 17 15:46:33 2020 +0100

    rxrpc: Fix afs large storage transmission performance drop
    
    [ Upstream commit 02c28dffb13abbaaedece1e4a6493b48ad3f913a ]
    
    Commit 2ad6691d988c, which moved the modification of the status annotation
    for a packet in the Tx buffer prior to the retransmission moved the state
    clearance, but managed to lose the bit that set it to UNACK.
    
    Consequently, if a retransmission occurs, the packet is accidentally
    changed to the ACK state (ie. 0) by masking it off, which means that the
    packet isn't counted towards the tally of newly-ACK'd packets if it gets
    hard-ACK'd.  This then prevents the congestion control algorithm from
    recovering properly.
    
    Fix by reinstating the change of state to UNACK.
    
    Spotted by the generic/460 xfstest.
    
    Fixes: 2ad6691d988c ("rxrpc: Fix race between incoming ACK parser and retransmitter")
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 60d7de28e0ca288faca3639aae0739858e168f9d
Author: Chen Tao <chentao107@huawei.com>
Date:   Mon Jun 8 09:48:59 2020 +0800

    drm/msm/dpu: fix error return code in dpu_encoder_init
    
    [ Upstream commit aa472721c8dbe1713cf510f56ffbc56ae9e14247 ]
    
    Fix to return negative error code -ENOMEM with the use of
    ERR_PTR from dpu_encoder_init.
    
    Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
    Signed-off-by: Chen Tao <chentao107@huawei.com>
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cc0f678353027580c09748ef15e0183a37745291
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Mon Jun 8 16:48:43 2020 +1000

    crypto: af_alg - fix use-after-free in af_alg_accept() due to bh_lock_sock()
    
    commit 34c86f4c4a7be3b3e35aa48bd18299d4c756064d upstream.
    
    The locking in af_alg_release_parent is broken as the BH socket
    lock can only be taken if there is a code-path to handle the case
    where the lock is owned by process-context.  Instead of adding
    such handling, we can fix this by changing the ref counts to
    atomic_t.
    
    This patch also modifies the main refcnt to include both normal
    and nokey sockets.  This way we don't have to fudge the nokey
    ref count when a socket changes from nokey to normal.
    
    Credits go to Mauricio Faria de Oliveira who diagnosed this bug
    and sent a patch for it:
    
    https://lore.kernel.org/linux-crypto/20200605161657.535043-1-mfo@canonical.com/
    
    Reported-by: Brian Moyles <bmoyles@netflix.com>
    Reported-by: Mauricio Faria de Oliveira <mfo@canonical.com>
    Fixes: 37f96694cf73 ("crypto: af_alg - Use bh_lock_sock in...")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5d6b46a94dbb42d6181fa16c6719cec58ed7c110
Author: James Bottomley <James.Bottomley@HansenPartnership.com>
Date:   Thu May 28 11:10:57 2020 -0700

    tpm: Fix TIS locality timeout problems
    
    commit 7862840219058436b80029a0263fd1ef065fb1b3 upstream.
    
    It has been reported that some TIS based TPMs are giving unexpected
    errors when using the O_NONBLOCK path of the TPM device. The problem
    is that some TPMs don't like it when you get and then relinquish a
    locality (as the tpm_try_get_ops()/tpm_put_ops() pair does) without
    sending a command.  This currently happens all the time in the
    O_NONBLOCK write path. Fix this by moving the tpm_try_get_ops()
    further down the code to after the O_NONBLOCK determination is made.
    This is safe because the priv->buffer_mutex still protects the priv
    state being modified.
    
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206275
    Fixes: d23d12484307 ("tpm: fix invalid locking in NONBLOCKING mode")
    Reported-by: Mario Limonciello <Mario.Limonciello@dell.com>
    Tested-by: Alex Guzman <alex@guzman.io>
    Cc: stable@vger.kernel.org
    Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
    Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
    Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
    Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 563e9491f0a30a947cfa757cc6d3219fb49d3979
Author: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Date:   Tue Jun 23 00:20:22 2020 +0300

    selftests: tpm: Use /bin/sh instead of /bin/bash
    
    commit 377ff83083c953dd58c5a030b3c9b5b85d8cc727 upstream.
    
    It's better to use /bin/sh instead of /bin/bash in order to run the tests
    in the BusyBox shell.
    
    Fixes: 6ea3dfe1e073 ("selftests: add TPM 2.0 tests")
    Cc: stable@vger.kernel.org
    Cc: linux-integrity@vger.kernel.org
    Cc: linux-kselftest@vger.kernel.org
    Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f98a9ed57990560889a392f5b79508e0ac1fdf4
Author: Douglas Anderson <dianders@chromium.org>
Date:   Tue Jun 2 15:47:39 2020 -0700

    kgdb: Avoid suspicious RCU usage warning
    
    [ Upstream commit 440ab9e10e2e6e5fd677473ee6f9e3af0f6904d6 ]
    
    At times when I'm using kgdb I see a splat on my console about
    suspicious RCU usage.  I managed to come up with a case that could
    reproduce this that looked like this:
    
      WARNING: suspicious RCU usage
      5.7.0-rc4+ #609 Not tainted
      -----------------------------
      kernel/pid.c:395 find_task_by_pid_ns() needs rcu_read_lock() protection!
    
      other info that might help us debug this:
    
        rcu_scheduler_active = 2, debug_locks = 1
      3 locks held by swapper/0/1:
       #0: ffffff81b6b8e988 (&dev->mutex){....}-{3:3}, at: __device_attach+0x40/0x13c
       #1: ffffffd01109e9e8 (dbg_master_lock){....}-{2:2}, at: kgdb_cpu_enter+0x20c/0x7ac
       #2: ffffffd01109ea90 (dbg_slave_lock){....}-{2:2}, at: kgdb_cpu_enter+0x3ec/0x7ac
    
      stack backtrace:
      CPU: 7 PID: 1 Comm: swapper/0 Not tainted 5.7.0-rc4+ #609
      Hardware name: Google Cheza (rev3+) (DT)
      Call trace:
       dump_backtrace+0x0/0x1b8
       show_stack+0x1c/0x24
       dump_stack+0xd4/0x134
       lockdep_rcu_suspicious+0xf0/0x100
       find_task_by_pid_ns+0x5c/0x80
       getthread+0x8c/0xb0
       gdb_serial_stub+0x9d4/0xd04
       kgdb_cpu_enter+0x284/0x7ac
       kgdb_handle_exception+0x174/0x20c
       kgdb_brk_fn+0x24/0x30
       call_break_hook+0x6c/0x7c
       brk_handler+0x20/0x5c
       do_debug_exception+0x1c8/0x22c
       el1_sync_handler+0x3c/0xe4
       el1_sync+0x7c/0x100
       rpmh_rsc_probe+0x38/0x420
       platform_drv_probe+0x94/0xb4
       really_probe+0x134/0x300
       driver_probe_device+0x68/0x100
       __device_attach_driver+0x90/0xa8
       bus_for_each_drv+0x84/0xcc
       __device_attach+0xb4/0x13c
       device_initial_probe+0x18/0x20
       bus_probe_device+0x38/0x98
       device_add+0x38c/0x420
    
    If I understand properly we should just be able to blanket kgdb under
    one big RCU read lock and the problem should go away.  We'll add it to
    the beast-of-a-function known as kgdb_cpu_enter().
    
    With this I no longer get any splats and things seem to work fine.
    
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Link: https://lore.kernel.org/r/20200602154729.v2.1.I70e0d4fd46d5ed2aaf0c98a355e8e1b7a5bb7e4e@changeid
    Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e6b2e3b5e16ea0089ea6368306fbb7697fb3733a
Author: Sagi Grimberg <sagi@grimberg.me>
Date:   Wed Jun 24 01:53:12 2020 -0700

    nvme-multipath: fix bogus request queue reference put
    
    [ Upstream commit c31244669f57963b6ce133a5555b118fc50aec95 ]
    
    The mpath disk node takes a reference on the request mpath
    request queue when adding live path to the mpath gendisk.
    However if we connected to an inaccessible path device_add_disk
    is not called, so if we disconnect and remove the mpath gendisk
    we endup putting an reference on the request queue that was
    never taken [1].
    
    Fix that to check if we ever added a live path (using
    NVME_NS_HEAD_HAS_DISK flag) and if not, clear the disk->queue
    reference.
    
    [1]:
    ------------[ cut here ]------------
    refcount_t: underflow; use-after-free.
    WARNING: CPU: 1 PID: 1372 at lib/refcount.c:28 refcount_warn_saturate+0xa6/0xf0
    CPU: 1 PID: 1372 Comm: nvme Tainted: G           O      5.7.0-rc2+ #3
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1 04/01/2014
    RIP: 0010:refcount_warn_saturate+0xa6/0xf0
    RSP: 0018:ffffb29e8053bdc0 EFLAGS: 00010282
    RAX: 0000000000000000 RBX: ffff8b7a2f4fc060 RCX: 0000000000000007
    RDX: 0000000000000007 RSI: 0000000000000092 RDI: ffff8b7a3ec99980
    RBP: ffff8b7a2f4fc000 R08: 00000000000002e1 R09: 0000000000000004
    R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
    R13: fffffffffffffff2 R14: ffffb29e8053bf08 R15: ffff8b7a320e2da0
    FS:  00007f135d4ca800(0000) GS:ffff8b7a3ec80000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00005651178c0c30 CR3: 000000003b650005 CR4: 0000000000360ee0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     disk_release+0xa2/0xc0
     device_release+0x28/0x80
     kobject_put+0xa5/0x1b0
     nvme_put_ns_head+0x26/0x70 [nvme_core]
     nvme_put_ns+0x30/0x60 [nvme_core]
     nvme_remove_namespaces+0x9b/0xe0 [nvme_core]
     nvme_do_delete_ctrl+0x43/0x5c [nvme_core]
     nvme_sysfs_delete.cold+0x8/0xd [nvme_core]
     kernfs_fop_write+0xc1/0x1a0
     vfs_write+0xb6/0x1a0
     ksys_write+0x5f/0xe0
     do_syscall_64+0x52/0x1a0
     entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    Reported-by: Anton Eidelman <anton@lightbitslabs.com>
    Tested-by: Anton Eidelman <anton@lightbitslabs.com>
    Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5e9523d7e8cd96f9996cf4d1f102818e0822bb28
Author: Anton Eidelman <anton@lightbitslabs.com>
Date:   Wed Jun 24 01:53:11 2020 -0700

    nvme-multipath: fix deadlock due to head->lock
    
    [ Upstream commit d8a22f85609fadb46ba699e0136cc3ebdeebff79 ]
    
    In the following scenario scan_work and ana_work will deadlock:
    
    When scan_work calls nvme_mpath_add_disk() this holds ana_lock
    and invokes nvme_parse_ana_log(), which may issue IO
    in device_add_disk() and hang waiting for an accessible path.
    
    While nvme_mpath_set_live() only called when nvme_state_is_live(),
    a transition may cause NVME_SC_ANA_TRANSITION and requeue the IO.
    
    Since nvme_mpath_set_live() holds ns->head->lock, an ana_work on
    ANY ctrl will not be able to complete nvme_mpath_set_live()
    on the same ns->head, which is required in order to update
    the new accessible path and remove NVME_NS_ANA_PENDING..
    Therefore IO never completes: deadlock [1].
    
    Fix:
    Move device_add_disk out of the head->lock and protect it with an
    atomic test_and_set for a new NVME_NS_HEAD_HAS_DISK bit.
    
    [1]:
    kernel: INFO: task kworker/u8:2:160 blocked for more than 120 seconds.
    kernel:       Tainted: G           OE     5.3.5-050305-generic #201910071830
    kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    kernel: kworker/u8:2    D    0   160      2 0x80004000
    kernel: Workqueue: nvme-wq nvme_ana_work [nvme_core]
    kernel: Call Trace:
    kernel:  __schedule+0x2b9/0x6c0
    kernel:  schedule+0x42/0xb0
    kernel:  schedule_preempt_disabled+0xe/0x10
    kernel:  __mutex_lock.isra.0+0x182/0x4f0
    kernel:  __mutex_lock_slowpath+0x13/0x20
    kernel:  mutex_lock+0x2e/0x40
    kernel:  nvme_update_ns_ana_state+0x22/0x60 [nvme_core]
    kernel:  nvme_update_ana_state+0xca/0xe0 [nvme_core]
    kernel:  nvme_parse_ana_log+0xa1/0x180 [nvme_core]
    kernel:  nvme_read_ana_log+0x76/0x100 [nvme_core]
    kernel:  nvme_ana_work+0x15/0x20 [nvme_core]
    kernel:  process_one_work+0x1db/0x380
    kernel:  worker_thread+0x4d/0x400
    kernel:  kthread+0x104/0x140
    kernel:  ret_from_fork+0x35/0x40
    kernel: INFO: task kworker/u8:4:439 blocked for more than 120 seconds.
    kernel:       Tainted: G           OE     5.3.5-050305-generic #201910071830
    kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    kernel: kworker/u8:4    D    0   439      2 0x80004000
    kernel: Workqueue: nvme-wq nvme_scan_work [nvme_core]
    kernel: Call Trace:
    kernel:  __schedule+0x2b9/0x6c0
    kernel:  schedule+0x42/0xb0
    kernel:  io_schedule+0x16/0x40
    kernel:  do_read_cache_page+0x438/0x830
    kernel:  read_cache_page+0x12/0x20
    kernel:  read_dev_sector+0x27/0xc0
    kernel:  read_lba+0xc1/0x220
    kernel:  efi_partition+0x1e6/0x708
    kernel:  check_partition+0x154/0x244
    kernel:  rescan_partitions+0xae/0x280
    kernel:  __blkdev_get+0x40f/0x560
    kernel:  blkdev_get+0x3d/0x140
    kernel:  __device_add_disk+0x388/0x480
    kernel:  device_add_disk+0x13/0x20
    kernel:  nvme_mpath_set_live+0x119/0x140 [nvme_core]
    kernel:  nvme_update_ns_ana_state+0x5c/0x60 [nvme_core]
    kernel:  nvme_mpath_add_disk+0xbe/0x100 [nvme_core]
    kernel:  nvme_validate_ns+0x396/0x940 [nvme_core]
    kernel:  nvme_scan_work+0x256/0x390 [nvme_core]
    kernel:  process_one_work+0x1db/0x380
    kernel:  worker_thread+0x4d/0x400
    kernel:  kthread+0x104/0x140
    kernel:  ret_from_fork+0x35/0x40
    
    Fixes: 0d0b660f214d ("nvme: add ANA support")
    Signed-off-by: Anton Eidelman <anton@lightbitslabs.com>
    Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ad69fbe1d262af15fbeb7be7e205e8d6eb43b612
Author: Anton Eidelman <anton@lightbitslabs.com>
Date:   Wed Jun 24 01:53:09 2020 -0700

    nvme-multipath: fix deadlock between ana_work and scan_work
    
    [ Upstream commit 489dd102a2c7c94d783a35f9412eb085b8da1aa4 ]
    
    When scan_work calls nvme_mpath_add_disk() this holds ana_lock
    and invokes nvme_parse_ana_log(), which may issue IO
    in device_add_disk() and hang waiting for an accessible path.
    While nvme_mpath_set_live() only called when nvme_state_is_live(),
    a transition may cause NVME_SC_ANA_TRANSITION and requeue the IO.
    
    In order to recover and complete the IO ana_work on the same ctrl
    should be able to update the path state and remove NVME_NS_ANA_PENDING.
    
    The deadlock occurs because scan_work keeps holding ana_lock,
    so ana_work hangs [1].
    
    Fix:
    Now nvme_mpath_add_disk() uses nvme_parse_ana_log() to obtain a copy
    of the ANA group desc, and then calls nvme_update_ns_ana_state() without
    holding ana_lock.
    
    [1]:
    kernel: Workqueue: nvme-wq nvme_scan_work [nvme_core]
    kernel: Call Trace:
    kernel:  __schedule+0x2b9/0x6c0
    kernel:  schedule+0x42/0xb0
    kernel:  io_schedule+0x16/0x40
    kernel:  do_read_cache_page+0x438/0x830
    kernel:  read_cache_page+0x12/0x20
    kernel:  read_dev_sector+0x27/0xc0
    kernel:  read_lba+0xc1/0x220
    kernel:  efi_partition+0x1e6/0x708
    kernel:  check_partition+0x154/0x244
    kernel:  rescan_partitions+0xae/0x280
    kernel:  __blkdev_get+0x40f/0x560
    kernel:  blkdev_get+0x3d/0x140
    kernel:  __device_add_disk+0x388/0x480
    kernel:  device_add_disk+0x13/0x20
    kernel:  nvme_mpath_set_live+0x119/0x140 [nvme_core]
    kernel:  nvme_update_ns_ana_state+0x5c/0x60 [nvme_core]
    kernel:  nvme_set_ns_ana_state+0x1e/0x30 [nvme_core]
    kernel:  nvme_parse_ana_log+0xa1/0x180 [nvme_core]
    kernel:  nvme_mpath_add_disk+0x47/0x90 [nvme_core]
    kernel:  nvme_validate_ns+0x396/0x940 [nvme_core]
    kernel:  nvme_scan_work+0x24f/0x380 [nvme_core]
    kernel:  process_one_work+0x1db/0x380
    kernel:  worker_thread+0x249/0x400
    kernel:  kthread+0x104/0x140
    
    kernel: Workqueue: nvme-wq nvme_ana_work [nvme_core]
    kernel: Call Trace:
    kernel:  __schedule+0x2b9/0x6c0
    kernel:  schedule+0x42/0xb0
    kernel:  schedule_preempt_disabled+0xe/0x10
    kernel:  __mutex_lock.isra.0+0x182/0x4f0
    kernel:  ? __switch_to_asm+0x34/0x70
    kernel:  ? select_task_rq_fair+0x1aa/0x5c0
    kernel:  ? kvm_sched_clock_read+0x11/0x20
    kernel:  ? sched_clock+0x9/0x10
    kernel:  __mutex_lock_slowpath+0x13/0x20
    kernel:  mutex_lock+0x2e/0x40
    kernel:  nvme_read_ana_log+0x3a/0x100 [nvme_core]
    kernel:  nvme_ana_work+0x15/0x20 [nvme_core]
    kernel:  process_one_work+0x1db/0x380
    kernel:  worker_thread+0x4d/0x400
    kernel:  kthread+0x104/0x140
    kernel:  ? process_one_work+0x380/0x380
    kernel:  ? kthread_park+0x80/0x80
    kernel:  ret_from_fork+0x35/0x40
    
    Fixes: 0d0b660f214d ("nvme: add ANA support")
    Signed-off-by: Anton Eidelman <anton@lightbitslabs.com>
    Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c4f007d3dbdd455b04156541bd21fbfe29de3004
Author: Keith Busch <kbusch@kernel.org>
Date:   Thu Apr 9 09:09:04 2020 -0700

    nvme-multipath: set bdi capabilities once
    
    [ Upstream commit b2ce4d90690bd29ce5b554e203cd03682dd59697 ]
    
    The queues' backing device info capabilities don't change with each
    namespace revalidation. Set it only when each path's request_queue
    is initially added to a multipath queue.
    
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8f4aa3a6de249b9ae30b3d07ef13a20cae8193d5
Author: Christian Borntraeger <borntraeger@de.ibm.com>
Date:   Tue Mar 31 05:57:23 2020 -0400

    s390/debug: avoid kernel warning on too large number of pages
    
    [ Upstream commit 827c4913923e0b441ba07ba4cc41e01181102303 ]
    
    When specifying insanely large debug buffers a kernel warning is
    printed. The debug code does handle the error gracefully, though.
    Instead of duplicating the check let us silence the warning to
    avoid crashes when panic_on_warn is used.
    
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com>
    Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 517326aaf41e3a6c1d3a01596d5f426cfeacbec1
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Tue Mar 24 16:08:47 2020 -0400

    tools lib traceevent: Handle __attribute__((user)) in field names
    
    [ Upstream commit 74621d929d944529a5e2878a84f48bfa6fb69a66 ]
    
    Commit c61f13eaa1ee1 ("gcc-plugins: Add structleak for more stack
    initialization") added "__attribute__((user))" to the user when
    stackleak detector is enabled. This now appears in the field format of
    system call trace events for system calls that have user buffers. The
    "__attribute__((user))" breaks the parsing in libtraceevent. That needs
    to be handled.
    
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Jaewon Kim <jaewon31.kim@samsung.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Kees Kook <keescook@chromium.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: linux-mm@kvack.org
    Cc: linux-trace-devel@vger.kernel.org
    Link: http://lore.kernel.org/lkml/20200324200956.663647256@goodmis.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6f3b8c269d884c223a0d5e78b6f338c58dee0918
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Tue Mar 24 16:08:46 2020 -0400

    tools lib traceevent: Add append() function helper for appending strings
    
    [ Upstream commit 27d4d336f2872193e90ee5450559e1699fae0f6d ]
    
    There's several locations that open code realloc and strcat() to append
    text to strings. Add an append() function that takes a delimiter and a
    string to append to another string.
    
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Jaewon Lim <jaewon31.kim@samsung.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Kees Kook <keescook@chromium.org>
    Cc: linux-mm@kvack.org
    Cc: linux-trace-devel@vger.kernel.org
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Link: http://lore.kernel.org/lkml/20200324200956.515118403@goodmis.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3dca0a299ff43204a69c9a7a00ce2b3e7ab3088c
Author: Zqiang <qiang.zhang@windriver.com>
Date:   Fri Jun 12 11:52:10 2020 +0800

    usb: usbtest: fix missing kfree(dev->buf) in usbtest_disconnect
    
    [ Upstream commit 28ebeb8db77035e058a510ce9bd17c2b9a009dba ]
    
    BUG: memory leak
    unreferenced object 0xffff888055046e00 (size 256):
      comm "kworker/2:9", pid 2570, jiffies 4294942129 (age 1095.500s)
      hex dump (first 32 bytes):
        00 70 04 55 80 88 ff ff 18 bb 5a 81 ff ff ff ff  .p.U......Z.....
        f5 96 78 81 ff ff ff ff 37 de 8e 81 ff ff ff ff  ..x.....7.......
      backtrace:
        [<00000000d121dccf>] kmemleak_alloc_recursive
    include/linux/kmemleak.h:43 [inline]
        [<00000000d121dccf>] slab_post_alloc_hook mm/slab.h:586 [inline]
        [<00000000d121dccf>] slab_alloc_node mm/slub.c:2786 [inline]
        [<00000000d121dccf>] slab_alloc mm/slub.c:2794 [inline]
        [<00000000d121dccf>] kmem_cache_alloc_trace+0x15e/0x2d0 mm/slub.c:2811
        [<000000005c3c3381>] kmalloc include/linux/slab.h:555 [inline]
        [<000000005c3c3381>] usbtest_probe+0x286/0x19d0
    drivers/usb/misc/usbtest.c:2790
        [<000000001cec6910>] usb_probe_interface+0x2bd/0x870
    drivers/usb/core/driver.c:361
        [<000000007806c118>] really_probe+0x48d/0x8f0 drivers/base/dd.c:551
        [<00000000a3308c3e>] driver_probe_device+0xfc/0x2a0 drivers/base/dd.c:724
        [<000000003ef66004>] __device_attach_driver+0x1b6/0x240
    drivers/base/dd.c:831
        [<00000000eee53e97>] bus_for_each_drv+0x14e/0x1e0 drivers/base/bus.c:431
        [<00000000bb0648d0>] __device_attach+0x1f9/0x350 drivers/base/dd.c:897
        [<00000000838b324a>] device_initial_probe+0x1a/0x20 drivers/base/dd.c:944
        [<0000000030d501c1>] bus_probe_device+0x1e1/0x280 drivers/base/bus.c:491
        [<000000005bd7adef>] device_add+0x131d/0x1c40 drivers/base/core.c:2504
        [<00000000a0937814>] usb_set_configuration+0xe84/0x1ab0
    drivers/usb/core/message.c:2030
        [<00000000e3934741>] generic_probe+0x6a/0xe0 drivers/usb/core/generic.c:210
        [<0000000098ade0f1>] usb_probe_device+0x90/0xd0
    drivers/usb/core/driver.c:266
        [<000000007806c118>] really_probe+0x48d/0x8f0 drivers/base/dd.c:551
        [<00000000a3308c3e>] driver_probe_device+0xfc/0x2a0 drivers/base/dd.c:724
    
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: Kyungtae Kim <kt0755@gmail.com>
    Signed-off-by: Zqiang <qiang.zhang@windriver.com>
    Link: https://lore.kernel.org/r/20200612035210.20494-1-qiang.zhang@windriver.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0ff5b1b50d5ca2f7c76966cf0621aacd6ccefcab
Author: David Howells <dhowells@redhat.com>
Date:   Thu Jun 11 21:57:00 2020 +0100

    rxrpc: Fix race between incoming ACK parser and retransmitter
    
    [ Upstream commit 2ad6691d988c0c611362ddc2aad89e0fb50e3261 ]
    
    There's a race between the retransmission code and the received ACK parser.
    The problem is that the retransmission loop has to drop the lock under
    which it is iterating through the transmission buffer in order to transmit
    a packet, but whilst the lock is dropped, the ACK parser can crank the Tx
    window round and discard the packets from the buffer.
    
    The retransmission code then updated the annotations for the wrong packet
    and a later retransmission thought it had to retransmit a packet that
    wasn't there, leading to a NULL pointer dereference.
    
    Fix this by:
    
     (1) Moving the annotation change to before we drop the lock prior to
         transmission.  This means we can't vary the annotation depending on
         the outcome of the transmission, but that's fine - we'll retransmit
         again later if it failed now.
    
     (2) Skipping the packet if the skb pointer is NULL.
    
    The following oops was seen:
    
            BUG: kernel NULL pointer dereference, address: 000000000000002d
            Workqueue: krxrpcd rxrpc_process_call
            RIP: 0010:rxrpc_get_skb+0x14/0x8a
            ...
            Call Trace:
             rxrpc_resend+0x331/0x41e
             ? get_vtime_delta+0x13/0x20
             rxrpc_process_call+0x3c0/0x4ac
             process_one_work+0x18f/0x27f
             worker_thread+0x1a3/0x247
             ? create_worker+0x17d/0x17d
             kthread+0xe6/0xeb
             ? kthread_delayed_work_timer_fn+0x83/0x83
             ret_from_fork+0x1f/0x30
    
    Fixes: 248f219cb8bc ("rxrpc: Rewrite the data and ack handling code")
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fe688b144c14f676f6d4d2c254423a1db6bca66b
Author: Qian Cai <cai@lca.pw>
Date:   Mon Jun 1 21:45:57 2020 -0700

    mm/slub: fix stack overruns with SLUB_STATS
    
    [ Upstream commit a68ee0573991e90af2f1785db309206408bad3e5 ]
    
    There is no need to copy SLUB_STATS items from root memcg cache to new
    memcg cache copies.  Doing so could result in stack overruns because the
    store function only accepts 0 to clear the stat and returns an error for
    everything else while the show method would print out the whole stat.
    
    Then, the mismatch of the lengths returns from show and store methods
    happens in memcg_propagate_slab_attrs():
    
            else if (root_cache->max_attr_size < ARRAY_SIZE(mbuf))
                    buf = mbuf;
    
    max_attr_size is only 2 from slab_attr_store(), then, it uses mbuf[64]
    in show_stat() later where a bounch of sprintf() would overrun the stack
    variable.  Fix it by always allocating a page of buffer to be used in
    show_stat() if SLUB_STATS=y which should only be used for debug purpose.
    
      # echo 1 > /sys/kernel/slab/fs_cache/shrink
      BUG: KASAN: stack-out-of-bounds in number+0x421/0x6e0
      Write of size 1 at addr ffffc900256cfde0 by task kworker/76:0/53251
    
      Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385 Gen10, BIOS A40 07/10/2019
      Workqueue: memcg_kmem_cache memcg_kmem_cache_create_func
      Call Trace:
        number+0x421/0x6e0
        vsnprintf+0x451/0x8e0
        sprintf+0x9e/0xd0
        show_stat+0x124/0x1d0
        alloc_slowpath_show+0x13/0x20
        __kmem_cache_create+0x47a/0x6b0
    
      addr ffffc900256cfde0 is located in stack of task kworker/76:0/53251 at offset 0 in frame:
       process_one_work+0x0/0xb90
    
      this frame has 1 object:
       [32, 72) 'lockdep_map'
    
      Memory state around the buggy address:
       ffffc900256cfc80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
       ffffc900256cfd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      >ffffc900256cfd80: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
                                                             ^
       ffffc900256cfe00: 00 00 00 00 00 f2 f2 f2 00 00 00 00 00 00 00 00
       ffffc900256cfe80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      ==================================================================
      Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: __kmem_cache_create+0x6ac/0x6b0
      Workqueue: memcg_kmem_cache memcg_kmem_cache_create_func
      Call Trace:
        __kmem_cache_create+0x6ac/0x6b0
    
    Fixes: 107dab5c92d5 ("slub: slub-specific propagation changes")
    Signed-off-by: Qian Cai <cai@lca.pw>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Glauber Costa <glauber@scylladb.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>
    Link: http://lkml.kernel.org/r/20200429222356.4322-1-cai@lca.pw
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f459e8fc7c6950a589892e20ce5b9ebc5b39bd77
Author: Dongli Zhang <dongli.zhang@oracle.com>
Date:   Mon Jun 1 21:45:47 2020 -0700

    mm/slub.c: fix corrupted freechain in deactivate_slab()
    
    [ Upstream commit 52f23478081ae0dcdb95d1650ea1e7d52d586829 ]
    
    The slub_debug is able to fix the corrupted slab freelist/page.
    However, alloc_debug_processing() only checks the validity of current
    and next freepointer during allocation path.  As a result, once some
    objects have their freepointers corrupted, deactivate_slab() may lead to
    page fault.
    
    Below is from a test kernel module when 'slub_debug=PUF,kmalloc-128
    slub_nomerge'.  The test kernel corrupts the freepointer of one free
    object on purpose.  Unfortunately, deactivate_slab() does not detect it
    when iterating the freechain.
    
      BUG: unable to handle page fault for address: 00000000123456f8
      #PF: supervisor read access in kernel mode
      #PF: error_code(0x0000) - not-present page
      PGD 0 P4D 0
      Oops: 0000 [#1] SMP PTI
      ... ...
      RIP: 0010:deactivate_slab.isra.92+0xed/0x490
      ... ...
      Call Trace:
       ___slab_alloc+0x536/0x570
       __slab_alloc+0x17/0x30
       __kmalloc+0x1d9/0x200
       ext4_htree_store_dirent+0x30/0xf0
       htree_dirblock_to_tree+0xcb/0x1c0
       ext4_htree_fill_tree+0x1bc/0x2d0
       ext4_readdir+0x54f/0x920
       iterate_dir+0x88/0x190
       __x64_sys_getdents+0xa6/0x140
       do_syscall_64+0x49/0x170
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    Therefore, this patch adds extra consistency check in deactivate_slab().
    Once an object's freepointer is corrupted, all following objects
    starting at this object are isolated.
    
    [akpm@linux-foundation.org: fix build with CONFIG_SLAB_DEBUG=n]
    Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Joe Jin <joe.jin@oracle.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>
    Link: http://lkml.kernel.org/r/20200331031450.12182-1-dongli.zhang@oracle.com
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 542d541c1eddd13ab8266d404160228f85eafe34
Author: Valentin Schneider <valentin.schneider@arm.com>
Date:   Wed Apr 15 22:05:05 2020 +0100

    sched/debug: Make sd->flags sysctl read-only
    
    [ Upstream commit 9818427c6270a9ce8c52c8621026fe9cebae0f92 ]
    
    Writing to the sysctl of a sched_domain->flags directly updates the value of
    the field, and goes nowhere near update_top_cache_domain(). This means that
    the cached domain pointers can end up containing stale data (e.g. the
    domain pointed to doesn't have the relevant flag set anymore).
    
    Explicit domain walks that check for flags will be affected by
    the write, but this won't be in sync with the cached pointers which will
    still point to the domains that were cached at the last sched_domain
    build.
    
    In other words, writing to this interface is playing a dangerous game. It
    could be made to trigger an update of the cached sched_domain pointers when
    written to, but this does not seem to be worth the trouble. Make it
    read-only.
    
    Signed-off-by: Valentin Schneider <valentin.schneider@arm.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lkml.kernel.org/r/20200415210512.805-3-valentin.schneider@arm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ab9ee18f4646c926992fe09c6adfbf05c6e34162
Author: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Date:   Sun Jun 21 13:43:26 2020 +0300

    usbnet: smsc95xx: Fix use-after-free after removal
    
    [ Upstream commit b835a71ef64a61383c414d6bf2896d2c0161deca ]
    
    Syzbot reports an use-after-free in workqueue context:
    
    BUG: KASAN: use-after-free in mutex_unlock+0x19/0x40 kernel/locking/mutex.c:737
     mutex_unlock+0x19/0x40 kernel/locking/mutex.c:737
     __smsc95xx_mdio_read drivers/net/usb/smsc95xx.c:217 [inline]
     smsc95xx_mdio_read+0x583/0x870 drivers/net/usb/smsc95xx.c:278
     check_carrier+0xd1/0x2e0 drivers/net/usb/smsc95xx.c:644
     process_one_work+0x777/0xf90 kernel/workqueue.c:2274
     worker_thread+0xa8f/0x1430 kernel/workqueue.c:2420
     kthread+0x2df/0x300 kernel/kthread.c:255
    
    It looks like that smsc95xx_unbind() is freeing the structures that are
    still in use by the concurrently running workqueue callback. Thus switch
    to using cancel_delayed_work_sync() to ensure the work callback really
    is no longer active.
    
    Reported-by: syzbot+29dc7d4ae19b703ff947@syzkaller.appspotmail.com
    Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 58ab86e58b558e1b428704b1251458a23699f164
Author: Borislav Petkov <bp@suse.de>
Date:   Thu Jun 18 20:25:25 2020 +0200

    EDAC/amd64: Read back the scrub rate PCI register on F15h
    
    [ Upstream commit ee470bb25d0dcdf126f586ec0ae6dca66cb340a4 ]
    
    Commit:
    
      da92110dfdfa ("EDAC, amd64_edac: Extend scrub rate support to F15hM60h")
    
    added support for F15h, model 0x60 CPUs but in doing so, missed to read
    back SCRCTRL PCI config register on F15h CPUs which are *not* model
    0x60. Add that read so that doing
    
      $ cat /sys/devices/system/edac/mc/mc0/sdram_scrub_rate
    
    can show the previously set DRAM scrub rate.
    
    Fixes: da92110dfdfa ("EDAC, amd64_edac: Extend scrub rate support to F15hM60h")
    Reported-by: Anders Andersson <pipatron@gmail.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Cc: <stable@vger.kernel.org> #v4.4..
    Link: https://lkml.kernel.org/r/CAKkunMbNWppx_i6xSdDHLseA2QQmGJqj_crY=NF-GZML5np4Vw@mail.gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d0e533584a0554ff077b3cc97d458e49eef184b6
Author: Hugh Dickins <hughd@google.com>
Date:   Thu Jun 25 20:29:59 2020 -0700

    mm: fix swap cache node allocation mask
    
    [ Upstream commit 243bce09c91b0145aeaedd5afba799d81841c030 ]
    
    Chris Murphy reports that a slightly overcommitted load, testing swap
    and zram along with i915, splats and keeps on splatting, when it had
    better fail less noisily:
    
      gnome-shell: page allocation failure: order:0,
      mode:0x400d0(__GFP_IO|__GFP_FS|__GFP_COMP|__GFP_RECLAIMABLE),
      nodemask=(null),cpuset=/,mems_allowed=0
      CPU: 2 PID: 1155 Comm: gnome-shell Not tainted 5.7.0-1.fc33.x86_64 #1
      Call Trace:
        dump_stack+0x64/0x88
        warn_alloc.cold+0x75/0xd9
        __alloc_pages_slowpath.constprop.0+0xcfa/0xd30
        __alloc_pages_nodemask+0x2df/0x320
        alloc_slab_page+0x195/0x310
        allocate_slab+0x3c5/0x440
        ___slab_alloc+0x40c/0x5f0
        __slab_alloc+0x1c/0x30
        kmem_cache_alloc+0x20e/0x220
        xas_nomem+0x28/0x70
        add_to_swap_cache+0x321/0x400
        __read_swap_cache_async+0x105/0x240
        swap_cluster_readahead+0x22c/0x2e0
        shmem_swapin+0x8e/0xc0
        shmem_swapin_page+0x196/0x740
        shmem_getpage_gfp+0x3a2/0xa60
        shmem_read_mapping_page_gfp+0x32/0x60
        shmem_get_pages+0x155/0x5e0 [i915]
        __i915_gem_object_get_pages+0x68/0xa0 [i915]
        i915_vma_pin+0x3fe/0x6c0 [i915]
        eb_add_vma+0x10b/0x2c0 [i915]
        i915_gem_do_execbuffer+0x704/0x3430 [i915]
        i915_gem_execbuffer2_ioctl+0x1ea/0x3e0 [i915]
        drm_ioctl_kernel+0x86/0xd0 [drm]
        drm_ioctl+0x206/0x390 [drm]
        ksys_ioctl+0x82/0xc0
        __x64_sys_ioctl+0x16/0x20
        do_syscall_64+0x5b/0xf0
        entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    Reported on 5.7, but it goes back really to 3.1: when
    shmem_read_mapping_page_gfp() was implemented for use by i915, and
    allowed for __GFP_NORETRY and __GFP_NOWARN flags in most places, but
    missed swapin's "& GFP_KERNEL" mask for page tree node allocation in
    __read_swap_cache_async() - that was to mask off HIGHUSER_MOVABLE bits
    from what page cache uses, but GFP_RECLAIM_MASK is now what's needed.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=208085
    Link: http://lkml.kernel.org/r/alpine.LSU.2.11.2006151330070.11064@eggly.anvils
    Fixes: 68da9f055755 ("tmpfs: pass gfp to shmem_getpage_gfp")
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
    Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Reported-by: Chris Murphy <lists@colorremedies.com>
    Analyzed-by: Vlastimil Babka <vbabka@suse.cz>
    Analyzed-by: Matthew Wilcox <willy@infradead.org>
    Tested-by: Chris Murphy <lists@colorremedies.com>
    Cc: <stable@vger.kernel.org>    [3.1+]
    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 1c4404efcf2c01a89152d160487746e056f6de1f
Author: Jens Axboe <axboe@kernel.dk>
Date:   Wed Jul 1 21:30:14 2020 -0400

    io_uring: make sure async workqueue is canceled on exit
    
    Track async work items that we queue, so we can safely cancel them
    if the ring is closed or the process exits. Newer kernels handle
    this automatically with io-wq, but the old workqueue based setup needs
    a bit of special help to get there.
    
    There's no upstream variant of this, as that would require backporting
    all the io-wq changes from 5.5 and on. Hence I made a one-off that
    ensures that we don't leak memory if we have async work items that
    need active cancelation (like socket IO).
    
    Reported-by: Agarwal, Anchal <anchalag@amazon.com>
    Tested-by: Agarwal, Anchal <anchalag@amazon.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>