commit 856cd02bbdd412bf91ce327a3c97c52066f11c79
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Mar 25 09:04:18 2021 +0100

    Linux 5.10.26
    
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Hulk Robot <hulkrobot@huawei.com>
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Tested-by: Jason Self <jason@bluehome.net>
    Link: https://lore.kernel.org/r/20210322121933.746237845@linuxfoundation.org
    Link: https://lore.kernel.org/r/20210322151845.637893645@linuxfoundation.org
    Link: https://lore.kernel.org/r/20210324093435.962321672@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit de1126ea44bb259afa9b74a25fed0255ecdaa756
Author: Vincent Whitchurch <vincent.whitchurch@axis.com>
Date:   Wed Mar 10 13:20:40 2021 +0100

    cifs: Fix preauth hash corruption
    
    commit 05946d4b7a7349ae58bfa2d51ae832e64a394c2d upstream.
    
    smb311_update_preauth_hash() uses the shash in server->secmech without
    appropriate locking, and this can lead to sessions corrupting each
    other's preauth hashes.
    
    The following script can easily trigger the problem:
    
            #!/bin/sh -e
    
            NMOUNTS=10
            for i in $(seq $NMOUNTS);
                    mkdir -p /tmp/mnt$i
                    umount /tmp/mnt$i 2>/dev/null || :
            done
            while :; do
                    for i in $(seq $NMOUNTS); do
                            mount -t cifs //192.168.0.1/test /tmp/mnt$i -o ... &
                    done
                    wait
                    for i in $(seq $NMOUNTS); do
                            umount /tmp/mnt$i
                    done
            done
    
    Usually within seconds this leads to one or more of the mounts failing
    with the following errors, and a "Bad SMB2 signature for message" is
    seen in the server logs:
    
     CIFS: VFS: \\192.168.0.1 failed to connect to IPC (rc=-13)
     CIFS: VFS: cifs_mount failed w/return code = -13
    
    Fix it by holding the server mutex just like in the other places where
    the shashes are used.
    
    Fixes: 8bd68c6e47abff34e4 ("CIFS: implement v3.11 preauth integrity")
    Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
    CC: <stable@vger.kernel.org>
    Reviewed-by: Aurelien Aptel <aaptel@suse.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    [aaptel: backport to kernel without CIFS_SESS_OP]
    Signed-off-by: Aurelien Aptel <aaptel@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 21536d7b7e6f58a2a7b3af3909c5150fe1fceb8c
Author: Johan Hovold <johan@kernel.org>
Date:   Fri Mar 12 10:20:33 2021 +0100

    x86/apic/of: Fix CPU devicetree-node lookups
    
    commit dd926880da8dbbe409e709c1d3c1620729a94732 upstream.
    
    Architectures that describe the CPU topology in devicetree and do not have
    an identity mapping between physical and logical CPU ids must override the
    default implementation of arch_match_cpu_phys_id().
    
    Failing to do so breaks CPU devicetree-node lookups using of_get_cpu_node()
    and of_cpu_device_node_get() which several drivers rely on. It also causes
    the CPU struct devices exported through sysfs to point to the wrong
    devicetree nodes.
    
    On x86, CPUs are described in devicetree using their APIC ids and those
    do not generally coincide with the logical ids, even if CPU0 typically
    uses APIC id 0.
    
    Add the missing implementation of arch_match_cpu_phys_id() so that CPU-node
    lookups work also with SMP.
    
    Apart from fixing the broken sysfs devicetree-node links this likely does
    not affect current users of mainline kernels on x86.
    
    Fixes: 4e07db9c8db8 ("x86/devicetree: Use CPU description from Device Tree")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Link: https://lore.kernel.org/r/20210312092033.26317-1-johan@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 95247d24c4d4973146a9e7175ec0803f734cf50e
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Wed Mar 17 15:38:52 2021 +0100

    genirq: Disable interrupts for force threaded handlers
    
    commit 81e2073c175b887398e5bca6c004efa89983f58d upstream.
    
    With interrupt force threading all device interrupt handlers are invoked
    from kernel threads. Contrary to hard interrupt context the invocation only
    disables bottom halfs, but not interrupts. This was an oversight back then
    because any code like this will have an issue:
    
    thread(irq_A)
      irq_handler(A)
        spin_lock(&foo->lock);
    
    interrupt(irq_B)
      irq_handler(B)
        spin_lock(&foo->lock);
    
    This has been triggered with networking (NAPI vs. hrtimers) and console
    drivers where printk() happens from an interrupt which interrupted the
    force threaded handler.
    
    Now people noticed and started to change the spin_lock() in the handler to
    spin_lock_irqsave() which affects performance or add IRQF_NOTHREAD to the
    interrupt request which in turn breaks RT.
    
    Fix the root cause and not the symptom and disable interrupts before
    invoking the force threaded handler which preserves the regular semantics
    and the usefulness of the interrupt force threading as a general debugging
    tool.
    
    For not RT this is not changing much, except that during the execution of
    the threaded handler interrupts are delayed until the handler
    returns. Vs. scheduling and softirq processing there is no difference.
    
    For RT kernels there is no issue.
    
    Fixes: 8d32a307e4fa ("genirq: Provide forced interrupt threading")
    Reported-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Johan Hovold <johan@kernel.org>
    Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Link: https://lore.kernel.org/r/20210317143859.513307808@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 80b2787789afef0a98e64eb9a1a9203f4a83ff99
Author: Lv Yunlong <lyl2019@mail.ustc.edu.cn>
Date:   Wed Mar 10 00:31:27 2021 -0800

    firmware/efi: Fix a use after bug in efi_mem_reserve_persistent
    
    commit 9ceee7d0841a8f7d7644021ba7d4cc1fbc7966e3 upstream.
    
    In the for loop in efi_mem_reserve_persistent(), prsv = rsv->next
    use the unmapped rsv. Use the unmapped pages will cause segment
    fault.
    
    Fixes: 18df7577adae6 ("efi/memreserve: deal with memreserve entries in unmapped memory")
    Signed-off-by: Lv Yunlong <lyl2019@mail.ustc.edu.cn>
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 47ba0d4d2afb476e2a67f781166186e24b1e3bc1
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Wed Mar 10 08:33:19 2021 +0100

    efi: use 32-bit alignment for efi_guid_t literals
    
    commit fb98cc0b3af2ba4d87301dff2b381b12eee35d7d upstream.
    
    Commit 494c704f9af0 ("efi: Use 32-bit alignment for efi_guid_t") updated
    the type definition of efi_guid_t to ensure that it always appears
    sufficiently aligned (the UEFI spec is ambiguous about this, but given
    the fact that its EFI_GUID type is defined in terms of a struct carrying
    a uint32_t, the natural alignment is definitely >= 32 bits).
    
    However, we missed the EFI_GUID() macro which is used to instantiate
    efi_guid_t literals: that macro is still based on the guid_t type,
    which does not have a minimum alignment at all. This results in warnings
    such as
    
      In file included from drivers/firmware/efi/mokvar-table.c:35:
      include/linux/efi.h:1093:34: warning: passing 1-byte aligned argument to
          4-byte aligned parameter 2 of 'get_var' may result in an unaligned pointer
          access [-Walign-mismatch]
              status = get_var(L"SecureBoot", &EFI_GLOBAL_VARIABLE_GUID, NULL, &size,
                                              ^
      include/linux/efi.h:1101:24: warning: passing 1-byte aligned argument to
          4-byte aligned parameter 2 of 'get_var' may result in an unaligned pointer
          access [-Walign-mismatch]
              get_var(L"SetupMode", &EFI_GLOBAL_VARIABLE_GUID, NULL, &size, &setupmode);
    
    The distinction only matters on CPUs that do not support misaligned loads
    fully, but 32-bit ARM's load-multiple instructions fall into that category,
    and these are likely to be emitted by the compiler that built the firmware
    for loading word-aligned 128-bit GUIDs from memory
    
    So re-implement the initializer in terms of our own efi_guid_t type, so that
    the alignment becomes a property of the literal's type.
    
    Fixes: 494c704f9af0 ("efi: Use 32-bit alignment for efi_guid_t")
    Reported-by: Nathan Chancellor <nathan@kernel.org>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Reviewed-by: Nathan Chancellor <nathan@kernel.org>
    Tested-by: Nathan Chancellor <nathan@kernel.org>
    Link: https://github.com/ClangBuiltLinux/linux/issues/1327
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e5154ea8e48fccde1b2fbd30a1616b002e47f3c6
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Thu Mar 18 11:31:51 2021 +0100

    static_call: Fix static_call_update() sanity check
    
    commit 38c93587375053c5b9ef093f4a5ea754538cba32 upstream.
    
    Sites that match init_section_contains() get marked as INIT. For
    built-in code init_sections contains both __init and __exit text. OTOH
    kernel_text_address() only explicitly includes __init text (and there
    are no __exit text markers).
    
    Match what jump_label already does and ignore the warning for INIT
    sites. Also see the excellent changelog for commit: 8f35eaa5f2de
    ("jump_label: Don't warn on __exit jump entries")
    
    Fixes: 9183c3f9ed710 ("static_call: Add inline static call infrastructure")
    Reported-by: Sumit Garg <sumit.garg@linaro.org>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Acked-by: Jarkko Sakkinen <jarkko@kernel.org>
    Tested-by: Sumit Garg <sumit.garg@linaro.org>
    Link: https://lkml.kernel.org/r/20210318113610.739542434@infradead.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 51ccdd25d7e57260aca5f8cf7aeb03416121e992
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Mar 16 11:23:11 2021 +0100

    MAINTAINERS: move the staging subsystem to lists.linux.dev
    
    commit e06da9ea3e3f6746a849edeae1d09ee821f5c2ce upstream.
    
    The drivers/staging/ tree has a new mailing list,
    linux-staging@lists.linux.dev, so move the MAINTAINER entry to point to
    it so that we get patches sent to the proper place.
    
    There was no need to specify a list for the hikey9xx driver, the tools
    pick up the "base" list for drivers/staging/* so remove that line to
    make the file simpler.
    
    Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Link: https://lore.kernel.org/r/20210316102311.182375-1-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4c9a74798ef1aaa85073d349807cc91f5d592e32
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Mar 13 14:58:02 2021 +0100

    MAINTAINERS: move some real subsystems off of the staging mailing list
    
    commit f8d70fd6a5a7a38a95eb8021e00d2e547f88efec upstream.
    
    The VME and Android drivers still have their MAINTAINERS entries
    pointing to the "driverdevel" mailing list, due to them having their
    codebase move out of the drivers/staging/ directory, but no one
    remembered to change the mailing list entries.
    
    Move them both to linux-kernel for lack of a more specific place at the
    moment.  These are both low-volume areas of the kernel, so this
    shouldn't be an issue.
    
    Cc: Martyn Welch <martyn@welchs.me.uk>
    Cc: Manohar Vanga <manohar.vanga@gmail.com>
    Cc: Arve Hjønnevåg <arve@android.com>
    Cc: Todd Kjos <tkjos@android.com>
    Cc: Martijn Coenen <maco@android.com>
    Cc: Joel Fernandes <joel@joelfernandes.org>
    Cc: Christian Brauner <christian@brauner.io>
    Cc: Hridya Valsaraju <hridya@google.com>
    Cc: Suren Baghdasaryan <surenb@google.com>
    Reported-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
    Link: https://lore.kernel.org/r/YEzE6u6U1jkBatmr@kroah.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 35ecf664fd6c14b679586bd5a7ccc8a725b043aa
Author: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Date:   Tue Mar 16 15:19:21 2021 -0700

    ext4: fix rename whiteout with fast commit
    
    commit 8210bb29c1b66200cff7b25febcf6e39baf49fbf upstream.
    
    This patch adds rename whiteout support in fast commits. Note that the
    whiteout object that gets created is actually char device. Which
    imples, the function ext4_inode_journal_mode(struct inode *inode)
    would return "JOURNAL_DATA" for this inode. This has a consequence in
    fast commit code that it will make creation of the whiteout object a
    fast-commit ineligible behavior and thus will fall back to full
    commits. With this patch, this can be observed by running fast commits
    with rename whiteout and seeing the stats generated by ext4_fc_stats
    tracepoint as follows:
    
    ext4_fc_stats: dev 254:32 fc ineligible reasons:
    XATTR:0, CROSS_RENAME:0, JOURNAL_FLAG_CHANGE:0, NO_MEM:0, SWAP_BOOT:0,
    RESIZE:0, RENAME_DIR:0, FALLOC_RANGE:0, INODE_JOURNAL_DATA:16;
    num_commits:6, ineligible: 6, numblks: 3
    
    So in short, this patch guarantees that in case of rename whiteout, we
    fall back to full commits.
    
    Amir mentioned that instead of creating a new whiteout object for
    every rename, we can create a static whiteout object with irrelevant
    nlink. That will make fast commits to not fall back to full
    commit. But until this happens, this patch will ensure correctness by
    falling back to full commits.
    
    Fixes: 8016e29f4362 ("ext4: fast commit recovery path")
    Cc: stable@kernel.org
    Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
    Link: https://lore.kernel.org/r/20210316221921.1124955-1-harshadshirwadkar@gmail.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e8fa569465e5d45e322ce61759d06b4629384bda
Author: Shijie Luo <luoshijie1@huawei.com>
Date:   Fri Mar 12 01:50:51 2021 -0500

    ext4: fix potential error in ext4_do_update_inode
    
    commit 7d8bd3c76da1d94b85e6c9b7007e20e980bfcfe6 upstream.
    
    If set_large_file = 1 and errors occur in ext4_handle_dirty_metadata(),
    the error code will be overridden, go to out_brelse to avoid this
    situation.
    
    Signed-off-by: Shijie Luo <luoshijie1@huawei.com>
    Link: https://lore.kernel.org/r/20210312065051.36314-1-luoshijie1@huawei.com
    Cc: stable@kernel.org
    Reviewed-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6163a0662b794598f4853e62904a26f5f85ca9b4
Author: zhangyi (F) <yi.zhang@huawei.com>
Date:   Fri Mar 5 20:05:08 2021 +0800

    ext4: do not try to set xattr into ea_inode if value is empty
    
    commit 6b22489911b726eebbf169caee52fea52013fbdd upstream.
    
    Syzbot report a warning that ext4 may create an empty ea_inode if set
    an empty extent attribute to a file on the file system which is no free
    blocks left.
    
      WARNING: CPU: 6 PID: 10667 at fs/ext4/xattr.c:1640 ext4_xattr_set_entry+0x10f8/0x1114 fs/ext4/xattr.c:1640
      ...
      Call trace:
       ext4_xattr_set_entry+0x10f8/0x1114 fs/ext4/xattr.c:1640
       ext4_xattr_block_set+0x1d0/0x1b1c fs/ext4/xattr.c:1942
       ext4_xattr_set_handle+0x8a0/0xf1c fs/ext4/xattr.c:2390
       ext4_xattr_set+0x120/0x1f0 fs/ext4/xattr.c:2491
       ext4_xattr_trusted_set+0x48/0x5c fs/ext4/xattr_trusted.c:37
       __vfs_setxattr+0x208/0x23c fs/xattr.c:177
      ...
    
    Now, ext4 try to store extent attribute into an external inode if
    ext4_xattr_block_set() return -ENOSPC, but for the case of store an
    empty extent attribute, store the extent entry into the extent
    attribute block is enough. A simple reproduce below.
    
      fallocate test.img -l 1M
      mkfs.ext4 -F -b 2048 -O ea_inode test.img
      mount test.img /mnt
      dd if=/dev/zero of=/mnt/foo bs=2048 count=500
      setfattr -n "user.test" /mnt/foo
    
    Reported-by: syzbot+98b881fdd8ebf45ab4ae@syzkaller.appspotmail.com
    Fixes: 9c6e7853c531 ("ext4: reserve space for xattr entries/names")
    Cc: stable@kernel.org
    Signed-off-by: zhangyi (F) <yi.zhang@huawei.com>
    Link: https://lore.kernel.org/r/20210305120508.298465-1-yi.zhang@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d130b802f98a80c43c13607003911a7bb03b0cc7
Author: Pan Bian <bianpan2016@163.com>
Date:   Sun Jan 17 00:57:32 2021 -0800

    ext4: stop inode update before return
    
    commit 512c15ef05d73a04f1aef18a3bc61a8bb516f323 upstream.
    
    The inode update should be stopped before returing the error code.
    
    Signed-off-by: Pan Bian <bianpan2016@163.com>
    Link: https://lore.kernel.org/r/20210117085732.93788-1-bianpan2016@163.com
    Fixes: 8016e29f4362 ("ext4: fast commit recovery path")
    Cc: stable@kernel.org
    Reviewed-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 258db8e6ffdc11535ea25cb3b1bc0cb70317b43f
Author: zhangyi (F) <yi.zhang@huawei.com>
Date:   Wed Mar 3 21:17:02 2021 +0800

    ext4: find old entry again if failed to rename whiteout
    
    commit b7ff91fd030dc9d72ed91b1aab36e445a003af4f upstream.
    
    If we failed to add new entry on rename whiteout, we cannot reset the
    old->de entry directly, because the old->de could have moved from under
    us during make indexed dir. So find the old entry again before reset is
    needed, otherwise it may corrupt the filesystem as below.
    
      /dev/sda: Entry '00000001' in ??? (12) has deleted/unused inode 15. CLEARED.
      /dev/sda: Unattached inode 75
      /dev/sda: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
    
    Fixes: 6b4b8e6b4ad ("ext4: fix bug for rename with RENAME_WHITEOUT")
    Cc: stable@vger.kernel.org
    Signed-off-by: zhangyi (F) <yi.zhang@huawei.com>
    Link: https://lore.kernel.org/r/20210303131703.330415-1-yi.zhang@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9689ecadf8a79e7836313eff994ae20baaf00f0f
Author: Eric Biggers <ebiggers@google.com>
Date:   Tue Mar 2 12:04:19 2021 -0800

    ext4: fix error handling in ext4_end_enable_verity()
    
    commit f053cf7aa66cd9d592b0fc967f4d887c2abff1b7 upstream.
    
    ext4 didn't properly clean up if verity failed to be enabled on a file:
    
    - It left verity metadata (pages past EOF) in the page cache, which
      would be exposed to userspace if the file was later extended.
    
    - It didn't truncate the verity metadata at all (either from cache or
      from disk) if an error occurred while setting the verity bit.
    
    Fix these bugs by adding a call to truncate_inode_pages() and ensuring
    that we truncate the verity metadata (both from cache and from disk) in
    all error paths.  Also rework the code to cleanly separate the success
    path from the error paths, which makes it much easier to understand.
    
    Reported-by: Yunlei He <heyunlei@hihonor.com>
    Fixes: c93d8f885809 ("ext4: add basic fs-verity support")
    Cc: stable@vger.kernel.org # v5.4+
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Link: https://lore.kernel.org/r/20210302200420.137977-2-ebiggers@kernel.org
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e4ea2a28d068885f2637b5d48a3280d2707b9289
Author: Shawn Guo <shawn.guo@linaro.org>
Date:   Wed Mar 17 14:36:06 2021 +0800

    efivars: respect EFI_UNSUPPORTED return from firmware
    
    commit 483028edacab374060d93955382b4865a9e07cba upstream.
    
    As per UEFI spec 2.8B section 8.2, EFI_UNSUPPORTED may be returned by
    EFI variable runtime services if no variable storage is supported by
    firmware.  In this case, there is no point for kernel to continue
    efivars initialization.  That said, efivar_init() should fail by
    returning an error code, so that efivarfs will not be mounted on
    /sys/firmware/efi/efivars at all.  Otherwise, user space like efibootmgr
    will be confused by the EFIVARFS_MAGIC seen there, while EFI variable
    calls cannot be made successfully.
    
    Cc: <stable@vger.kernel.org> # v5.10+
    Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
    Acked-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a548acde9608f8dd05545109ff085a9d0d0ffd65
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Mon Feb 1 18:47:09 2021 +0100

    x86: Introduce TS_COMPAT_RESTART to fix get_nr_restart_syscall()
    
    commit 8c150ba2fb5995c84a7a43848250d444a3329a7d upstream.
    
    The comment in get_nr_restart_syscall() says:
    
             * The problem is that we can get here when ptrace pokes
             * syscall-like values into regs even if we're not in a syscall
             * at all.
    
    Yes, but if not in a syscall then the
    
            status & (TS_COMPAT|TS_I386_REGS_POKED)
    
    check below can't really help:
    
            - TS_COMPAT can't be set
    
            - TS_I386_REGS_POKED is only set if regs->orig_ax was changed by
              32bit debugger; and even in this case get_nr_restart_syscall()
              is only correct if the tracee is 32bit too.
    
    Suppose that a 64bit debugger plays with a 32bit tracee and
    
            * Tracee calls sleep(2) // TS_COMPAT is set
            * User interrupts the tracee by CTRL-C after 1 sec and does
              "(gdb) call func()"
            * gdb saves the regs by PTRACE_GETREGS
            * does PTRACE_SETREGS to set %rip='func' and %orig_rax=-1
            * PTRACE_CONT           // TS_COMPAT is cleared
            * func() hits int3.
            * Debugger catches SIGTRAP.
            * Restore original regs by PTRACE_SETREGS.
            * PTRACE_CONT
    
    get_nr_restart_syscall() wrongly returns __NR_restart_syscall==219, the
    tracee calls ia32_sys_call_table[219] == sys_madvise.
    
    Add the sticky TS_COMPAT_RESTART flag which survives after return to user
    mode. It's going to be removed in the next step again by storing the
    information in the restart block. As a further cleanup it might be possible
    to remove also TS_I386_REGS_POKED with that.
    
    Test-case:
    
      $ cvs -d :pserver:anoncvs:anoncvs@sourceware.org:/cvs/systemtap co ptrace-tests
      $ gcc -o erestartsys-trap-debuggee ptrace-tests/tests/erestartsys-trap-debuggee.c --m32
      $ gcc -o erestartsys-trap-debugger ptrace-tests/tests/erestartsys-trap-debugger.c -lutil
      $ ./erestartsys-trap-debugger
      Unexpected: retval 1, errno 22
      erestartsys-trap-debugger: ptrace-tests/tests/erestartsys-trap-debugger.c:421
    
    Fixes: 609c19a385c8 ("x86/ptrace: Stop setting TS_COMPAT in ptrace code")
    Reported-by: Jan Kratochvil <jan.kratochvil@redhat.com>
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210201174709.GA17895@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 97c608959c27ce8594d61cb3291538bb0fb33be1
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Mon Feb 1 18:46:49 2021 +0100

    x86: Move TS_COMPAT back to asm/thread_info.h
    
    commit 66c1b6d74cd7035e85c426f0af4aede19e805c8a upstream.
    
    Move TS_COMPAT back to asm/thread_info.h, close to TS_I386_REGS_POKED.
    
    It was moved to asm/processor.h by b9d989c7218a ("x86/asm: Move the
    thread_info::status field to thread_struct"), then later 37a8f7c38339
    ("x86/asm: Move 'status' from thread_struct to thread_info") moved the
    'status' field back but TS_COMPAT was forgotten.
    
    Preparatory patch to fix the COMPAT case for get_nr_restart_syscall()
    
    Fixes: 609c19a385c8 ("x86/ptrace: Stop setting TS_COMPAT in ptrace code")
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210201174649.GA17880@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4523e648b7b7fb41f2d6df51890f197ed807d1c9
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Mon Feb 1 18:46:41 2021 +0100

    kernel, fs: Introduce and use set_restart_fn() and arch_set_restart_data()
    
    commit 5abbe51a526253b9f003e9a0a195638dc882d660 upstream.
    
    Preparation for fixing get_nr_restart_syscall() on X86 for COMPAT.
    
    Add a new helper which sets restart_block->fn and calls a dummy
    arch_set_restart_data() helper.
    
    Fixes: 609c19a385c8 ("x86/ptrace: Stop setting TS_COMPAT in ptrace code")
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210201174641.GA17871@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e245256e34db476eb27d377f18f7920cfe07362
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Thu Mar 18 20:26:47 2021 +0100

    x86/ioapic: Ignore IRQ2 again
    
    commit a501b048a95b79e1e34f03cac3c87ff1e9f229ad upstream.
    
    Vitaly ran into an issue with hotplugging CPU0 on an Amazon instance where
    the matrix allocator claimed to be out of vectors. He analyzed it down to
    the point that IRQ2, the PIC cascade interrupt, which is supposed to be not
    ever routed to the IO/APIC ended up having an interrupt vector assigned
    which got moved during unplug of CPU0.
    
    The underlying issue is that IRQ2 for various reasons (see commit
    af174783b925 ("x86: I/O APIC: Never configure IRQ2" for details) is treated
    as a reserved system vector by the vector core code and is not accounted as
    a regular vector. The Amazon BIOS has an routing entry of pin2 to IRQ2
    which causes the IO/APIC setup to claim that interrupt which is granted by
    the vector domain because there is no sanity check. As a consequence the
    allocation counter of CPU0 underflows which causes a subsequent unplug to
    fail with:
    
      [ ... ] CPU 0 has 4294967295 vectors, 589 available. Cannot disable CPU
    
    There is another sanity check missing in the matrix allocator, but the
    underlying root cause is that the IO/APIC code lost the IRQ2 ignore logic
    during the conversion to irqdomains.
    
    For almost 6 years nobody complained about this wreckage, which might
    indicate that this requirement could be lifted, but for any system which
    actually has a PIC IRQ2 is unusable by design so any routing entry has no
    effect and the interrupt cannot be connected to a device anyway.
    
    Due to that and due to history biased paranoia reasons restore the IRQ2
    ignore logic and treat it as non existent despite a routing entry claiming
    otherwise.
    
    Fixes: d32932d02e18 ("x86/irq: Convert IOAPIC to use hierarchical irqdomain interfaces")
    Reported-by: Vitaly Kuznetsov <vkuznets@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Vitaly Kuznetsov <vkuznets@redhat.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210318192819.636943062@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4fdf5f4ba61f3f35912bb7de2a914ce6d4c1e223
Author: Kan Liang <kan.liang@linux.intel.com>
Date:   Fri Mar 12 05:21:38 2021 -0800

    perf/x86/intel: Fix unchecked MSR access error caused by VLBR_EVENT
    
    commit 2dc0572f2cef87425147658698dce2600b799bd3 upstream.
    
    On a Haswell machine, the perf_fuzzer managed to trigger this message:
    
    [117248.075892] unchecked MSR access error: WRMSR to 0x3f1 (tried to
    write 0x0400000000000000) at rIP: 0xffffffff8106e4f4
    (native_write_msr+0x4/0x20)
    [117248.089957] Call Trace:
    [117248.092685]  intel_pmu_pebs_enable_all+0x31/0x40
    [117248.097737]  intel_pmu_enable_all+0xa/0x10
    [117248.102210]  __perf_event_task_sched_in+0x2df/0x2f0
    [117248.107511]  finish_task_switch.isra.0+0x15f/0x280
    [117248.112765]  schedule_tail+0xc/0x40
    [117248.116562]  ret_from_fork+0x8/0x30
    
    A fake event called VLBR_EVENT may use the bit 58 of the PEBS_ENABLE, if
    the precise_ip is set. The bit 58 is reserved by the HW. Accessing the
    bit causes the unchecked MSR access error.
    
    The fake event doesn't support PEBS. The case should be rejected.
    
    Fixes: 097e4311cda9 ("perf/x86: Add constraint to create guest LBR event without hw counter")
    Reported-by: Vince Weaver <vincent.weaver@maine.edu>
    Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/1615555298-140216-2-git-send-email-kan.liang@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 514ea597be8e4b6a787bc34da111c44944fbf5a5
Author: Kan Liang <kan.liang@linux.intel.com>
Date:   Fri Mar 12 05:21:37 2021 -0800

    perf/x86/intel: Fix a crash caused by zero PEBS status
    
    commit d88d05a9e0b6d9356e97129d4ff9942d765f46ea upstream.
    
    A repeatable crash can be triggered by the perf_fuzzer on some Haswell
    system.
    https://lore.kernel.org/lkml/7170d3b-c17f-1ded-52aa-cc6d9ae999f4@maine.edu/
    
    For some old CPUs (HSW and earlier), the PEBS status in a PEBS record
    may be mistakenly set to 0. To minimize the impact of the defect, the
    commit was introduced to try to avoid dropping the PEBS record for some
    cases. It adds a check in the intel_pmu_drain_pebs_nhm(), and updates
    the local pebs_status accordingly. However, it doesn't correct the PEBS
    status in the PEBS record, which may trigger the crash, especially for
    the large PEBS.
    
    It's possible that all the PEBS records in a large PEBS have the PEBS
    status 0. If so, the first get_next_pebs_record_by_bit() in the
    __intel_pmu_pebs_event() returns NULL. The at = NULL. Since it's a large
    PEBS, the 'count' parameter must > 1. The second
    get_next_pebs_record_by_bit() will crash.
    
    Besides the local pebs_status, correct the PEBS status in the PEBS
    record as well.
    
    Fixes: 01330d7288e0 ("perf/x86: Allow zero PEBS status with only single active event")
    Reported-by: Vince Weaver <vincent.weaver@maine.edu>
    Suggested-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/1615555298-140216-1-git-send-email-kan.liang@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit be1f58e58f7644ab33f1413685c84173766408d3
Author: Tyrel Datwyler <tyreld@linux.ibm.com>
Date:   Mon Mar 15 15:48:21 2021 -0600

    PCI: rpadlpar: Fix potential drc_name corruption in store functions
    
    commit cc7a0bb058b85ea03db87169c60c7cfdd5d34678 upstream.
    
    Both add_slot_store() and remove_slot_store() try to fix up the
    drc_name copied from the store buffer by placing a NUL terminator at
    nbyte + 1 or in place of a '\n' if present. However, the static buffer
    that we copy the drc_name data into is not zeroed and can contain
    anything past the n-th byte.
    
    This is problematic if a '\n' byte appears in that buffer after nbytes
    and the string copied into the store buffer was not NUL terminated to
    start with as the strchr() search for a '\n' byte will mark this
    incorrectly as the end of the drc_name string resulting in a drc_name
    string that contains garbage data after the n-th byte.
    
    Additionally it will cause us to overwrite that '\n' byte on the stack
    with NUL, potentially corrupting data on the stack.
    
    The following debugging shows an example of the drmgr utility writing
    "PHB 4543" to the add_slot sysfs attribute, but add_slot_store()
    logging a corrupted string value.
    
      drmgr: drmgr: -c phb -a -s PHB 4543 -d 1
      add_slot_store: drc_name = PHB 4543°|<82>!, rc = -19
    
    Fix this by using strscpy() instead of memcpy() to ensure the string
    is NUL terminated when copied into the static drc_name buffer.
    Further, since the string is now NUL terminated the code only needs to
    change '\n' to '\0' when present.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
    [mpe: Reformat change log and add mention of possible stack corruption]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20210315214821.452959-1-tyreld@linux.ibm.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6d4e1fed18d04663f5f8981d4500183888e8d8f0
Author: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Date:   Wed Mar 3 18:49:49 2021 +0100

    counter: stm32-timer-cnt: fix ceiling miss-alignment with reload register
    
    commit b14d72ac731753708a7c1a6b3657b9312b6f0042 upstream.
    
    Ceiling value may be miss-aligned with what's actually configured into the
    ARR register. This is seen after probe as currently the ARR value is zero,
    whereas ceiling value is set to the maximum. So:
    - reading ceiling reports zero
    - in case the counter gets enabled without any prior configuration,
      it won't count.
    - in case the function gets set by the user 1st, (priv->ceiling) is used.
    
    Fix it by getting rid of the cached "priv->ceiling" variable. Rather use
    the ARR register value directly by using regmap read or write when needed.
    There should be no drawback on performance as priv->ceiling isn't used in
    performance critical path.
    There's also no point in writing ARR while setting function (sms), so
    it can be safely removed.
    
    Fixes: ad29937e206f ("counter: Add STM32 Timer quadrature encoder")
    Suggested-by: William Breathitt Gray <vilhelm.gray@gmail.com>
    Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
    Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com>
    Cc: <Stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/1614793789-10346-1-git-send-email-fabrice.gasnier@foss.st.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cbc4c42dbec01922c15ac5c8071ff7d9cdc12587
Author: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Date:   Tue Mar 2 15:43:55 2021 +0100

    counter: stm32-timer-cnt: fix ceiling write max value
    
    commit e4c3e133294c0a292d21073899b05ebf530169bd upstream.
    
    The ceiling value isn't checked before writing it into registers. The user
    could write a value higher than the counter resolution (e.g. 16 or 32 bits
    indicated by max_arr). This makes most significant bits to be truncated.
    Fix it by checking the max_arr to report a range error [1] to the user.
    
    [1] https://lkml.org/lkml/2021/2/12/358
    
    Fixes: ad29937e206f ("counter: Add STM32 Timer quadrature encoder")
    Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
    Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com>
    Cc: <Stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/1614696235-24088-1-git-send-email-fabrice.gasnier@foss.st.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dcdde25844d4ec41b44e1538d2da39404327032d
Author: Ye Xiang <xiang.ye@intel.com>
Date:   Wed Mar 3 14:36:14 2021 +0800

    iio: hid-sensor-temperature: Fix issues of timestamp channel
    
    commit 141e7633aa4d2838d1f6ad5c74cccc53547c16ac upstream.
    
    This patch fixes 2 issues of timestamp channel:
    1. This patch ensures that there is sufficient space and correct
    alignment for the timestamp.
    2. Correct the timestamp channel scan index.
    
    Fixes: 59d0f2da3569 ("iio: hid: Add temperature sensor support")
    Signed-off-by: Ye Xiang <xiang.ye@intel.com>
    Cc: <Stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20210303063615.12130-4-xiang.ye@intel.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7de97c4bba51c7e1458fc4462fb80f8d1beac68b
Author: Ye Xiang <xiang.ye@intel.com>
Date:   Sat Jan 30 18:25:30 2021 +0800

    iio: hid-sensor-prox: Fix scale not correct issue
    
    commit d68c592e02f6f49a88e705f13dfc1883432cf300 upstream.
    
    Currently, the proxy sensor scale is zero because it just return the
    exponent directly. To fix this issue, this patch use
    hid_sensor_format_scale to process the scale first then return the
    output.
    
    Fixes: 39a3a0138f61 ("iio: hid-sensors: Added Proximity Sensor Driver")
    Signed-off-by: Ye Xiang <xiang.ye@intel.com>
    Link: https://lore.kernel.org/r/20210130102530.31064-1-xiang.ye@intel.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fd8efe16d86742c4717be1f723f370bf20360fa2
Author: Ye Xiang <xiang.ye@intel.com>
Date:   Wed Mar 3 14:36:12 2021 +0800

    iio: hid-sensor-humidity: Fix alignment issue of timestamp channel
    
    commit 37e89e574dc238a4ebe439543c5ab4fbb2f0311b upstream.
    
    This patch ensures that, there is sufficient space and correct
    alignment for the timestamp.
    
    Fixes: d7ed89d5aadf ("iio: hid: Add humidity sensor support")
    Signed-off-by: Ye Xiang <xiang.ye@intel.com>
    Cc: <Stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20210303063615.12130-2-xiang.ye@intel.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b477c121a287955ad46bf6bf29520737d6699e43
Author: Alexandru Ardelean <alexandru.ardelean@analog.com>
Date:   Wed Feb 10 12:50:44 2021 +0200

    iio: adc: adi-axi-adc: add proper Kconfig dependencies
    
    commit be24c65e9fa2486bb8ec98d9f592bdcf04bedd88 upstream.
    
    The ADI AXI ADC driver requires IO mem access and OF to work. This change
    adds these dependencies to the Kconfig symbol of the driver.
    
    This was also found via the lkp bot, as the
    devm_platform_ioremap_resource() symbol was not found at link-time on the
    S390 architecture.
    
    Fixes: ef04070692a21 ("iio: adc: adi-axi-adc: add support for AXI ADC IP core")
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
    Cc: <Stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20210210105044.48914-1-alexandru.ardelean@analog.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d894acab284426d1500f84dca4bfc4634711b28a
Author: Wilfried Wessner <wilfried.wessner@gmail.com>
Date:   Mon Feb 8 15:27:05 2021 +0100

    iio: adc: ad7949: fix wrong ADC result due to incorrect bit mask
    
    commit f890987fac8153227258121740a9609668c427f3 upstream.
    
    Fixes a wrong bit mask used for the ADC's result, which was caused by an
    improper usage of the GENMASK() macro. The bits higher than ADC's
    resolution are undefined and if not masked out correctly, a wrong result
    can be given. The GENMASK() macro indexing is zero based, so the mask has
    to go from [resolution - 1 , 0].
    
    Fixes: 7f40e0614317f ("iio:adc:ad7949: Add AD7949 ADC driver family")
    Signed-off-by: Wilfried Wessner <wilfried.wessner@gmail.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Reviewed-by: Charles-Antoine Couret <charles-antoine.couret@essensium.com>
    Cc: <Stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20210208142705.GA51260@ubuntu
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 533ee1e28455d93bfd8925955698a5bae6e775aa
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Thu Dec 24 02:17:00 2020 +0100

    iio: adc: ab8500-gpadc: Fix off by 10 to 3
    
    commit 4f5434086d9223f20b3128a7dc78b35271e76655 upstream.
    
    Fix an off by three orders of magnitude error in the AB8500
    GPADC driver. Luckily it showed up quite quickly when trying
    to make use of it. The processed reads were returning
    microvolts, microamperes and microcelsius instead of millivolts,
    milliamperes and millicelsius as advertised.
    
    Cc: stable@vger.kernel.org
    Fixes: 07063bbfa98e ("iio: adc: New driver for the AB8500 GPADC")
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Link: https://lore.kernel.org/r/20201224011700.1059659-1-linus.walleij@linaro.org
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f8bfbd3917fa18b6ba45e069e0d921f777902797
Author: Dinghao Liu <dinghao.liu@zju.edu.cn>
Date:   Mon Mar 1 16:04:21 2021 +0800

    iio: gyro: mpu3050: Fix error handling in mpu3050_trigger_handler
    
    commit 6dbbbe4cfd398704b72b21c1d4a5d3807e909d60 upstream.
    
    There is one regmap_bulk_read() call in mpu3050_trigger_handler
    that we have caught its return value bug lack further handling.
    Check and terminate the execution flow just like the other three
    regmap_bulk_read() calls in this function.
    
    Fixes: 3904b28efb2c7 ("iio: gyro: Add driver for the MPU-3050 gyroscope")
    Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Link: https://lore.kernel.org/r/20210301080421.13436-1-dinghao.liu@zju.edu.cn
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 06c281c23acedf71e8fabd1a7b19d46313392d0c
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Feb 16 22:42:13 2021 +0300

    iio: adis16400: Fix an error code in adis16400_initial_setup()
    
    commit a71266e454b5df10d019b06f5ebacd579f76be28 upstream.
    
    This is to silence a new Smatch warning:
    
        drivers/iio/imu/adis16400.c:492 adis16400_initial_setup()
        warn: sscanf doesn't return error codes
    
    If the condition "if (st->variant->flags & ADIS16400_HAS_SLOW_MODE) {"
    is false then we return 1 instead of returning 0 and probe will fail.
    
    Fixes: 72a868b38bdd ("iio: imu: check sscanf return value")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Cc: <Stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/YCwgFb3JVG6qrlQ+@mwanda
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5312314858444b1bb7278623d8a1237389b26af6
Author: Jonathan Albrieux <jonathan.albrieux@gmail.com>
Date:   Wed Jan 13 16:18:07 2021 +0100

    iio:adc:qcom-spmi-vadc: add default scale to LR_MUX2_BAT_ID channel
    
    commit 7d200b283aa049fcda0d43dd6e03e9e783d2799c upstream.
    
    Checking at both msm8909-pm8916.dtsi and msm8916.dtsi from downstream
    it is indicated that "batt_id" channel has to be scaled with the default
    function:
    
            chan@31 {
                    label = "batt_id";
                    reg = <0x31>;
                    qcom,decimation = <0>;
                    qcom,pre-div-channel-scaling = <0>;
                    qcom,calibration-type = "ratiometric";
                    qcom,scale-function = <0>;
                    qcom,hw-settle-time = <0xb>;
                    qcom,fast-avg-setup = <0>;
            };
    
    Change LR_MUX2_BAT_ID scaling accordingly.
    
    Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
    Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Fixes: 7c271eea7b8a ("iio: adc: spmi-vadc: Changes to support different scaling")
    Link: https://lore.kernel.org/r/20210113151808.4628-2-jonathan.albrieux@gmail.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ce2e7b2d3605c7113b322509fcedbfb81b5e496
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Sun Jan 24 19:50:34 2021 +0000

    iio:adc:stm32-adc: Add HAS_IOMEM dependency
    
    commit 121875b28e3bd7519a675bf8ea2c2e793452c2bd upstream.
    
    Seems that there are config combinations in which this driver gets enabled
    and hence selects the MFD, but with out HAS_IOMEM getting pulled in
    via some other route.  MFD is entirely contained in an
    if HAS_IOMEM block, leading to the build issue in this bugzilla.
    
    https://bugzilla.kernel.org/show_bug.cgi?id=209889
    
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Link: https://lore.kernel.org/r/20210124195034.22576-1-jic23@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c3c90058b95c70f9e001a1d82aaf53b50562a08
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date:   Thu Dec 10 14:57:10 2020 +0200

    thunderbolt: Increase runtime PM reference count on DP tunnel discovery
    
    commit c94732bda079ee66b5c3904cbb628d0cb218ab39 upstream.
    
    If the driver is unbound and then bound back it goes over the topology
    and figure out the existing tunnels. However, if it finds DP tunnel it
    should make sure the domain does not runtime suspend as otherwise it
    will tear down the DP tunnel unexpectedly.
    
    Fixes: 6ac6faee5d7d ("thunderbolt: Add runtime PM for Software CM")
    Cc: stable@vger.kernel.org
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f4ca082e3f59f1c3a4d4b7ec383131fd18ce1b69
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date:   Wed Feb 10 16:06:33 2021 +0200

    thunderbolt: Initialize HopID IDAs in tb_switch_alloc()
    
    commit 781e14eaa7d168dc07d2a2eea5c55831a5bb46f3 upstream.
    
    If there is a failure before the tb_switch_add() is called the switch
    object is released by tb_switch_release() but at that point HopID IDAs
    have not yet been initialized. So we see splat like this:
    
    BUG: spinlock bad magic on CPU#2, kworker/u8:5/115
    ...
    Workqueue: thunderbolt0 tb_handle_hotplug
    Call Trace:
     dump_stack+0x97/0xdc
     ? spin_bug+0x9a/0xa7
     do_raw_spin_lock+0x68/0x98
     _raw_spin_lock_irqsave+0x3f/0x5d
     ida_destroy+0x4f/0x127
     tb_switch_release+0x6d/0xfd
     device_release+0x2c/0x7d
     kobject_put+0x9b/0xbc
     tb_handle_hotplug+0x278/0x452
     process_one_work+0x1db/0x396
     worker_thread+0x216/0x375
     kthread+0x14d/0x155
     ? pr_cont_work+0x58/0x58
     ? kthread_blkcg+0x2e/0x2e
     ret_from_fork+0x1f/0x40
    
    Fix this by always initializing HopID IDAs in tb_switch_alloc().
    
    Fixes: 0b2863ac3cfd ("thunderbolt: Add functions for allocating and releasing HopIDs")
    Cc: stable@vger.kernel.org
    Reported-by: Chiranjeevi Rapolu <chiranjeevi.rapolu@intel.com>
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c7bb96a37dd2095fcd6c65a59689004e63e4b872
Author: Wesley Cheng <wcheng@codeaurora.org>
Date:   Thu Mar 11 15:59:02 2021 -0800

    usb: dwc3: gadget: Prevent EP queuing while stopping transfers
    
    commit f09ddcfcb8c569675066337adac2ac205113471f upstream.
    
    In the situations where the DWC3 gadget stops active transfers, once
    calling the dwc3_gadget_giveback(), there is a chance where a function
    driver can queue a new USB request in between the time where the dwc3
    lock has been released and re-aquired.  This occurs after we've already
    issued an ENDXFER command.  When the stop active transfers continues
    to remove USB requests from all dep lists, the newly added request will
    also be removed, while controller still has an active TRB for it.
    This can lead to the controller accessing an unmapped memory address.
    
    Fix this by ensuring parameters to prevent EP queuing are set before
    calling the stop active transfers API.
    
    Fixes: ae7e86108b12 ("usb: dwc3: Stop active transfers before halting the controller")
    Signed-off-by: Wesley Cheng <wcheng@codeaurora.org>
    Link: https://lore.kernel.org/r/1615507142-23097-1-git-send-email-wcheng@codeaurora.org
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 395d273f29980f658ac0087019661325aa777344
Author: Wesley Cheng <wcheng@codeaurora.org>
Date:   Tue Dec 29 15:05:35 2020 -0800

    usb: dwc3: gadget: Allow runtime suspend if UDC unbinded
    
    commit 77adb8bdf4227257e26b7ff67272678e66a0b250 upstream.
    
    The DWC3 runtime suspend routine checks for the USB connected parameter to
    determine if the controller can enter into a low power state.  The
    connected state is only set to false after receiving a disconnect event.
    However, in the case of a device initiated disconnect (i.e. UDC unbind),
    the controller is halted and a disconnect event is never generated.  Set
    the connected flag to false if issuing a device initiated disconnect to
    allow the controller to be suspended.
    
    Signed-off-by: Wesley Cheng <wcheng@codeaurora.org>
    Link: https://lore.kernel.org/r/1609283136-22140-2-git-send-email-wcheng@codeaurora.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8b8a84234c38993dd7f5e8d86344b631b501dc09
Author: Badhri Jagan Sridharan <badhri@google.com>
Date:   Wed Mar 17 11:12:48 2021 -0700

    usb: typec: tcpm: Invoke power_supply_changed for tcpm-source-psy-
    
    commit 86629e098a077922438efa98dc80917604dfd317 upstream.
    
    tcpm-source-psy- does not invoke power_supply_changed API when
    one of the published power supply properties is changed.
    power_supply_changed needs to be called to notify
    userspace clients(uevents) and kernel clients.
    
    Fixes: f2a8aa053c176 ("typec: tcpm: Represent source supply through power_supply")
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20210317181249.1062995-1-badhri@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0ea3fb15a87e302f4aa9a75f24a555cfe8ef9dca
Author: Elias Rudberg <mail@eliasrudberg.se>
Date:   Thu Mar 11 13:47:10 2021 +0100

    usb: typec: Remove vdo[3] part of tps6598x_rx_identity_reg struct
    
    commit 3cac9104bea41099cf622091f0c0538bcb19050d upstream.
    
    Remove the unused "u32 vdo[3]" part in the tps6598x_rx_identity_reg
    struct. This helps avoid "failed to register partner" errors which
    happen when tps6598x_read_partner_identity() fails because the
    amount of data read is 12 bytes smaller than the struct size.
    Note that vdo[3] is already in usb_pd_identity and hence
    shouldn't be added to tps6598x_rx_identity_reg as well.
    
    Fixes: f6c56ca91b92 ("usb: typec: Add the Product Type VDOs to struct usb_pd_identity")
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Reviewed-by: Guido Günther <agx@sigxcpu.org>
    Signed-off-by: Elias Rudberg <mail@eliasrudberg.se>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20210311124710.6563-1-mail@eliasrudberg.se
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0f882bcc6407bfa534a95e63ece983449de2f47f
Author: Jim Lin <jilin@nvidia.com>
Date:   Thu Mar 11 14:42:41 2021 +0800

    usb: gadget: configfs: Fix KASAN use-after-free
    
    commit 98f153a10da403ddd5e9d98a3c8c2bb54bb5a0b6 upstream.
    
    When gadget is disconnected, running sequence is like this.
    . composite_disconnect
    . Call trace:
      usb_string_copy+0xd0/0x128
      gadget_config_name_configuration_store+0x4
      gadget_config_name_attr_store+0x40/0x50
      configfs_write_file+0x198/0x1f4
      vfs_write+0x100/0x220
      SyS_write+0x58/0xa8
    . configfs_composite_unbind
    . configfs_composite_bind
    
    In configfs_composite_bind, it has
    "cn->strings.s = cn->configuration;"
    
    When usb_string_copy is invoked. it would
    allocate memory, copy input string, release previous pointed memory space,
    and use new allocated memory.
    
    When gadget is connected, host sends down request to get information.
    Call trace:
      usb_gadget_get_string+0xec/0x168
      lookup_string+0x64/0x98
      composite_setup+0xa34/0x1ee8
    
    If gadget is disconnected and connected quickly, in the failed case,
    cn->configuration memory has been released by usb_string_copy kfree but
    configfs_composite_bind hasn't been run in time to assign new allocated
    "cn->configuration" pointer to "cn->strings.s".
    
    When "strlen(s->s) of usb_gadget_get_string is being executed, the dangling
    memory is accessed, "BUG: KASAN: use-after-free" error occurs.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Jim Lin <jilin@nvidia.com>
    Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
    Link: https://lore.kernel.org/r/1615444961-13376-1-git-send-email-macpaul.lin@mediatek.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 22e85a6a35cc7e8966fd7879f61cdd86deb19409
Author: Colin Ian King <colin.king@canonical.com>
Date:   Thu Mar 11 10:44:45 2021 +0000

    usbip: Fix incorrect double assignment to udc->ud.tcp_rx
    
    commit 9858af27e69247c5d04c3b093190a93ca365f33d upstream.
    
    Currently udc->ud.tcp_rx is being assigned twice, the second assignment
    is incorrect, it should be to udc->ud.tcp_tx instead of rx. Fix this.
    
    Fixes: 46613c9dfa96 ("usbip: fix vudc usbip_sockfd_store races leading to gpf")
    Acked-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Cc: stable <stable@vger.kernel.org>
    Addresses-Coverity: ("Unused value")
    Link: https://lore.kernel.org/r/20210311104445.7811-1-colin.king@canonical.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7046e5f7a2f66c78a08998964be31da0c635be21
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Wed Mar 17 15:06:54 2021 -0400

    usb-storage: Add quirk to defeat Kindle's automatic unload
    
    commit 546aa0e4ea6ed81b6c51baeebc4364542fa3f3a7 upstream.
    
    Matthias reports that the Amazon Kindle automatically removes its
    emulated media if it doesn't receive another SCSI command within about
    one second after a SYNCHRONIZE CACHE.  It does so even when the host
    has sent a PREVENT MEDIUM REMOVAL command.  The reason for this
    behavior isn't clear, although it's not hard to make some guesses.
    
    At any rate, the results can be unexpected for anyone who tries to
    access the Kindle in an unusual fashion, and in theory they can lead
    to data loss (for example, if one file is closed and synchronized
    while other files are still in the middle of being written).
    
    To avoid such problems, this patch creates a new usb-storage quirks
    flag telling the driver always to issue a REQUEST SENSE following a
    SYNCHRONIZE CACHE command, and adds an unusual_devs entry for the
    Kindle with the flag set.  This is sufficient to prevent the Kindle
    from doing its automatic unload, without interfering with proper
    operation.
    
    Another possible way to deal with this would be to increase the
    frequency of TEST UNIT READY polling that the kernel normally carries
    out for removable-media storage devices.  However that would increase
    the overall load on the system and it is not as reliable, because the
    user can override the polling interval.  Changing the driver's
    behavior is safer and has minimal overhead.
    
    CC: <stable@vger.kernel.org>
    Reported-and-tested-by: Matthias Schwarzott <zzam@gentoo.org>
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Link: https://lore.kernel.org/r/20210317190654.GA497856@rowland.harvard.edu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5a62d6d7afa06d34b7c1a525b05fb5bddfe7b595
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Wed Mar 10 12:10:34 2021 +0000

    powerpc: Force inlining of cpu_has_feature() to avoid build failure
    
    commit eed5fae00593ab9d261a0c1ffc1bdb786a87a55a upstream.
    
    The code relies on constant folding of cpu_has_feature() based
    on possible and always true values as defined per
    CPU_FTRS_ALWAYS and CPU_FTRS_POSSIBLE.
    
    Build failure is encountered with for instance
    book3e_all_defconfig on kisskb in the AMDGPU driver which uses
    cpu_has_feature(CPU_FTR_VSX_COMP) to decide whether calling
    kernel_enable_vsx() or not.
    
    The failure is due to cpu_has_feature() not being inlined with
    that configuration with gcc 4.9.
    
    In the same way as commit acdad8fb4a15 ("powerpc: Force inlining of
    mmu_has_feature to fix build failure"), for inlining of
    cpu_has_feature().
    
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/b231dfa040ce4cc37f702f5c3a595fdeabfe0462.1615378209.git.christophe.leroy@csgroup.eu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2bdef2b476e2c6c9e62155ede561e76d0deb84e9
Author: Bob Peterson <rpeterso@redhat.com>
Date:   Fri Mar 12 07:58:54 2021 -0500

    gfs2: bypass signal_our_withdraw if no journal
    
    [ Upstream commit d5bf630f355d8c532bef2347cf90e8ae60a5f1bd ]
    
    Before this patch, function signal_our_withdraw referenced the journal
    inode immediately. But corrupt file systems may have some invalid
    journals, in which case our attempt to read it in will withdraw and the
    resulting signal_our_withdraw would dereference the NULL value.
    
    This patch adds a check to signal_our_withdraw so that if the journal
    has not yet been initialized, it simply returns and does the old-style
    withdraw.
    
    Thanks, Andy Price, for his analysis.
    
    Reported-by: syzbot+50a8a9cf8127f2c6f5df@syzkaller.appspotmail.com
    Fixes: 601ef0d52e96 ("gfs2: Force withdraw to replay journals and wait for it to finish")
    Signed-off-by: Bob Peterson <rpeterso@redhat.com>
    Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a602e830ddafd4928bbc98c5b2fb56cfc134741d
Author: Bob Peterson <rpeterso@redhat.com>
Date:   Tue Dec 22 14:43:28 2020 -0600

    gfs2: move freeze glock outside the make_fs_rw and _ro functions
    
    [ Upstream commit 96b1454f2e8ede4c619fde405a1bb4e9ba8d218e ]
    
    Before this patch, sister functions gfs2_make_fs_rw and gfs2_make_fs_ro locked
    (held) the freeze glock by calling gfs2_freeze_lock and gfs2_freeze_unlock.
    The problem is, not all the callers of gfs2_make_fs_ro should be doing this.
    The three callers of gfs2_make_fs_ro are: remount (gfs2_reconfigure),
    signal_our_withdraw, and unmount (gfs2_put_super). But when unmounting the
    file system we can get into the following circular lock dependency:
    
    deactivate_super
       down_write(&s->s_umount); <-------------------------------------- s_umount
       deactivate_locked_super
          gfs2_kill_sb
             kill_block_super
                generic_shutdown_super
                   gfs2_put_super
                      gfs2_make_fs_ro
                         gfs2_glock_nq_init sd_freeze_gl
                            freeze_go_sync
                               if (freeze glock in SH)
                                  freeze_super (vfs)
                                     down_write(&sb->s_umount); <------- s_umount
    
    This patch moves the hold of the freeze glock outside the two sister rw/ro
    functions to their callers, but it doesn't request the glock from
    gfs2_put_super, thus eliminating the circular dependency.
    
    Signed-off-by: Bob Peterson <rpeterso@redhat.com>
    Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 49787b1bba1ff63c691d25c108a61c5361f60b5f
Author: Bob Peterson <rpeterso@redhat.com>
Date:   Tue Dec 22 14:43:27 2020 -0600

    gfs2: Add common helper for holding and releasing the freeze glock
    
    [ Upstream commit c77b52c0a137994ad796f44544c802b0b766e496 ]
    
    Many places in the gfs2 code queued and dequeued the freeze glock.
    Almost all of them acquire it in SHARED mode, and need to specify the
    same LM_FLAG_NOEXP and GL_EXACT flags.
    
    This patch adds common helper functions gfs2_freeze_lock and gfs2_freeze_unlock
    to make the code more readable, and to prepare for the next patch.
    
    Signed-off-by: Bob Peterson <rpeterso@redhat.com>
    Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit db37238f3452f8034f7abc3ab84edd8749faa201
Author: Frieder Schrempf <frieder.schrempf@kontron.de>
Date:   Mon Feb 22 12:52:20 2021 +0100

    regulator: pca9450: Clear PRESET_EN bit to fix BUCK1/2/3 voltage setting
    
    [ Upstream commit 98b94b6e38ca0c4eeb29949c656f6a315000c23e ]
    
    The driver uses the DVS registers PCA9450_REG_BUCKxOUT_DVS0 to set the
    voltage for the buck regulators 1, 2 and 3. This has no effect as the
    PRESET_EN bit is set by default and therefore the preset values are used
    instead, which are set to 850 mV.
    
    To fix this we clear the PRESET_EN bit at time of initialization.
    
    Fixes: 0935ff5f1f0a ("regulator: pca9450: add pca9450 pmic driver")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
    Link: https://lore.kernel.org/r/20210222115229.166620-1-frieder.schrempf@kontron.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cfbff8bd9efcb8e2584c7082431723f4864b30dd
Author: Frieder Schrempf <frieder.schrempf@kontron.de>
Date:   Thu Feb 11 11:55:30 2021 +0100

    regulator: pca9450: Enable system reset on WDOG_B assertion
    
    [ Upstream commit f7684f5a048febd2a7bc98ee81d6dce52f7268b8 ]
    
    By default the PCA9450 doesn't handle the assertion of the WDOG_B
    signal, but this is required to guarantee that things like software
    resets triggered by the watchdog work reliably.
    
    As we don't want to rely on the bootloader to enable this, we tell
    the PMIC to issue a cold reset in case the WDOG_B signal is
    asserted (WDOG_B_CFG = 10), just as the NXP U-Boot code does.
    
    Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
    Link: https://lore.kernel.org/r/20210211105534.38972-3-frieder.schrempf@kontron.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 775691b94ce74e02297b9165c7df99c589374b2d
Author: Frieder Schrempf <frieder.schrempf@kontron.de>
Date:   Thu Feb 11 11:55:28 2021 +0100

    regulator: pca9450: Add SD_VSEL GPIO for LDO5
    
    [ Upstream commit 8c67a11bae889f51fe5054364c3c789dfae3ad73 ]
    
    LDO5 has two separate control registers. LDO5CTRL_L is used if the
    input signal SD_VSEL is low and LDO5CTRL_H if it is high.
    The current driver implementation only uses LDO5CTRL_H. To make this
    work on boards that have SD_VSEL connected to a GPIO, we add support
    for specifying an optional GPIO and setting it to high at probe time.
    
    In the future we might also want to add support for boards that have
    SD_VSEL set to a fixed low level. In this case we need to change the
    driver to be able to use the LDO5CTRL_L register.
    
    Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
    Link: https://lore.kernel.org/r/20210211105534.38972-1-frieder.schrempf@kontron.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9392b8219b62b0536df25c9de82b33f8a00881ef
Author: Jia-Ju Bai <baijiaju1990@gmail.com>
Date:   Sun Mar 7 19:11:02 2021 -0800

    net: bonding: fix error return code of bond_neigh_init()
    
    [ Upstream commit 2055a99da8a253a357bdfd359b3338ef3375a26c ]
    
    When slave is NULL or slave_ops->ndo_neigh_setup is NULL, no error
    return code of bond_neigh_init() is assigned.
    To fix this bug, ret is assigned with -EINVAL in these cases.
    
    Fixes: 9e99bfefdbce ("bonding: fix bond_neigh_init()")
    Reported-by: TOTE Robot <oslab@tsinghua.edu.cn>
    Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 76f496681d6a125d28321deda355ca14d0e4ad23
Author: Jens Axboe <axboe@kernel.dk>
Date:   Thu Mar 4 21:02:58 2021 -0700

    io_uring: clear IOCB_WAITQ for non -EIOCBQUEUED return
    
    [ Upstream commit b5b0ecb736f1ce1e68eb50613c0cfecff10198eb ]
    
    The callback can only be armed, if we get -EIOCBQUEUED returned. It's
    important that we clear the WAITQ bit for other cases, otherwise we can
    queue for async retry and filemap will assume that we're armed and
    return -EAGAIN instead of just blocking for the IO.
    
    Cc: stable@vger.kernel.org # 5.9+
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3c08f772ad0db70876021aa5d276e14747f77512
Author: Jens Axboe <axboe@kernel.dk>
Date:   Tue Feb 23 19:17:35 2021 -0700

    io_uring: don't attempt IO reissue from the ring exit path
    
    [ Upstream commit 7c977a58dc83366e488c217fd88b1469d242bee5 ]
    
    If we're exiting the ring, just let the IO fail with -EAGAIN as nobody
    will care anyway. It's not the right context to reissue from.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 40345b9c9d90684cb546fdc51de6b4bd18343ae5
Author: Evan Quan <evan.quan@amd.com>
Date:   Mon Sep 28 17:17:56 2020 +0800

    drm/amd/pm: fulfill the Polaris implementation for get_clock_by_type_with_latency()
    
    [ Upstream commit 690cdc2635849db8b782dbbcabfb1c7519c84fa1 ]
    
    Fulfill Polaris get_clock_by_type_with_latency().
    
    Signed-off-by: Evan Quan <evan.quan@amd.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e8e99acd08300f27fd2133ceb9501e149501b6b5
Author: Julian Wiedmann <jwi@linux.ibm.com>
Date:   Tue Mar 9 17:52:20 2021 +0100

    s390/qeth: schedule TX NAPI on QAOB completion
    
    [ Upstream commit 3e83d467a08e25b27c44c885f511624a71c84f7c ]
    
    When a QAOB notifies us that a pending TX buffer has been delivered, the
    actual TX completion processing by qeth_tx_complete_pending_bufs()
    is done within the context of a TX NAPI instance. We shouldn't rely on
    this instance being scheduled by some other TX event, but just do it
    ourselves.
    
    qeth_qdio_handle_aob() is called from qeth_poll(), ie. our main NAPI
    instance. To avoid touching the TX queue's NAPI instance
    before/after it is (un-)registered, reorder the code in qeth_open()
    and qeth_stop() accordingly.
    
    Fixes: 0da9581ddb0f ("qeth: exploit asynchronous delivery of storage blocks")
    Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f3f6765fd0e8c32dd13c98329c8f48d0d98e4161
Author: Junlin Yang <yangjunlin@yulong.com>
Date:   Fri Mar 5 16:48:39 2021 +0800

    ibmvnic: remove excessive irqsave
    
    [ Upstream commit 69cdb7947adb816fc9325b4ec02a6dddd5070b82 ]
    
    ibmvnic_remove locks multiple spinlocks while disabling interrupts:
    spin_lock_irqsave(&adapter->state_lock, flags);
    spin_lock_irqsave(&adapter->rwi_lock, flags);
    
    As reported by coccinelle, the second _irqsave() overwrites the value
    saved in 'flags' by the first _irqsave(),   therefore when the second
    _irqrestore() comes,the value in 'flags' is not valid,the value saved
    by the first _irqsave() has been lost.
    This likely leads to IRQs remaining disabled. So remove the second
    _irqsave():
    spin_lock_irqsave(&adapter->state_lock, flags);
    spin_lock(&adapter->rwi_lock);
    
    Generated by: ./scripts/coccinelle/locks/flags.cocci
    ./drivers/net/ethernet/ibm/ibmvnic.c:5413:1-18:
    ERROR: nested lock+irqsave that reuses flags from line 5404.
    
    Fixes: 4a41c421f367 ("ibmvnic: serialize access to work queue on remove")
    Signed-off-by: Junlin Yang <yangjunlin@yulong.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 96823c1e99978e590ffdf8ed0dd074537cc494b5
Author: Ezequiel Garcia <ezequiel@collabora.com>
Date:   Thu Nov 26 10:36:08 2020 +0100

    media: cedrus: h264: Support profile controls
    
    [ Upstream commit c8363ff21b5168f2252aa8b8447173ce48ff0149 ]
    
    Cedrus supports H.264 profiles from Baseline to High,
    except for the Extended profile
    
    Expose the V4L2_CID_MPEG_VIDEO_H264_PROFILE so that
    userspace can query the driver for the supported
    profiles and levels.
    
    Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
    Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net>
    Tested-by: Jernej Skrabec <jernej.skrabec@siol.net>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1c20e9040f49687ba2ccc2ffd4411351a6c2ebff
Author: Pavel Begunkov <asml.silence@gmail.com>
Date:   Wed Mar 10 11:30:37 2021 +0000

    io_uring: fix inconsistent lock state
    
    [ Upstream commit 9ae1f8dd372e0e4c020b345cf9e09f519265e981 ]
    
    WARNING: inconsistent lock state
    
    inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
    syz-executor217/8450 [HC1[1]:SC0[0]:HE0:SE1] takes:
    ffff888023d6e620 (&fs->lock){?.+.}-{2:2}, at: spin_lock include/linux/spinlock.h:354 [inline]
    ffff888023d6e620 (&fs->lock){?.+.}-{2:2}, at: io_req_clean_work fs/io_uring.c:1398 [inline]
    ffff888023d6e620 (&fs->lock){?.+.}-{2:2}, at: io_dismantle_req+0x66f/0xf60 fs/io_uring.c:2029
    
    other info that might help us debug this:
     Possible unsafe locking scenario:
    
           CPU0
           ----
      lock(&fs->lock);
      <Interrupt>
        lock(&fs->lock);
    
     *** DEADLOCK ***
    
    1 lock held by syz-executor217/8450:
     #0: ffff88802417c3e8 (&ctx->uring_lock){+.+.}-{3:3}, at: __do_sys_io_uring_enter+0x1071/0x1f30 fs/io_uring.c:9442
    
    stack backtrace:
    CPU: 1 PID: 8450 Comm: syz-executor217 Not tainted 5.11.0-rc5-next-20210129-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Call Trace:
     <IRQ>
    [...]
     _raw_spin_lock+0x2a/0x40 kernel/locking/spinlock.c:151
     spin_lock include/linux/spinlock.h:354 [inline]
     io_req_clean_work fs/io_uring.c:1398 [inline]
     io_dismantle_req+0x66f/0xf60 fs/io_uring.c:2029
     __io_free_req+0x3d/0x2e0 fs/io_uring.c:2046
     io_free_req fs/io_uring.c:2269 [inline]
     io_double_put_req fs/io_uring.c:2392 [inline]
     io_put_req+0xf9/0x570 fs/io_uring.c:2388
     io_link_timeout_fn+0x30c/0x480 fs/io_uring.c:6497
     __run_hrtimer kernel/time/hrtimer.c:1519 [inline]
     __hrtimer_run_queues+0x609/0xe40 kernel/time/hrtimer.c:1583
     hrtimer_interrupt+0x334/0x940 kernel/time/hrtimer.c:1645
     local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1085 [inline]
     __sysvec_apic_timer_interrupt+0x146/0x540 arch/x86/kernel/apic/apic.c:1102
     asm_call_irq_on_stack+0xf/0x20
     </IRQ>
     __run_sysvec_on_irqstack arch/x86/include/asm/irq_stack.h:37 [inline]
     run_sysvec_on_irqstack_cond arch/x86/include/asm/irq_stack.h:89 [inline]
     sysvec_apic_timer_interrupt+0xbd/0x100 arch/x86/kernel/apic/apic.c:1096
     asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:629
    RIP: 0010:__raw_spin_unlock_irq include/linux/spinlock_api_smp.h:169 [inline]
    RIP: 0010:_raw_spin_unlock_irq+0x25/0x40 kernel/locking/spinlock.c:199
     spin_unlock_irq include/linux/spinlock.h:404 [inline]
     io_queue_linked_timeout+0x194/0x1f0 fs/io_uring.c:6525
     __io_queue_sqe+0x328/0x1290 fs/io_uring.c:6594
     io_queue_sqe+0x631/0x10d0 fs/io_uring.c:6639
     io_queue_link_head fs/io_uring.c:6650 [inline]
     io_submit_sqe fs/io_uring.c:6697 [inline]
     io_submit_sqes+0x19b5/0x2720 fs/io_uring.c:6960
     __do_sys_io_uring_enter+0x107d/0x1f30 fs/io_uring.c:9443
     do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
     entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    Don't free requests from under hrtimer context (softirq) as it may sleep
    or take spinlocks improperly (e.g. non-irq versions).
    
    Cc: stable@vger.kernel.org # 5.6+
    Reported-by: syzbot+81d17233a2b02eafba33@syzkaller.appspotmail.com
    Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e1a69079edc45daead5c4835c30ae18cbdcb4145
Author: Matti Gottlieb <matti.gottlieb@intel.com>
Date:   Wed Dec 9 23:16:45 2020 +0200

    iwlwifi: Add a new card for MA family
    
    [ Upstream commit ac1a98e1e924e7e8d7c7e5b1ca8ddc522e10ddd0 ]
    
    Add a PCI ID for snj with mr in AX family.
    
    Signed-off-by: Matti Gottlieb <matti.gottlieb@intel.com>
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Link: https://lore.kernel.org/r/iwlwifi.20201209231352.101ac3058c04.Idd28706b122cdc8103956f8e72bb062fe4adb54e@changeid
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e7f6ebde21cf1fd69218e57c36aa19ba732b1699
Author: Aurabindo Pillai <aurabindo.pillai@amd.com>
Date:   Thu Nov 26 16:45:59 2020 -0500

    drm/amd/display: turn DPMS off on connector unplug
    
    [ Upstream commit 3c4d55c9b9becedd8d31a7c96783a364533713ab ]
    
    [Why&How]
    
    Set dpms off on the connector that was unplugged, for the side effect of
    releasing some references held through deallocation of MST payload. This is
    the expected behaviour for non MST devices as well.
    
    Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
    Signed-off-by: Eryk Brol <eryk.brol@amd.com>
    Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 559b842a64ffb34390cf1545c9843affdb23535d
Author: Alexander Lobakin <alobakin@pm.me>
Date:   Mon Feb 8 12:37:42 2021 +0000

    MIPS: compressed: fix build with enabled UBSAN
    
    [ Upstream commit fc4cac4cfc437659ce445c3c47b807e1cc625b66 ]
    
    Commit 1e35918ad9d1 ("MIPS: Enable Undefined Behavior Sanitizer
    UBSAN") added a possibility to build the entire kernel with UBSAN
    instrumentation for MIPS, with the exception for VDSO.
    However, self-extracting head wasn't been added to exceptions, so
    this occurs:
    
    mips-alpine-linux-musl-ld: arch/mips/boot/compressed/decompress.o:
    in function `FSE_buildDTable_wksp':
    decompress.c:(.text.FSE_buildDTable_wksp+0x278): undefined reference
    to `__ubsan_handle_shift_out_of_bounds'
    mips-alpine-linux-musl-ld: decompress.c:(.text.FSE_buildDTable_wksp+0x2a8):
    undefined reference to `__ubsan_handle_shift_out_of_bounds'
    mips-alpine-linux-musl-ld: decompress.c:(.text.FSE_buildDTable_wksp+0x2c4):
    undefined reference to `__ubsan_handle_shift_out_of_bounds'
    mips-alpine-linux-musl-ld: arch/mips/boot/compressed/decompress.o:
    decompress.c:(.text.FSE_buildDTable_raw+0x9c): more undefined references
    to `__ubsan_handle_shift_out_of_bounds' follow
    
    Add UBSAN_SANITIZE := n to mips/boot/compressed/Makefile to exclude
    it from instrumentation scope and fix this issue.
    
    Fixes: 1e35918ad9d1 ("MIPS: Enable Undefined Behavior Sanitizer UBSAN")
    Cc: stable@vger.kernel.org # 5.0+
    Signed-off-by: Alexander Lobakin <alobakin@pm.me>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8545519b1f51b73372c86d754bc9ee83c5d06760
Author: Christian Melki <christian.melki@t2data.com>
Date:   Wed Feb 24 21:55:36 2021 +0100

    net: phy: micrel: set soft_reset callback to genphy_soft_reset for KSZ8081
    
    [ Upstream commit 764d31cacfe48440745c4bbb55a62ac9471c9f19 ]
    
    Following a similar reinstate for the KSZ9031.
    
    Older kernels would use the genphy_soft_reset if the PHY did not implement
    a .soft_reset.
    
    Bluntly removing that default may expose a lot of situations where various
    PHYs/board implementations won't recover on various changes.
    Like with this implementation during a 4.9.x to 5.4.x LTS transition.
    I think it's a good thing to remove unwanted soft resets but wonder if it
    did open a can of worms?
    
    Atleast this fixes one iMX6 FEC/RMII/8081 combo.
    
    Fixes: 6e2d85ec0559 ("net: phy: Stop with excessive soft reset")
    Signed-off-by: Christian Melki <christian.melki@t2data.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Link: https://lore.kernel.org/r/20210224205536.9349-1-christian.melki@t2data.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 33cafc7952a4f95564f4eb615663d17603e24663
Author: Norbert Ciosek <norbertx.ciosek@intel.com>
Date:   Fri Feb 5 08:48:52 2021 +0000

    i40e: Fix endianness conversions
    
    [ Upstream commit b32cddd2247cf730731f93f1967d0147a40682c7 ]
    
    Fixes the following sparse warnings:
    i40e_main.c:5953:32: warning: cast from restricted __le16
    i40e_main.c:8008:29: warning: incorrect type in assignment (different base types)
    i40e_main.c:8008:29:    expected unsigned int [assigned] [usertype] ipa
    i40e_main.c:8008:29:    got restricted __le32 [usertype]
    i40e_main.c:8008:29: warning: incorrect type in assignment (different base types)
    i40e_main.c:8008:29:    expected unsigned int [assigned] [usertype] ipa
    i40e_main.c:8008:29:    got restricted __le32 [usertype]
    i40e_txrx.c:1950:59: warning: incorrect type in initializer (different base types)
    i40e_txrx.c:1950:59:    expected unsigned short [usertype] vlan_tag
    i40e_txrx.c:1950:59:    got restricted __le16 [usertype] l2tag1
    i40e_txrx.c:1953:40: warning: cast to restricted __le16
    i40e_xsk.c:448:38: warning: invalid assignment: |=
    i40e_xsk.c:448:38:    left side has type restricted __le64
    i40e_xsk.c:448:38:    right side has type int
    
    Fixes: 2f4b411a3d67 ("i40e: Enable cloud filters via tc-flower")
    Fixes: 2a508c64ad27 ("i40e: fix VLAN.TCI == 0 RX HW offload")
    Fixes: 3106c580fb7c ("i40e: Use batched xsk Tx interfaces to increase performance")
    Fixes: 8f88b3034db3 ("i40e: Add infrastructure for queue channel support")
    Signed-off-by: Norbert Ciosek <norbertx.ciosek@intel.com>
    Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 41d4c889b27424af7725be35187aba167a53b8c9
Author: Sandipan Das <sandipan@linux.ibm.com>
Date:   Thu Feb 4 13:37:44 2021 +0530

    powerpc/sstep: Fix darn emulation
    
    [ Upstream commit 22b89ba178dd0a66a26699ead014a3e73ff8e044 ]
    
    Commit 8813ff49607e ("powerpc/sstep: Check instruction validity
    against ISA version before emulation") introduced a proper way to skip
    unknown instructions. This makes sure that the same is used for the
    darn instruction when the range selection bits have a reserved value.
    
    Fixes: a23987ef267a ("powerpc: sstep: Add support for darn instruction")
    Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20210204080744.135785-2-sandipan@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8a335142f1c58467d0244ce51e4199200fa6da8a
Author: Sandipan Das <sandipan@linux.ibm.com>
Date:   Thu Feb 4 13:37:43 2021 +0530

    powerpc/sstep: Fix load-store and update emulation
    
    [ Upstream commit bbda4b6c7d7c7f79da71f95c92a5d76be22c3efd ]
    
    The Power ISA says that the fixed-point load and update instructions
    must neither use R0 for the base address (RA) nor have the
    destination (RT) and the base address (RA) as the same register.
    Similarly, for fixed-point stores and floating-point loads and stores,
    the instruction is invalid when R0 is used as the base address (RA).
    
    This is applicable to the following instructions.
      * Load Byte and Zero with Update (lbzu)
      * Load Byte and Zero with Update Indexed (lbzux)
      * Load Halfword and Zero with Update (lhzu)
      * Load Halfword and Zero with Update Indexed (lhzux)
      * Load Halfword Algebraic with Update (lhau)
      * Load Halfword Algebraic with Update Indexed (lhaux)
      * Load Word and Zero with Update (lwzu)
      * Load Word and Zero with Update Indexed (lwzux)
      * Load Word Algebraic with Update Indexed (lwaux)
      * Load Doubleword with Update (ldu)
      * Load Doubleword with Update Indexed (ldux)
      * Load Floating Single with Update (lfsu)
      * Load Floating Single with Update Indexed (lfsux)
      * Load Floating Double with Update (lfdu)
      * Load Floating Double with Update Indexed (lfdux)
      * Store Byte with Update (stbu)
      * Store Byte with Update Indexed (stbux)
      * Store Halfword with Update (sthu)
      * Store Halfword with Update Indexed (sthux)
      * Store Word with Update (stwu)
      * Store Word with Update Indexed (stwux)
      * Store Doubleword with Update (stdu)
      * Store Doubleword with Update Indexed (stdux)
      * Store Floating Single with Update (stfsu)
      * Store Floating Single with Update Indexed (stfsux)
      * Store Floating Double with Update (stfdu)
      * Store Floating Double with Update Indexed (stfdux)
    
    E.g. the following behaviour is observed for an invalid load and
    update instruction having RA = RT.
    
    While a userspace program having an instruction word like 0xe9ce0001,
    i.e. ldu r14, 0(r14), runs without getting receiving a SIGILL on a
    Power system (observed on P8 and P9), the outcome of executing that
    instruction word varies and its behaviour can be considered to be
    undefined.
    
    Attaching an uprobe at that instruction's address results in emulation
    which currently performs the load as well as writes the effective
    address back to the base register. This might not match the outcome
    from hardware.
    
    To remove any inconsistencies, this adds additional checks for the
    aforementioned instructions to make sure that the emulation
    infrastructure treats them as unknown. The kernel can then fallback to
    executing such instructions on hardware.
    
    Fixes: 0016a4cf5582 ("powerpc: Emulate most Book I instructions in emulate_step()")
    Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
    Reviewed-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20210204080744.135785-1-sandipan@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8b4a797e86a0fad5dcdd1c4ae71cd9bafbfa7295
Author: Mark Bloch <mbloch@nvidia.com>
Date:   Mon Jan 25 14:07:09 2021 +0200

    RDMA/mlx5: Allow creating all QPs even when non RDMA profile is used
    
    [ Upstream commit 2614488d1f3cd5989375042286b11424208e20c8 ]
    
    The cited commit disallowed creating any QP which isn't raw ethernet, reg
    umr or the special UD qp for testing WC, this proved too strict.
    
    While modify can't be done (no GIDS/GID table for example) just creating a
    QP is okay.
    
    This patch partially reverts the bellow mentioned commit and places the
    restriction at the modify QP stage and not at the creation.  DEVX commands
    should be used to manipulate such QPs.
    
    Fixes: 42caf9cb5937 ("RDMA/mlx5: Allow only raw Ethernet QPs when RoCE isn't enabled")
    Link: https://lore.kernel.org/r/20210125120709.836718-1-leon@kernel.org
    Signed-off-by: Mark Bloch <mbloch@nvidia.com>
    Reviewed-by: Maor Gottlieb <maorg@mellanox.com>
    Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bb38c1c0338415f6916eb929c4ca8e514eeaa355
Author: Ahmed S. Darwish <a.darwish@linutronix.de>
Date:   Mon Jan 18 11:09:43 2021 +0100

    scsi: isci: Pass gfp_t flags in isci_port_bc_change_received()
    
    [ Upstream commit 71dca5539fcf977aead0c9ea1962e70e78484b8e ]
    
    Use the new libsas event notifiers API, which requires callers to
    explicitly pass the gfp_t memory allocation flags.
    
    libsas sas_notify_port_event() is called from
    isci_port_bc_change_received(). Below is the context analysis for all of
    its call chains:
    
    host.c: sci_controller_error_handler(): atomic, irq handler     (*)
    OR host.c: sci_controller_completion_handler(), atomic, tasklet (*)
      -> sci_controller_process_completions()
        -> sci_controller_event_completion()
          -> phy.c: sci_phy_event_handler()
            -> port.c: sci_port_broadcast_change_received()
              -> isci_port_bc_change_received()
    
    host.c: isci_host_init()                                        (@)
    spin_lock_irq(isci_host::scic_lock)
      -> sci_controller_initialize(), atomic                        (*)
        -> port_config.c: sci_port_configuration_agent_initialize()
          -> sci_mpc_agent_validate_phy_configuration()
            -> port.c: sci_port_add_phy()
              -> sci_port_set_phy()
                -> phy.c: sci_phy_set_port()
                  -> port.c: sci_port_broadcast_change_received()
                    -> isci_port_bc_change_received()
    
    port_config.c: apc_agent_timeout(), atomic, timer callback      (*)
      -> sci_apc_agent_configure_ports()
        -> port.c: sci_port_add_phy()
          -> sci_port_set_phy()
            -> phy.c: sci_phy_set_port()
              -> port.c: sci_port_broadcast_change_received()
                -> isci_port_bc_change_received()
    
    phy.c: enter SCI state: *SCI_PHY_STOPPED*                       # Cont. from [1]
      -> sci_phy_stopped_state_enter()
        -> host.c: sci_controller_link_down()
          -> ->link_down_handler()
          == port_config.c: sci_apc_agent_link_down()
            -> port.c: sci_port_remove_phy()
              -> sci_port_clear_phy()
                -> phy.c: sci_phy_set_port()
                  -> port.c: sci_port_broadcast_change_received()
                    -> isci_port_bc_change_received()
    
    phy.c: enter SCI state: *SCI_PHY_STARTING*                      # Cont. from [2]
      -> sci_phy_starting_state_enter()
        -> host.c: sci_controller_link_down()
          -> ->link_down_handler()
          == port_config.c: sci_apc_agent_link_down()
            -> port.c: sci_port_remove_phy()
              -> sci_port_clear_phy()
                -> phy.c: sci_phy_set_port()
                  -> port.c: sci_port_broadcast_change_received()
                    -> isci_port_bc_change_received()
    
    [1] Call chains for entering state: *SCI_PHY_STOPPED*
    -----------------------------------------------------
    
    host.c: isci_host_init()                                        (@)
    spin_lock_irq(isci_host::scic_lock)
      -> sci_controller_initialize(), atomic                        (*)
          -> phy.c: sci_phy_initialize()
            -> phy.c: sci_phy_link_layer_initialization()
              -> phy.c: sci_change_state(SCI_PHY_STOPPED)
    
    init.c: PCI ->remove() || PM_OPS ->suspend,  process context    (+)
      -> host.c: isci_host_deinit()
        -> sci_controller_stop_phys()
          -> phy.c: sci_phy_stop()
            -> sci_change_state(SCI_PHY_STOPPED)
    
    phy.c: isci_phy_control()
    spin_lock_irqsave(isci_host::scic_lock, )
      -> sci_phy_stop(), atomic                                     (*)
        -> sci_change_state(SCI_PHY_STOPPED)
    
    [2] Call chains for entering state: *SCI_PHY_STARTING*
    ------------------------------------------------------
    
    phy.c: phy_sata_timeout(), atimer, timer callback               (*)
    spin_lock_irqsave(isci_host::scic_lock, )
      -> sci_change_state(SCI_PHY_STARTING)
    
    host.c: phy_startup_timeout(), atomic, timer callback           (*)
    spin_lock_irqsave(isci_host::scic_lock, )
      -> sci_controller_start_next_phy()
        -> sci_phy_start()
          -> sci_change_state(SCI_PHY_STARTING)
    
    host.c: isci_host_start()                                       (@)
    spin_lock_irq(isci_host::scic_lock)
      -> sci_controller_start(), atomic                             (*)
        -> sci_controller_start_next_phy()
          -> sci_phy_start()
            -> sci_change_state(SCI_PHY_STARTING)
    
    phy.c: Enter SCI state *SCI_PHY_SUB_FINAL*                      # Cont. from [2A]
      -> sci_change_state(SCI_PHY_SUB_FINAL)
        -> sci_phy_starting_final_substate_enter()
          -> sci_change_state(SCI_PHY_READY)
            -> Enter SCI state: *SCI_PHY_READY*
              -> sci_phy_ready_state_enter()
                -> host.c: sci_controller_link_up()
                  -> sci_controller_start_next_phy()
                    -> sci_phy_start()
                      -> sci_change_state(SCI_PHY_STARTING)
    
    phy.c: sci_phy_event_handler(), atomic, discussed earlier       (*)
      -> sci_change_state(SCI_PHY_STARTING), 11 instances
    
    port.c: isci_port_perform_hard_reset()
    spin_lock_irqsave(isci_host::scic_lock, )
      -> port.c: sci_port_hard_reset(), atomic                      (*)
        -> phy.c: sci_phy_reset()
          -> sci_change_state(SCI_PHY_RESETTING)
            -> enter SCI PHY state: *SCI_PHY_RESETTING*
              -> sci_phy_resetting_state_enter()
                -> sci_change_state(SCI_PHY_STARTING)
    
    [2A] Call chains for entering SCI state: *SCI_PHY_SUB_FINAL*
    ------------------------------------------------------------
    
    host.c: power_control_timeout(), atomic, timer callback         (*)
    spin_lock_irqsave(isci_host::scic_lock, )
      -> phy.c: sci_phy_consume_power_handler()
        -> phy.c: sci_change_state(SCI_PHY_SUB_FINAL)
    
    host.c: sci_controller_error_handler(): atomic, irq handler     (*)
    OR host.c: sci_controller_completion_handler(), atomic, tasklet (*)
      -> sci_controller_process_completions()
        -> sci_controller_unsolicited_frame()
          -> phy.c: sci_phy_frame_handler()
            -> sci_change_state(SCI_PHY_SUB_AWAIT_SAS_POWER)
              -> sci_phy_starting_await_sas_power_substate_enter()
                -> host.c: sci_controller_power_control_queue_insert()
                  -> phy.c: sci_phy_consume_power_handler()
                    -> sci_change_state(SCI_PHY_SUB_FINAL)
            -> sci_change_state(SCI_PHY_SUB_FINAL)
        -> sci_controller_event_completion()
          -> phy.c: sci_phy_event_handler()
            -> sci_phy_start_sata_link_training()
              -> sci_change_state(SCI_PHY_SUB_AWAIT_SATA_POWER)
                -> sci_phy_starting_await_sata_power_substate_enter
                  -> host.c: sci_controller_power_control_queue_insert()
                    -> phy.c: sci_phy_consume_power_handler()
                      -> sci_change_state(SCI_PHY_SUB_FINAL)
    
    As can be seen from the "(*)" markers above, almost all the call-chains are
    atomic. The only exception, marked with "(+)", is a PCI ->remove() and
    PM_OPS ->suspend() cold path. Thus, pass GFP_ATOMIC to the libsas port
    event notifier.
    
    Note, the now-replaced libsas APIs used in_interrupt() to implicitly decide
    which memory allocation type to use.  This was only partially correct, as
    it fails to choose the correct GFP flags when just preemption or interrupts
    are disabled. Such buggy code paths are marked with "(@)" in the call
    chains above.
    
    Link: https://lore.kernel.org/r/20210118100955.1761652-8-a.darwish@linutronix.de
    Fixes: 1c393b970e0f ("scsi: libsas: Use dynamic alloced work to avoid sas event lost")
    Cc: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
    Reviewed-by: John Garry <john.garry@huawei.com>
    Signed-off-by: Ahmed S. Darwish <a.darwish@linutronix.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d74238028a11f9404c25c6a20e005e92095010b9
Author: Ahmed S. Darwish <a.darwish@linutronix.de>
Date:   Mon Jan 18 11:09:42 2021 +0100

    scsi: isci: Pass gfp_t flags in isci_port_link_up()
    
    [ Upstream commit 5ce7902902adb8d154d67ba494f06daa29360ef0 ]
    
    Use the new libsas event notifiers API, which requires callers to
    explicitly pass the gfp_t memory allocation flags.
    
    libsas sas_notify_port_event() is called from isci_port_link_up().  Below
    is the context analysis for all of its call chains:
    
    host.c: isci_host_init()                                        (@)
    spin_lock_irq(isci_host::scic_lock)
      -> sci_controller_initialize(), atomic                        (*)
        -> port_config.c: sci_port_configuration_agent_initialize()
          -> sci_mpc_agent_validate_phy_configuration()
            -> port.c: sci_port_add_phy()
              -> sci_port_general_link_up_handler()
                -> sci_port_activate_phy()
                  -> isci_port_link_up()
    
    port_config.c: apc_agent_timeout(), atomic, timer callback      (*)
      -> sci_apc_agent_configure_ports()
        -> port.c: sci_port_add_phy()
          -> sci_port_general_link_up_handler()
            -> sci_port_activate_phy()
              -> isci_port_link_up()
    
    phy.c: enter SCI state: *SCI_PHY_SUB_FINAL*                     # Cont. from [1]
      -> phy.c: sci_phy_starting_final_substate_enter()
        -> phy.c: sci_change_state(SCI_PHY_READY)
          -> enter SCI state: *SCI_PHY_READY*
            -> phy.c: sci_phy_ready_state_enter()
              -> host.c: sci_controller_link_up()
                -> .link_up_handler()
                == port_config.c: sci_apc_agent_link_up()
                  -> port.c: sci_port_link_up()
                    -> (continue at [A])
                == port_config.c: sci_mpc_agent_link_up()
                  -> port.c: sci_port_link_up()
                    -> (continue at [A])
    
    port_config.c: mpc_agent_timeout(), atomic, timer callback      (*)
    spin_lock_irqsave(isci_host::scic_lock, )
      -> ->link_up_handler()
      == port_config.c: sci_apc_agent_link_up()
        -> port.c: sci_port_link_up()
          -> (continue at [A])
      == port_config.c: sci_mpc_agent_link_up()
        -> port.c: sci_port_link_up()
          -> (continue at [A])
    
    [A] port.c: sci_port_link_up()
      -> sci_port_activate_phy()
        -> isci_port_link_up()
      -> sci_port_general_link_up_handler()
        -> sci_port_activate_phy()
          -> isci_port_link_up()
    
    [1] Call chains for entering SCI state: *SCI_PHY_SUB_FINAL*
    -----------------------------------------------------------
    
    host.c: power_control_timeout(), atomic, timer callback         (*)
    spin_lock_irqsave(isci_host::scic_lock, )
      -> phy.c: sci_phy_consume_power_handler()
        -> phy.c: sci_change_state(SCI_PHY_SUB_FINAL)
    
    host.c: sci_controller_error_handler(): atomic, irq handler     (*)
    OR host.c: sci_controller_completion_handler(), atomic, tasklet (*)
      -> sci_controller_process_completions()
        -> sci_controller_unsolicited_frame()
          -> phy.c: sci_phy_frame_handler()
            -> sci_change_state(SCI_PHY_SUB_AWAIT_SAS_POWER)
              -> sci_phy_starting_await_sas_power_substate_enter()
                -> host.c: sci_controller_power_control_queue_insert()
                  -> phy.c: sci_phy_consume_power_handler()
                    -> sci_change_state(SCI_PHY_SUB_FINAL)
            -> sci_change_state(SCI_PHY_SUB_FINAL)
        -> sci_controller_event_completion()
          -> phy.c: sci_phy_event_handler()
            -> sci_phy_start_sata_link_training()
              -> sci_change_state(SCI_PHY_SUB_AWAIT_SATA_POWER)
                -> sci_phy_starting_await_sata_power_substate_enter
                  -> host.c: sci_controller_power_control_queue_insert()
                    -> phy.c: sci_phy_consume_power_handler()
                      -> sci_change_state(SCI_PHY_SUB_FINAL)
    
    As can be seen from the "(*)" markers above, all the call-chains are
    atomic.  Pass GFP_ATOMIC to libsas port event notifier.
    
    Note, the now-replaced libsas APIs used in_interrupt() to implicitly decide
    which memory allocation type to use.  This was only partially correct, as
    it fails to choose the correct GFP flags when just preemption or interrupts
    are disabled. Such buggy code paths are marked with "(@)" in the call
    chains above.
    
    Link: https://lore.kernel.org/r/20210118100955.1761652-7-a.darwish@linutronix.de
    Fixes: 1c393b970e0f ("scsi: libsas: Use dynamic alloced work to avoid sas event lost")
    Cc: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
    Reviewed-by: John Garry <john.garry@huawei.com>
    Signed-off-by: Ahmed S. Darwish <a.darwish@linutronix.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d9f5efd1afc4c3178b6cefc9d3d612386c60996d
Author: Ahmed S. Darwish <a.darwish@linutronix.de>
Date:   Mon Jan 18 11:09:41 2021 +0100

    scsi: isci: Pass gfp_t flags in isci_port_link_down()
    
    [ Upstream commit 885ab3b8926fdf9cdd7163dfad99deb9b0662b39 ]
    
    Use the new libsas event notifiers API, which requires callers to
    explicitly pass the gfp_t memory allocation flags.
    
    sas_notify_phy_event() is exclusively called by isci_port_link_down().
    Below is the context analysis for all of its call chains:
    
    port.c: port_timeout(), atomic, timer callback                  (*)
    spin_lock_irqsave(isci_host::scic_lock, )
      -> port_state_machine_change(..., SCI_PORT_FAILED)
        -> enter SCI port state: *SCI_PORT_FAILED*
          -> sci_port_failed_state_enter()
            -> isci_port_hard_reset_complete()
              -> isci_port_link_down()
    
    port.c: isci_port_perform_hard_reset()
    spin_lock_irqsave(isci_host::scic_lock, )
      -> port.c: sci_port_hard_reset(), atomic                      (*)
        -> phy.c: sci_phy_reset()
          -> sci_change_state(SCI_PHY_RESETTING)
            -> enter SCI PHY state: *SCI_PHY_RESETTING*
              -> sci_phy_resetting_state_enter()
                -> port.c: sci_port_deactivate_phy()
                  -> isci_port_link_down()
    
    port.c: enter SCI port state: *SCI_PORT_READY*                  # Cont. from [1]
      -> sci_port_ready_state_enter()
        -> isci_port_hard_reset_complete()
          -> isci_port_link_down()
    
    phy.c: enter SCI state: *SCI_PHY_STOPPED*                       # Cont. from [2]
      -> sci_phy_stopped_state_enter()
        -> host.c: sci_controller_link_down()
          -> ->link_down_handler()
          == port_config.c: sci_apc_agent_link_down()
            -> port.c: sci_port_remove_phy()
              -> sci_port_deactivate_phy()
                -> isci_port_link_down()
          == port_config.c: sci_mpc_agent_link_down()
            -> port.c: sci_port_link_down()
              -> sci_port_deactivate_phy()
                -> isci_port_link_down()
    
    phy.c: enter SCI state: *SCI_PHY_STARTING*                      # Cont. from [3]
      -> sci_phy_starting_state_enter()
        -> host.c: sci_controller_link_down()
          -> ->link_down_handler()
          == port_config.c: sci_apc_agent_link_down()
            -> port.c: sci_port_remove_phy()
              -> isci_port_link_down()
          == port_config.c: sci_mpc_agent_link_down()
            -> port.c: sci_port_link_down()
              -> sci_port_deactivate_phy()
                -> isci_port_link_down()
    
    [1] Call chains for 'enter SCI port state: *SCI_PORT_READY*'
    ------------------------------------------------------------
    
    host.c: isci_host_init()                                        (@)
    spin_lock_irq(isci_host::scic_lock)
      -> sci_controller_initialize(), atomic                        (*)
        -> port_config.c: sci_port_configuration_agent_initialize()
          -> sci_mpc_agent_validate_phy_configuration()
            -> port.c: sci_port_add_phy()
              -> sci_port_general_link_up_handler()
                -> port_state_machine_change(, SCI_PORT_READY)
                  -> enter port state *SCI_PORT_READY*
    
    host.c: isci_host_start()                                       (@)
    spin_lock_irq(isci_host::scic_lock)
      -> host.c: sci_controller_start(), atomic                     (*)
        -> host.c: sci_port_start()
          -> port.c: port_state_machine_change(, SCI_PORT_READY)
            -> enter port state *SCI_PORT_READY*
    
    port_config.c: apc_agent_timeout(), atomic, timer callback      (*)
      -> sci_apc_agent_configure_ports()
        -> port.c: sci_port_add_phy()
          -> sci_port_general_link_up_handler()
            -> port_state_machine_change(, SCI_PORT_READY)
              -> enter port state *SCI_PORT_READY*
    
    port_config.c: mpc_agent_timeout(), atomic, timer callback      (*)
    spin_lock_irqsave(isci_host::scic_lock, )
      -> ->link_up_handler()
      == port.c: sci_apc_agent_link_up()
        -> sci_port_general_link_up_handler()
          -> port_state_machine_change(, SCI_PORT_READY)
            -> enter port state *SCI_PORT_READY*
      == port.c: sci_mpc_agent_link_up()
        -> port.c: sci_port_link_up()
          -> sci_port_general_link_up_handler()
            -> port_state_machine_change(, SCI_PORT_READY)
              -> enter port state *SCI_PORT_READY*
    
    phy.c: enter SCI state: SCI_PHY_SUB_FINAL                       # Cont. from [1A]
      -> sci_phy_starting_final_substate_enter()
        -> sci_change_state(SCI_PHY_READY)
          -> enter SCI state: *SCI_PHY_READY*
            -> sci_phy_ready_state_enter()
              -> host.c: sci_controller_link_up()
                -> port_agent.link_up_handler()
                == port_config.c: sci_apc_agent_link_up()
                  -> port.c: sci_port_link_up()
                    -> sci_port_general_link_up_handler()
                      -> port_state_machine_change(, SCI_PORT_READY)
                        -> enter port state *SCI_PORT_READY*
                == port_config.c: sci_mpc_agent_link_up()
                  -> port.c: sci_port_link_up()
                    -> sci_port_general_link_up_handler()
                      -> port_state_machine_change(, SCI_PORT_READY)
                        -> enter port state *SCI_PORT_READY*
    
    [1A] Call chains for entering SCI state: *SCI_PHY_SUB_FINAL*
    ------------------------------------------------------------
    
    host.c: power_control_timeout(), atomic, timer callback         (*)
    spin_lock_irqsave(isci_host::scic_lock, )
      -> phy.c: sci_phy_consume_power_handler()
        -> phy.c: sci_change_state(SCI_PHY_SUB_FINAL)
    
    host.c: sci_controller_error_handler(): atomic, irq handler     (*)
    OR host.c: sci_controller_completion_handler(), atomic, tasklet (*)
      -> sci_controller_process_completions()
        -> sci_controller_unsolicited_frame()
          -> phy.c: sci_phy_frame_handler()
            -> sci_change_state(SCI_PHY_SUB_AWAIT_SAS_POWER)
              -> sci_phy_starting_await_sas_power_substate_enter()
                -> host.c: sci_controller_power_control_queue_insert()
                  -> phy.c: sci_phy_consume_power_handler()
                    -> sci_change_state(SCI_PHY_SUB_FINAL)
            -> sci_change_state(SCI_PHY_SUB_FINAL)
        -> sci_controller_event_completion()
          -> phy.c: sci_phy_event_handler()
            -> sci_phy_start_sata_link_training()
              -> sci_change_state(SCI_PHY_SUB_AWAIT_SATA_POWER)
                -> sci_phy_starting_await_sata_power_substate_enter
                  -> host.c: sci_controller_power_control_queue_insert()
                    -> phy.c: sci_phy_consume_power_handler()
                      -> sci_change_state(SCI_PHY_SUB_FINAL)
    
    [2] Call chains for entering state: *SCI_PHY_STOPPED*
    -----------------------------------------------------
    
    host.c: isci_host_init()                                        (@)
    spin_lock_irq(isci_host::scic_lock)
      -> sci_controller_initialize(), atomic                        (*)
          -> phy.c: sci_phy_initialize()
            -> phy.c: sci_phy_link_layer_initialization()
              -> phy.c: sci_change_state(SCI_PHY_STOPPED)
    
    init.c: PCI ->remove() || PM_OPS ->suspend,  process context    (+)
      -> host.c: isci_host_deinit()
        -> sci_controller_stop_phys()
          -> phy.c: sci_phy_stop()
            -> sci_change_state(SCI_PHY_STOPPED)
    
    phy.c: isci_phy_control()
    spin_lock_irqsave(isci_host::scic_lock, )
      -> sci_phy_stop(), atomic                                     (*)
        -> sci_change_state(SCI_PHY_STOPPED)
    
    [3] Call chains for entering state: *SCI_PHY_STARTING*
    ------------------------------------------------------
    
    phy.c: phy_sata_timeout(), atimer, timer callback               (*)
    spin_lock_irqsave(isci_host::scic_lock, )
      -> sci_change_state(SCI_PHY_STARTING)
    
    host.c: phy_startup_timeout(), atomic, timer callback           (*)
    spin_lock_irqsave(isci_host::scic_lock, )
      -> sci_controller_start_next_phy()
        -> sci_phy_start()
          -> sci_change_state(SCI_PHY_STARTING)
    
    host.c: isci_host_start()                                       (@)
    spin_lock_irq(isci_host::scic_lock)
      -> sci_controller_start(), atomic                             (*)
        -> sci_controller_start_next_phy()
          -> sci_phy_start()
            -> sci_change_state(SCI_PHY_STARTING)
    
    phy.c: Enter SCI state *SCI_PHY_SUB_FINAL*, atomic, check above (*)
      -> sci_change_state(SCI_PHY_SUB_FINAL)
        -> sci_phy_starting_final_substate_enter()
          -> sci_change_state(SCI_PHY_READY)
            -> Enter SCI state: *SCI_PHY_READY*
              -> sci_phy_ready_state_enter()
                -> host.c: sci_controller_link_up()
                  -> sci_controller_start_next_phy()
                    -> sci_phy_start()
                      -> sci_change_state(SCI_PHY_STARTING)
    
    phy.c: sci_phy_event_handler(), atomic, discussed earlier       (*)
      -> sci_change_state(SCI_PHY_STARTING), 11 instances
    
    phy.c: enter SCI state: *SCI_PHY_RESETTING*, atomic, discussed  (*)
      -> sci_phy_resetting_state_enter()
        -> sci_change_state(SCI_PHY_STARTING)
    
    As can be seen from the "(*)" markers above, almost all the call-chains are
    atomic. The only exception, marked with "(+)", is a PCI ->remove() and
    PM_OPS ->suspend() cold path. Thus, pass GFP_ATOMIC to the libsas phy event
    notifier.
    
    Note, The now-replaced libsas APIs used in_interrupt() to implicitly decide
    which memory allocation type to use.  This was only partially correct, as
    it fails to choose the correct GFP flags when just preemption or interrupts
    are disabled. Such buggy code paths are marked with "(@)" in the call
    chains above.
    
    Link: https://lore.kernel.org/r/20210118100955.1761652-6-a.darwish@linutronix.de
    Fixes: 1c393b970e0f ("scsi: libsas: Use dynamic alloced work to avoid sas event lost")
    Cc: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
    Reviewed-by: John Garry <john.garry@huawei.com>
    Signed-off-by: Ahmed S. Darwish <a.darwish@linutronix.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1eda358e37e5f8ad404621f43d34b1357dd0ab49
Author: Ahmed S. Darwish <a.darwish@linutronix.de>
Date:   Mon Jan 18 11:09:40 2021 +0100

    scsi: mvsas: Pass gfp_t flags to libsas event notifiers
    
    [ Upstream commit feb18e900f0048001ff375dca639eaa327ab3c1b ]
    
    mvsas calls the non _gfp version of the libsas event notifiers API, leading
    to the buggy call chains below:
    
      mvsas/mv_sas.c: mvs_work_queue() [process context]
      spin_lock_irqsave(mvs_info::lock, )
        -> libsas/sas_event.c: sas_notify_phy_event()
          -> sas_alloc_event()
            -> in_interrupt() = false
              -> invalid GFP_KERNEL allocation
        -> libsas/sas_event.c: sas_notify_port_event()
          -> sas_alloc_event()
            -> in_interrupt() = false
              -> invalid GFP_KERNEL allocation
    
    Use the new event notifiers API instead, which requires callers to
    explicitly pass the gfp_t memory allocation flags.
    
    Below are context analysis for the modified functions:
    
    => mvs_bytes_dmaed():
    
    Since it is invoked from both process and atomic contexts, let its callers
    pass the gfp_t flags. Call chains:
    
      scsi_scan.c: do_scsi_scan_host() [has msleep()]
        -> shost->hostt->scan_start()
        -> [mvsas/mv_init.c: Scsi_Host::scsi_host_template .scan_start = mvs_scan_start()]
        -> mvsas/mv_sas.c: mvs_scan_start()
          -> mvs_bytes_dmaed(..., GFP_KERNEL)
    
      mvsas/mv_sas.c: mvs_work_queue()
      spin_lock_irqsave(mvs_info::lock,)
        -> mvs_bytes_dmaed(..., GFP_ATOMIC)
    
      mvsas/mv_64xx.c: mvs_64xx_isr() || mvsas/mv_94xx.c: mvs_94xx_isr()
        -> mvsas/mv_chips.h: mvs_int_full()
          -> mvsas/mv_sas.c: mvs_int_port()
            -> mvs_bytes_dmaed(..., GFP_ATOMIC);
    
    => mvs_work_queue():
    
    Invoked from process context, but it calls all the libsas event notifier
    APIs under a spin_lock_irqsave(). Pass GFP_ATOMIC.
    
    Link: https://lore.kernel.org/r/20210118100955.1761652-5-a.darwish@linutronix.de
    Fixes: 1c393b970e0f ("scsi: libsas: Use dynamic alloced work to avoid sas event lost")
    Cc: Jason Yan <yanaijie@huawei.com>
    Reviewed-by: John Garry <john.garry@huawei.com>
    Signed-off-by: Ahmed S. Darwish <a.darwish@linutronix.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 58bdc321beb5f9094d8386ea1df6ea0de81c94af
Author: Ahmed S. Darwish <a.darwish@linutronix.de>
Date:   Mon Jan 18 11:09:39 2021 +0100

    scsi: libsas: Introduce a _gfp() variant of event notifiers
    
    [ Upstream commit c2d0f1a65ab9fbabebb463bf36f50ea8f4633386 ]
    
    sas_alloc_event() uses in_interrupt() to decide which allocation should be
    used.
    
    The usage of in_interrupt() in drivers is phased out and Linus clearly
    requested that code which changes behaviour depending on context should
    either be separated or the context be conveyed in an argument passed by the
    caller, which usually knows the context.
    
    The in_interrupt() check is also only partially correct, because it fails
    to choose the correct code path when just preemption or interrupts are
    disabled. For example, as in the following call chain:
    
      mvsas/mv_sas.c: mvs_work_queue() [process context]
      spin_lock_irqsave(mvs_info::lock, )
        -> libsas/sas_event.c: sas_notify_phy_event()
          -> sas_alloc_event()
            -> in_interrupt() = false
              -> invalid GFP_KERNEL allocation
        -> libsas/sas_event.c: sas_notify_port_event()
          -> sas_alloc_event()
            -> in_interrupt() = false
              -> invalid GFP_KERNEL allocation
    
    Introduce sas_alloc_event_gfp(), sas_notify_port_event_gfp(), and
    sas_notify_phy_event_gfp(), which all behave like the non _gfp() variants
    but use a caller-passed GFP mask for allocations.
    
    For bisectability, all callers will be modified first to pass GFP context,
    then the non _gfp() libsas API variants will be modified to take a gfp_t by
    default.
    
    Link: https://lore.kernel.org/r/20210118100955.1761652-4-a.darwish@linutronix.de
    Fixes: 1c393b970e0f ("scsi: libsas: Use dynamic alloced work to avoid sas event lost")
    Cc: Jason Yan <yanaijie@huawei.com>
    Reviewed-by: John Garry <john.garry@huawei.com>
    Signed-off-by: Ahmed S. Darwish <a.darwish@linutronix.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 18c3c04e8e53ee6008375cec1fb006a19f991746
Author: John Garry <john.garry@huawei.com>
Date:   Mon Jan 18 11:09:38 2021 +0100

    scsi: libsas: Remove notifier indirection
    
    [ Upstream commit 121181f3f839c29d8dd9fdc3cc9babbdc74227f8 ]
    
    LLDDs report events to libsas with .notify_port_event and .notify_phy_event
    callbacks.
    
    These callbacks are fixed and so there is no reason why the functions
    cannot be called directly, so do that.
    
    This neatens the code slightly, makes it more obvious, and reduces function
    pointer usage, which is generally a good thing. Downside is that there are
    2x more symbol exports.
    
    [a.darwish@linutronix.de: Remove the now unused "sas_ha" local variables]
    
    Link: https://lore.kernel.org/r/20210118100955.1761652-3-a.darwish@linutronix.de
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Jack Wang <jinpu.wang@cloud.ionos.com>
    Signed-off-by: John Garry <john.garry@huawei.com>
    Signed-off-by: Ahmed S. Darwish <a.darwish@linutronix.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 29c5b80327b72c08f50e62429a9ff13df2b0e7c3
Author: Joe Perches <joe@perches.com>
Date:   Fri Nov 20 15:16:09 2020 -0800

    scsi: pm8001: Neaten debug logging macros and uses
    
    [ Upstream commit 1b5d2793283dcb97b401b3b2c02b8a94eee29af1 ]
    
    Every PM8001_<FOO>_DBG macro uses an internal call to pm8001_printk.
    
    Convert all uses of:
    
            PM8001_<FOO>_DBG(hba, pm8001_printk(fmt, ...))
    to
            pm8001_dbg(hba, <FOO>, fmt, ...)
    
    so the visual complexity of each macro is reduced.
    
    The repetitive macro definitions are converted to a single pm8001_dbg and
    the level is concatenated using PM8001_##level##_LOGGING for the specific
    level test.
    
    Done with coccinelle, checkpatch and a little typing of the new macro
    definition.
    
    Miscellanea:
    
     - Coalesce formats
    
     - Realign arguments
    
     - Add missing terminating newlines to formats
    
     - Remove trailing spaces from formats
    
     - Change defective loop with printk(KERN_INFO... to emit a 16 byte hex
       block to %p16h
    
    Link: https://lore.kernel.org/r/49f36a93af7752b613d03c89a87078243567fd9a.1605914030.git.joe@perches.com
    Reported-by: kernel test robot <lkp@intel.com>
    Acked-by: Jack Wang <jinpu.wang@cloud.ionos.com>
    Signed-off-by: Joe Perches <joe@perches.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c4186c00adc1e951cfe6d2ff40f2119afe8386c6
Author: yuuzheng <yuuzheng@google.com>
Date:   Mon Nov 2 22:25:28 2020 +0530

    scsi: pm80xx: Fix pm8001_mpi_get_nvmd_resp() race condition
    
    [ Upstream commit 1f889b58716a5f5e3e4fe0e6742c1a4472f29ac1 ]
    
    A use-after-free or null-pointer error occurs when the 251-byte response
    data is copied from IOMB buffer to response message buffer in function
    pm8001_mpi_get_nvmd_resp().
    
    After sending the command get_nvmd_data(), the caller begins to sleep by
    calling wait_for_complete() and waits for the wake-up from calling
    complete() in pm8001_mpi_get_nvmd_resp(). Due to unexpected events (e.g.,
    interrupt), if response buffer gets freed before memcpy(), a use-after-free
    error will occur. To fix this, the complete() should be called after
    memcpy().
    
    Link: https://lore.kernel.org/r/20201102165528.26510-5-Viswas.G@microchip.com.com
    Acked-by: Jack Wang <jinpu.wang@cloud.ionos.com>
    Signed-off-by: yuuzheng <yuuzheng@google.com>
    Signed-off-by: Viswas G <Viswas.G@microchip.com>
    Signed-off-by: Ruksar Devadi <Ruksar.devadi@microchip.com>
    Signed-off-by: Radha Ramachandran <radha@google.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3e4b3770744d93623af61be88856ff57b4dea26b
Author: Viswas G <Viswas.G@microchip.com>
Date:   Mon Nov 2 22:25:26 2020 +0530

    scsi: pm80xx: Make running_req atomic
    
    [ Upstream commit 4a2efd4b89fcaa6e9a7b4ce49a441afaacba00ea ]
    
    Incorrect value of the running_req was causing the driver unload to be
    stuck during the SAS lldd_dev_gone notification handling.  During SATA I/O
    completion, for some error status values, the driver schedules the event
    handler and running_req is decremented from that.  However, there are some
    other error status values (like IO_DS_IN_RECOVERY,
    IO_XFER_ERR_LAST_PIO_DATAIN_CRC_ERR) where the I/O has already been
    completed by fw/driver so running_req is not decremented.
    
    Also during NCQ error handling, driver itself will initiate READ_LOG_EXT
    and ABORT_ALL. When libsas/libata initiate READ_LOG_EXT (0x2F), driver
    increments running_req. This will be completed by the driver in
    pm80xx_chip_sata_req(), but running_req was not decremented.
    
    Link: https://lore.kernel.org/r/20201102165528.26510-3-Viswas.G@microchip.com.com
    Acked-by: Jack Wang <jinpu.wang@cloud.ionos.com>
    Signed-off-by: Viswas G <Viswas.G@microchip.com>
    Signed-off-by: Ruksar Devadi <Ruksar.devadi@microchip.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6075c84a98ce517bd18c2c780cc962d2010b066e
Author: peter chang <dpf@google.com>
Date:   Mon Nov 2 22:25:25 2020 +0530

    scsi: pm80xx: Make mpi_build_cmd locking consistent
    
    [ Upstream commit 7640e1eb8c5de33dafa6c68fd4389214ff9ec1f9 ]
    
    Driver submits all internal requests (like abort_task, event acknowledgment
    etc.) through inbound queue 0. While submitting those, driver does not
    acquire any lock and this may lead to a race when there is an I/O request
    coming in on CPU0 and submitted through inbound queue 0.  To avoid this,
    lock acquisition has been moved to pm8001_mpi_build_cmd().  All command
    submission will go through this path.
    
    Link: https://lore.kernel.org/r/20201102165528.26510-2-Viswas.G@microchip.com.com
    Acked-by: Jack Wang <jinpu.wang@cloud.ionos.com>
    Signed-off-by: peter chang <dpf@google.com>
    Signed-off-by: Viswas G <Viswas.G@microchip.com>
    Signed-off-by: Ruksar Devadi <Ruksar.devadi@microchip.com>
    Signed-off-by: Radha Ramachandran <radha@google.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d802672c7f00963613f289579073ac519f0d306c
Author: Frank van der Linden <fllinden@amazon.com>
Date:   Thu Jan 14 22:21:46 2021 +0000

    module: harden ELF info handling
    
    [ Upstream commit ec2a29593c83ed71a7f16e3243941ebfcf75fdf6 ]
    
    5fdc7db644 ("module: setup load info before module_sig_check()")
    moved the ELF setup, so that it was done before the signature
    check. This made the module name available to signature error
    messages.
    
    However, the checks for ELF correctness in setup_load_info
    are not sufficient to prevent bad memory references due to
    corrupted offset fields, indices, etc.
    
    So, there's a regression in behavior here: a corrupt and unsigned
    (or badly signed) module, which might previously have been rejected
    immediately, can now cause an oops/crash.
    
    Harden ELF handling for module loading by doing the following:
    
    - Move the signature check back up so that it comes before ELF
      initialization. It's best to do the signature check to see
      if we can trust the module, before using the ELF structures
      inside it. This also makes checks against info->len
      more accurate again, as this field will be reduced by the
      length of the signature in mod_check_sig().
    
      The module name is now once again not available for error
      messages during the signature check, but that seems like
      a fair tradeoff.
    
    - Check if sections have offset / size fields that at least don't
      exceed the length of the module.
    
    - Check if sections have section name offsets that don't fall
      outside the section name table.
    
    - Add a few other sanity checks against invalid section indices,
      etc.
    
    This is not an exhaustive consistency check, but the idea is to
    at least get through the signature and blacklist checks without
    crashing because of corrupted ELF info, and to error out gracefully
    for most issues that would have caused problems later on.
    
    Fixes: 5fdc7db6448a ("module: setup load info before module_sig_check()")
    Signed-off-by: Frank van der Linden <fllinden@amazon.com>
    Signed-off-by: Jessica Yu <jeyu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e2c8978a75e0e13a911b7c9d6e2b3a490f1f24d8
Author: Sergey Shtylyov <s.shtylyov@omprussia.ru>
Date:   Sat Oct 31 23:09:31 2020 +0300

    module: avoid *goto*s in module_sig_check()
    
    [ Upstream commit 10ccd1abb808599a6dc7c9389560016ea3568085 ]
    
    Let's move the common handling of the non-fatal errors after the *switch*
    statement -- this avoids *goto*s inside that *switch*...
    
    Suggested-by: Joe Perches <joe@perches.com>
    Reviewed-by: Miroslav Benes <mbenes@suse.cz>
    Signed-off-by: Sergey Shtylyov <s.shtylyov@omprussia.ru>
    Signed-off-by: Jessica Yu <jeyu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8587715b65faae25b07db16d07d09b5831f44742
Author: Sergey Shtylyov <s.shtylyov@omprussia.ru>
Date:   Sat Oct 31 23:06:45 2020 +0300

    module: merge repetitive strings in module_sig_check()
    
    [ Upstream commit 705e9195187d85249fbb0eaa844b1604a98fbc9a ]
    
    The 'reason' variable in module_sig_check() points to 3 strings across
    the *switch* statement, all needlessly starting with the same text.
    Let's put the starting text into the pr_notice() call -- it saves 21
    bytes of the object code (x86 gcc 10.2.1).
    
    Suggested-by: Joe Perches <joe@perches.com>
    Reviewed-by: Miroslav Benes <mbenes@suse.cz>
    Signed-off-by: Sergey Shtylyov <s.shtylyov@omprussia.ru>
    Signed-off-by: Jessica Yu <jeyu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c02a33f0fd287f7d146227bb733fc1c7a2ab8909
Author: Jack Wang <jinpu.wang@cloud.ionos.com>
Date:   Thu Dec 17 15:19:15 2020 +0100

    RDMA/rtrs: Fix KASAN: stack-out-of-bounds bug
    
    [ Upstream commit 7fbc3c373eefc291ff96d48496106c106b7f81c6 ]
    
    When KASAN is enabled, we notice warning below:
    [  483.436975] ==================================================================
    [  483.437234] BUG: KASAN: stack-out-of-bounds in _mlx5_ib_post_send+0x188a/0x2560 [mlx5_ib]
    [  483.437430] Read of size 4 at addr ffff88a195fd7d30 by task kworker/1:3/6954
    
    [  483.437731] CPU: 1 PID: 6954 Comm: kworker/1:3 Kdump: loaded Tainted: G           O      5.4.82-pserver #5.4.82-1+feature+linux+5.4.y+dbg+20201210.1532+987e7a6~deb10
    [  483.437976] Hardware name: Supermicro Super Server/X11DDW-L, BIOS 3.3 02/21/2020
    [  483.438168] Workqueue: rtrs_server_wq hb_work [rtrs_core]
    [  483.438323] Call Trace:
    [  483.438486]  dump_stack+0x96/0xe0
    [  483.438646]  ? _mlx5_ib_post_send+0x188a/0x2560 [mlx5_ib]
    [  483.438802]  print_address_description.constprop.6+0x1b/0x220
    [  483.438966]  ? _mlx5_ib_post_send+0x188a/0x2560 [mlx5_ib]
    [  483.439133]  ? _mlx5_ib_post_send+0x188a/0x2560 [mlx5_ib]
    [  483.439285]  __kasan_report.cold.9+0x1a/0x32
    [  483.439444]  ? _mlx5_ib_post_send+0x188a/0x2560 [mlx5_ib]
    [  483.439597]  kasan_report+0x10/0x20
    [  483.439752]  _mlx5_ib_post_send+0x188a/0x2560 [mlx5_ib]
    [  483.439910]  ? update_sd_lb_stats+0xfb1/0xfc0
    [  483.440073]  ? set_reg_wr+0x520/0x520 [mlx5_ib]
    [  483.440222]  ? update_group_capacity+0x340/0x340
    [  483.440377]  ? find_busiest_group+0x314/0x870
    [  483.440526]  ? update_sd_lb_stats+0xfc0/0xfc0
    [  483.440683]  ? __bitmap_and+0x6f/0x100
    [  483.440832]  ? __lock_acquire+0xa2/0x2150
    [  483.440979]  ? __lock_acquire+0xa2/0x2150
    [  483.441128]  ? __lock_acquire+0xa2/0x2150
    [  483.441279]  ? debug_lockdep_rcu_enabled+0x23/0x60
    [  483.441430]  ? lock_downgrade+0x390/0x390
    [  483.441582]  ? __lock_acquire+0xa2/0x2150
    [  483.441729]  ? __lock_acquire+0xa2/0x2150
    [  483.441876]  ? newidle_balance+0x425/0x8f0
    [  483.442024]  ? __lock_acquire+0xa2/0x2150
    [  483.442172]  ? debug_lockdep_rcu_enabled+0x23/0x60
    [  483.442330]  hb_work+0x15d/0x1d0 [rtrs_core]
    [  483.442479]  ? schedule_hb+0x50/0x50 [rtrs_core]
    [  483.442627]  ? lock_downgrade+0x390/0x390
    [  483.442781]  ? process_one_work+0x40d/0xa50
    [  483.442931]  process_one_work+0x4ee/0xa50
    [  483.443082]  ? pwq_dec_nr_in_flight+0x110/0x110
    [  483.443231]  ? do_raw_spin_lock+0x119/0x1d0
    [  483.443383]  worker_thread+0x65/0x5c0
    [  483.443532]  ? process_one_work+0xa50/0xa50
    [  483.451839]  kthread+0x1e2/0x200
    [  483.451983]  ? kthread_create_on_node+0xc0/0xc0
    [  483.452139]  ret_from_fork+0x3a/0x50
    
    The problem is we use wrong type when send wr, hw driver expect the type
    of IB_WR_RDMA_WRITE_WITH_IMM wr should be ib_rdma_wr, and doing
    container_of to access member. The fix is simple use ib_rdma_wr instread
    of ib_send_wr.
    
    Fixes: c0894b3ea69d ("RDMA/rtrs: core: lib functions shared between client and server modules")
    Link: https://lore.kernel.org/r/20201217141915.56989-20-jinpu.wang@cloud.ionos.com
    Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com>
    Reviewed-by: Gioh Kim <gi-oh.kim@cloud.ionos.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 904a52dd9e50c3992696e35d85ea8129bf06c64e
Author: Guoqing Jiang <guoqing.jiang@cloud.ionos.com>
Date:   Fri Oct 23 09:43:52 2020 +0200

    RDMA/rtrs: Introduce rtrs_post_send
    
    [ Upstream commit e6ab8cf50fa1c38652feba3e4921c60538236f30 ]
    
    Since the three functions share the similar logic, let's introduce one
    common function for it.
    
    Link: https://lore.kernel.org/r/20201023074353.21946-12-jinpu.wang@cloud.ionos.com
    Signed-off-by: Guoqing Jiang <guoqing.jiang@cloud.ionos.com>
    Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9e97c211b7010f6170e54df1a80e53f6d7f22f77
Author: Guoqing Jiang <guoqing.jiang@cloud.ionos.com>
Date:   Thu Dec 17 15:19:02 2020 +0100

    RDMA/rtrs-srv: Jump to dereg_mr label if allocate iu fails
    
    [ Upstream commit f77c4839ee8f4612dcb6601602329096030bd813 ]
    
    The rtrs_iu_free is called in rtrs_iu_alloc if memory is limited, so we
    don't need to free the same iu again.
    
    Fixes: 9cb837480424 ("RDMA/rtrs: server: main functionality")
    Link: https://lore.kernel.org/r/20201217141915.56989-7-jinpu.wang@cloud.ionos.com
    Signed-off-by: Guoqing Jiang <guoqing.jiang@cloud.ionos.com>
    Reviewed-by: Gioh Kim <gi-oh.kim@cloud.ionos.com>
    Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5abee8b1fc4fdba11f9268029ef9399fb72952df
Author: Gioh Kim <gi-oh.kim@cloud.ionos.com>
Date:   Fri Oct 23 09:43:48 2020 +0200

    RDMA/rtrs: Remove unnecessary argument dir of rtrs_iu_free
    
    [ Upstream commit 8bd372ace32ec88fe3ad1421929ae1604f2a2c2c ]
    
    The direction of DMA operation is already in the rtrs_iu
    
    Link: https://lore.kernel.org/r/20201023074353.21946-8-jinpu.wang@cloud.ionos.com
    Signed-off-by: Gioh Kim <gi-oh.kim@cloud.ionos.com>
    Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4ebd8f0c82a55e337c09ec351f88e9977eb0b90a
Author: Andrii Nakryiko <andrii@kernel.org>
Date:   Mon Jan 11 23:55:16 2021 -0800

    bpf: Declare __bpf_free_used_maps() unconditionally
    
    [ Upstream commit 936f8946bdb48239f4292812d4d2e26c6d328c95 ]
    
    __bpf_free_used_maps() is always defined in kernel/bpf/core.c, while
    include/linux/bpf.h is guarding it behind CONFIG_BPF_SYSCALL. Move it out of
    that guard region and fix compiler warning.
    
    Fixes: a2ea07465c8d ("bpf: Fix missing prog untrack in release_maps")
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Acked-by: Yonghong Song <yhs@fb.com>
    Link: https://lore.kernel.org/bpf/20210112075520.4103414-4-andrii@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0e44f1e18398efbc726103a0d49abf8c8894dbe4
Author: Erwan Le Ray <erwan.leray@foss.st.com>
Date:   Wed Jan 6 17:21:56 2021 +0100

    serial: stm32: fix DMA initialization error handling
    
    [ Upstream commit e7997f7ff7f8154d477f6f976698d868a2ac3934 ]
    
    DMA initialization error handling is not properly implemented in the
    driver.
    Fix DMA initialization error handling by:
    - moving TX DMA descriptor request error handling in a new dedicated
    fallback_err label
    - adding error handling to TX DMA descriptor submission
    - adding error handling to RX DMA descriptor submission
    
    This patch depends on '24832ca3ee85 ("tty: serial: stm32-usart: Remove set
    but unused 'cookie' variables")' which unfortunately doesn't include a
    "Fixes" tag.
    
    Fixes: 3489187204eb ("serial: stm32: adding dma support")
    Signed-off-by: Erwan Le Ray <erwan.leray@foss.st.com>
    Link: https://lore.kernel.org/r/20210106162203.28854-2-erwan.leray@foss.st.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5f8659adf7a2889acf9d105d579efa6ed4033993
Author: Lee Jones <lee.jones@linaro.org>
Date:   Wed Nov 4 19:35:41 2020 +0000

    tty: serial: stm32-usart: Remove set but unused 'cookie' variables
    
    [ Upstream commit 24832ca3ee85a14c42a4f23a5c8841ef5db3d029 ]
    
    Fixes the following W=1 kernel build warning(s):
    
     drivers/tty/serial/stm32-usart.c: In function ‘stm32_transmit_chars_dma’:
     drivers/tty/serial/stm32-usart.c:353:15: warning: variable ‘cookie’ set but not used [-Wunused-but-set-variable]
     drivers/tty/serial/stm32-usart.c: In function ‘stm32_of_dma_rx_probe’:
     drivers/tty/serial/stm32-usart.c:1090:15: warning: variable ‘cookie’ set but not used [-Wunused-but-set-variable]
    
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Jiri Slaby <jirislaby@kernel.org>
    Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
    Cc: Alexandre Torgue <alexandre.torgue@st.com>
    Cc: Gerald Baeza <gerald.baeza@st.com>
    Cc: linux-serial@vger.kernel.org
    Cc: linux-stm32@st-md-mailman.stormreply.com
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Link: https://lore.kernel.org/r/20201104193549.4026187-29-lee.jones@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 20c0bd2b657931e16e1099ca9aab01f4baebce57
Author: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
Date:   Fri Feb 12 20:42:50 2021 -0800

    ibmvnic: serialize access to work queue on remove
    
    [ Upstream commit 4a41c421f3676fdeea91733cf434dcf319c4c351 ]
    
    The work queue is used to queue reset requests like CHANGE-PARAM or
    FAILOVER resets for the worker thread. When the adapter is being removed
    the adapter state is set to VNIC_REMOVING and the work queue is flushed
    so no new work is added. However the check for adapter being removed is
    racy in that the adapter can go into REMOVING state just after we check
    and we might end up adding work just as it is being flushed (or after).
    
    The ->rwi_lock is already being used to serialize queue/dequeue work.
    Extend its usage ensure there is no race when scheduling/flushing work.
    
    Fixes: 6954a9e4192b ("ibmvnic: Flush existing work items before device removal")
    Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
    Cc:Uwe Kleine-König <uwe@kleine-koenig.org>
    Cc:Saeed Mahameed <saeed@kernel.org>
    Reviewed-by: Dany Madden <drt@linux.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f8ba6913c40af93930d854da75a739f95c8b1fda
Author: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
Date:   Fri Dec 4 18:22:35 2020 -0800

    ibmvnic: add some debugs
    
    [ Upstream commit 38bd5cec76e2282986b1bf2f8e7d2d05ffe68b22 ]
    
    We sometimes run into situations where a soft/hard reset of the adapter
    takes a long time or fails to complete. Having additional messages that
    include important adapter state info will hopefully help understand what
    is happening, reduce the guess work and minimize requests to reproduce
    problems with debug patches.
    
    Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
    Link: https://lore.kernel.org/r/20201205022235.2414110-1-sukadev@linux.ibm.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b4be6e6e26965dce716f59a027f635cb5d480bfd
Author: Sagi Grimberg <sagi@grimberg.me>
Date:   Mon Mar 15 14:04:27 2021 -0700

    nvme-rdma: fix possible hang when failing to set io queues
    
    [ Upstream commit c4c6df5fc84659690d4391d1fba155cd94185295 ]
    
    We only setup io queues for nvme controllers, and it makes absolutely no
    sense to allow a controller (re)connect without any I/O queues.  If we
    happen to fail setting the queue count for any reason, we should not allow
    this to be a successful reconnect as I/O has no chance in going through.
    Instead just fail and schedule another reconnect.
    
    Reported-by: Chao Leng <lengchao@huawei.com>
    Fixes: 711023071960 ("nvme-rdma: add a NVMe over Fabrics RDMA host driver")
    Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
    Reviewed-by: Chao Leng <lengchao@huawei.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b3901ceb120df061133097e46e56fa35d5902446
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Mon Mar 15 20:44:30 2021 +0200

    gpiolib: Assign fwnode to parent's if no primary one provided
    
    [ Upstream commit 6cb59afe9e5b45a035bd6b97da6593743feefc72 ]
    
    In case when the properties are supplied in the secondary fwnode
    (for example, built-in device properties) the fwnode pointer left
    unassigned. This makes unable to retrieve them.
    
    Assign fwnode to parent's if no primary one provided.
    
    Fixes: 7cba1a4d5e16 ("gpiolib: generalize devprop_gpiochip_set_names() for device properties")
    Fixes: 2afa97e9868f ("gpiolib: Read "gpio-line-names" from a firmware node")
    Reported-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
    Tested-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c5fe922eaf1a669741094a07076ed34b44c9b7e7
Author: William Breathitt Gray <vilhelm.gray@gmail.com>
Date:   Fri Feb 26 10:29:31 2021 +0900

    counter: stm32-timer-cnt: Report count function when SLAVE_MODE_DISABLED
    
    [ Upstream commit fae6f62e6a580b663ecf42c2120a0898deae9137 ]
    
    When in SLAVE_MODE_DISABLED mode, the count still increases if the
    counter is enabled because an internal clock is used. This patch fixes
    the stm32_count_function_get() and stm32_count_function_set() functions
    to properly handle this behavior.
    
    Fixes: ad29937e206f ("counter: Add STM32 Timer quadrature encoder")
    Cc: Fabrice Gasnier <fabrice.gasnier@st.com>
    Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
    Cc: Alexandre Torgue <alexandre.torgue@st.com>
    Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
    Reviewed-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
    Link: https://lore.kernel.org/r/20210226012931.161429-1-vilhelm.gray@gmail.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f854abe46b0edd757046908d191888ff919c30ea
Author: Heinrich Schuchardt <xypron.glpk@gmx.de>
Date:   Sat Mar 6 06:48:01 2021 +0100

    RISC-V: correct enum sbi_ext_rfence_fid
    
    commit 6dd4879f59b0a0679ed8c3ebaff3d79f37930778 upstream.
    
    The constants in enum sbi_ext_rfence_fid should match the SBI
    specification. See
    https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc#78-function-listing
    
    | Function Name               | FID | EID
    | sbi_remote_fence_i          |   0 | 0x52464E43
    | sbi_remote_sfence_vma       |   1 | 0x52464E43
    | sbi_remote_sfence_vma_asid  |   2 | 0x52464E43
    | sbi_remote_hfence_gvma_vmid |   3 | 0x52464E43
    | sbi_remote_hfence_gvma      |   4 | 0x52464E43
    | sbi_remote_hfence_vvma_asid |   5 | 0x52464E43
    | sbi_remote_hfence_vvma      |   6 | 0x52464E43
    
    Fixes: ecbacc2a3efd ("RISC-V: Add SBI v0.2 extension definitions")
    Reported-by: Sean Anderson <seanga2@gmail.com>
    Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
    Reviewed-by: Anup Patel <anup@brainfault.org>
    Reviewed-by: Atish Patra <atish.patra@wdc.com>
    Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 359d8ff40a09ff95a6382dc0cb0227d2b70e9b40
Author: dongjian <dongjian@yulong.com>
Date:   Tue Mar 16 20:15:15 2021 +0800

    scsi: ufs: ufs-mediatek: Correct operator & -> &&
    
    commit 0fdc7d5d8f3719950478cca452cf7f0f1355be10 upstream.
    
    The "lpm" and "->enabled" are all boolean. We should be using &&
    rather than the bit operator.
    
    Link: https://lore.kernel.org/r/1615896915-148864-1-git-send-email-dj0227@163.com
    Fixes: 488edafb1120 ("scsi: ufs-mediatek: Introduce low-power mode for device power supply")
    Reviewed-by: Avri Altman <avri.altman@wdc.com>
    Signed-off-by: dongjian <dongjian@yulong.com>
    Signed-off-by: Yue Hu <huyue2@yulong.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 38089ba4b20cca60ca9561b531672a6425c44d46
Author: Lv Yunlong <lyl2019@mail.ustc.edu.cn>
Date:   Wed Mar 10 22:30:05 2021 -0800

    scsi: myrs: Fix a double free in myrs_cleanup()
    
    commit 2bb817712e2f77486d6ee17e7efaf91997a685f8 upstream.
    
    In myrs_cleanup(), cs->mmio_base will be freed twice by iounmap().
    
    Link: https://lore.kernel.org/r/20210311063005.9963-1-lyl2019@mail.ustc.edu.cn
    Fixes: 77266186397c ("scsi: myrs: Add Mylex RAID controller (SCSI interface)")
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Lv Yunlong <lyl2019@mail.ustc.edu.cn>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb9d08b343510b1544fa3a734194594a5960dfdf
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Mar 12 10:42:11 2021 +0300

    scsi: lpfc: Fix some error codes in debugfs
    
    commit 19f1bc7edf0f97186810e13a88f5b62069d89097 upstream.
    
    If copy_from_user() or kstrtoull() fail then the correct behavior is to
    return a negative error code.
    
    Link: https://lore.kernel.org/r/YEsbU/UxYypVrC7/@mwanda
    Fixes: f9bb2da11db8 ("[SCSI] lpfc 8.3.27: T10 additions for SLI4")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e95c0d43509c1118d39ce0094b973f0a57f64d03
Author: Kefeng Wang <wangkefeng.wang@huawei.com>
Date:   Mon Mar 15 20:03:07 2021 +0800

    riscv: Correct SPARSEMEM configuration
    
    commit a5406a7ff56e63376c210b06072aa0ef23473366 upstream.
    
    There are two issues for RV32,
    1) if use FLATMEM, it is useless to enable SPARSEMEM_STATIC.
    2) if use SPARSMEM, both SPARSEMEM_VMEMMAP and SPARSEMEM_STATIC is enabled.
    
    Fixes: d95f1a542c3d ("RISC-V: Implement sparsemem")
    Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 04eb2b2fa12ff6023a92d5199275255e9b82011b
Author: Steve French <stfrench@microsoft.com>
Date:   Fri Mar 19 00:05:48 2021 -0500

    cifs: fix allocation size on newly created files
    
    commit 65af8f0166f4d15e61c63db498ec7981acdd897f upstream.
    
    Applications that create and extend and write to a file do not
    expect to see 0 allocation size.  When file is extended,
    set its allocation size to a plausible value until we have a
    chance to query the server for it.  When the file is cached
    this will prevent showing an impossible number of allocated
    blocks (like 0).  This fixes e.g. xfstests 614 which does
    
        1) create a file and set its size to 64K
        2) mmap write 64K to the file
        3) stat -c %b for the file (to query the number of allocated blocks)
    
    It was failing because we returned 0 blocks.  Even though we would
    return the correct cached file size, we returned an impossible
    allocation size.
    
    Signed-off-by: Steve French <stfrench@microsoft.com>
    CC: <stable@vger.kernel.org>
    Reviewed-by: Aurelien Aptel <aaptel@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bb2e41e65c33a40502c9d876c7a337984d665a30
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Sat Feb 27 23:20:23 2021 +0900

    kbuild: Fix <linux/version.h> for empty SUBLEVEL or PATCHLEVEL again
    
    commit 207da4c82ade9a6d59f7e794d737ba0748613fa2 upstream.
    
    Commit 78d3bb4483ba ("kbuild: Fix <linux/version.h> for empty SUBLEVEL
    or PATCHLEVEL") fixed the build error for empty SUBLEVEL or PATCHLEVEL
    by prepending a zero.
    
    Commit 9b82f13e7ef3 ("kbuild: clamp SUBLEVEL to 255") re-introduced
    this issue.
    
    This time, we cannot take the same approach because we have C code:
    
      #define LINUX_VERSION_PATCHLEVEL $(PATCHLEVEL)
      #define LINUX_VERSION_SUBLEVEL $(SUBLEVEL)
    
    Replace empty SUBLEVEL/PATCHLEVEL with a zero.
    
    Fixes: 9b82f13e7ef3 ("kbuild: clamp SUBLEVEL to 255")
    Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Reviewed-and-tested-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 72714560fbc7c2fc79e4a5e79c4aa2fd2118c616
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Mon Mar 1 02:22:40 2021 +0300

    net/qrtr: fix __netdev_alloc_skb call
    
    commit 093b036aa94e01a0bea31a38d7f0ee28a2749023 upstream.
    
    syzbot found WARNING in __alloc_pages_nodemask()[1] when order >= MAX_ORDER.
    It was caused by a huge length value passed from userspace to qrtr_tun_write_iter(),
    which tries to allocate skb. Since the value comes from the untrusted source
    there is no need to raise a warning in __alloc_pages_nodemask().
    
    [1] WARNING in __alloc_pages_nodemask+0x5f8/0x730 mm/page_alloc.c:5014
    Call Trace:
     __alloc_pages include/linux/gfp.h:511 [inline]
     __alloc_pages_node include/linux/gfp.h:524 [inline]
     alloc_pages_node include/linux/gfp.h:538 [inline]
     kmalloc_large_node+0x60/0x110 mm/slub.c:3999
     __kmalloc_node_track_caller+0x319/0x3f0 mm/slub.c:4496
     __kmalloc_reserve net/core/skbuff.c:150 [inline]
     __alloc_skb+0x4e4/0x5a0 net/core/skbuff.c:210
     __netdev_alloc_skb+0x70/0x400 net/core/skbuff.c:446
     netdev_alloc_skb include/linux/skbuff.h:2832 [inline]
     qrtr_endpoint_post+0x84/0x11b0 net/qrtr/qrtr.c:442
     qrtr_tun_write_iter+0x11f/0x1a0 net/qrtr/tun.c:98
     call_write_iter include/linux/fs.h:1901 [inline]
     new_sync_write+0x426/0x650 fs/read_write.c:518
     vfs_write+0x791/0xa30 fs/read_write.c:605
     ksys_write+0x12d/0x250 fs/read_write.c:658
     do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
     entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    Reported-by: syzbot+80dccaee7c6630fa9dcf@syzkaller.appspotmail.com
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Acked-by: Alexander Lobakin <alobakin@pm.me>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6cae8095490caae12875300243ec94b39b6a2a78
Author: Jens Axboe <axboe@kernel.dk>
Date:   Sun Feb 28 15:32:18 2021 -0700

    io_uring: ensure that SQPOLL thread is started for exit
    
    commit 3ebba796fa251d042be42b929a2d916ee5c34a49 upstream.
    
    If we create it in a disabled state because IORING_SETUP_R_DISABLED is
    set on ring creation, we need to ensure that we've kicked the thread if
    we're exiting before it's been explicitly disabled. Otherwise we can run
    into a deadlock where exit is waiting go park the SQPOLL thread, but the
    SQPOLL thread itself is waiting to get a signal to start.
    
    That results in the below trace of both tasks hung, waiting on each other:
    
    INFO: task syz-executor458:8401 blocked for more than 143 seconds.
          Not tainted 5.11.0-next-20210226-syzkaller #0
    "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    task:syz-executor458 state:D stack:27536 pid: 8401 ppid:  8400 flags:0x00004004
    Call Trace:
     context_switch kernel/sched/core.c:4324 [inline]
     __schedule+0x90c/0x21a0 kernel/sched/core.c:5075
     schedule+0xcf/0x270 kernel/sched/core.c:5154
     schedule_timeout+0x1db/0x250 kernel/time/timer.c:1868
     do_wait_for_common kernel/sched/completion.c:85 [inline]
     __wait_for_common kernel/sched/completion.c:106 [inline]
     wait_for_common kernel/sched/completion.c:117 [inline]
     wait_for_completion+0x168/0x270 kernel/sched/completion.c:138
     io_sq_thread_park fs/io_uring.c:7115 [inline]
     io_sq_thread_park+0xd5/0x130 fs/io_uring.c:7103
     io_uring_cancel_task_requests+0x24c/0xd90 fs/io_uring.c:8745
     __io_uring_files_cancel+0x110/0x230 fs/io_uring.c:8840
     io_uring_files_cancel include/linux/io_uring.h:47 [inline]
     do_exit+0x299/0x2a60 kernel/exit.c:780
     do_group_exit+0x125/0x310 kernel/exit.c:922
     __do_sys_exit_group kernel/exit.c:933 [inline]
     __se_sys_exit_group kernel/exit.c:931 [inline]
     __x64_sys_exit_group+0x3a/0x50 kernel/exit.c:931
     do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    RIP: 0033:0x43e899
    RSP: 002b:00007ffe89376d48 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
    RAX: ffffffffffffffda RBX: 00000000004af2f0 RCX: 000000000043e899
    RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000
    RBP: 0000000000000000 R08: ffffffffffffffc0 R09: 0000000010000000
    R10: 0000000000008011 R11: 0000000000000246 R12: 00000000004af2f0
    R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001
    INFO: task iou-sqp-8401:8402 can't die for more than 143 seconds.
    task:iou-sqp-8401    state:D stack:30272 pid: 8402 ppid:  8400 flags:0x00004004
    Call Trace:
     context_switch kernel/sched/core.c:4324 [inline]
     __schedule+0x90c/0x21a0 kernel/sched/core.c:5075
     schedule+0xcf/0x270 kernel/sched/core.c:5154
     schedule_timeout+0x1db/0x250 kernel/time/timer.c:1868
     do_wait_for_common kernel/sched/completion.c:85 [inline]
     __wait_for_common kernel/sched/completion.c:106 [inline]
     wait_for_common kernel/sched/completion.c:117 [inline]
     wait_for_completion+0x168/0x270 kernel/sched/completion.c:138
     io_sq_thread+0x27d/0x1ae0 fs/io_uring.c:6717
     ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
    INFO: task iou-sqp-8401:8402 blocked for more than 143 seconds.
    
    Reported-by: syzbot+fb5458330b4442f2090d@syzkaller.appspotmail.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a7acb614287b7de8bf86d6758dac43bbd1d29534
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Sun Feb 14 12:13:07 2021 +0900

    pstore: Fix warning in pstore_kill_sb()
    
    commit 9c7d83ae6ba67d6c6199cce24573983db3b56332 upstream.
    
    syzbot is hitting WARN_ON(pstore_sb != sb) at pstore_kill_sb() [1], for the
    assumption that pstore_sb != NULL is wrong because pstore_fill_super() will
    not assign pstore_sb = sb when new_inode() for d_make_root() returned NULL
    (due to memory allocation fault injection).
    
    Since mount_single() calls pstore_kill_sb() when pstore_fill_super()
    failed, pstore_kill_sb() needs to be aware of such failure path.
    
    [1] https://syzkaller.appspot.com/bug?id=6abacb8da5137cb47a416f2bef95719ed60508a0
    
    Reported-by: syzbot <syzbot+d0cf0ad6513e9a1da5df@syzkaller.appspotmail.com>
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/20210214031307.57903-1-penguin-kernel@I-love.SAKURA.ne.jp
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5f7d470696add2a0eb0d9f34e32b0ced2dddb9ad
Author: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Date:   Fri Mar 5 13:09:47 2021 -0800

    i915/perf: Start hrtimer only if sampling the OA buffer
    
    commit 6a77c6bb7260bd5000f95df454d9f8cdb1af7132 upstream.
    
    SAMPLE_OA parameter enables sampling of OA buffer and results in a call
    to init the OA buffer which initializes the OA unit head/tail pointers.
    The OA_EXPONENT parameter controls the periodicity of the OA reports in
    the OA buffer and results in starting a hrtimer.
    
    Before gen12, all use cases required the use of the OA buffer and i915
    enforced this setting when vetting out the parameters passed. In these
    platforms the hrtimer was enabled if OA_EXPONENT was passed. This worked
    fine since it was implied that SAMPLE_OA is always passed.
    
    With gen12, this changed. Users can use perf without enabling the OA
    buffer as in OAR use cases. While an OAR use case should ideally not
    start the hrtimer, we see that passing an OA_EXPONENT parameter will
    start the hrtimer even though SAMPLE_OA is not specified. This results
    in an uninitialized OA buffer, so the head/tail pointers used to track
    the buffer are zero.
    
    This itself does not fail, but if we ran a use-case that SAMPLED the OA
    buffer previously, then the OA_TAIL register is still pointing to an old
    value. When the timer callback runs, it ends up calculating a
    wrong/large number of available reports. Since we do a spinlock_irq_save
    and start processing a large number of reports, NMI watchdog fires and
    causes a crash.
    
    Start the timer only if SAMPLE_OA is specified.
    
    v2:
    - Drop SAMPLE OA check when appending samples (Ashutosh)
    - Prevent read if OA buffer is not being sampled
    
    Fixes: 00a7f0d7155c ("drm/i915/tgl: Add perf support on TGL")
    Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
    Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
    Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210305210947.58751-1-umesh.nerlige.ramappa@intel.com
    (cherry picked from commit be0bdd67fda9468156c733976688f6487d0c42f7)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cb14e99e886f4f13ab0b804b7e3544fbc9212bbb
Author: Daniel Kobras <kobras@puzzle-itc.de>
Date:   Sat Feb 27 00:04:37 2021 +0100

    sunrpc: fix refcount leak for rpc auth modules
    
    commit f1442d6349a2e7bb7a6134791bdc26cb776c79af upstream.
    
    If an auth module's accept op returns SVC_CLOSE, svc_process_common()
    enters a call path that does not call svc_authorise() before leaving the
    function, and thus leaks a reference on the auth module's refcount. Hence,
    make sure calls to svc_authenticate() and svc_authorise() are paired for
    all call paths, to make sure rpc auth modules can be unloaded.
    
    Signed-off-by: Daniel Kobras <kobras@puzzle-itc.de>
    Fixes: 4d712ef1db05 ("svcauth_gss: Close connection when dropping an incoming message")
    Link: https://lore.kernel.org/linux-nfs/3F1B347F-B809-478F-A1E9-0BE98E22B0F0@oracle.com/T/#t
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2ea2d3a7980030888acf3e283673594d685430b6
Author: Gautam Dawar <gdawar.xilinx@gmail.com>
Date:   Wed Feb 24 17:18:45 2021 +0530

    vhost_vdpa: fix the missing irq_bypass_unregister_producer() invocation
    
    commit 4c050286bb202cffd5467c1cba982dff391d62e1 upstream.
    
    When qemu with vhost-vdpa netdevice is run for the first time,
    it works well. But after the VM is powered off, the next qemu run
    causes kernel panic due to a NULL pointer dereference in
    irq_bypass_register_producer().
    
    When the VM is powered off, vhost_vdpa_clean_irq() misses on calling
    irq_bypass_unregister_producer() for irq 0 because of the existing check.
    
    This leaves stale producer nodes, which are reset in
    vhost_vring_call_reset() when vhost_dev_init() is invoked during the
    second qemu run.
    
    As the node member of struct irq_bypass_producer is also initialized
    to zero, traversal on the producers list causes crash due to NULL
    pointer dereference.
    
    Fixes: 2cf1ba9a4d15c ("vhost_vdpa: implement IRQ offloading in vhost_vdpa")
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=211711
    Signed-off-by: Gautam Dawar <gdawar.xilinx@gmail.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Link: https://lore.kernel.org/r/20210224114845.104173-1-gdawar.xilinx@gmail.com
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3e5a1bb6ea201bdd4609a0ef22bd53c2be09eea3
Author: Jason Gunthorpe <jgg@ziepe.ca>
Date:   Tue Feb 23 15:17:46 2021 -0400

    vfio: IOMMU_API should be selected
    
    commit 179209fa12709a3df8888c323b37315da2683c24 upstream.
    
    As IOMMU_API is a kconfig without a description (eg does not show in the
    menu) the correct operator is select not 'depends on'. Using 'depends on'
    for this kind of symbol means VFIO is not selectable unless some other
    random kconfig has already enabled IOMMU_API for it.
    
    Fixes: cba3345cc494 ("vfio: VFIO core")
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Message-Id: <1-v1-df057e0f92c3+91-vfio_arm_compile_test_jgg@nvidia.com>
    Reviewed-by: Eric Auger <eric.auger@redhat.com>
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c2219627091c8d22d5979ec10703709d96b24ffb
Author: Timo Rothenpieler <timo@rothenpieler.org>
Date:   Tue Feb 23 00:36:19 2021 +0100

    svcrdma: disable timeouts on rdma backchannel
    
    commit 6820bf77864d5894ff67b5c00d7dba8f92011e3d upstream.
    
    This brings it in line with the regular tcp backchannel, which also has
    all those timeouts disabled.
    
    Prevents the backchannel from timing out, getting some async operations
    like server side copying getting stuck indefinitely on the client side.
    
    Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
    Fixes: 5d252f90a800 ("svcrdma: Add class for RDMA backwards direction transport")
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 982b899ba672c1eb2e0c01fef197bda13de4af55
Author: Olga Kornievskaia <kolga@netapp.com>
Date:   Tue Mar 9 09:41:14 2021 -0500

    NFSD: fix dest to src mount in inter-server COPY
    
    commit 614c9750173e412663728215152cc6d12bcb3425 upstream.
    
    A cleanup of the inter SSC copy needs to call fput() of the source
    file handle to make sure that file structure is freed as well as
    drop the reference on the superblock to unmount the source server.
    
    Fixes: 36e1e5ba90fb ("NFSD: Fix use-after-free warning when doing inter-server copy")
    Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Tested-by: Dai Ngo <dai.ngo@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 800369d61add0216a72b4c433c246832b28a790e
Author: Joe Korty <joe.korty@concurrent-rt.com>
Date:   Fri Feb 26 09:38:20 2021 -0500

    NFSD: Repair misuse of sv_lock in 5.10.16-rt30.
    
    commit c7de87ff9dac5f396f62d584f3908f80ddc0e07b upstream.
    
    [ This problem is in mainline, but only rt has the chops to be
    able to detect it. ]
    
    Lockdep reports a circular lock dependency between serv->sv_lock and
    softirq_ctl.lock on system shutdown, when using a kernel built with
    CONFIG_PREEMPT_RT=y, and a nfs mount exists.
    
    This is due to the definition of spin_lock_bh on rt:
    
            local_bh_disable();
            rt_spin_lock(lock);
    
    which forces a softirq_ctl.lock -> serv->sv_lock dependency.  This is
    not a problem as long as _every_ lock of serv->sv_lock is a:
    
            spin_lock_bh(&serv->sv_lock);
    
    but there is one of the form:
    
            spin_lock(&serv->sv_lock);
    
    This is what is causing the circular dependency splat.  The spin_lock()
    grabs the lock without first grabbing softirq_ctl.lock via local_bh_disable.
    If later on in the critical region,  someone does a local_bh_disable, we
    get a serv->sv_lock -> softirq_ctrl.lock dependency established.  Deadlock.
    
    Fix is to make serv->sv_lock be locked with spin_lock_bh everywhere, no
    exceptions.
    
    [  OK  ] Stopped target NFS client services.
             Stopping Logout off all iSCSI sessions on shutdown...
             Stopping NFS server and services...
    [  109.442380]
    [  109.442385] ======================================================
    [  109.442386] WARNING: possible circular locking dependency detected
    [  109.442387] 5.10.16-rt30 #1 Not tainted
    [  109.442389] ------------------------------------------------------
    [  109.442390] nfsd/1032 is trying to acquire lock:
    [  109.442392] ffff994237617f60 ((softirq_ctrl.lock).lock){+.+.}-{2:2}, at: __local_bh_disable_ip+0xd9/0x270
    [  109.442405]
    [  109.442405] but task is already holding lock:
    [  109.442406] ffff994245cb00b0 (&serv->sv_lock){+.+.}-{0:0}, at: svc_close_list+0x1f/0x90
    [  109.442415]
    [  109.442415] which lock already depends on the new lock.
    [  109.442415]
    [  109.442416]
    [  109.442416] the existing dependency chain (in reverse order) is:
    [  109.442417]
    [  109.442417] -> #1 (&serv->sv_lock){+.+.}-{0:0}:
    [  109.442421]        rt_spin_lock+0x2b/0xc0
    [  109.442428]        svc_add_new_perm_xprt+0x42/0xa0
    [  109.442430]        svc_addsock+0x135/0x220
    [  109.442434]        write_ports+0x4b3/0x620
    [  109.442438]        nfsctl_transaction_write+0x45/0x80
    [  109.442440]        vfs_write+0xff/0x420
    [  109.442444]        ksys_write+0x4f/0xc0
    [  109.442446]        do_syscall_64+0x33/0x40
    [  109.442450]        entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [  109.442454]
    [  109.442454] -> #0 ((softirq_ctrl.lock).lock){+.+.}-{2:2}:
    [  109.442457]        __lock_acquire+0x1264/0x20b0
    [  109.442463]        lock_acquire+0xc2/0x400
    [  109.442466]        rt_spin_lock+0x2b/0xc0
    [  109.442469]        __local_bh_disable_ip+0xd9/0x270
    [  109.442471]        svc_xprt_do_enqueue+0xc0/0x4d0
    [  109.442474]        svc_close_list+0x60/0x90
    [  109.442476]        svc_close_net+0x49/0x1a0
    [  109.442478]        svc_shutdown_net+0x12/0x40
    [  109.442480]        nfsd_destroy+0xc5/0x180
    [  109.442482]        nfsd+0x1bc/0x270
    [  109.442483]        kthread+0x194/0x1b0
    [  109.442487]        ret_from_fork+0x22/0x30
    [  109.442492]
    [  109.442492] other info that might help us debug this:
    [  109.442492]
    [  109.442493]  Possible unsafe locking scenario:
    [  109.442493]
    [  109.442493]        CPU0                    CPU1
    [  109.442494]        ----                    ----
    [  109.442495]   lock(&serv->sv_lock);
    [  109.442496]                                lock((softirq_ctrl.lock).lock);
    [  109.442498]                                lock(&serv->sv_lock);
    [  109.442499]   lock((softirq_ctrl.lock).lock);
    [  109.442501]
    [  109.442501]  *** DEADLOCK ***
    [  109.442501]
    [  109.442501] 3 locks held by nfsd/1032:
    [  109.442503]  #0: ffffffff93b49258 (nfsd_mutex){+.+.}-{3:3}, at: nfsd+0x19a/0x270
    [  109.442508]  #1: ffff994245cb00b0 (&serv->sv_lock){+.+.}-{0:0}, at: svc_close_list+0x1f/0x90
    [  109.442512]  #2: ffffffff93a81b20 (rcu_read_lock){....}-{1:2}, at: rt_spin_lock+0x5/0xc0
    [  109.442518]
    [  109.442518] stack backtrace:
    [  109.442519] CPU: 0 PID: 1032 Comm: nfsd Not tainted 5.10.16-rt30 #1
    [  109.442522] Hardware name: Supermicro X9DRL-3F/iF/X9DRL-3F/iF, BIOS 3.2 09/22/2015
    [  109.442524] Call Trace:
    [  109.442527]  dump_stack+0x77/0x97
    [  109.442533]  check_noncircular+0xdc/0xf0
    [  109.442546]  __lock_acquire+0x1264/0x20b0
    [  109.442553]  lock_acquire+0xc2/0x400
    [  109.442564]  rt_spin_lock+0x2b/0xc0
    [  109.442570]  __local_bh_disable_ip+0xd9/0x270
    [  109.442573]  svc_xprt_do_enqueue+0xc0/0x4d0
    [  109.442577]  svc_close_list+0x60/0x90
    [  109.442581]  svc_close_net+0x49/0x1a0
    [  109.442585]  svc_shutdown_net+0x12/0x40
    [  109.442588]  nfsd_destroy+0xc5/0x180
    [  109.442590]  nfsd+0x1bc/0x270
    [  109.442595]  kthread+0x194/0x1b0
    [  109.442600]  ret_from_fork+0x22/0x30
    [  109.518225] nfsd: last server has exited, flushing export cache
    [  OK  ] Stopped NFSv4 ID-name mapping service.
    [  OK  ] Stopped GSSAPI Proxy Daemon.
    [  OK  ] Stopped NFS Mount Daemon.
    [  OK  ] Stopped NFS status monitor for NFSv2/3 locking..
    
    Fixes: 719f8bcc883e ("svcrpc: fix xpt_list traversal locking on shutdown")
    Signed-off-by: Joe Korty <joe.korty@concurrent-rt.com>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 12628e7779f8e191c010955058d278df5bf0c0d4
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Wed Feb 24 13:39:50 2021 -0500

    nfsd: don't abort copies early
    
    commit bfdd89f232aa2de5a4b3fc985cba894148b830a8 upstream.
    
    The typical result of the backwards comparison here is that the source
    server in a server-to-server copy will return BAD_STATEID within a few
    seconds of the copy starting, instead of giving the copy a full lease
    period, so the copy_file_range() call will end up unnecessarily
    returning a short read.
    
    Fixes: 624322f1adc5 "NFSD add COPY_NOTIFY operation"
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5ea0aa29ad4b8bc96b8cfcfb367f04b50b9cf92f
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Thu Feb 18 21:02:07 2021 -0500

    nfsd: Don't keep looking up unhashed files in the nfsd file cache
    
    commit d30881f573e565ebb5dbb50b31ed6106b5c81328 upstream.
    
    If a file is unhashed, then we're going to reject it anyway and retry,
    so make sure we skip it when we're doing the RCU lockless lookup.
    This avoids a number of unnecessary nfserr_jukebox returns from
    nfsd_file_acquire()
    
    Fixes: 65294c1f2c5e ("nfsd: add a new struct file caching facility to nfsd")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 628f39a57a461379643c2ebc4837e31da63abfd2
Author: Sagi Grimberg <sagi@grimberg.me>
Date:   Mon Mar 15 15:34:51 2021 -0700

    nvmet: don't check iosqes,iocqes for discovery controllers
    
    commit d218a8a3003e84ab136e69a4e30dd4ec7dab2d22 upstream.
    
    From the base spec, Figure 78:
    
      "Controller Configuration, these fields are defined as parameters to
       configure an "I/O Controller (IOC)" and not to configure a "Discovery
       Controller (DC).
    
       ...
       If the controller does not support I/O queues, then this field shall
       be read-only with a value of 0h
    
    Just perform this check for I/O controllers.
    
    Fixes: a07b4970f464 ("nvmet: add a generic NVMe target")
    Reported-by: Belanger, Martin <Martin.Belanger@dell.com>
    Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
    Reviewed-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b4f911e3a9821d20d2a440cdb5863b43242fcfbe
Author: Sagi Grimberg <sagi@grimberg.me>
Date:   Mon Mar 15 14:08:11 2021 -0700

    nvme-tcp: fix a NULL deref when receiving a 0-length r2t PDU
    
    commit fd0823f405090f9f410fc3e3ff7efb52e7b486fa upstream.
    
    When the controller sends us a 0-length r2t PDU we should not attempt to
    try to set up a h2cdata PDU but rather conclude that this is a buggy
    controller (forward progress is not possible) and simply fail it
    immediately.
    
    Fixes: 3f2304f8c6d6 ("nvme-tcp: add NVMe over TCP host driver")
    Reported-by: Belanger, Martin <Martin.Belanger@dell.com>
    Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7089cdfce32f9cf5397350140216bbc000347bae
Author: Sagi Grimberg <sagi@grimberg.me>
Date:   Mon Mar 15 14:04:26 2021 -0700

    nvme-tcp: fix possible hang when failing to set io queues
    
    commit 72f572428b83d0bc7028e7c4326d1a5f45205e44 upstream.
    
    We only setup io queues for nvme controllers, and it makes absolutely no
    sense to allow a controller (re)connect without any I/O queues.  If we
    happen to fail setting the queue count for any reason, we should not
    allow this to be a successful reconnect as I/O has no chance in going
    through. Instead just fail and schedule another reconnect.
    
    Fixes: 3f2304f8c6d6 ("nvme-tcp: add NVMe over TCP host driver")
    Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a83e5c6c35fa0ad0259b850e1f727fee922e3ba3
Author: Sagi Grimberg <sagi@grimberg.me>
Date:   Mon Mar 15 13:53:47 2021 -0700

    nvme-tcp: fix misuse of __smp_processor_id with preemption enabled
    
    commit bb83337058a7000644cdeffc67361d2473534756 upstream.
    
    For our pure advisory use-case, we only rely on this call as a hint, so
    fix the warning complaints of using the smp_processor_id variants with
    preemption enabled.
    
    Fixes: db5ad6b7f8cd ("nvme-tcp: try to send request in queue_rq context")
    Fixes: ada831772188 ("nvme-tcp: Fix warning with CONFIG_DEBUG_PREEMPT")
    Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
    Reviewed-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
    Tested-by: Yi Zhang <yi.zhang@redhat.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fd9e2b99974019a717c975c2c2fa08729ab712f3
Author: Christoph Hellwig <hch@lst.de>
Date:   Mon Mar 15 10:32:07 2021 +0100

    nvme: fix Write Zeroes limitations
    
    commit b94e8cd2e6a94fc7563529ddc82726a7e77e04de upstream.
    
    We voluntarily limit the Write Zeroes sizes to the MDTS value provided by
    the hardware, but currently get the units wrong, so fix that.
    
    Fixes: 6e02318eaea5 ("nvme: add support for the Write Zeroes command")
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Keith Busch <kbusch@kernel.org>
    Tested-by: Klaus Jensen <k.jensen@samsung.com>
    Reviewed-by: Klaus Jensen <k.jensen@samsung.com>
    Reviewed-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2d202085d2dd53b8364a17050887a805c9e1601f
Author: Colin Ian King <colin.king@canonical.com>
Date:   Thu Mar 18 13:20:08 2021 +0000

    ALSA: usb-audio: Fix unintentional sign extension issue
    
    commit 50b1affc891cbc103a2334ce909a026e25f4c84d upstream.
    
    The shifting of the u8 integer device by 24 bits to the left will
    be promoted to a 32 bit signed int and then sign-extended to a
    64 bit unsigned long. In the event that the top bit of device is
    set then all then all the upper 32 bits of the unsigned long will
    end up as also being set because of the sign-extension. Fix this
    by casting device to an unsigned long before the shift.
    
    Addresses-Coverity: ("Unintended sign extension")
    Fixes: a07df82c7990 ("ALSA: usb-audio: Add DJM750 to Pioneer mixer quirk")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Link: https://lore.kernel.org/r/20210318132008.15266-1-colin.king@canonical.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 64195f022ae8c24e0abccc1545d557b064e73ed3
Author: David Howells <dhowells@redhat.com>
Date:   Tue Mar 9 08:27:39 2021 +0000

    afs: Stop listxattr() from listing "afs.*" attributes
    
    commit a7889c6320b9200e3fe415238f546db677310fa9 upstream.
    
    afs_listxattr() lists all the available special afs xattrs (i.e. those in
    the "afs.*" space), no matter what type of server we're dealing with.  But
    OpenAFS servers, for example, cannot deal with some of the extra-capable
    attributes that AuriStor (YFS) servers provide.  Unfortunately, the
    presence of the afs.yfs.* attributes causes errors[1] for anything that
    tries to read them if the server is of the wrong type.
    
    Fix the problem by removing afs_listxattr() so that none of the special
    xattrs are listed (AFS doesn't support xattrs).  It does mean, however,
    that getfattr won't list them, though they can still be accessed with
    getxattr() and setxattr().
    
    This can be tested with something like:
    
            getfattr -d -m ".*" /afs/example.com/path/to/file
    
    With this change, none of the afs.* attributes should be visible.
    
    Changes:
    ver #2:
     - Hide all of the afs.* xattrs, not just the ACL ones.
    
    Fixes: ae46578b963f ("afs: Get YFS ACLs and information through xattrs")
    Reported-by: Gaja Sophie Peters <gaja.peters@math.uni-hamburg.de>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Tested-by: Gaja Sophie Peters <gaja.peters@math.uni-hamburg.de>
    Reviewed-by: Jeffrey Altman <jaltman@auristor.com>
    Reviewed-by: Marc Dionne <marc.dionne@auristor.com>
    cc: linux-afs@lists.infradead.org
    Link: http://lists.infradead.org/pipermail/linux-afs/2021-March/003502.html [1]
    Link: http://lists.infradead.org/pipermail/linux-afs/2021-March/003567.html # v1
    Link: http://lists.infradead.org/pipermail/linux-afs/2021-March/003573.html # v2
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 78ba4793b084f722a0aaf5f32a3d9f7c3e284b22
Author: David Howells <dhowells@redhat.com>
Date:   Tue Mar 2 10:26:45 2021 +0000

    afs: Fix accessing YFS xattrs on a non-YFS server
    
    commit 64fcbb6158ecc684d84c64424830a9c37c77c5b9 upstream.
    
    If someone attempts to access YFS-related xattrs (e.g. afs.yfs.acl) on a
    file on a non-YFS AFS server (such as OpenAFS), then the kernel will jump
    to a NULL function pointer because the afs_fetch_acl_operation descriptor
    doesn't point to a function for issuing an operation on a non-YFS
    server[1].
    
    Fix this by making afs_wait_for_operation() check that the issue_afs_rpc
    method is set before jumping to it and setting -ENOTSUPP if not.  This fix
    also covers other potential operations that also only exist on YFS servers.
    
    afs_xattr_get/set_yfs() then need to translate -ENOTSUPP to -ENODATA as the
    former error is internal to the kernel.
    
    The bug shows up as an oops like the following:
    
            BUG: kernel NULL pointer dereference, address: 0000000000000000
            [...]
            Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.
            [...]
            Call Trace:
             afs_wait_for_operation+0x83/0x1b0 [kafs]
             afs_xattr_get_yfs+0xe6/0x270 [kafs]
             __vfs_getxattr+0x59/0x80
             vfs_getxattr+0x11c/0x140
             getxattr+0x181/0x250
             ? __check_object_size+0x13f/0x150
             ? __fput+0x16d/0x250
             __x64_sys_fgetxattr+0x64/0xb0
             do_syscall_64+0x49/0xc0
             entry_SYSCALL_64_after_hwframe+0x44/0xa9
            RIP: 0033:0x7fb120a9defe
    
    This was triggered with "cp -a" which attempts to copy xattrs, including
    afs ones, but is easier to reproduce with getfattr, e.g.:
    
            getfattr -d -m ".*" /afs/openafs.org/
    
    Fixes: e49c7b2f6de7 ("afs: Build an abstraction around an "operation" concept")
    Reported-by: Gaja Sophie Peters <gaja.peters@math.uni-hamburg.de>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Tested-by: Gaja Sophie Peters <gaja.peters@math.uni-hamburg.de>
    Reviewed-by: Marc Dionne <marc.dionne@auristor.com>
    Reviewed-by: Jeffrey Altman <jaltman@auristor.com>
    cc: linux-afs@lists.infradead.org
    Link: http://lists.infradead.org/pipermail/linux-afs/2021-March/003498.html [1]
    Link: http://lists.infradead.org/pipermail/linux-afs/2021-March/003566.html # v1
    Link: http://lists.infradead.org/pipermail/linux-afs/2021-March/003572.html # v2
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 07fa872bf79cb5b8b6ba13a2918233defadae338
Author: Sameer Pujar <spujar@nvidia.com>
Date:   Mon Mar 15 23:01:31 2021 +0530

    ASoC: simple-card-utils: Do not handle device clock
    
    commit 8ca88d53351cc58d535b2bfc7386835378fb0db2 upstream.
    
    This reverts commit 1e30f642cf29 ("ASoC: simple-card-utils: Fix device
    module clock"). The original patch ended up breaking following platform,
    which depends on set_sysclk() to configure internal PLL on wm8904 codec
    and expects simple-card-utils to not update the MCLK rate.
     - "arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3-ads2.dts"
    
    It would be best if codec takes care of setting MCLK clock via DAI
    set_sysclk() callback.
    
    Reported-by: Michael Walle <michael@walle.cc>
    Suggested-by: Mark Brown <broonie@kernel.org>
    Suggested-by: Michael Walle <michael@walle.cc>
    Fixes: 1e30f642cf29 ("ASoC: simple-card-utils: Fix device module clock")
    Signed-off-by: Sameer Pujar <spujar@nvidia.com>
    Tested-by: Michael Walle <michael@walle.cc>
    Link: https://lore.kernel.org/r/1615829492-8972-2-git-send-email-spujar@nvidia.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d1ab87e31761111b9b450b24bf4f797e7261c817
Author: Srinivasa Rao Mandadapu <srivasam@codeaurora.org>
Date:   Thu Mar 11 21:15:57 2021 +0530

    ASoC: qcom: lpass-cpu: Fix lpass dai ids parse
    
    commit 9922f50f7178496e709d3d064920b5031f0d9061 upstream.
    
    The max boundary check while parsing dai ids makes
    sound card registration fail after common up dai ids.
    
    Fixes: cd3484f7f138 ("ASoC: qcom: Fix broken support to MI2S TERTIARY and QUATERNARY")
    
    Signed-off-by: Srinivasa Rao Mandadapu <srivasam@codeaurora.org>
    Link: https://lore.kernel.org/r/20210311154557.24978-1-srivasam@codeaurora.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1ae54de79fba3f08c4491127f48e5e937ec3d518
Author: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Date:   Tue Mar 9 14:21:29 2021 +0000

    ASoC: codecs: wcd934x: add a sanity check in set channel map
    
    commit 3bb4852d598f0275ed5996a059df55be7318ac2f upstream.
    
    set channel map can be passed with a channel maps, however if
    the number of channels that are passed are more than the actual
    supported channels then we would be accessing array out of bounds.
    
    So add a sanity check to validate these numbers!
    
    Fixes: a61f3b4f476e ("ASoC: wcd934x: add support to wcd9340/wcd9341 codec")
    Reported-by: John Stultz <john.stultz@linaro.org>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20210309142129.14182-4-srinivas.kandagatla@linaro.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 03079a0f1bf75f66a243d4484563dfbbe9d021fa
Author: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Date:   Tue Mar 9 14:21:28 2021 +0000

    ASoC: qcom: sdm845: Fix array out of range on rx slim channels
    
    commit 4800fe6ea1022eb240215b1743d2541adad8efc7 upstream.
    
    WCD934x has only 13 RX SLIM ports however we are setting it as 16
    in set_channel_map, this will lead to array out of bounds error!
    
    Orignally caught by enabling USBAN array out of bounds check:
    
    Fixes: 5caf64c633a3 ("ASoC: qcom: sdm845: add support to DB845c and Lenovo Yoga")
    Reported-by: John Stultz <john.stultz@linaro.org>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20210309142129.14182-3-srinivas.kandagatla@linaro.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 26b08c08a5f3008fe45822d8b163f1516178c42b
Author: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Date:   Tue Mar 9 14:21:27 2021 +0000

    ASoC: qcom: sdm845: Fix array out of bounds access
    
    commit 1c668e1c0a0f74472469cd514f40c9012b324c31 upstream.
    
    Static analysis Coverity had detected a potential array out-of-bounds
    write issue due to the fact that MAX AFE port Id was set to 16 instead
    of using AFE_PORT_MAX macro.
    
    Fix this by properly using AFE_PORT_MAX macro.
    
    Fixes: 1b93a8843147 ("ASoC: qcom: sdm845: handle soundwire stream")
    Reported-by: John Stultz <john.stultz@linaro.org>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20210309142129.14182-2-srinivas.kandagatla@linaro.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 47a6cadb6cfd784837e71a95bbff2d9dd9d09aee
Author: Pan Xiuli <xiuli.pan@linux.intel.com>
Date:   Mon Mar 8 18:41:27 2021 -0600

    ASoC: SOF: intel: fix wrong poll bits in dsp power down
    
    commit fd8299181995093948ec6ca75432e797b4a39143 upstream.
    
    The ADSPCS_SPA is Set Power Active bit. To check if DSP is powered
    down, we need to check ADSPCS_CPA, the Current Power Active bit.
    
    Fixes: 747503b1813a3 ("ASoC: SOF: Intel: Add Intel specific HDA DSP HW operations")
    Reviewed-by: Rander Wang <rander.wang@intel.com>
    Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
    Signed-off-by: Pan Xiuli <xiuli.pan@linux.intel.com>
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Link: https://lore.kernel.org/r/20210309004127.4940-1-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b94b71a7a6f62f5f85c4949b1f71aa460aa39604
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Mon Mar 1 18:34:10 2021 -0600

    ASoC: SOF: Intel: unregister DMIC device on probe error
    
    commit 5bb0ecddb2a7f638d65e457f3da9fa334c967b14 upstream.
    
    We only unregister the platform device during the .remove operation,
    but if the probe fails we will never reach this sequence.
    
    Suggested-by: Bard Liao <yung-chuan.liao@linux.intel.com>
    Fixes: dd96daca6c83e ("ASoC: SOF: Intel: Add APL/CNL HW DSP support")
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
    Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
    Link: https://lore.kernel.org/r/20210302003410.1178535-1-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4da5a9a73c4c4c3405860022ca17dbad2a1817f0
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Wed Feb 24 11:50:52 2021 +0100

    ASoC: Intel: bytcr_rt5640: Fix HP Pavilion x2 10-p0XX OVCD current threshold
    
    commit ca08ddfd961d2a17208d9182e0ee5791b39bd8bf upstream.
    
    When I added the quirk for the "HP Pavilion x2 10-p0XX" I copied the
    byt_rt5640_quirk_table[] entry for the HP Pavilion x2 10-k0XX / 10-n0XX
    models since these use almost the same settings.
    
    While doing this I accidentally also copied and kept the non-standard
    OVCD_TH_1500UA setting used on those models. This too low threshold is
    causing headsets to often be seen as headphones (without a headset-mic)
    and when correctly identified it is causing ghost play/pause
    button-presses to get detected.
    
    Correct the HP Pavilion x2 10-p0XX quirk to use the default OVCD_TH_2000UA
    setting, fixing these problems.
    
    Fixes: fbdae7d6d04d ("ASoC: Intel: bytcr_rt5640: Fix HP Pavilion x2 Detachable quirks")
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Link: https://lore.kernel.org/r/20210224105052.42116-1-hdegoede@redhat.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 118cfdc770cdfff793d4f68b3bd45903fea6d474
Author: Alexander Shiyan <shc_work@mail.ru>
Date:   Tue Feb 16 14:42:21 2021 +0300

    ASoC: fsl_ssi: Fix TDM slot setup for I2S mode
    
    commit 87263968516fb9507d6215d53f44052627fae8d8 upstream.
    
    When using the driver in I2S TDM mode, the _fsl_ssi_set_dai_fmt()
    function rewrites the number of slots previously set by the
    fsl_ssi_set_dai_tdm_slot() function to 2 by default.
    To fix this, let's use the saved slot count value or, if TDM
    is not used and the slot count is not set, proceed as before.
    
    Fixes: 4f14f5c11db1 ("ASoC: fsl_ssi: Fix number of words per frame for I2S-slave mode")
    Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
    Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
    Link: https://lore.kernel.org/r/20210216114221.26635-1-shc_work@mail.ru
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 223dc51caa51d72ca4cc3662450da7651eca4427
Author: Calvin Hou <Calvin.Hou@amd.com>
Date:   Tue Mar 2 10:48:26 2021 -0500

    drm/amd/display: Correct algorithm for reversed gamma
    
    commit 34fa493a565cc6fcee6919787c11e264f55603c6 upstream.
    
    [Why]
    DCN30 needs to correctly program reversed gamma curve, which DCN20
    already has.
    Also needs to fix a bug that 252-255 values are clipped.
    
    [How]
    Apply two fixes into DCN30.
    
    Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1513
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Calvin Hou <Calvin.Hou@amd.com>
    Reviewed-by: Jun Lei <Jun.Lei@amd.com>
    Reviewed-by: Krunoslav Kovac <Krunoslav.Kovac@amd.com>
    Acked-by: Solomon Chiu <solomon.chiu@amd.com>
    Acked-by: Vladimir Stempen <Vladimir.Stempen@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 4daa70a80c68c76df87d70565cf62f716e240e0f
Author: Stefano Garzarella <sgarzare@redhat.com>
Date:   Thu Mar 11 14:52:57 2021 +0100

    vhost-vdpa: set v->config_ctx to NULL if eventfd_ctx_fdget() fails
    
    commit 0bde59c1723a29e294765c96dbe5c7fb639c2f96 upstream.
    
    In vhost_vdpa_set_config_call() if eventfd_ctx_fdget() fails the
    'v->config_ctx' contains an error instead of a valid pointer.
    
    Since we consider 'v->config_ctx' valid if it is not NULL, we should
    set it to NULL in this case to avoid to use an invalid pointer in
    other functions such as vhost_vdpa_config_put().
    
    Fixes: 776f395004d8 ("vhost_vdpa: Support config interrupt in vdpa")
    Cc: lingshan.zhu@intel.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
    Link: https://lore.kernel.org/r/20210311135257.109460-3-sgarzare@redhat.com
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 49ca3100fbaf864853c922c8f7a8fe7090a83860
Author: Stefano Garzarella <sgarzare@redhat.com>
Date:   Thu Mar 11 14:52:56 2021 +0100

    vhost-vdpa: fix use-after-free of v->config_ctx
    
    commit f6bbf0010ba004f5e90c7aefdebc0ee4bd3283b9 upstream.
    
    When the 'v->config_ctx' eventfd_ctx reference is released we didn't
    set it to NULL. So if the same character device (e.g. /dev/vhost-vdpa-0)
    is re-opened, the 'v->config_ctx' is invalid and calling again
    vhost_vdpa_config_put() causes use-after-free issues like the
    following refcount_t underflow:
    
        refcount_t: underflow; use-after-free.
        WARNING: CPU: 2 PID: 872 at lib/refcount.c:28 refcount_warn_saturate+0xae/0xf0
        RIP: 0010:refcount_warn_saturate+0xae/0xf0
        Call Trace:
         eventfd_ctx_put+0x5b/0x70
         vhost_vdpa_release+0xcd/0x150 [vhost_vdpa]
         __fput+0x8e/0x240
         ____fput+0xe/0x10
         task_work_run+0x66/0xa0
         exit_to_user_mode_prepare+0x118/0x120
         syscall_exit_to_user_mode+0x21/0x50
         ? __x64_sys_close+0x12/0x40
         do_syscall_64+0x45/0x50
         entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    Fixes: 776f395004d8 ("vhost_vdpa: Support config interrupt in vdpa")
    Cc: lingshan.zhu@intel.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
    Link: https://lore.kernel.org/r/20210311135257.109460-2-sgarzare@redhat.com
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Reviewed-by: Zhu Lingshan <lingshan.zhu@intel.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2c8d6a9474f07375c87c4dc6f008610b3ce755a7
Author: David Sterba <dsterba@suse.com>
Date:   Mon Mar 15 15:18:24 2021 +0100

    btrfs: fix slab cache flags for free space tree bitmap
    
    commit 34e49994d0dcdb2d31d4d2908d04f4e9ce57e4d7 upstream.
    
    The free space tree bitmap slab cache is created with SLAB_RED_ZONE but
    that's a debugging flag and not always enabled. Also the other slabs are
    created with at least SLAB_MEM_SPREAD that we want as well to average
    the memory placement cost.
    
    Reported-by: Vlastimil Babka <vbabka@suse.cz>
    Fixes: 3acd48507dc4 ("btrfs: fix allocation of free space cache v1 bitmap pages")
    CC: stable@vger.kernel.org # 5.4+
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 38ffe9eaeb7cce383525439f0948f9eb74632e1d
Author: Filipe Manana <fdmanana@suse.com>
Date:   Thu Mar 11 14:31:05 2021 +0000

    btrfs: fix race when cloning extent buffer during rewind of an old root
    
    commit dbcc7d57bffc0c8cac9dac11bec548597d59a6a5 upstream.
    
    While resolving backreferences, as part of a logical ino ioctl call or
    fiemap, we can end up hitting a BUG_ON() when replaying tree mod log
    operations of a root, triggering a stack trace like the following:
    
      ------------[ cut here ]------------
      kernel BUG at fs/btrfs/ctree.c:1210!
      invalid opcode: 0000 [#1] SMP KASAN PTI
      CPU: 1 PID: 19054 Comm: crawl_335 Tainted: G        W         5.11.0-2d11c0084b02-misc-next+ #89
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
      RIP: 0010:__tree_mod_log_rewind+0x3b1/0x3c0
      Code: 05 48 8d 74 10 (...)
      RSP: 0018:ffffc90001eb70b8 EFLAGS: 00010297
      RAX: 0000000000000000 RBX: ffff88812344e400 RCX: ffffffffb28933b6
      RDX: 0000000000000007 RSI: dffffc0000000000 RDI: ffff88812344e42c
      RBP: ffffc90001eb7108 R08: 1ffff11020b60a20 R09: ffffed1020b60a20
      R10: ffff888105b050f9 R11: ffffed1020b60a1f R12: 00000000000000ee
      R13: ffff8880195520c0 R14: ffff8881bc958500 R15: ffff88812344e42c
      FS:  00007fd1955e8700(0000) GS:ffff8881f5600000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007efdb7928718 CR3: 000000010103a006 CR4: 0000000000170ee0
      Call Trace:
       btrfs_search_old_slot+0x265/0x10d0
       ? lock_acquired+0xbb/0x600
       ? btrfs_search_slot+0x1090/0x1090
       ? free_extent_buffer.part.61+0xd7/0x140
       ? free_extent_buffer+0x13/0x20
       resolve_indirect_refs+0x3e9/0xfc0
       ? lock_downgrade+0x3d0/0x3d0
       ? __kasan_check_read+0x11/0x20
       ? add_prelim_ref.part.11+0x150/0x150
       ? lock_downgrade+0x3d0/0x3d0
       ? __kasan_check_read+0x11/0x20
       ? lock_acquired+0xbb/0x600
       ? __kasan_check_write+0x14/0x20
       ? do_raw_spin_unlock+0xa8/0x140
       ? rb_insert_color+0x30/0x360
       ? prelim_ref_insert+0x12d/0x430
       find_parent_nodes+0x5c3/0x1830
       ? resolve_indirect_refs+0xfc0/0xfc0
       ? lock_release+0xc8/0x620
       ? fs_reclaim_acquire+0x67/0xf0
       ? lock_acquire+0xc7/0x510
       ? lock_downgrade+0x3d0/0x3d0
       ? lockdep_hardirqs_on_prepare+0x160/0x210
       ? lock_release+0xc8/0x620
       ? fs_reclaim_acquire+0x67/0xf0
       ? lock_acquire+0xc7/0x510
       ? poison_range+0x38/0x40
       ? unpoison_range+0x14/0x40
       ? trace_hardirqs_on+0x55/0x120
       btrfs_find_all_roots_safe+0x142/0x1e0
       ? find_parent_nodes+0x1830/0x1830
       ? btrfs_inode_flags_to_xflags+0x50/0x50
       iterate_extent_inodes+0x20e/0x580
       ? tree_backref_for_extent+0x230/0x230
       ? lock_downgrade+0x3d0/0x3d0
       ? read_extent_buffer+0xdd/0x110
       ? lock_downgrade+0x3d0/0x3d0
       ? __kasan_check_read+0x11/0x20
       ? lock_acquired+0xbb/0x600
       ? __kasan_check_write+0x14/0x20
       ? _raw_spin_unlock+0x22/0x30
       ? __kasan_check_write+0x14/0x20
       iterate_inodes_from_logical+0x129/0x170
       ? iterate_inodes_from_logical+0x129/0x170
       ? btrfs_inode_flags_to_xflags+0x50/0x50
       ? iterate_extent_inodes+0x580/0x580
       ? __vmalloc_node+0x92/0xb0
       ? init_data_container+0x34/0xb0
       ? init_data_container+0x34/0xb0
       ? kvmalloc_node+0x60/0x80
       btrfs_ioctl_logical_to_ino+0x158/0x230
       btrfs_ioctl+0x205e/0x4040
       ? __might_sleep+0x71/0xe0
       ? btrfs_ioctl_get_supported_features+0x30/0x30
       ? getrusage+0x4b6/0x9c0
       ? __kasan_check_read+0x11/0x20
       ? lock_release+0xc8/0x620
       ? __might_fault+0x64/0xd0
       ? lock_acquire+0xc7/0x510
       ? lock_downgrade+0x3d0/0x3d0
       ? lockdep_hardirqs_on_prepare+0x210/0x210
       ? lockdep_hardirqs_on_prepare+0x210/0x210
       ? __kasan_check_read+0x11/0x20
       ? do_vfs_ioctl+0xfc/0x9d0
       ? ioctl_file_clone+0xe0/0xe0
       ? lock_downgrade+0x3d0/0x3d0
       ? lockdep_hardirqs_on_prepare+0x210/0x210
       ? __kasan_check_read+0x11/0x20
       ? lock_release+0xc8/0x620
       ? __task_pid_nr_ns+0xd3/0x250
       ? lock_acquire+0xc7/0x510
       ? __fget_files+0x160/0x230
       ? __fget_light+0xf2/0x110
       __x64_sys_ioctl+0xc3/0x100
       do_syscall_64+0x37/0x80
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      RIP: 0033:0x7fd1976e2427
      Code: 00 00 90 48 8b 05 (...)
      RSP: 002b:00007fd1955e5cf8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
      RAX: ffffffffffffffda RBX: 00007fd1955e5f40 RCX: 00007fd1976e2427
      RDX: 00007fd1955e5f48 RSI: 00000000c038943b RDI: 0000000000000004
      RBP: 0000000001000000 R08: 0000000000000000 R09: 00007fd1955e6120
      R10: 0000557835366b00 R11: 0000000000000246 R12: 0000000000000004
      R13: 00007fd1955e5f48 R14: 00007fd1955e5f40 R15: 00007fd1955e5ef8
      Modules linked in:
      ---[ end trace ec8931a1c36e57be ]---
    
      (gdb) l *(__tree_mod_log_rewind+0x3b1)
      0xffffffff81893521 is in __tree_mod_log_rewind (fs/btrfs/ctree.c:1210).
      1205                     * the modification. as we're going backwards, we do the
      1206                     * opposite of each operation here.
      1207                     */
      1208                    switch (tm->op) {
      1209                    case MOD_LOG_KEY_REMOVE_WHILE_FREEING:
      1210                            BUG_ON(tm->slot < n);
      1211                            fallthrough;
      1212                    case MOD_LOG_KEY_REMOVE_WHILE_MOVING:
      1213                    case MOD_LOG_KEY_REMOVE:
      1214                            btrfs_set_node_key(eb, &tm->key, tm->slot);
    
    Here's what happens to hit that BUG_ON():
    
    1) We have one tree mod log user (through fiemap or the logical ino ioctl),
       with a sequence number of 1, so we have fs_info->tree_mod_seq == 1;
    
    2) Another task is at ctree.c:balance_level() and we have eb X currently as
       the root of the tree, and we promote its single child, eb Y, as the new
       root.
    
       Then, at ctree.c:balance_level(), we call:
    
          tree_mod_log_insert_root(eb X, eb Y, 1);
    
    3) At tree_mod_log_insert_root() we create tree mod log elements for each
       slot of eb X, of operation type MOD_LOG_KEY_REMOVE_WHILE_FREEING each
       with a ->logical pointing to ebX->start. These are placed in an array
       named tm_list.
       Lets assume there are N elements (N pointers in eb X);
    
    4) Then, still at tree_mod_log_insert_root(), we create a tree mod log
       element of operation type MOD_LOG_ROOT_REPLACE, ->logical set to
       ebY->start, ->old_root.logical set to ebX->start, ->old_root.level set
       to the level of eb X and ->generation set to the generation of eb X;
    
    5) Then tree_mod_log_insert_root() calls tree_mod_log_free_eb() with
       tm_list as argument. After that, tree_mod_log_free_eb() calls
       __tree_mod_log_insert() for each member of tm_list in reverse order,
       from highest slot in eb X, slot N - 1, to slot 0 of eb X;
    
    6) __tree_mod_log_insert() sets the sequence number of each given tree mod
       log operation - it increments fs_info->tree_mod_seq and sets
       fs_info->tree_mod_seq as the sequence number of the given tree mod log
       operation.
    
       This means that for the tm_list created at tree_mod_log_insert_root(),
       the element corresponding to slot 0 of eb X has the highest sequence
       number (1 + N), and the element corresponding to the last slot has the
       lowest sequence number (2);
    
    7) Then, after inserting tm_list's elements into the tree mod log rbtree,
       the MOD_LOG_ROOT_REPLACE element is inserted, which gets the highest
       sequence number, which is N + 2;
    
    8) Back to ctree.c:balance_level(), we free eb X by calling
       btrfs_free_tree_block() on it. Because eb X was created in the current
       transaction, has no other references and writeback did not happen for
       it, we add it back to the free space cache/tree;
    
    9) Later some other task T allocates the metadata extent from eb X, since
       it is marked as free space in the space cache/tree, and uses it as a
       node for some other btree;
    
    10) The tree mod log user task calls btrfs_search_old_slot(), which calls
        get_old_root(), and finally that calls __tree_mod_log_oldest_root()
        with time_seq == 1 and eb_root == eb Y;
    
    11) First iteration of the while loop finds the tree mod log element with
        sequence number N + 2, for the logical address of eb Y and of type
        MOD_LOG_ROOT_REPLACE;
    
    12) Because the operation type is MOD_LOG_ROOT_REPLACE, we don't break out
        of the loop, and set root_logical to point to tm->old_root.logical
        which corresponds to the logical address of eb X;
    
    13) On the next iteration of the while loop, the call to
        tree_mod_log_search_oldest() returns the smallest tree mod log element
        for the logical address of eb X, which has a sequence number of 2, an
        operation type of MOD_LOG_KEY_REMOVE_WHILE_FREEING and corresponds to
        the old slot N - 1 of eb X (eb X had N items in it before being freed);
    
    14) We then break out of the while loop and return the tree mod log operation
        of type MOD_LOG_ROOT_REPLACE (eb Y), and not the one for slot N - 1 of
        eb X, to get_old_root();
    
    15) At get_old_root(), we process the MOD_LOG_ROOT_REPLACE operation
        and set "logical" to the logical address of eb X, which was the old
        root. We then call tree_mod_log_search() passing it the logical
        address of eb X and time_seq == 1;
    
    16) Then before calling tree_mod_log_search(), task T adds a key to eb X,
        which results in adding a tree mod log operation of type
        MOD_LOG_KEY_ADD to the tree mod log - this is done at
        ctree.c:insert_ptr() - but after adding the tree mod log operation
        and before updating the number of items in eb X from 0 to 1...
    
    17) The task at get_old_root() calls tree_mod_log_search() and gets the
        tree mod log operation of type MOD_LOG_KEY_ADD just added by task T.
        Then it enters the following if branch:
    
        if (old_root && tm && tm->op != MOD_LOG_KEY_REMOVE_WHILE_FREEING) {
           (...)
        } (...)
    
        Calls read_tree_block() for eb X, which gets a reference on eb X but
        does not lock it - task T has it locked.
        Then it clones eb X while it has nritems set to 0 in its header, before
        task T sets nritems to 1 in eb X's header. From hereupon we use the
        clone of eb X which no other task has access to;
    
    18) Then we call __tree_mod_log_rewind(), passing it the MOD_LOG_KEY_ADD
        mod log operation we just got from tree_mod_log_search() in the
        previous step and the cloned version of eb X;
    
    19) At __tree_mod_log_rewind(), we set the local variable "n" to the number
        of items set in eb X's clone, which is 0. Then we enter the while loop,
        and in its first iteration we process the MOD_LOG_KEY_ADD operation,
        which just decrements "n" from 0 to (u32)-1, since "n" is declared with
        a type of u32. At the end of this iteration we call rb_next() to find the
        next tree mod log operation for eb X, that gives us the mod log operation
        of type MOD_LOG_KEY_REMOVE_WHILE_FREEING, for slot 0, with a sequence
        number of N + 1 (steps 3 to 6);
    
    20) Then we go back to the top of the while loop and trigger the following
        BUG_ON():
    
            (...)
            switch (tm->op) {
            case MOD_LOG_KEY_REMOVE_WHILE_FREEING:
                     BUG_ON(tm->slot < n);
                     fallthrough;
            (...)
    
        Because "n" has a value of (u32)-1 (4294967295) and tm->slot is 0.
    
    Fix this by taking a read lock on the extent buffer before cloning it at
    ctree.c:get_old_root(). This should be done regardless of the extent
    buffer having been freed and reused, as a concurrent task might be
    modifying it (while holding a write lock on it).
    
    Reported-by: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
    Link: https://lore.kernel.org/linux-btrfs/20210227155037.GN28049@hungrycats.org/
    Fixes: 834328a8493079 ("Btrfs: tree mod log's old roots could still be part of the tree")
    CC: stable@vger.kernel.org # 4.4+
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 78486cf1f31e3f646a981f91f4be3db62689265e
Author: Chao Yu <chao@kernel.org>
Date:   Tue Mar 16 20:30:26 2021 +0800

    zonefs: fix to update .i_wr_refcnt correctly in zonefs_open_zone()
    
    commit 6980d29ce4da223ad7f0751c7f1d61d3c6b54ab3 upstream.
    
    In zonefs_open_zone(), if opened zone count is larger than
    .s_max_open_zones threshold, we missed to recover .i_wr_refcnt,
    fix this.
    
    Fixes: b5c00e975779 ("zonefs: open/close zone on file open/close")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9c1c5e81a00250628b1dea74b815fc641ee77952
Author: Damien Le Moal <damien.lemoal@wdc.com>
Date:   Mon Mar 15 12:43:55 2021 +0900

    zonefs: prevent use of seq files as swap file
    
    commit 1601ea068b886da1f8f8d4e18b9403e9e24adef6 upstream.
    
    The sequential write constraint of sequential zone file prevent their
    use as swap files. Only allow conventional zone files to be used as swap
    files.
    
    Fixes: 8dcc1a9d90c1 ("fs: New zonefs file system")
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dfbdbf0f359abbe5005ee3d99d1923af904c8584
Author: Damien Le Moal <damien.lemoal@wdc.com>
Date:   Wed Mar 10 15:20:28 2021 +0900

    zonefs: Fix O_APPEND async write handling
    
    commit ebfd68cd0c1e81267c757332385cb96df30dacce upstream.
    
    zonefs updates the size of a sequential zone file inode only on
    completion of direct writes. When executing asynchronous append writes
    (with a file open with O_APPEND or using RWF_APPEND), the use of the
    current inode size in generic_write_checks() to set an iocb offset thus
    leads to unaligned write if an application issues an append write
    operation with another write already being executed.
    
    Fix this problem by introducing zonefs_write_checks() as a modified
    version of generic_write_checks() using the file inode wp_offset for an
    append write iocb offset. Also introduce zonefs_write_check_limits() to
    replace generic_write_check_limits() call. This zonefs special helper
    makes sure that the maximum file limit used is the maximum size of the
    file being accessed.
    
    Since zonefs_write_checks() already truncates the iov_iter, the calls
    to iov_iter_truncate() in zonefs_file_dio_write() and
    zonefs_file_buffered_write() are removed.
    
    Fixes: 8dcc1a9d90c1 ("fs: New zonefs file system")
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 38c74f2f2318b92082990865fd9eb2f24a5b7ec5
Author: Niklas Schnelle <schnelle@linux.ibm.com>
Date:   Wed Mar 10 13:46:26 2021 +0100

    s390/pci: fix leak of PCI device structure
    
    commit 0b13525c20febcfecccf6fc1db5969727401317d upstream.
    
    In commit 05bc1be6db4b2 ("s390/pci: create zPCI bus") we removed the
    pci_dev_put() call matching the earlier pci_get_slot() done as part of
    __zpci_event_availability(). This was based on the wrong understanding
    that the device_put() done as part of pci_destroy_device() would counter
    the pci_get_slot() when it only counters the initial reference. This
    same understanding and existing bad example also lead to not doing
    a pci_dev_put() in zpci_remove_device().
    
    Since releasing the PCI devices, unlike releasing the PCI slot, does not
    print any debug message for testing I added one in pci_release_dev().
    This revealed that we are indeed leaking the PCI device on PCI
    hotunplug. Further testing also revealed another missing pci_dev_put() in
    disable_slot().
    
    Fix this by adding the missing pci_dev_put() in disable_slot() and fix
    zpci_remove_device() with the correct pci_dev_put() calls. Also instead
    of calling pci_get_slot() in __zpci_event_availability() to determine if
    a PCI device is registered and then doing the same again in
    zpci_remove_device() do this once in zpci_remove_device() which makes
    sure that the pdev in __zpci_event_availability() is only used for the
    result of pci_scan_single_device() which does not need a reference count
    decremnt as its ownership goes to the PCI bus.
    
    Also move the check if zdev->zbus->bus is set into zpci_remove_device()
    since it may be that we're removing a device with devfn != 0 which never
    had a PCI bus. So we can still set the pdev->error_state to indicate
    that the device is not usable anymore, add a flag to set the error state.
    
    Fixes: 05bc1be6db4b2 ("s390/pci: create zPCI bus")
    Cc: <stable@vger.kernel.org> # 5.8+: e1bff843cde6 s390/pci: remove superfluous zdev->zbus check
    Cc: <stable@vger.kernel.org> # 5.8+: ba764dd703fe s390/pci: refactor zpci_create_device()
    Cc: <stable@vger.kernel.org> # 5.8+
    Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
    Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 075e3034740cb1910aa857e91f4010bfa2d89652
Author: Niklas Schnelle <schnelle@linux.ibm.com>
Date:   Tue Jan 19 08:49:37 2021 +0100

    s390/pci: remove superfluous zdev->zbus check
    
    commit e1bff843cde62a45a287b7f9b4cd5e824e8e49e2 upstream.
    
    Checking zdev->zbus for NULL in __zpci_event_availability() is
    superfluous as it can never be NULL at this point. While harmless this
    check causes smatch warnings because we later access zdev->zbus with
    only having checked zdev != NULL which is sufficient.
    
    The reason zdev->zbus can never be NULL is since with zdev != NULL given
    we know the zdev came from get_zdev_by_fid() and thus the zpci_list.
    Now on first glance at zpci_create_device() one may assume that there is
    a window where the zdev is in the list without a zdev, however this
    window can't overlap with __zpci_event_availability() as
    zpci_create_device() either runs on the same kthread as part of
    availability events, or during the initial CLP List PCI at which point
    the __zpci_event_availability() is not yet called as zPCI is not yet
    initialized.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bd37d9b9c4fb2bfb8d2a49f4448663720063c01a
Author: Niklas Schnelle <schnelle@linux.ibm.com>
Date:   Wed Jul 22 16:53:54 2020 +0200

    s390/pci: refactor zpci_create_device()
    
    commit ba764dd703feacb5a9c410d191af1b6cfbe96845 upstream.
    
    Currently zpci_create_device() is only called in clp_add_pci_device()
    which allocates the memory for the struct zpci_dev being created. There
    is little separation of concerns as only both functions together can
    create a zpci_dev and the only CLP specific code in
    clp_add_pci_device() is a call to clp_query_pci_fn().
    
    Improve this by removing clp_add_pci_device() and refactor
    zpci_create_device() such that it alone creates and initializes the
    zpci_dev given the FID and Function Handle. For this we need to make
    clp_query_pci_fn() non-static. While at it remove the function handle
    parameter since we can just take that from the zpci_dev. Also move
    adding to the zpci_list to after the zdev has been fully created which
    eliminates a window where a partially initialized zdev can be found by
    get_zdev_by_fid().
    
    Acked-by: Pierre Morel <pmorel@linux.ibm.com>
    Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 015916ca026680ab08c0c8e0fbca399be0240a56
Author: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Date:   Wed Mar 10 14:23:37 2021 +0100

    s390/vtime: fix increased steal time accounting
    
    commit d54cb7d54877d529bc1e0e1f47a3dd082f73add3 upstream.
    
    Commit 152e9b8676c6e ("s390/vtime: steal time exponential moving average")
    inadvertently changed the input value for account_steal_time() from
    "cputime_to_nsecs(steal)" to just "steal", resulting in broken increased
    steal time accounting.
    
    Fix this by changing it back to "cputime_to_nsecs(steal)".
    
    Fixes: 152e9b8676c6e ("s390/vtime: steal time exponential moving average")
    Cc: <stable@vger.kernel.org> # 5.1
    Reported-by: Sabine Forkel <sabine.forkel@de.ibm.com>
    Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5c0a3a331dc5e1b6e459e7d605396b9361ab4bfb
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Fri Mar 19 15:47:25 2021 +0100

    Revert "PM: runtime: Update device status before letting suppliers suspend"
    
    commit 0cab893f409c53634d0d818fa414641cbcdb0dab upstream.
    
    Revert commit 44cc89f76464 ("PM: runtime: Update device status
    before letting suppliers suspend") that introduced a race condition
    into __rpm_callback() which allowed a concurrent rpm_resume() to
    run and resume the device prematurely after its status had been
    changed to RPM_SUSPENDED by __rpm_callback().
    
    Fixes: 44cc89f76464 ("PM: runtime: Update device status before letting suppliers suspend")
    Link: https://lore.kernel.org/linux-pm/24dfb6fc-5d54-6ee2-9195-26428b7ecf8a@intel.com/
    Reported-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: 4.10+ <stable@vger.kernel.org> # 4.10+
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 68525e424175e1120bd7c68b3ecfe3018405b07f
Author: Jeremy Szu <jeremy.szu@canonical.com>
Date:   Tue Mar 16 17:42:35 2021 +0800

    ALSA: hda/realtek: fix mute/micmute LEDs for HP 850 G8
    
    commit 53b861bec737c189cc14ec3b5785d0f13445ac0f upstream.
    
    The HP EliteBook 850 G8 Notebook PC is using ALC285 codec which is
    using 0x04 to control mute LED and 0x01 to control micmute LED.
    Therefore, add a quirk to make it works.
    
    Signed-off-by: Jeremy Szu <jeremy.szu@canonical.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20210316094236.89028-1-jeremy.szu@canonical.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f086deab2c64f82a4eb88c2159674e2bfe98f8f0
Author: Jeremy Szu <jeremy.szu@canonical.com>
Date:   Tue Mar 16 15:46:24 2021 +0800

    ALSA: hda/realtek: fix mute/micmute LEDs for HP 440 G8
    
    commit e7d66cf799390166e90f9a5715f2eede4fe06d51 upstream.
    
    The HP EliteBook 840 G8 Notebook PC is using ALC236 codec which is
    using 0x02 to control mute LED and 0x01 to control micmute LED.
    Therefore, add a quirk to make it works.
    
    Signed-off-by: Jeremy Szu <jeremy.szu@canonical.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20210316074626.79895-1-jeremy.szu@canonical.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7b00df1894c6c3d72753f37358a05322c861d5dd
Author: Jeremy Szu <jeremy.szu@canonical.com>
Date:   Tue Mar 16 14:54:50 2021 +0800

    ALSA: hda/realtek: fix mute/micmute LEDs for HP 840 G8
    
    commit ca6883393f0fa7f13ec8b860dbcef423a759c4a2 upstream.
    
    The HP EliteBook 840 G8 Notebook PC is using ALC285 codec which is
    using 0x04 to control mute LED and 0x01 to control micmute LED.
    Therefore, add a quirk to make it works.
    
    Signed-off-by: Jeremy Szu <jeremy.szu@canonical.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20210316065452.75659-1-jeremy.szu@canonical.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 14af4bf8d48160cd3fa46046b425a4e14f3852bd
Author: Xiaoliang Yu <yxl_22@outlook.com>
Date:   Sat Mar 13 07:54:53 2021 +0800

    ALSA: hda/realtek: Apply headset-mic quirks for Xiaomi Redmibook Air
    
    commit e1c86210fe27428399643861b81b080eccd79f87 upstream.
    
    There is another fix for headset-mic problem on Redmibook (1d72:1602),
    it also works on Redmibook Air (1d72:1947), which has the same issue.
    
    Signed-off-by: Xiaoliang Yu <yxl_22@outlook.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/TYBP286MB02856DC016849DEA0F9B6A37EE6F9@TYBP286MB0285.JPNP286.PROD.OUTLOOK.COM
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4c698a3b8fb72b2fa8908aa752972e68d2e9987e
Author: Hui Wang <hui.wang@canonical.com>
Date:   Fri Mar 12 12:14:08 2021 +0800

    ALSA: hda: generic: Fix the micmute led init state
    
    commit 2bf44e0ee95f39cc54ea1b942f0a027e0181ca4e upstream.
    
    Recently we found the micmute led init state is not correct after
    freshly installing the ubuntu linux on a Lenovo AIO machine. The
    internal mic is not muted, but the micmute led is on and led mode is
    'follow mute'. If we mute internal mic, the led is keeping on, then
    unmute the internal mic, the led is off. And from then on, the
    micmute led will work correctly.
    
    So the micmute led init state is not correct. The led is controlled
    by codec gpio (ALC233_FIXUP_LENOVO_LINE2_MIC_HOTKEY), in the
    patch_realtek, the gpio data is set to 0x4 initially and the led is
    on with this data. In the hda_generic, the led_value is set to
    0 initially, suppose users set the 'capture switch' to on from
    user space and the micmute led should change to be off with this
    operation, but the check "if (val == spec->micmute_led.led_value)" in
    the call_micmute_led_update() will skip the led setting.
    
    To guarantee the led state will be set by the 1st time of changing
    "Capture Switch", set -1 to the init led_value.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Hui Wang <hui.wang@canonical.com>
    Link: https://lore.kernel.org/r/20210312041408.3776-1-hui.wang@canonical.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e6c7cdf0baf3ef5ea53bd16d230ff24647e5dd35
Author: Xiaoliang Yu <yxl_22@outlook.com>
Date:   Tue Mar 16 00:49:00 2021 +0800

    ALSA: hda/realtek: apply pin quirk for XiaomiNotebook Pro
    
    commit b95bc12e0412d14d5fc764f0b82631c7bcaf1959 upstream.
    
    Built-in microphone and combojack on Xiaomi Notebook Pro (1d72:1701) needs
    to be fixed, the existing quirk for Dell works well on that machine.
    
    Signed-off-by: Xiaoliang Yu <yxl_22@outlook.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/OS0P286MB02749B9E13920E6899902CD8EE6C9@OS0P286MB0274.JPNP286.PROD.OUTLOOK.COM
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cd7b17ba8e4d17d9375231cfb4b99e94c383f622
Author: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Date:   Fri Mar 12 18:34:07 2021 +0900

    ALSA: dice: fix null pointer dereference when node is disconnected
    
    commit dd7b836d6bc935df95c826f69ff4d051f5561604 upstream.
    
    When node is removed from IEEE 1394 bus, any transaction fails to the node.
    In the case, ALSA dice driver doesn't stop isochronous contexts even if
    they are running. As a result, null pointer dereference occurs in callback
    from the running context.
    
    This commit fixes the bug to release isochronous contexts always.
    
    Cc: <stable@vger.kernel.org> # v5.4 or later
    Fixes: e9f21129b8d8 ("ALSA: dice: support AMDTP domain")
    Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
    Link: https://lore.kernel.org/r/20210312093407.23437-1-o-takashi@sakamocchi.jp
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 422806f8d2893393bf1bf2519f25509850cd2213
Author: Meng Li <Meng.Li@windriver.com>
Date:   Thu Mar 11 17:12:20 2021 +0800

    spi: cadence: set cqspi to the driver_data field of struct device
    
    commit ea94191e584b146878f0b7fd4b767500d7aae870 upstream.
    
    When initialize cadence qspi controller, it is need to set cqspi
    to the driver_data field of struct device, because it will be
    used in function cqspi_remove/suspend/resume(). Otherwise, there
    will be a crash trace as below when invoking these finctions.
    
    Fixes: 31fb632b5d43 ("spi: Move cadence-quadspi driver to drivers/spi/")
    Cc: stable@vger.kernel.org
    Signed-off-by: Meng Li <Meng.Li@windriver.com>
    Link: https://lore.kernel.org/r/20210311091220.3615-1-Meng.Li@windriver.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f8d5ced57b07215b2133ea5deba98d0646318e97
Author: Shengjiu Wang <shengjiu.wang@nxp.com>
Date:   Wed Feb 24 14:57:52 2021 +0800

    ASoC: ak5558: Add MODULE_DEVICE_TABLE
    
    commit 80cffd2468ddb850e678f17841fc356930b2304a upstream.
    
    Add missed MODULE_DEVICE_TABLE for the driver can be loaded
    automatically at boot.
    
    Fixes: 920884777480 ("ASoC: ak5558: Add support for AK5558 ADC driver")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
    Link: https://lore.kernel.org/r/1614149872-25510-2-git-send-email-shengjiu.wang@nxp.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 064a7289b445f8d06bae7ab8e6388457f1fac9dd
Author: Shengjiu Wang <shengjiu.wang@nxp.com>
Date:   Wed Feb 24 14:57:51 2021 +0800

    ASoC: ak4458: Add MODULE_DEVICE_TABLE
    
    commit 4ec5b96775a88dd9b1c3ba1d23c43c478cab95a2 upstream.
    
    Add missed MODULE_DEVICE_TABLE for the driver can be loaded
    automatically at boot.
    
    Fixes: 08660086eff9 ("ASoC: ak4458: Add support for AK4458 DAC driver")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
    Link: https://lore.kernel.org/r/1614149872-25510-1-git-send-email-shengjiu.wang@nxp.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>