commit a603798fb16829e56f80f57879611e67bba4910d
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Sep 3 10:23:08 2021 +0200

    Linux 5.13.14
    
    Link: https://lore.kernel.org/r/20210901122301.984263453@linuxfoundation.org
    Tested-by: Fox Chen <foxhlchen@gmail.com>
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Justin M. Forbes <jforbes@fedoraproject.org>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 49da19a8538335d7721bcc02b830221daef840b0
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Aug 2 16:10:00 2021 +0200

    platform/x86: Make dual_accel_detect() KIOX010A + KIOX020A detect more robust
    
    commit 085fc31f81765e061c78cdcab0e5516fd672bff7 upstream.
    
    360 degree hinges devices with dual KIOX010A + KIOX020A accelerometers
    always have both a KIOX010A and a KIOX020A ACPI device (one for each
    accel).
    
    Theoretical some vendor may re-use some DSDT for a non-convertible
    stripping out just the KIOX020A ACPI device from the DSDT. Check that
    both ACPI devices are present to make the check more robust.
    
    Fixes: 153cca9caa81 ("platform/x86: Add and use a dual_accel_detect() helper")
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20210802141000.978035-1-hdegoede@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4e25ac3793f76aec260a7158f5d897133afd70da
Author: Richard Guy Briggs <rgb@redhat.com>
Date:   Mon Aug 23 22:04:09 2021 -0400

    audit: move put_tree() to avoid trim_trees refcount underflow and UAF
    
    commit 67d69e9d1a6c889d98951c1d74b19332ce0565af upstream.
    
    AUDIT_TRIM is expected to be idempotent, but multiple executions resulted
    in a refcount underflow and use-after-free.
    
    git bisect fingered commit fb041bb7c0a9 ("locking/refcount: Consolidate
    implementations of refcount_t") but this patch with its more thorough
    checking that wasn't in the x86 assembly code merely exposed a previously
    existing tree refcount imbalance in the case of tree trimming code that
    was refactored with prune_one() to remove a tree introduced in
    commit 8432c7006297 ("audit: Simplify locking around untag_chunk()")
    
    Move the put_tree() to cover only the prune_one() case.
    
    Passes audit-testsuite and 3 passes of "auditctl -t" with at least one
    directory watch.
    
    Cc: Jan Kara <jack@suse.cz>
    Cc: Will Deacon <will@kernel.org>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    Cc: Seiji Nishikawa <snishika@redhat.com>
    Cc: stable@vger.kernel.org
    Fixes: 8432c7006297 ("audit: Simplify locking around untag_chunk()")
    Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    [PM: reformatted/cleaned-up the commit description]
    Signed-off-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f8132a4726df98345594d89666f99a33fec3d00a
Author: Peter Collingbourne <pcc@google.com>
Date:   Thu Aug 26 12:46:01 2021 -0700

    net: don't unconditionally copy_from_user a struct ifreq for socket ioctls
    
    commit d0efb16294d145d157432feda83877ae9d7cdf37 upstream.
    
    A common implementation of isatty(3) involves calling a ioctl passing
    a dummy struct argument and checking whether the syscall failed --
    bionic and glibc use TCGETS (passing a struct termios), and musl uses
    TIOCGWINSZ (passing a struct winsize). If the FD is a socket, we will
    copy sizeof(struct ifreq) bytes of data from the argument and return
    -EFAULT if that fails. The result is that the isatty implementations
    may return a non-POSIX-compliant value in errno in the case where part
    of the dummy struct argument is inaccessible, as both struct termios
    and struct winsize are smaller than struct ifreq (at least on arm64).
    
    Although there is usually enough stack space following the argument
    on the stack that this did not present a practical problem up to now,
    with MTE stack instrumentation it's more likely for the copy to fail,
    as the memory following the struct may have a different tag.
    
    Fix the problem by adding an early check for whether the ioctl is a
    valid socket ioctl, and return -ENOTTY if it isn't.
    
    Fixes: 44c02a2c3dc5 ("dev_ioctl(): move copyin/copyout to callers")
    Link: https://linux-review.googlesource.com/id/I869da6cf6daabc3e4b7b82ac979683ba05e27d4d
    Signed-off-by: Peter Collingbourne <pcc@google.com>
    Cc: <stable@vger.kernel.org> # 4.19
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b58e692a685037e0c21e618ad68b28da7d70056
Author: Helge Deller <deller@gmx.de>
Date:   Fri Aug 27 20:42:57 2021 +0200

    Revert "parisc: Add assembly implementations for memset, strlen, strcpy, strncpy and strcat"
    
    commit f6a3308d6feb351d9854eb8b3f6289a1ac163125 upstream.
    
    This reverts commit 83af58f8068ea3f7b3c537c37a30887bfa585069.
    
    It turns out that at least the assembly implementation for strncpy() was
    buggy.  Revert the whole commit and return back to the default coding.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Cc: <stable@vger.kernel.org> # v5.4+
    Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9caa2e5a818dee5fce284ec426ad24dad1470d93
Author: Eric Biggers <ebiggers@google.com>
Date:   Thu Jul 1 23:53:49 2021 -0700

    ubifs: report correct st_size for encrypted symlinks
    
    commit 064c734986011390b4d111f1a99372b7f26c3850 upstream.
    
    The stat() family of syscalls report the wrong size for encrypted
    symlinks, which has caused breakage in several userspace programs.
    
    Fix this by calling fscrypt_symlink_getattr() after ubifs_getattr() for
    encrypted symlinks.  This function computes the correct size by reading
    and decrypting the symlink target (if it's not already cached).
    
    For more details, see the commit which added fscrypt_symlink_getattr().
    
    Fixes: ca7f85be8d6c ("ubifs: Add support for encrypted symlinks")
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210702065350.209646-5-ebiggers@kernel.org
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7532df5ee0853c38ad43a89c01fd304194cce140
Author: Eric Biggers <ebiggers@google.com>
Date:   Thu Jul 1 23:53:48 2021 -0700

    f2fs: report correct st_size for encrypted symlinks
    
    commit 461b43a8f92e68e96c4424b31e15f2b35f1bbfa9 upstream.
    
    The stat() family of syscalls report the wrong size for encrypted
    symlinks, which has caused breakage in several userspace programs.
    
    Fix this by calling fscrypt_symlink_getattr() after f2fs_getattr() for
    encrypted symlinks.  This function computes the correct size by reading
    and decrypting the symlink target (if it's not already cached).
    
    For more details, see the commit which added fscrypt_symlink_getattr().
    
    Fixes: cbaf042a3cc6 ("f2fs crypto: add symlink encryption")
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210702065350.209646-4-ebiggers@kernel.org
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f04584399d1cf1d4f8f4956b1b97e87dd1d6a0f1
Author: Eric Biggers <ebiggers@google.com>
Date:   Thu Jul 1 23:53:47 2021 -0700

    ext4: report correct st_size for encrypted symlinks
    
    commit 8c4bca10ceafc43b1ca0a9fab5fa27e13cbce99e upstream.
    
    The stat() family of syscalls report the wrong size for encrypted
    symlinks, which has caused breakage in several userspace programs.
    
    Fix this by calling fscrypt_symlink_getattr() after ext4_getattr() for
    encrypted symlinks.  This function computes the correct size by reading
    and decrypting the symlink target (if it's not already cached).
    
    For more details, see the commit which added fscrypt_symlink_getattr().
    
    Fixes: f348c252320b ("ext4 crypto: add symlink encryption")
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210702065350.209646-3-ebiggers@kernel.org
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2bc40caa809921c21f9b86ebb5bcc90ae56391da
Author: Eric Biggers <ebiggers@google.com>
Date:   Thu Jul 1 23:53:46 2021 -0700

    fscrypt: add fscrypt_symlink_getattr() for computing st_size
    
    commit d18760560593e5af921f51a8c9b64b6109d634c2 upstream.
    
    Add a helper function fscrypt_symlink_getattr() which will be called
    from the various filesystems' ->getattr() methods to read and decrypt
    the target of encrypted symlinks in order to report the correct st_size.
    
    Detailed explanation:
    
    As required by POSIX and as documented in various man pages, st_size for
    a symlink is supposed to be the length of the symlink target.
    Unfortunately, st_size has always been wrong for encrypted symlinks
    because st_size is populated from i_size from disk, which intentionally
    contains the length of the encrypted symlink target.  That's slightly
    greater than the length of the decrypted symlink target (which is the
    symlink target that userspace usually sees), and usually won't match the
    length of the no-key encoded symlink target either.
    
    This hadn't been fixed yet because reporting the correct st_size would
    require reading the symlink target from disk and decrypting or encoding
    it, which historically has been considered too heavyweight to do in
    ->getattr().  Also historically, the wrong st_size had only broken a
    test (LTP lstat03) and there were no known complaints from real users.
    (This is probably because the st_size of symlinks isn't used too often,
    and when it is, typically it's for a hint for what buffer size to pass
    to readlink() -- which a slightly-too-large size still works for.)
    
    However, a couple things have changed now.  First, there have recently
    been complaints about the current behavior from real users:
    
    - Breakage in rpmbuild:
      https://github.com/rpm-software-management/rpm/issues/1682
      https://github.com/google/fscrypt/issues/305
    
    - Breakage in toybox cpio:
      https://www.mail-archive.com/toybox@lists.landley.net/msg07193.html
    
    - Breakage in libgit2: https://issuetracker.google.com/issues/189629152
      (on Android public issue tracker, requires login)
    
    Second, we now cache decrypted symlink targets in ->i_link.  Therefore,
    taking the performance hit of reading and decrypting the symlink target
    in ->getattr() wouldn't be as big a deal as it used to be, since usually
    it will just save having to do the same thing later.
    
    Also note that eCryptfs ended up having to read and decrypt symlink
    targets in ->getattr() as well, to fix this same issue; see
    commit 3a60a1686f0d ("eCryptfs: Decrypt symlink target for stat size").
    
    So, let's just bite the bullet, and read and decrypt the symlink target
    in ->getattr() in order to report the correct st_size.  Add a function
    fscrypt_symlink_getattr() which the filesystems will call to do this.
    
    (Alternatively, we could store the decrypted size of symlinks on-disk.
    But there isn't a great place to do so, and encryption is meant to hide
    the original size to some extent; that property would be lost.)
    
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210702065350.209646-2-ebiggers@kernel.org
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ba17363729d21aefa58431d1dca717d96c7b5bab
Author: Denis Efremov <efremov@linux.com>
Date:   Sat Aug 7 10:37:02 2021 +0300

    Revert "floppy: reintroduce O_NDELAY fix"
    
    commit c7e9d0020361f4308a70cdfd6d5335e273eb8717 upstream.
    
    The patch breaks userspace implementations (e.g. fdutils) and introduces
    regressions in behaviour. Previously, it was possible to O_NDELAY open a
    floppy device with no media inserted or with write protected media without
    an error. Some userspace tools use this particular behavior for probing.
    
    It's not the first time when we revert this patch. Previous revert is in
    commit f2791e7eadf4 (Revert "floppy: refactor open() flags handling").
    
    This reverts commit 8a0c014cd20516ade9654fc13b51345ec58e7be8.
    
    Link: https://lore.kernel.org/linux-block/de10cb47-34d1-5a88-7751-225ca380f735@compro.net/
    Reported-by: Mark Hounschell <markh@compro.net>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Wim Osterholt <wim@djo.tudelft.nl>
    Cc: Kurt Garloff <kurt@garloff.de>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Denis Efremov <efremov@linux.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 301aabe0239f227818622096be7e180fcdbedf80
Author: Qu Wenruo <wqu@suse.com>
Date:   Fri Aug 6 18:24:15 2021 +0800

    btrfs: fix NULL pointer dereference when deleting device by invalid id
    
    commit e4571b8c5e9ffa1e85c0c671995bd4dcc5c75091 upstream.
    
    [BUG]
    It's easy to trigger NULL pointer dereference, just by removing a
    non-existing device id:
    
     # mkfs.btrfs -f -m single -d single /dev/test/scratch1 \
                                         /dev/test/scratch2
     # mount /dev/test/scratch1 /mnt/btrfs
     # btrfs device remove 3 /mnt/btrfs
    
    Then we have the following kernel NULL pointer dereference:
    
     BUG: kernel NULL pointer dereference, address: 0000000000000000
     #PF: supervisor read access in kernel mode
     #PF: error_code(0x0000) - not-present page
     PGD 0 P4D 0
     Oops: 0000 [#1] PREEMPT SMP NOPTI
     CPU: 9 PID: 649 Comm: btrfs Not tainted 5.14.0-rc3-custom+ #35
     Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
     RIP: 0010:btrfs_rm_device+0x4de/0x6b0 [btrfs]
      btrfs_ioctl+0x18bb/0x3190 [btrfs]
      ? lock_is_held_type+0xa5/0x120
      ? find_held_lock.constprop.0+0x2b/0x80
      ? do_user_addr_fault+0x201/0x6a0
      ? lock_release+0xd2/0x2d0
      ? __x64_sys_ioctl+0x83/0xb0
      __x64_sys_ioctl+0x83/0xb0
      do_syscall_64+0x3b/0x90
      entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    [CAUSE]
    Commit a27a94c2b0c7 ("btrfs: Make btrfs_find_device_by_devspec return
    btrfs_device directly") moves the "missing" device path check into
    btrfs_rm_device().
    
    But btrfs_rm_device() itself can have case where it only receives
    @devid, with NULL as @device_path.
    
    In that case, calling strcmp() on NULL will trigger the NULL pointer
    dereference.
    
    Before that commit, we handle the "missing" case inside
    btrfs_find_device_by_devspec(), which will not check @device_path at all
    if @devid is provided, thus no way to trigger the bug.
    
    [FIX]
    Before calling strcmp(), also make sure @device_path is not NULL.
    
    Fixes: a27a94c2b0c7 ("btrfs: Make btrfs_find_device_by_devspec return btrfs_device directly")
    CC: stable@vger.kernel.org # 5.4+
    Reported-by: butt3rflyh4ck <butterflyhuangxx@gmail.com>
    Reviewed-by: Anand Jain <anand.jain@oracle.com>
    Signed-off-by: Qu Wenruo <wqu@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8e2112d600b2c0152c5a75e4c61fbae6b619af61
Author: Petr Vorel <petr.vorel@gmail.com>
Date:   Thu Apr 15 21:39:13 2021 +0200

    arm64: dts: qcom: msm8994-angler: Fix gpio-reserved-ranges 85-88
    
    commit f890f89d9a80fffbfa7ca791b78927e5b8aba869 upstream.
    
    Reserve GPIO pins 85-88 as these aren't meant to be accessible from the
    application CPUs (causes reboot). Yet another fix similar to
    9134586715e3, 5f8d3ab136d0, which is needed to allow angler to boot after
    3edfb7bd76bd ("gpiolib: Show correct direction from the beginning").
    
    Fixes: feeaf56ac78d ("arm64: dts: msm8994 SoC and Huawei Angler (Nexus 6P) support")
    
    Signed-off-by: Petr Vorel <petr.vorel@gmail.com>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
    Link: https://lore.kernel.org/r/20210415193913.1836153-1-petr.vorel@gmail.com
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 98d1fcc6c937b0fd8c4ad5a9e386dd934d0c63b6
Author: DENG Qingfang <dqfext@gmail.com>
Date:   Wed Aug 11 17:50:43 2021 +0800

    net: dsa: mt7530: fix VLAN traffic leaks again
    
    commit 7428022b50d0fbb4846dd0f00639ea09d36dff02 upstream.
    
    When a port leaves a VLAN-aware bridge, the current code does not clear
    other ports' matrix field bit. If the bridge is later set to VLAN-unaware
    mode, traffic in the bridge may leak to that port.
    
    Remove the VLAN filtering check in mt7530_port_bridge_leave.
    
    Fixes: 474a2ddaa192 ("net: dsa: mt7530: fix VLAN traffic leaks")
    Fixes: 83163f7dca56 ("net: dsa: mediatek: add VLAN support for MT7530")
    Signed-off-by: DENG Qingfang <dqfext@gmail.com>
    Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 339e8ba1a3d06b50e71a202dd05523a08227bd65
Author: Pauli Virtanen <pav@iki.fi>
Date:   Mon Jul 26 21:02:06 2021 +0300

    Bluetooth: btusb: check conditions before enabling USB ALT 3 for WBS
    
    commit 55981d3541812234e687062926ff199c83f79a39 upstream.
    
    Some USB BT adapters don't satisfy the MTU requirement mentioned in
    commit e848dbd364ac ("Bluetooth: btusb: Add support USB ALT 3 for WBS")
    and have ALT 3 setting that produces no/garbled audio. Some adapters
    with larger MTU were also reported to have problems with ALT 3.
    
    Add a flag and check it and MTU before selecting ALT 3, falling back to
    ALT 1. Enable the flag for Realtek, restoring the previous behavior for
    non-Realtek devices.
    
    Tested with USB adapters (mtu<72, no/garbled sound with ALT3, ALT1
    works) BCM20702A1 0b05:17cb, CSR8510A10 0a12:0001, and (mtu>=72, ALT3
    works) RTL8761BU 0bda:8771, Intel AX200 8087:0029 (after disabling
    ALT6). Also got reports for (mtu>=72, ALT 3 reported to produce bad
    audio) Intel 8087:0a2b.
    
    Signed-off-by: Pauli Virtanen <pav@iki.fi>
    Fixes: e848dbd364ac ("Bluetooth: btusb: Add support USB ALT 3 for WBS")
    Tested-by: Michał Kępień <kernel@kempniu.pl>
    Tested-by: Jonathan Lampérth <jon@h4n.dev>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a5dfcf3d8ecc549f8dc324ab6caf9dd14de87986
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon Aug 30 08:55:18 2021 -0700

    vt_kdsetmode: extend console locking
    
    commit 2287a51ba822384834dafc1c798453375d1107c7 upstream.
    
    As per the long-suffering comment.
    
    Reported-by: Minh Yuan <yuanmingbuaa@gmail.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Jiri Slaby <jirislaby@kernel.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 65f5602cd767c384af39429cbe9ff1ecdd1d3db8
Author: Xin Long <lucien.xin@gmail.com>
Date:   Sun Aug 15 03:13:36 2021 -0400

    tipc: call tipc_wait_for_connect only when dlen is not 0
    
    commit 7387a72c5f84f0dfb57618f9e4770672c0d2e4c9 upstream.
    
    __tipc_sendmsg() is called to send SYN packet by either tipc_sendmsg()
    or tipc_connect(). The difference is in tipc_connect(), it will call
    tipc_wait_for_connect() after __tipc_sendmsg() to wait until connecting
    is done. So there's no need to wait in __tipc_sendmsg() for this case.
    
    This patch is to fix it by calling tipc_wait_for_connect() only when dlen
    is not 0 in __tipc_sendmsg(), which means it's called by tipc_connect().
    
    Note this also fixes the failure in tipcutils/test/ptts/:
    
      # ./tipcTS &
      # ./tipcTC 9
      (hang)
    
    Fixes: 36239dab6da7 ("tipc: fix implicit-connect for SYN+")
    Reported-by: Shuang Li <shuali@redhat.com>
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Acked-by: Jon Maloy <jmaloy@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b7533e796aa9dec22f7c4cd4aa36d798e5ed368
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Tue Aug 24 10:39:25 2021 -0700

    pipe: do FASYNC notifications for every pipe IO, not just state changes
    
    commit fe67f4dd8daa252eb9aa7acb61555f3cc3c1ce4c upstream.
    
    It turns out that the SIGIO/FASYNC situation is almost exactly the same
    as the EPOLLET case was: user space really wants to be notified after
    every operation.
    
    Now, in a perfect world it should be sufficient to only notify user
    space on "state transitions" when the IO state changes (ie when a pipe
    goes from unreadable to readable, or from unwritable to writable).  User
    space should then do as much as possible - fully emptying the buffer or
    what not - and we'll notify it again the next time the state changes.
    
    But as with EPOLLET, we have at least one case (stress-ng) where the
    kernel sent SIGIO due to the pipe being marked for asynchronous
    notification, but the user space signal handler then didn't actually
    necessarily read it all before returning (it read more than what was
    written, but since there could be multiple writes, it could leave data
    pending).
    
    The user space code then expected to get another SIGIO for subsequent
    writes - even though the pipe had been readable the whole time - and
    would only then read more.
    
    This is arguably a user space bug - and Colin King already fixed the
    stress-ng code in question - but the kernel regression rules are clear:
    it doesn't matter if kernel people think that user space did something
    silly and wrong.  What matters is that it used to work.
    
    So if user space depends on specific historical kernel behavior, it's a
    regression when that behavior changes.  It's on us: we were silly to
    have that non-optimal historical behavior, and our old kernel behavior
    was what user space was tested against.
    
    Because of how the FASYNC notification was tied to wakeup behavior, this
    was first broken by commits f467a6a66419 and 1b6b26ae7053 ("pipe: fix
    and clarify pipe read/write wakeup logic"), but at the time it seems
    nobody noticed.  Probably because the stress-ng problem case ends up
    being timing-dependent too.
    
    It was then unwittingly fixed by commit 3a34b13a88ca ("pipe: make pipe
    writes always wake up readers") only to be broken again when by commit
    3b844826b6c6 ("pipe: avoid unnecessary EPOLLET wakeups under normal
    loads").
    
    And at that point the kernel test robot noticed the performance
    refression in the stress-ng.sigio.ops_per_sec case.  So the "Fixes" tag
    below is somewhat ad hoc, but it matches when the issue was noticed.
    
    Fix it for good (knock wood) by simply making the kill_fasync() case
    separate from the wakeup case.  FASYNC is quite rare, and we clearly
    shouldn't even try to use the "avoid unnecessary wakeups" logic for it.
    
    Link: https://lore.kernel.org/lkml/20210824151337.GC27667@xsang-OptiPlex-9020/
    Fixes: 3b844826b6c6 ("pipe: avoid unnecessary EPOLLET wakeups under normal loads")
    Reported-by: kernel test robot <oliver.sang@intel.com>
    Tested-by: Oliver Sang <oliver.sang@intel.com>
    Cc: Eric Biederman <ebiederm@xmission.com>
    Cc: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4abb1d77321ae43f9d22e50521c05039212ad65c
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Aug 5 10:04:43 2021 -0700

    pipe: avoid unnecessary EPOLLET wakeups under normal loads
    
    commit 3b844826b6c6affa80755254da322b017358a2f4 upstream.
    
    I had forgotten just how sensitive hackbench is to extra pipe wakeups,
    and commit 3a34b13a88ca ("pipe: make pipe writes always wake up
    readers") ended up causing a quite noticeable regression on larger
    machines.
    
    Now, hackbench isn't necessarily a hugely meaningful benchmark, and it's
    not clear that this matters in real life all that much, but as Mel
    points out, it's used often enough when comparing kernels and so the
    performance regression shows up like a sore thumb.
    
    It's easy enough to fix at least for the common cases where pipes are
    used purely for data transfer, and you never have any exciting poll
    usage at all.  So set a special 'poll_usage' flag when there is polling
    activity, and make the ugly "EPOLLET has crazy legacy expectations"
    semantics explicit to only that case.
    
    I would love to limit it to just the broken EPOLLET case, but the pipe
    code can't see the difference between epoll and regular select/poll, so
    any non-read/write waiting will trigger the extra wakeup behavior.  That
    is sufficient for at least the hackbench case.
    
    Apart from making the odd extra wakeup cases more explicitly about
    EPOLLET, this also makes the extra wakeup be at the _end_ of the pipe
    write, not at the first write chunk.  That is actually much saner
    semantics (as much as you can call any of the legacy edge-triggered
    expectations for EPOLLET "sane") since it means that you know the wakeup
    will happen once the write is done, rather than possibly in the middle
    of one.
    
    [ For stable people: I'm putting a "Fixes" tag on this, but I leave it
      up to you to decide whether you actually want to backport it or not.
      It likely has no impact outside of synthetic benchmarks  - Linus ]
    
    Link: https://lore.kernel.org/lkml/20210802024945.GA8372@xsang-OptiPlex-9020/
    Fixes: 3a34b13a88ca ("pipe: make pipe writes always wake up readers")
    Reported-by: kernel test robot <oliver.sang@intel.com>
    Tested-by: Sandeep Patil <sspatil@android.com>
    Tested-by: Mel Gorman <mgorman@techsingularity.net>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eec6f991bf286e52e8c261f0998903761188c048
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Wed Aug 18 17:15:35 2021 +0100

    arm64: initialize all of CNTHCTL_EL2
    
    [ Upstream commit bde8fff82e4a4b0f000dbf4d5eadab2079be0b56 ]
    
    In __init_el2_timers we initialize CNTHCTL_EL2.{EL1PCEN,EL1PCTEN} with a
    RMW sequence, leaving all other bits UNKNOWN.
    
    In general, we should initialize all bits in a register rather than
    using an RMW sequence, since most bits are UNKNOWN out of reset, and as
    new bits are added to the reigster their reset value might not result in
    expected behaviour.
    
    In the case of CNTHCTL_EL2, FEAT_ECV added a number of new control bits
    in previously RES0 bits, which reset to UNKNOWN values, and may cause
    issues for EL1 and EL0:
    
    * CNTHCTL_EL2.ECV enables the CNTPOFF_EL2 offset (which itself resets to
      an UNKNOWN value) at EL0 and EL1. Since the offset could reset to
      distinct values across CPUs, when the control bit resets to 1 this
      could break timekeeping generally.
    
    * CNTHCTL_EL2.{EL1TVT,EL1TVCT} trap EL0 and EL1 accesses to the EL1
      virtual timer/counter registers to EL2. When reset to 1, this could
      cause unexpected traps to EL2.
    
    Initializing these bits to zero avoids these problems, and all other
    bits in CNTHCTL_EL2 other than EL1PCEN and EL1PCTEN can safely be reset
    to zero.
    
    This patch ensures we initialize CNTHCTL_EL2 accordingly, only setting
    EL1PCEN and EL1PCTEN, and setting all other bits to zero.
    
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Marc Zyngier <maz@kernel.org>
    Cc: Oliver Upton <oupton@google.com>
    Cc: Will Deacon <will@kernel.org>
    Reviewed-by: Oliver Upton <oupton@google.com>
    Acked-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20210818161535.52786-1-mark.rutland@arm.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c9ecaffe65cb81dcf5e1019367729f97acb174b1
Author: Gerd Rausch <gerd.rausch@oracle.com>
Date:   Tue Aug 17 10:04:37 2021 -0700

    net/rds: dma_map_sg is entitled to merge entries
    
    [ Upstream commit fb4b1373dcab086d0619c29310f0466a0b2ceb8a ]
    
    Function "dma_map_sg" is entitled to merge adjacent entries
    and return a value smaller than what was passed as "nents".
    
    Subsequently "ib_map_mr_sg" needs to work with this value ("sg_dma_len")
    rather than the original "nents" parameter ("sg_len").
    
    This old RDS bug was exposed and reliably causes kernel panics
    (using RDMA operations "rds-stress -D") on x86_64 starting with:
    commit c588072bba6b ("iommu/vt-d: Convert intel iommu driver to the iommu ops")
    
    Simply put: Linux 5.11 and later.
    
    Signed-off-by: Gerd Rausch <gerd.rausch@oracle.com>
    Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
    Link: https://lore.kernel.org/r/60efc69f-1f35-529d-a7ef-da0549cad143@oracle.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 66d8d0677e4db378d9a4c6dce9001b77a9a29796
Author: Thomas Weißschuh <linux@weissschuh.net>
Date:   Wed Aug 18 18:44:35 2021 +0200

    platform/x86: gigabyte-wmi: add support for B450M S2H V2
    
    [ Upstream commit 1e35b8a7780a0c043cc5389420f069b69343f5d9 ]
    
    Reported as working here:
    https://github.com/t-8ch/linux-gigabyte-wmi-driver/issues/1#issuecomment-901207693
    
    Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
    Link: https://lore.kernel.org/r/20210818164435.99821-1-linux@weissschuh.net
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b484bcabe66babd261ede1679c71677b59452ec2
Author: Ben Skeggs <bskeggs@redhat.com>
Date:   Tue Aug 10 19:29:57 2021 +1000

    drm/nouveau/kms/nv50: workaround EFI GOP window channel format differences
    
    [ Upstream commit e78b1b545c6cfe9f87fc577128e00026fff230ba ]
    
    Should fix some initial modeset failures on (at least) Ampere boards.
    
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Reviewed-by: Lyude Paul <lyude@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 045f785ad85940183164eddb7f5d987422f26d05
Author: Ben Skeggs <bskeggs@redhat.com>
Date:   Mon Aug 9 16:40:48 2021 +1000

    drm/nouveau/disp: power down unused DP links during init
    
    [ Upstream commit 6eaa1f3c59a707332e921e32782ffcad49915c5e ]
    
    When booted with multiple displays attached, the EFI GOP driver on (at
    least) Ampere, can leave DP links powered up that aren't being used to
    display anything.  This confuses our tracking of SOR routing, with the
    likely result being a failed modeset and display engine hang.
    
    Fix this by (ab?)using the DisableLT IED script to power-down the link,
    restoring HW to a state the driver expects.
    
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Reviewed-by: Lyude Paul <lyude@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4dc8c06fd51ea264ab268db5183220aadc656cb3
Author: Ben Skeggs <bskeggs@redhat.com>
Date:   Tue Aug 10 20:29:24 2021 +1000

    drm/nouveau: recognise GA107
    
    [ Upstream commit fa25f28ef2cef19bc9ffeb827b8ecbf48af7f892 ]
    
    Still no GA106 as I don't have HW to verif.
    
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Reviewed-by: Lyude Paul <lyude@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2a0e1f9a62e56a1e91490962fa3ad7e9ebd67d34
Author: Thomas Weißschuh <linux@weissschuh.net>
Date:   Tue Aug 17 17:46:28 2021 +0200

    platform/x86: gigabyte-wmi: add support for X570 GAMING X
    
    [ Upstream commit b9570f5c9240cadf87fb5f9313e8f425aa9e788f ]
    
    Reported as working here:
    https://github.com/t-8ch/linux-gigabyte-wmi-driver/issues/1#issuecomment-900263115
    
    Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
    Link: https://lore.kernel.org/r/20210817154628.84992-1-linux@weissschuh.net
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7e6c3b5c9864fe25045948d68a8b7e4244429058
Author: Mark Yacoub <markyacoub@google.com>
Date:   Thu Aug 12 15:49:17 2021 -0400

    drm: Copy drm_wait_vblank to user before returning
    
    [ Upstream commit fa0b1ef5f7a694f48e00804a391245f3471aa155 ]
    
    [Why]
    Userspace should get back a copy of drm_wait_vblank that's been modified
    even when drm_wait_vblank_ioctl returns a failure.
    
    Rationale:
    drm_wait_vblank_ioctl modifies the request and expects the user to read
    it back. When the type is RELATIVE, it modifies it to ABSOLUTE and updates
    the sequence to become current_vblank_count + sequence (which was
    RELATIVE), but now it became ABSOLUTE.
    drmWaitVBlank (in libdrm) expects this to be the case as it modifies
    the request to be Absolute so it expects the sequence to would have been
    updated.
    
    The change is in compat_drm_wait_vblank, which is called by
    drm_compat_ioctl. This change of copying the data back regardless of the
    return number makes it en par with drm_ioctl, which always copies the
    data before returning.
    
    [How]
    Return from the function after everything has been copied to user.
    
    Fixes IGT:kms_flip::modeset-vs-vblank-race-interruptible
    Tested on ChromeOS Trogdor(msm)
    
    Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
    Signed-off-by: Mark Yacoub <markyacoub@chromium.org>
    Signed-off-by: Sean Paul <seanpaul@chromium.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210812194917.1703356-1-markyacoub@chromium.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 65bafad4556d99074401cc4630027bee7b0dd09e
Author: Ming Lei <ming.lei@redhat.com>
Date:   Wed Aug 11 23:52:02 2021 +0800

    blk-mq: don't grab rq's refcount in blk_mq_check_expired()
    
    [ Upstream commit c797b40ccc340b8a66f7a7842aecc90bf749f087 ]
    
    Inside blk_mq_queue_tag_busy_iter() we already grabbed request's
    refcount before calling ->fn(), so needn't to grab it one more time
    in blk_mq_check_expired().
    
    Meantime remove extra request expire check in blk_mq_check_expired().
    
    Cc: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: John Garry <john.garry@huawei.com>
    Link: https://lore.kernel.org/r/20210811155202.629575-1-ming.lei@redhat.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1ae8c1e2dbd78a9c571c1ca4baa8cd68ed069e00
Author: Kenneth Feng <kenneth.feng@amd.com>
Date:   Fri Aug 13 14:40:18 2021 +0800

    drm/amd/pm: change the workload type for some cards
    
    [ Upstream commit 93c5701b00d50d192ce2247cb10d6c0b3fe25cd8 ]
    
    change the workload type for some cards as it is needed.
    
    Signed-off-by: Kenneth Feng <kenneth.feng@amd.com>
    Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 19be3ad020b1228acffdb705c92047f25a367311
Author: Kenneth Feng <kenneth.feng@amd.com>
Date:   Fri Aug 13 14:20:33 2021 +0800

    Revert "drm/amd/pm: fix workload mismatch on vega10"
    
    [ Upstream commit 2fd31689f9e44af949f60ff4f8aca013e628ab81 ]
    
    This reverts commit 0979d43259e13846d86ba17e451e17fec185d240.
    Revert this because it does not apply to all the cards.
    
    Signed-off-by: Kenneth Feng <kenneth.feng@amd.com>
    Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e5baac73318204908b426f1a900dc513f96de76a
Author: Shai Malin <smalin@marvell.com>
Date:   Sun Aug 15 14:06:39 2021 +0300

    qed: Fix null-pointer dereference in qed_rdma_create_qp()
    
    [ Upstream commit d33d19d313d3466abdf8b0428be7837aff767802 ]
    
    Fix a possible null-pointer dereference in qed_rdma_create_qp().
    
    Changes from V2:
    - Revert checkpatch fixes.
    
    Reported-by: TOTE Robot <oslab@tsinghua.edu.cn>
    Signed-off-by: Ariel Elior <aelior@marvell.com>
    Signed-off-by: Shai Malin <smalin@marvell.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b6d485eb00e166ce4246d3d06e8ac631b2346a5d
Author: Shai Malin <smalin@marvell.com>
Date:   Sun Aug 15 14:05:08 2021 +0300

    qed: qed ll2 race condition fixes
    
    [ Upstream commit 37110237f31105d679fc0aa7b11cdec867750ea7 ]
    
    Avoiding qed ll2 race condition and NULL pointer dereference as part
    of the remove and recovery flows.
    
    Changes form V1:
    - Change (!p_rx->set_prod_addr).
    - qed_ll2.c checkpatch fixes.
    
    Change from V2:
    - Revert "qed_ll2.c checkpatch fixes".
    
    Signed-off-by: Ariel Elior <aelior@marvell.com>
    Signed-off-by: Shai Malin <smalin@marvell.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e415d2209567dcc33ec2b78033faf19b16203d93
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Thu Aug 12 16:55:13 2021 +0200

    platform/x86: asus-nb-wmi: Add tablet_mode_sw=lid-flip quirk for the TP200s
    
    [ Upstream commit 73fcbad691110ece47a487c9e584822070e3626f ]
    
    The Asus TP200s / E205SA 360 degree hinges 2-in-1 supports reporting
    SW_TABLET_MODE info through the ASUS_WMI_DEVID_LID_FLIP WMI device-id.
    Add a quirk to enable this.
    
    BugLink: https://gitlab.freedesktop.org/libinput/libinput/-/issues/639
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20210812145513.39117-2-hdegoede@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit aa4ad193d83b64bbd2a600e55692f59d497315e4
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Thu Aug 12 16:55:12 2021 +0200

    platform/x86: asus-nb-wmi: Allow configuring SW_TABLET_MODE method with a module option
    
    [ Upstream commit 7f45621c14a209b986cd636447bb53b7f6f881c3 ]
    
    Unfortunately we have been unable to find a reliable way to detect if
    and how SW_TABLET_MODE reporting is supported, so we are relying on
    DMI quirks for this.
    
    Add a module-option to specify the SW_TABLET_MODE method so that this can
    be easily tested without needing to rebuild the kernel.
    
    BugLink: https://gitlab.freedesktop.org/libinput/libinput/-/issues/639
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20210812145513.39117-1-hdegoede@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0eeee5f085e69d8fea1c20b36ed7fe66ad74236a
Author: Michael S. Tsirkin <mst@redhat.com>
Date:   Tue Aug 10 12:26:05 2021 -0400

    tools/virtio: fix build
    
    [ Upstream commit a24ce06c70fe7df795a846ad713ccaa9b56a7666 ]
    
    We use a spinlock now so add a stub.
    Ignore bogus uninitialized variable warnings.
    
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2aef43ab6de1fb8f31cf0e84fcfa65b4e161554a
Author: Neeraj Upadhyay <neeraju@codeaurora.org>
Date:   Fri Jun 25 08:55:02 2021 +0530

    vringh: Use wiov->used to check for read/write desc order
    
    [ Upstream commit e74cfa91f42c50f7f649b0eca46aa049754ccdbd ]
    
    As __vringh_iov() traverses a descriptor chain, it populates
    each descriptor entry into either read or write vring iov
    and increments that iov's ->used member. So, as we iterate
    over a descriptor chain, at any point, (riov/wriov)->used
    value gives the number of descriptor enteries available,
    which are to be read or written by the device. As all read
    iovs must precede the write iovs, wiov->used should be zero
    when we are traversing a read descriptor. Current code checks
    for wiov->i, to figure out whether any previous entry in the
    current descriptor chain was a write descriptor. However,
    iov->i is only incremented, when these vring iovs are consumed,
    at a later point, and remain 0 in __vringh_iov(). So, correct
    the check for read and write descriptor order, to use
    wiov->used.
    
    Acked-by: Jason Wang <jasowang@redhat.com>
    Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
    Signed-off-by: Neeraj Upadhyay <neeraju@codeaurora.org>
    Link: https://lore.kernel.org/r/1624591502-4827-1-git-send-email-neeraju@codeaurora.org
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 839815ea5f1d936ad1cd2a6c8bd134990d7582df
Author: Vincent Whitchurch <vincent.whitchurch@axis.com>
Date:   Thu Jul 1 13:46:52 2021 +0200

    virtio_vdpa: reject invalid vq indices
    
    [ Upstream commit cb5d2c1f6cc0e5769099a7d44b9d08cf58cae206 ]
    
    Do not call vDPA drivers' callbacks with vq indicies larger than what
    the drivers indicate that they support.  vDPA drivers do not bounds
    check the indices.
    
    Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
    Link: https://lore.kernel.org/r/20210701114652.21956-1-vincent.whitchurch@axis.com
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2f18a3c91fded9c90f94b82f315635c58d87469a
Author: Parav Pandit <parav@nvidia.com>
Date:   Wed Jul 21 17:26:48 2021 +0300

    virtio_pci: Support surprise removal of virtio pci device
    
    [ Upstream commit 43bb40c5b92659966bdf4bfe584fde0a3575a049 ]
    
    When a virtio pci device undergo surprise removal (aka async removal in
    PCIe spec), mark the device as broken so that any upper layer drivers can
    abort any outstanding operation.
    
    When a virtio net pci device undergo surprise removal which is used by a
    NetworkManager, a below call trace was observed.
    
    kernel:watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [kworker/1:1:27059]
    watchdog: BUG: soft lockup - CPU#1 stuck for 52s! [kworker/1:1:27059]
    CPU: 1 PID: 27059 Comm: kworker/1:1 Tainted: G S      W I  L    5.13.0-hotplug+ #8
    Hardware name: Dell Inc. PowerEdge R640/0H28RR, BIOS 2.9.4 11/06/2020
    Workqueue: events linkwatch_event
    RIP: 0010:virtnet_send_command+0xfc/0x150 [virtio_net]
    Call Trace:
     virtnet_set_rx_mode+0xcf/0x2a7 [virtio_net]
     ? __hw_addr_create_ex+0x85/0xc0
     __dev_mc_add+0x72/0x80
     igmp6_group_added+0xa7/0xd0
     ipv6_mc_up+0x3c/0x60
     ipv6_find_idev+0x36/0x80
     addrconf_add_dev+0x1e/0xa0
     addrconf_dev_config+0x71/0x130
     addrconf_notify+0x1f5/0xb40
     ? rtnl_is_locked+0x11/0x20
     ? __switch_to_asm+0x42/0x70
     ? finish_task_switch+0xaf/0x2c0
     ? raw_notifier_call_chain+0x3e/0x50
     raw_notifier_call_chain+0x3e/0x50
     netdev_state_change+0x67/0x90
     linkwatch_do_dev+0x3c/0x50
     __linkwatch_run_queue+0xd2/0x220
     linkwatch_event+0x21/0x30
     process_one_work+0x1c8/0x370
     worker_thread+0x30/0x380
     ? process_one_work+0x370/0x370
     kthread+0x118/0x140
     ? set_kthread_struct+0x40/0x40
     ret_from_fork+0x1f/0x30
    
    Hence, add the ability to abort the command on surprise removal
    which prevents infinite loop and system lockup.
    
    Signed-off-by: Parav Pandit <parav@nvidia.com>
    Link: https://lore.kernel.org/r/20210721142648.1525924-5-parav@nvidia.com
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6c4072f94fabf8c21193954e477fe0c98b5e9537
Author: Parav Pandit <parav@nvidia.com>
Date:   Wed Jul 21 17:26:45 2021 +0300

    virtio: Improve vq->broken access to avoid any compiler optimization
    
    [ Upstream commit 60f0779862e4ab943810187752c462e85f5fa371 ]
    
    Currently vq->broken field is read by virtqueue_is_broken() in busy
    loop in one context by virtnet_send_command().
    
    vq->broken is set to true in other process context by
    virtio_break_device(). Reader and writer are accessing it without any
    synchronization. This may lead to a compiler optimization which may
    result to optimize reading vq->broken only once.
    
    Hence, force reading vq->broken on each invocation of
    virtqueue_is_broken() and also force writing it so that such
    update is visible to the readers.
    
    It is a theoretical fix that isn't yet encountered in the field.
    
    Signed-off-by: Parav Pandit <parav@nvidia.com>
    Link: https://lore.kernel.org/r/20210721142648.1525924-2-parav@nvidia.com
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 25d4ff7e59aa71d5e81e1e11d2364e9dcec1c25a
Author: Thara Gopinath <thara.gopinath@linaro.org>
Date:   Wed Aug 4 16:34:20 2021 -0400

    cpufreq: blocklist Qualcomm sm8150 in cpufreq-dt-platdev
    
    [ Upstream commit 5d79e5ce5489b489cbc4c327305be9dfca0fc9ce ]
    
    The Qualcomm sm8150 platform uses the qcom-cpufreq-hw driver, so
    add it to the cpufreq-dt-platdev driver's blocklist.
    
    Signed-off-by: Thara Gopinath <thara.gopinath@linaro.org>
    Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ef3738a60d1826a46e6fdc4e8dc037705b32693c
Author: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date:   Mon Jul 26 10:30:56 2021 +0200

    opp: remove WARN when no valid OPPs remain
    
    [ Upstream commit 335ffab3ef864539e814b9a2903b0ae420c1c067 ]
    
    This WARN can be triggered per-core and the stack trace is not useful.
    Replace it with plain dev_err(). Fix a comment while at it.
    
    Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 184caa4f8b83add4b988edcf8b02ab4cc2f3ecc9
Author: Yaara Baruch <yaara.baruch@intel.com>
Date:   Mon Jul 19 14:45:39 2021 +0200

    iwlwifi: add new so-jf devices
    
    [ Upstream commit 891332f697e14bfb2002f56e21d9bbd4800a7098 ]
    
    Add new so-jf devices to the driver.
    
    Signed-off-by: Yaara Baruch <yaara.baruch@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210719144523.1c9a59fd2760.If5aef1942007828210f0f2c4a17985f63050bb45@changeid
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eed3c6bb51fef0cc957e55ea9086980858bbd63f
Author: Yaara Baruch <yaara.baruch@intel.com>
Date:   Mon Jul 19 14:45:38 2021 +0200

    iwlwifi: add new SoF with JF devices
    
    [ Upstream commit a5bf1d4434b93394fa37494d78fe9f3513557185 ]
    
    Add new SoF JF devices to the driver.
    
    Signed-off-by: Yaara Baruch <yaara.baruch@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210719144523.0545d8964ff2.I3498879d8c184e42b1578a64aa7b7c99a18b75fb@changeid
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0dabf99c08decfbbaf05e695b9df1d4e89842a0f
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon Jul 19 14:01:56 2021 +0200

    iwlwifi: pnvm: accept multiple HW-type TLVs
    
    [ Upstream commit 0f673c16c850250db386537a422c11d248fb123c ]
    
    Some products (So) may have two different types of products
    with different mac-type that are otherwise equivalent, and
    have the same PNVM data, so the PNVM file will contain two
    (or perhaps later more) HW-type TLVs. Accept the file and
    use the data section that contains any matching entry.
    
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210719140154.a6a86e903035.Ic0b1b75c45d386698859f251518e8a5144431938@changeid
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2fcb7f101fa20eaf10c1eb3cdd12113badd2f469
Author: Adam Ford <aford173@gmail.com>
Date:   Thu Aug 26 09:17:21 2021 -0500

    clk: renesas: rcar-usb2-clock-sel: Fix kernel NULL pointer dereference
    
    [ Upstream commit 1669a941f7c4844ae808cf441db51dde9e94db07 ]
    
    The probe was manually passing NULL instead of dev to devm_clk_hw_register.
    This caused a Unable to handle kernel NULL pointer dereference error.
    Fix this by passing 'dev'.
    
    Signed-off-by: Adam Ford <aford173@gmail.com>
    Fixes: a20a40a8bbc2 ("clk: renesas: rcar-usb2-clock-sel: Fix error handling in .probe()")
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0298f03cf8ee54b74e2971d90f88e6f601c9d3bd
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date:   Thu Aug 26 15:37:38 2021 +0200

    sched: Fix get_push_task() vs migrate_disable()
    
    [ Upstream commit e681dcbaa4b284454fecd09617f8b24231448446 ]
    
    push_rt_task() attempts to move the currently running task away if the
    next runnable task has migration disabled and therefore is pinned on the
    current CPU.
    
    The current task is retrieved via get_push_task() which only checks for
    nr_cpus_allowed == 1, but does not check whether the task has migration
    disabled and therefore cannot be moved either. The consequence is a
    pointless invocation of the migration thread which correctly observes
    that the task cannot be moved.
    
    Return NULL if the task has migration disabled and cannot be moved to
    another CPU.
    
    Fixes: a7c81556ec4d3 ("sched: Fix migrate_disable() vs rt/dl balancing")
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lkml.kernel.org/r/20210826133738.yiotqbtdaxzjsnfj@linutronix.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 886364f99b7cb77c4e13940b451c7659ca674f7e
Author: Colin Ian King <colin.king@canonical.com>
Date:   Tue Jul 6 12:45:53 2021 +0100

    perf/x86/intel/uncore: Fix integer overflow on 23 bit left shift of a u32
    
    [ Upstream commit 0b3a8738b76fe2087f7bc2bd59f4c78504c79180 ]
    
    The u32 variable pci_dword is being masked with 0x1fffffff and then left
    shifted 23 places. The shift is a u32 operation,so a value of 0x200 or
    more in pci_dword will overflow the u32 and only the bottow 32 bits
    are assigned to addr. I don't believe this was the original intent.
    Fix this by casting pci_dword to a resource_size_t to ensure no
    overflow occurs.
    
    Note that the mask and 12 bit left shift operation does not need this
    because the mask SNR_IMC_MMIO_MEM0_MASK and shift is always a 32 bit
    value.
    
    Fixes: ee49532b38dd ("perf/x86/intel/uncore: Add IMC uncore support for Snow Ridge")
    Addresses-Coverity: ("Unintentional integer overflow")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Reviewed-by: Kan Liang <kan.liang@linux.intel.com>
    Link: https://lore.kernel.org/r/20210706114553.28249-1-colin.king@canonical.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6e6822e47ee3c70399c74e0c66cffa90c7082ead
Author: Jerome Brunet <jbrunet@baylibre.com>
Date:   Fri Aug 27 11:29:27 2021 +0200

    usb: gadget: u_audio: fix race condition on endpoint stop
    
    [ Upstream commit 068fdad20454f815e61e6f6eb9f051a8b3120e88 ]
    
    If the endpoint completion callback is call right after the ep_enabled flag
    is cleared and before usb_ep_dequeue() is call, we could do a double free
    on the request and the associated buffer.
    
    Fix this by clearing ep_enabled after all the endpoint requests have been
    dequeued.
    
    Fixes: 7de8681be2cd ("usb: gadget: u_audio: Free requests only after callback")
    Cc: stable <stable@vger.kernel.org>
    Reported-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
    Link: https://lore.kernel.org/r/20210827092927.366482-1-jbrunet@baylibre.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0b3d2bfa79062365176290485645c13616a3edd5
Author: Wong Vee Khee <vee.khee.wong@linux.intel.com>
Date:   Fri Aug 20 21:26:22 2021 +0800

    net: stmmac: fix kernel panic due to NULL pointer dereference of plat->est
    
    [ Upstream commit 82a44ae113b7b35850f4542f0443fcab221e376a ]
    
    In the case of taprio offload is not enabled, the error handling path
    causes a kernel crash due to kernel NULL pointer deference.
    
    Fix this by adding check for NULL before attempt to access 'plat->est'
    on the mutex_lock() call.
    
    The following kernel panic is observed without this patch:
    
    RIP: 0010:mutex_lock+0x10/0x20
    Call Trace:
    tc_setup_taprio+0x482/0x560 [stmmac]
    kmem_cache_alloc_trace+0x13f/0x490
    taprio_disable_offload.isra.0+0x9d/0x180 [sch_taprio]
    taprio_destroy+0x6c/0x100 [sch_taprio]
    qdisc_create+0x2e5/0x4f0
    tc_modify_qdisc+0x126/0x740
    rtnetlink_rcv_msg+0x12b/0x380
    _raw_spin_lock_irqsave+0x19/0x40
    _raw_spin_unlock_irqrestore+0x18/0x30
    create_object+0x212/0x340
    rtnl_calcit.isra.0+0x110/0x110
    netlink_rcv_skb+0x50/0x100
    netlink_unicast+0x191/0x230
    netlink_sendmsg+0x243/0x470
    sock_sendmsg+0x5e/0x60
    ____sys_sendmsg+0x20b/0x280
    copy_msghdr_from_user+0x5c/0x90
    __mod_memcg_state+0x87/0xf0
     ___sys_sendmsg+0x7c/0xc0
    lru_cache_add+0x7f/0xa0
    _raw_spin_unlock+0x16/0x30
    wp_page_copy+0x449/0x890
    handle_mm_fault+0x921/0xfc0
    __sys_sendmsg+0x59/0xa0
    do_syscall_64+0x33/0x40
    entry_SYSCALL_64_after_hwframe+0x44/0xa9
    ---[ end trace b1f19b24368a96aa ]---
    
    Fixes: b60189e0392f ("net: stmmac: Integrate EST with TAPRIO scheduler API")
    Cc: <stable@vger.kernel.org> # 5.10.x
    Signed-off-by: Wong Vee Khee <vee.khee.wong@linux.intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5ce4cc16d47186f0b76254e6f27beea25bafc1d9
Author: Xiaoliang Yang <xiaoliang.yang_1@nxp.com>
Date:   Mon Jul 5 18:26:54 2021 +0800

    net: stmmac: add mutex lock to protect est parameters
    
    [ Upstream commit b2aae654a4794ef898ad33a179f341eb610f6b85 ]
    
    Add a mutex lock to protect est structure parameters so that the
    EST parameters can be updated by other threads.
    
    Signed-off-by: Xiaoliang Yang <xiaoliang.yang_1@nxp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 01e5bad5b6b81dd7691356ff3e3a3d5ce8675218
Author: Ulf Hansson <ulf.hansson@linaro.org>
Date:   Fri Aug 27 16:30:36 2021 +0200

    Revert "mmc: sdhci-iproc: Set SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN on BCM2711"
    
    [ Upstream commit 885814a97f5a1a2daf66bde5f2076f0bf632c174 ]
    
    This reverts commit 419dd626e357e89fc9c4e3863592c8b38cfe1571.
    
    It turned out that the change from the reverted commit breaks the ACPI
    based rpi's because it causes the 100Mhz max clock to be overridden to the
    return from sdhci_iproc_get_max_clock(), which is 0 because there isn't a
    OF/DT based clock device.
    
    Reported-by: Jeremy Linton <jeremy.linton@arm.com>
    Fixes: 419dd626e357 ("mmc: sdhci-iproc: Set SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN on BCM2711")
    Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fd8b3da890963f9aa67228b948bb8c3c159da0e1
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Thu Aug 26 13:53:24 2021 +0300

    media: ipu3-cio2: Drop reference on error path in cio2_bridge_connect_sensor()
    
    [ Upstream commit 294c34e704e78d641b039064ce72d4531afe0088 ]
    
    The commit 71f642833284 ("ACPI: utils: Fix reference counting in
    for_each_acpi_dev_match()") moved adev assignment outside of error
    path and hence made acpi_dev_put(sensor->adev) a no-op. We still
    need to drop reference count on error path, and to achieve that,
    replace sensor->adev by locally assigned adev.
    
    Fixes: 71f642833284 ("ACPI: utils: Fix reference counting in for_each_acpi_dev_match()")
    Depends-on: fc68f42aa737 ("ACPI: fix NULL pointer dereference")
    Reported-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 229db408796c5ad8979b41cd21ce4c6cc37ebcc7
Author: Guangbin Huang <huangguangbin2@huawei.com>
Date:   Thu Aug 26 19:22:01 2021 +0800

    net: hns3: fix get wrong pfc_en when query PFC configuration
    
    [ Upstream commit 8c1671e0d13d4a0ba4fb3a0da932bf3736d7ff73 ]
    
    Currently, when query PFC configuration by dcbtool, driver will return
    PFC enable status based on TC. As all priorities are mapped to TC0 by
    default, if TC0 is enabled, then all priorities mapped to TC0 will be
    shown as enabled status when query PFC setting, even though some
    priorities have never been set.
    
    for example:
    $ dcb pfc show dev eth0
    pfc-cap 4 macsec-bypass off delay 0
    prio-pfc 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off
    $ dcb pfc set dev eth0 prio-pfc 0:on 1:on 2:on 3:on
    $ dcb pfc show dev eth0
    pfc-cap 4 macsec-bypass off delay 0
    prio-pfc 0:on 1:on 2:on 3:on 4:on 5:on 6:on 7:on
    
    To fix this problem, just returns user's PFC config parameter saved in
    driver.
    
    Fixes: cacde272dd00 ("net: hns3: Add hclge_dcb module for the support of DCB feature")
    Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6434d7a172723fbd0e06cc4570a0bc9a0654ac50
Author: Guojia Liao <liaoguojia@huawei.com>
Date:   Thu Aug 26 19:21:58 2021 +0800

    net: hns3: fix duplicate node in VLAN list
    
    [ Upstream commit 94391fae82f71c98ecc7716a32611fcca73c74eb ]
    
    VLAN list should not be added duplicate VLAN node, otherwise it would
    cause "add failed" when restore VLAN from VLAN list, so this patch adds
    VLAN ID check before adding node into VLAN list.
    
    Fixes: c6075b193462 ("net: hns3: Record VF vlan tables")
    Signed-off-by: Guojia Liao <liaoguojia@huawei.com>
    Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5d73c3788d73326b0eeae72077d4cd87446fe4c5
Author: Yonglong Liu <liuyonglong@huawei.com>
Date:   Thu Aug 26 19:21:57 2021 +0800

    net: hns3: fix speed unknown issue in bond 4
    
    [ Upstream commit b15c072a9f4a404c09ad589477f4389034742a8b ]
    
    In bond 4, when the link goes down and up repeatedly, the bond may get an
    unknown speed, and then this port can not work.
    
    The driver notify netif_carrier_on() before update the link state, when the
    bond receive carrier on, will query the speed of the port, if the query
    operation happens before updating the link state, will get an unknown
    speed. So need to notify netif_carrier_on() after update the link state.
    
    Fixes: 46a3df9f9718 ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support")
    Fixes: e2cb1dec9779 ("net: hns3: Add HNS3 VF HCL(Hardware Compatibility Layer) Support")
    Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
    Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 728d196fe469bbd6fbc38c44ccb5d188575da04d
Author: Yufeng Mo <moyufeng@huawei.com>
Date:   Thu Aug 26 19:21:56 2021 +0800

    net: hns3: add waiting time before cmdq memory is released
    
    [ Upstream commit a96d9330b02a3d051ae689bc2c5e7d3a2ba25594 ]
    
    After the cmdq registers are cleared, the firmware may take time to
    clear out possible left over commands in the cmdq. Driver must release
    cmdq memory only after firmware has completed processing of left over
    commands.
    
    Fixes: 232d0d55fca6 ("net: hns3: uninitialize command queue while unloading PF driver")
    Signed-off-by: Yufeng Mo <moyufeng@huawei.com>
    Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 13c1896f8ace73769e5b552cf66d0966e4d35d1e
Author: Yufeng Mo <moyufeng@huawei.com>
Date:   Thu Aug 26 19:21:55 2021 +0800

    net: hns3: clear hardware resource when loading driver
    
    [ Upstream commit 1a6d281946c330cee2855f6d0cd796616e54601f ]
    
    If a PF is bonded to a virtual machine and the virtual machine exits
    unexpectedly, some hardware resource cannot be cleared. In this case,
    loading driver may cause exceptions. Therefore, the hardware resource
    needs to be cleared when the driver is loaded.
    
    Fixes: 46a3df9f9718 ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support")
    Signed-off-by: Yufeng Mo <moyufeng@huawei.com>
    Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
    Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6e472c800e5cfa2fad259324df1ee23a4d789f91
Author: Andrey Ignatov <rdna@fb.com>
Date:   Wed Aug 25 17:25:40 2021 -0700

    rtnetlink: Return correct error on changing device netns
    
    [ Upstream commit 96a6b93b69880b2c978e1b2be9cae6970b605008 ]
    
    Currently when device is moved between network namespaces using
    RTM_NEWLINK message type and one of netns attributes (FLA_NET_NS_PID,
    IFLA_NET_NS_FD, IFLA_TARGET_NETNSID) but w/o specifying IFLA_IFNAME, and
    target namespace already has device with same name, userspace will get
    EINVAL what is confusing and makes debugging harder.
    
    Fix it so that userspace gets more appropriate EEXIST instead what makes
    debugging much easier.
    
    Before:
    
      # ./ifname.sh
      + ip netns add ns0
      + ip netns exec ns0 ip link add l0 type dummy
      + ip netns exec ns0 ip link show l0
      8: l0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
          link/ether 66:90:b5:d5:78:69 brd ff:ff:ff:ff:ff:ff
      + ip link add l0 type dummy
      + ip link show l0
      10: l0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
          link/ether 6e:c6:1f:15:20:8d brd ff:ff:ff:ff:ff:ff
      + ip link set l0 netns ns0
      RTNETLINK answers: Invalid argument
    
    After:
    
      # ./ifname.sh
      + ip netns add ns0
      + ip netns exec ns0 ip link add l0 type dummy
      + ip netns exec ns0 ip link show l0
      8: l0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
          link/ether 1e:4a:72:e3:e3:8f brd ff:ff:ff:ff:ff:ff
      + ip link add l0 type dummy
      + ip link show l0
      10: l0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
          link/ether f2:fc:fe:2b:7d:a6 brd ff:ff:ff:ff:ff:ff
      + ip link set l0 netns ns0
      RTNETLINK answers: File exists
    
    The problem is that do_setlink() passes its `char *ifname` argument,
    that it gets from a caller, to __dev_change_net_namespace() as is (as
    `const char *pat`), but semantics of ifname and pat can be different.
    
    For example, __rtnl_newlink() does this:
    
    net/core/rtnetlink.c
        3270        char ifname[IFNAMSIZ];
         ...
        3286        if (tb[IFLA_IFNAME])
        3287                nla_strscpy(ifname, tb[IFLA_IFNAME], IFNAMSIZ);
        3288        else
        3289                ifname[0] = '\0';
         ...
        3364        if (dev) {
         ...
        3394                return do_setlink(skb, dev, ifm, extack, tb, ifname, status);
        3395        }
    
    , i.e. do_setlink() gets ifname pointer that is always valid no matter
    if user specified IFLA_IFNAME or not and then do_setlink() passes this
    ifname pointer as is to __dev_change_net_namespace() as pat argument.
    
    But the pat (pattern) in __dev_change_net_namespace() is used as:
    
    net/core/dev.c
       11198        err = -EEXIST;
       11199        if (__dev_get_by_name(net, dev->name)) {
       11200                /* We get here if we can't use the current device name */
       11201                if (!pat)
       11202                        goto out;
       11203                err = dev_get_valid_name(net, dev, pat);
       11204                if (err < 0)
       11205                        goto out;
       11206        }
    
    As the result the `goto out` path on line 11202 is neven taken and
    instead of returning EEXIST defined on line 11198,
    __dev_change_net_namespace() returns an error from dev_get_valid_name()
    and this, in turn, will be EINVAL for ifname[0] = '\0' set earlier.
    
    Fixes: d8a5ec672768 ("[NET]: netlink support for moving devices between network namespaces.")
    Signed-off-by: Andrey Ignatov <rdna@fb.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8f4e74663b4157fcad0c0d8c5ed40d9da5b81544
Author: Kurt Kanzenbach <kurt@linutronix.de>
Date:   Wed Aug 25 15:58:13 2021 +0200

    net: dsa: hellcreek: Adjust schedule look ahead window
    
    [ Upstream commit b7658ed35a5f5900f0f658e375f366513f3eb781 ]
    
    Traffic schedules can only be started up to eight seconds within the
    future. Therefore, the driver periodically checks every two seconds whether the
    admin base time provided by the user is inside that window. If so the schedule
    is started. Otherwise the check is deferred.
    
    However, according to the programming manual the look ahead window size should
    be four - not eight - seconds. By using the proposed value of four seconds
    starting a schedule at a specified admin base time actually works as expected.
    
    Fixes: 24dfc6eb39b2 ("net: dsa: hellcreek: Add TAPRIO offloading support")
    Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 35844a1bde106193258845bb6e8b63f8ba796cd9
Author: Kurt Kanzenbach <kurt@linutronix.de>
Date:   Wed Aug 25 15:58:12 2021 +0200

    net: dsa: hellcreek: Fix incorrect setting of GCL
    
    [ Upstream commit a7db5ed8632c88c029254d5d74765d52614af3fd ]
    
    Currently the gate control list which is programmed into the hardware is
    incorrect resulting in wrong traffic schedules. The problem is the loop
    variables are incremented before they are referenced. Therefore, move the
    increment to the end of the loop.
    
    Fixes: 24dfc6eb39b2 ("net: dsa: hellcreek: Add TAPRIO offloading support")
    Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7d1b598f92d78557af1e0b69ae9accba8f61b3f1
Author: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Date:   Thu Aug 26 02:59:42 2021 +0530

    cxgb4: dont touch blocked freelist bitmap after free
    
    [ Upstream commit 43fed4d48d325e0a61dc2638a84da972fbb1087b ]
    
    When adapter init fails, the blocked freelist bitmap is already freed
    up and should not be touched. So, move the bitmap zeroing closer to
    where it was successfully allocated. Also handle adapter init failure
    unwind path immediately and avoid setting up RDMA memory windows.
    
    Fixes: 5b377d114f2b ("cxgb4: Add debugfs facility to inject FL starvation")
    Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fc21a98484caf5c63d356868fabd622e813d91a6
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Aug 25 16:17:29 2021 -0700

    ipv4: use siphash instead of Jenkins in fnhe_hashfun()
    
    [ Upstream commit 6457378fe796815c973f631a1904e147d6ee33b1 ]
    
    A group of security researchers brought to our attention
    the weakness of hash function used in fnhe_hashfun().
    
    Lets use siphash instead of Jenkins Hash, to considerably
    reduce security risks.
    
    Also remove the inline keyword, this really is distracting.
    
    Fixes: d546c621542d ("ipv4: harden fnhe_hashfun()")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Keyu Man <kman001@ucr.edu>
    Cc: Willy Tarreau <w@1wt.eu>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b3f99fcc204b8f05a924922fdeb17f9be968137f
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Aug 25 16:17:28 2021 -0700

    ipv6: use siphash in rt6_exception_hash()
    
    [ Upstream commit 4785305c05b25a242e5314cc821f54ade4c18810 ]
    
    A group of security researchers brought to our attention
    the weakness of hash function used in rt6_exception_hash()
    
    Lets use siphash instead of Jenkins Hash, to considerably
    reduce security risks.
    
    Following patch deals with IPv4.
    
    Fixes: 35732d01fe31 ("ipv6: introduce a hash table to store dst cache")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Keyu Man <kman001@ucr.edu>
    Cc: Wei Wang <weiwan@google.com>
    Cc: Martin KaFai Lau <kafai@fb.com>
    Acked-by: Wei Wang <weiwan@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1a72ef276754bda2f894988a988d376d38dd5a2c
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Wed Aug 25 15:33:14 2021 -0400

    SUNRPC: Fix XPT_BUSY flag leakage in svc_handle_xprt()...
    
    [ Upstream commit 062b829c52ef4ed5df14f4850fc07651bb7c3b33 ]
    
    If the attempt to reserve a slot fails, we currently leak the XPT_BUSY
    flag on the socket. Among other things, this make it impossible to close
    the socket.
    
    Fixes: 82011c80b3ec ("SUNRPC: Move svc_xprt_received() call sites")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d05330672afe2e142ba97e63bd7c1faef76781bb
Author: Davide Caratti <dcaratti@redhat.com>
Date:   Wed Aug 25 00:33:48 2021 +0200

    net/sched: ets: fix crash when flipping from 'strict' to 'quantum'
    
    [ Upstream commit cd9b50adc6bb9ad3f7d244590a389522215865c4 ]
    
    While running kselftests, Hangbin observed that sch_ets.sh often crashes,
    and splats like the following one are seen in the output of 'dmesg':
    
     BUG: kernel NULL pointer dereference, address: 0000000000000000
     #PF: supervisor read access in kernel mode
     #PF: error_code(0x0000) - not-present page
     PGD 159f12067 P4D 159f12067 PUD 159f13067 PMD 0
     Oops: 0000 [#1] SMP NOPTI
     CPU: 2 PID: 921 Comm: tc Not tainted 5.14.0-rc6+ #458
     Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014
     RIP: 0010:__list_del_entry_valid+0x2d/0x50
     Code: 48 8b 57 08 48 b9 00 01 00 00 00 00 ad de 48 39 c8 0f 84 ac 6e 5b 00 48 b9 22 01 00 00 00 00 ad de 48 39 ca 0f 84 cf 6e 5b 00 <48> 8b 32 48 39 fe 0f 85 af 6e 5b 00 48 8b 50 08 48 39 f2 0f 85 94
     RSP: 0018:ffffb2da005c3890 EFLAGS: 00010217
     RAX: 0000000000000000 RBX: ffff9073ba23f800 RCX: dead000000000122
     RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffff9073ba23fbc8
     RBP: ffff9073ba23f890 R08: 0000000000000001 R09: 0000000000000001
     R10: 0000000000000001 R11: 0000000000000001 R12: dead000000000100
     R13: ffff9073ba23fb00 R14: 0000000000000002 R15: 0000000000000002
     FS:  00007f93e5564e40(0000) GS:ffff9073bba00000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 0000000000000000 CR3: 000000014ad34000 CR4: 0000000000350ee0
     Call Trace:
      ets_qdisc_reset+0x6e/0x100 [sch_ets]
      qdisc_reset+0x49/0x1d0
      tbf_reset+0x15/0x60 [sch_tbf]
      qdisc_reset+0x49/0x1d0
      dev_reset_queue.constprop.42+0x2f/0x90
      dev_deactivate_many+0x1d3/0x3d0
      dev_deactivate+0x56/0x90
      qdisc_graft+0x47e/0x5a0
      tc_get_qdisc+0x1db/0x3e0
      rtnetlink_rcv_msg+0x164/0x4c0
      netlink_rcv_skb+0x50/0x100
      netlink_unicast+0x1a5/0x280
      netlink_sendmsg+0x242/0x480
      sock_sendmsg+0x5b/0x60
      ____sys_sendmsg+0x1f2/0x260
      ___sys_sendmsg+0x7c/0xc0
      __sys_sendmsg+0x57/0xa0
      do_syscall_64+0x3a/0x80
      entry_SYSCALL_64_after_hwframe+0x44/0xae
     RIP: 0033:0x7f93e44b8338
     Code: 89 02 48 c7 c0 ff ff ff ff eb b5 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 25 43 2c 00 8b 00 85 c0 75 17 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 41 89 d4 55
     RSP: 002b:00007ffc0db737a8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
     RAX: ffffffffffffffda RBX: 0000000061255c06 RCX: 00007f93e44b8338
     RDX: 0000000000000000 RSI: 00007ffc0db73810 RDI: 0000000000000003
     RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
     R10: 000000000000000b R11: 0000000000000246 R12: 0000000000000001
     R13: 0000000000687880 R14: 0000000000000000 R15: 0000000000000000
     Modules linked in: sch_ets sch_tbf dummy rfkill iTCO_wdt iTCO_vendor_support intel_rapl_msr intel_rapl_common joydev i2c_i801 pcspkr i2c_smbus lpc_ich virtio_balloon ip_tables xfs libcrc32c crct10dif_pclmul crc32_pclmul crc32c_intel ahci libahci ghash_clmulni_intel libata serio_raw virtio_blk virtio_console virtio_net net_failover failover sunrpc dm_mirror dm_region_hash dm_log dm_mod
     CR2: 0000000000000000
    
    When the change() function decreases the value of 'nstrict', we must take
    into account that packets might be already enqueued on a class that flips
    from 'strict' to 'quantum': otherwise that class will not be added to the
    bandwidth-sharing list. Then, a call to ets_qdisc_reset() will attempt to
    do list_del(&alist) with 'alist' filled with zero, hence the NULL pointer
    dereference.
    For classes flipping from 'strict' to 'quantum', initialize an empty list
    and eventually add it to the bandwidth-sharing list, if there are packets
    already enqueued. In this way, the kernel will:
     a) prevent crashing as described above.
     b) avoid retaining the backlog packets (for an arbitrarily long time) in
        case no packet is enqueued after a change from 'strict' to 'quantum'.
    
    Reported-by: Hangbin Liu <liuhangbin@gmail.com>
    Fixes: dcc68b4d8084 ("net: sch_ets: Add a new Qdisc")
    Signed-off-by: Davide Caratti <dcaratti@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6faa3f1424f1a0715a0f5640158a2109acb56781
Author: Alexey Gladkov <legion@kernel.org>
Date:   Mon Aug 23 18:16:33 2021 +0200

    ucounts: Increase ucounts reference counter before the security hook
    
    [ Upstream commit bbb6d0f3e1feb43d663af089c7dedb23be6a04fb ]
    
    We need to increment the ucounts reference counter befor security_prepare_creds()
    because this function may fail and abort_creds() will try to decrement
    this reference.
    
    [   96.465056][ T8641] FAULT_INJECTION: forcing a failure.
    [   96.465056][ T8641] name fail_page_alloc, interval 1, probability 0, space 0, times 0
    [   96.478453][ T8641] CPU: 1 PID: 8641 Comm: syz-executor668 Not tainted 5.14.0-rc6-syzkaller #0
    [   96.487215][ T8641] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    [   96.497254][ T8641] Call Trace:
    [   96.500517][ T8641]  dump_stack_lvl+0x1d3/0x29f
    [   96.505758][ T8641]  ? show_regs_print_info+0x12/0x12
    [   96.510944][ T8641]  ? log_buf_vmcoreinfo_setup+0x498/0x498
    [   96.516652][ T8641]  should_fail+0x384/0x4b0
    [   96.521141][ T8641]  prepare_alloc_pages+0x1d1/0x5a0
    [   96.526236][ T8641]  __alloc_pages+0x14d/0x5f0
    [   96.530808][ T8641]  ? __rmqueue_pcplist+0x2030/0x2030
    [   96.536073][ T8641]  ? lockdep_hardirqs_on_prepare+0x3e2/0x750
    [   96.542056][ T8641]  ? alloc_pages+0x3f3/0x500
    [   96.546635][ T8641]  allocate_slab+0xf1/0x540
    [   96.551120][ T8641]  ___slab_alloc+0x1cf/0x350
    [   96.555689][ T8641]  ? kzalloc+0x1d/0x30
    [   96.559740][ T8641]  __kmalloc+0x2e7/0x390
    [   96.563980][ T8641]  ? kzalloc+0x1d/0x30
    [   96.568029][ T8641]  kzalloc+0x1d/0x30
    [   96.571903][ T8641]  security_prepare_creds+0x46/0x220
    [   96.577174][ T8641]  prepare_creds+0x411/0x640
    [   96.581747][ T8641]  __sys_setfsuid+0xe2/0x3a0
    [   96.586333][ T8641]  do_syscall_64+0x3d/0xb0
    [   96.590739][ T8641]  entry_SYSCALL_64_after_hwframe+0x44/0xae
    [   96.596611][ T8641] RIP: 0033:0x445a69
    [   96.600483][ T8641] Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 11 15 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
    [   96.620152][ T8641] RSP: 002b:00007f1054173318 EFLAGS: 00000246 ORIG_RAX: 000000000000007a
    [   96.628543][ T8641] RAX: ffffffffffffffda RBX: 00000000004ca4c8 RCX: 0000000000445a69
    [   96.636600][ T8641] RDX: 0000000000000010 RSI: 00007f10541732f0 RDI: 0000000000000000
    [   96.644550][ T8641] RBP: 00000000004ca4c0 R08: 0000000000000001 R09: 0000000000000000
    [   96.652500][ T8641] R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004ca4cc
    [   96.660631][ T8641] R13: 00007fffffe0b62f R14: 00007f1054173400 R15: 0000000000022000
    
    Fixes: 905ae01c4ae2 ("Add a reference to ucounts for each cred")
    Reported-by: syzbot+01985d7909f9468f013c@syzkaller.appspotmail.com
    Signed-off-by: Alexey Gladkov <legion@kernel.org>
    Link: https://lkml.kernel.org/r/97433b1742c3331f02ad92de5a4f07d673c90613.1629735352.git.legion@kernel.org
    Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 768d4cf8dbaf1d4fb8e287ebcc01cfc719e081bc
Author: Maxim Kiselev <bigunclemax@gmail.com>
Date:   Fri Aug 20 18:39:51 2021 +0300

    net: marvell: fix MVNETA_TX_IN_PRGRS bit number
    
    [ Upstream commit 359f4cdd7d78fdf8c098713b05fee950a730f131 ]
    
    According to Armada XP datasheet bit at 0 position is corresponding for
    TxInProg indication.
    
    Fixes: c5aff18204da ("net: mvneta: driver for Marvell Armada 370/XP network unit")
    Signed-off-by: Maxim Kiselev <bigunclemax@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a73e59683548413469cb8bd6f1c42a318ba1a4ea
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Aug 21 09:35:23 2021 +0200

    xgene-v2: Fix a resource leak in the error handling path of 'xge_probe()'
    
    [ Upstream commit 5ed74b03eb4d08f5dd281dcb5f1c9bb92b363a8d ]
    
    A successful 'xge_mdio_config()' call should be balanced by a corresponding
    'xge_mdio_remove()' call in the error handling path of the probe, as
    already done in the remove function.
    
    Update the error handling path accordingly.
    
    Fixes: ea8ab16ab225 ("drivers: net: xgene-v2: Add MDIO support")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 01951aeafc407b6e1c5d4e865286dae0ff92b1cb
Author: Shreyansh Chouhan <chouhan.shreyansh630@gmail.com>
Date:   Sat Aug 21 12:44:24 2021 +0530

    ip_gre: add validation for csum_start
    
    [ Upstream commit 1d011c4803c72f3907eccfc1ec63caefb852fcbf ]
    
    Validate csum_start in gre_handle_offloads before we call _gre_xmit so
    that we do not crash later when the csum_start value is used in the
    lco_csum function call.
    
    This patch deals with ipv4 code.
    
    Fixes: c54419321455 ("GRE: Refactor GRE tunneling code.")
    Reported-by: syzbot+ff8e1b9f2f36481e2efc@syzkaller.appspotmail.com
    Signed-off-by: Shreyansh Chouhan <chouhan.shreyansh630@gmail.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4c00ae66159ace6bf0788368b793b88396ab74ae
Author: Gal Pressman <galpress@amazon.com>
Date:   Wed Aug 11 18:11:28 2021 +0300

    RDMA/efa: Free IRQ vectors on error flow
    
    [ Upstream commit dbe986bdfd6dfe6ef24b833767fff4151e024357 ]
    
    Make sure to free the IRQ vectors in case the allocation doesn't return
    the expected number of IRQs.
    
    Fixes: b7f5e880f377 ("RDMA/efa: Add the efa module")
    Link: https://lore.kernel.org/r/20210811151131.39138-2-galpress@amazon.com
    Reviewed-by: Firas JahJah <firasj@amazon.com>
    Reviewed-by: Yossi Leybovich <sleybo@amazon.com>
    Signed-off-by: Gal Pressman <galpress@amazon.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 50092de6d9e4d6a1193f83d19852e03492cabe01
Author: Sasha Neftin <sasha.neftin@intel.com>
Date:   Sun Jul 18 07:10:31 2021 +0300

    e1000e: Do not take care about recovery NVM checksum
    
    [ Upstream commit 4051f68318ca9f3d3becef3b54e70ad2c146df97 ]
    
    On new platforms, the NVM is read-only. Attempting to update the NVM
    is causing a lockup to occur. Do not attempt to write to the NVM
    on platforms where it's not supported.
    Emit an error message when the NVM checksum is invalid.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=213667
    Fixes: fb776f5d57ee ("e1000e: Add support for Tiger Lake")
    Suggested-by: Dima Ruinskiy <dima.ruinskiy@intel.com>
    Suggested-by: Vitaly Lifshits <vitaly.lifshits@intel.com>
    Signed-off-by: Sasha Neftin <sasha.neftin@intel.com>
    Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7878e0fe833d17784c9f3c8224c9d4b0deac1384
Author: Sasha Neftin <sasha.neftin@intel.com>
Date:   Sun Jul 4 10:11:41 2021 +0300

    e1000e: Fix the max snoop/no-snoop latency for 10M
    
    [ Upstream commit 44a13a5d99c71bf9e1676d9e51679daf4d7b3d73 ]
    
    We should decode the latency and the max_latency before directly compare.
    The latency should be presented as lat_enc = scale x value:
    lat_enc_d = (lat_enc & 0x0x3ff) x (1U << (5*((max_ltr_enc & 0x1c00)
    >> 10)))
    
    Fixes: cf8fb73c23aa ("e1000e: add support for LTR on I217/I218")
    Suggested-by: Yee Li <seven.yi.lee@gmail.com>
    Signed-off-by: Sasha Neftin <sasha.neftin@intel.com>
    Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e46212393a300ee26f71586e072964743a62bac6
Author: Toshiki Nishioka <toshiki.nishioka@intel.com>
Date:   Wed Jul 21 17:34:03 2021 -0700

    igc: Use num_tx_queues when iterating over tx_ring queue
    
    [ Upstream commit 691bd4d7761992914a0e83c27a4ce57d01474cda ]
    
    Use num_tx_queues rather than the IGC_MAX_TX_QUEUES fixed number 4 when
    iterating over tx_ring queue since instantiated queue count could be
    less than 4 where on-line cpu count is less than 4.
    
    Fixes: ec50a9d437f0 ("igc: Add support for taprio offloading")
    Signed-off-by: Toshiki Nishioka <toshiki.nishioka@intel.com>
    Signed-off-by: Muhammad Husaini Zulkifli <muhammad.husaini.zulkifli@intel.com>
    Tested-by: Muhammad Husaini Zulkifli <muhammad.husaini.zulkifli@intel.com>
    Acked-by: Sasha Neftin <sasha.neftin@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7bc8e807665be6f356fc3c1889ccb28a1d9810fc
Author: Aaron Ma <aaron.ma@canonical.com>
Date:   Tue Jul 13 21:00:36 2021 +0800

    igc: fix page fault when thunderbolt is unplugged
    
    [ Upstream commit 4b79959510e6612d80f8d86022e0cb44eee6f4a2 ]
    
    After unplug thunderbolt dock with i225, pciehp interrupt is triggered,
    remove call will read/write mmio address which is already disconnected,
    then cause page fault and make system hang.
    
    Check PCI state to remove device safely.
    
    Trace:
    BUG: unable to handle page fault for address: 000000000000b604
    Oops: 0000 [#1] SMP NOPTI
    RIP: 0010:igc_rd32+0x1c/0x90 [igc]
    Call Trace:
    igc_ptp_suspend+0x6c/0xa0 [igc]
    igc_ptp_stop+0x12/0x50 [igc]
    igc_remove+0x7f/0x1c0 [igc]
    pci_device_remove+0x3e/0xb0
    __device_release_driver+0x181/0x240
    
    Fixes: 13b5b7fd6a4a ("igc: Add support for Tx/Rx rings")
    Fixes: b03c49cde61f ("igc: Save PTP time before a reset")
    Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
    Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 89362210ac19e339e5249cdf11702b15b3ac5be5
Author: Petko Manolov <petko.manolov@konsulko.com>
Date:   Fri Aug 20 09:57:53 2021 +0300

    net: usb: pegasus: fixes of set_register(s) return value evaluation;
    
    [ Upstream commit ffc9c3ebb4af870a121da99826e9ccb63dc8b3d7 ]
    
    - restore the behavior in enable_net_traffic() to avoid regressions - Jakub
        Kicinski;
      - hurried up and removed redundant assignment in pegasus_open() before yet
        another checker complains;
    
    Fixes: 8a160e2e9aeb ("net: usb: pegasus: Check the return value of get_geristers() and friends;")
    Reported-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Petko Manolov <petko.manolov@konsulko.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2b0267118a684e10abd32e65f916e16dd2cc832d
Author: Jacob Keller <jacob.e.keller@intel.com>
Date:   Thu Aug 19 15:34:51 2021 -0700

    ice: do not abort devlink info if board identifier can't be found
    
    [ Upstream commit a8f89fa27773a8c96fd09fb4e2f4892d794f21f6 ]
    
    The devlink dev info command reports version information about the
    device and firmware running on the board. This includes the "board.id"
    field which is supposed to represent an identifier of the board design.
    The ice driver uses the Product Board Assembly identifier for this.
    
    In some cases, the PBA is not present in the NVM. If this happens,
    devlink dev info will fail with an error. Instead, modify the
    ice_info_pba function to just exit without filling in the context
    buffer. This will cause the board.id field to be skipped. Log a dev_dbg
    message in case someone wants to confirm why board.id is not showing up
    for them.
    
    Fixes: e961b679fb0b ("ice: add board identifier info to devlink .info_get")
    Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
    Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Link: https://lore.kernel.org/r/20210819223451.245613-1-anthony.l.nguyen@intel.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a35de1e71b68591c0855024973d27c196a1a26c2
Author: Bob Pearson <rpearsonhpe@gmail.com>
Date:   Fri Aug 13 16:06:26 2021 -0500

    RDMA/rxe: Fix memory allocation while in a spin lock
    
    [ Upstream commit 65a81b61d8c5e96748671824cc46339afbd831d0 ]
    
    rxe_mcast_add_grp_elem() in rxe_mcast.c calls rxe_alloc() while holding
    spinlocks which in turn calls kzalloc(size, GFP_KERNEL) which is
    incorrect.  This patch replaces rxe_alloc() by rxe_alloc_locked() which
    uses GFP_ATOMIC.  This bug was caused by the below mentioned commit and
    failing to handle the need for the atomic allocate.
    
    Fixes: 4276fd0dddc9 ("RDMA/rxe: Remove RXE_POOL_ATOMIC")
    Link: https://lore.kernel.org/r/20210813210625.4484-1-rpearsonhpe@gmail.com
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Bob Pearson <rpearsonhpe@gmail.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9413a11e77ebd25faae62089b76ef3b8e5fac775
Author: Dinghao Liu <dinghao.liu@zju.edu.cn>
Date:   Mon Aug 16 16:55:31 2021 +0800

    RDMA/bnxt_re: Remove unpaired rtnl unlock in bnxt_re_dev_init()
    
    [ Upstream commit a036ad088306a88de87e973981f2b9224e466c3f ]
    
    The fixed commit removes all rtnl_lock() and rtnl_unlock() calls in
    function bnxt_re_dev_init(), but forgets to remove a rtnl_unlock() in the
    error handling path of bnxt_re_register_netdev(), which may cause a
    deadlock. This bug is suggested by a static analysis tool.
    
    Fixes: c2b777a95923 ("RDMA/bnxt_re: Refactor device add/remove functionalities")
    Link: https://lore.kernel.org/r/20210816085531.12167-1-dinghao.liu@zju.edu.cn
    Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
    Acked-by: Selvin Xavier <selvin.xavier@broadcom.com>
    Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7cfd5894226b27eca61f00981ee6ee9571aa9fd6
Author: Tuo Li <islituo@gmail.com>
Date:   Fri Aug 6 06:30:29 2021 -0700

    IB/hfi1: Fix possible null-pointer dereference in _extend_sdma_tx_descs()
    
    [ Upstream commit cbe71c61992c38f72c2b625b2ef25916b9f0d060 ]
    
    kmalloc_array() is called to allocate memory for tx->descp. If it fails,
    the function __sdma_txclean() is called:
      __sdma_txclean(dd, tx);
    
    However, in the function __sdma_txclean(), tx-descp is dereferenced if
    tx->num_desc is not zero:
      sdma_unmap_desc(dd, &tx->descp[0]);
    
    To fix this possible null-pointer dereference, assign the return value of
    kmalloc_array() to a local variable descp, and then assign it to tx->descp
    if it is not NULL. Otherwise, go to enomem.
    
    Fixes: 7724105686e7 ("IB/hfi1: add driver files")
    Link: https://lore.kernel.org/r/20210806133029.194964-1-islituo@gmail.com
    Reported-by: TOTE Robot <oslab@tsinghua.edu.cn>
    Signed-off-by: Tuo Li <islituo@gmail.com>
    Tested-by: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com>
    Acked-by: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4fdd674a31f20a9da64700b4e36e7330e9e56b10
Author: Naresh Kumar PBS <nareshkumar.pbs@broadcom.com>
Date:   Wed Aug 18 20:25:52 2021 -0700

    RDMA/bnxt_re: Add missing spin lock initialization
    
    [ Upstream commit 17f2569dce1848080825b8336e6b7c6900193b44 ]
    
    Add the missing initialization of srq lock.
    
    Fixes: 37cb11acf1f7 ("RDMA/bnxt_re: Add SRQ support for Broadcom adapters")
    Link: https://lore.kernel.org/r/1629343553-5843-3-git-send-email-selvin.xavier@broadcom.com
    Signed-off-by: Naresh Kumar PBS <nareshkumar.pbs@broadcom.com>
    Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 30067a9a161715d2a406e768c852cd3dffd190ae
Author: Gal Pressman <galpress@amazon.com>
Date:   Thu Aug 12 16:56:06 2021 +0300

    RDMA/uverbs: Track dmabuf memory regions
    
    [ Upstream commit f6018cc4602659e0e608849529704f3f41276c28 ]
    
    The dmabuf memory registrations are missing the restrack handling and
    hence do not appear in rdma tool.
    
    Fixes: bfe0cc6eb249 ("RDMA/uverbs: Add uverbs command for dma-buf based MR registration")
    Link: https://lore.kernel.org/r/20210812135607.6228-1-galpress@amazon.com
    Signed-off-by: Gal Pressman <galpress@amazon.com>
    Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6a4dd0859f4f0b9c9cec624bc17254a5316ce066
Author: Maor Gottlieb <maorg@nvidia.com>
Date:   Tue Aug 10 12:25:11 2021 +0300

    RDMA/mlx5: Fix crash when unbind multiport slave
    
    [ Upstream commit da78fe5fb35737058de52364484ffed74e7d329b ]
    
    Fix the below crash when deleting a slave from the unaffiliated list
    twice. First time when the slave is bound to the master and the second
    when the slave is unloaded.
    
    Fix it by checking if slave is unaffiliated (doesn't have ib device)
    before removing from the list.
    
      RIP: 0010:mlx5r_mp_remove+0x4e/0xa0 [mlx5_ib]
      Call Trace:
       auxiliary_bus_remove+0x18/0x30
       __device_release_driver+0x177/x220
       device_release_driver+0x24/0x30
       bus_remove_device+0xd8/0x140
       device_del+0x18a/0x3e0
       mlx5_rescan_drivers_locked+0xa9/0x210 [mlx5_core]
       mlx5_unregister_device+0x34/0x60 [mlx5_core]
       mlx5_uninit_one+0x32/0x100 [mlx5_core]
       remove_one+0x6e/0xe0 [mlx5_core]
       pci_device_remove+0x36/0xa0
       __device_release_driver+0x177/0x220
       device_driver_detach+0x3c/0xa0
       unbind_store+0x113/0x130
       kernfs_fop_write_iter+0x110/0x1a0
       new_sync_write+0x116/0x1a0
       vfs_write+0x1ba/0x260
       ksys_write+0x5f/0xe0
       do_syscall_64+0x3d/0x90
       entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    Fixes: 93f8244431ad ("RDMA/mlx5: Convert mlx5_ib to use auxiliary bus")
    Link: https://lore.kernel.org/r/17ec98989b0ba88f7adfbad68eb20bce8d567b44.1628587493.git.leonro@nvidia.com
    Signed-off-by: Maor Gottlieb <maorg@nvidia.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 db030881c4656e89bdd445ed383ecfce6466321b
Author: Li Jinlin <lijinlin3@huawei.com>
Date:   Tue Aug 24 10:59:21 2021 +0800

    scsi: core: Fix hang of freezing queue between blocking and running device
    
    commit 02c6dcd543f8f051973ee18bfbc4dc3bd595c558 upstream.
    
    We found a hang, the steps to reproduce  are as follows:
    
      1. blocking device via scsi_device_set_state()
    
      2. dd if=/dev/sda of=/mnt/t.log bs=1M count=10
    
      3. echo none > /sys/block/sda/queue/scheduler
    
      4. echo "running" >/sys/block/sda/device/state
    
    Step 3 and 4 should complete after step 4, but they hang.
    
      CPU#0               CPU#1                CPU#2
      ---------------     ----------------     ----------------
                                               Step 1: blocking device
    
                                               Step 2: dd xxxx
                                                      ^^^^^^ get request
                                                             q_usage_counter++
    
                          Step 3: switching scheculer
                          elv_iosched_store
                            elevator_switch
                              blk_mq_freeze_queue
                                blk_freeze_queue
                                  > blk_freeze_queue_start
                                    ^^^^^^ mq_freeze_depth++
    
                                  > blk_mq_run_hw_queues
                                    ^^^^^^ can't run queue when dev blocked
    
                                  > blk_mq_freeze_queue_wait
                                    ^^^^^^ Hang here!!!
                                           wait q_usage_counter==0
    
      Step 4: running device
      store_state_field
        scsi_rescan_device
          scsi_attach_vpd
            scsi_vpd_inquiry
              __scsi_execute
                blk_get_request
                  blk_mq_alloc_request
                    blk_queue_enter
                    ^^^^^^ Hang here!!!
                           wait mq_freeze_depth==0
    
        blk_mq_run_hw_queues
        ^^^^^^ dispatch IO, q_usage_counter will reduce to zero
    
                                blk_mq_unfreeze_queue
                                ^^^^^ mq_freeze_depth--
    
    To fix this, we need to run queue before rescanning device when the device
    state changes to SDEV_RUNNING.
    
    Link: https://lore.kernel.org/r/20210824025921.3277629-1-lijinlin3@huawei.com
    Fixes: f0f82e2476f6 ("scsi: core: Fix capacity set to zero after offlinining device")
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Li Jinlin <lijinlin3@huawei.com>
    Signed-off-by: Qiu Laibin <qiulaibin@huawei.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3e07893f0f82777a80670fe25e37c1ec5063d587
Author: Wesley Cheng <wcheng@codeaurora.org>
Date:   Tue Aug 24 21:28:55 2021 -0700

    usb: dwc3: gadget: Stop EP0 transfers during pullup disable
    
    commit 4a1e25c0a029b97ea4a3d423a6392bfacc3b2e39 upstream.
    
    During a USB cable disconnect, or soft disconnect scenario, a pending
    SETUP transaction may not be completed, leading to the following
    error:
    
        dwc3 a600000.dwc3: timed out waiting for SETUP phase
    
    If this occurs, then the entire pullup disable routine is skipped and
    proper cleanup and halting of the controller does not complete.
    
    Instead of returning an error (which is ignored from the UDC
    perspective), allow the pullup disable routine to continue, which
    will also handle disabling of EP0/1.  This will end any active
    transfers as well.  Ensure to clear any delayed_status also, as the
    timeout could happen within the STATUS stage.
    
    Fixes: bb0147364850 ("usb: dwc3: gadget: don't clear RUN/STOP when it's invalid to do so")
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Acked-by: Felipe Balbi <balbi@kernel.org>
    Signed-off-by: Wesley Cheng <wcheng@codeaurora.org>
    Link: https://lore.kernel.org/r/20210825042855.7977-1-wcheng@codeaurora.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b8951c842cdec769d815655e8ad2fc8b2e134a7
Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Date:   Thu Aug 19 03:17:03 2021 +0200

    usb: dwc3: gadget: Fix dwc3_calc_trbs_left()
    
    commit 51f1954ad853d01ba4dc2b35dee14d8490ee05a1 upstream.
    
    We can't depend on the TRB's HWO bit to determine if the TRB ring is
    "full". A TRB is only available when the driver had processed it, not
    when the controller consumed and relinquished the TRB's ownership to the
    driver. Otherwise, the driver may overwrite unprocessed TRBs. This can
    happen when many transfer events accumulate and the system is slow to
    process them and/or when there are too many small requests.
    
    If a request is in the started_list, that means there is one or more
    unprocessed TRBs remained. Check this instead of the TRB's HWO bit
    whether the TRB ring is full.
    
    Fixes: c4233573f6ee ("usb: dwc3: gadget: prepare TRBs on update transfers too")
    Cc: <stable@vger.kernel.org>
    Acked-by: Felipe Balbi <balbi@kernel.org>
    Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/e91e975affb0d0d02770686afc3a5b9eb84409f6.1629335416.git.Thinh.Nguyen@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 24bcaabc7be29960b9e2d0ba05ab5fb1e0e3ccac
Author: Kyle Tso <kyletso@google.com>
Date:   Thu Aug 26 20:42:01 2021 +0800

    usb: typec: tcpm: Raise vdm_sm_running flag only when VDM SM is running
    
    commit ef52b4a9fcc24e17e81cc60357e6107ae4e9c48e upstream.
    
    If the port is going to send Discover_Identity Message, vdm_sm_running
    flag was intentionally set before entering Ready States in order to
    avoid the conflict because the port and the port partner might start
    AMS at almost the same time after entering Ready States.
    
    However, the original design has a problem. When the port is doing
    DR_SWAP from Device to Host, it raises the flag. Later in the
    tcpm_send_discover_work, the flag blocks the procedure of sending the
    Discover_Identity and it might never be cleared until disconnection.
    
    Since there exists another flag send_discover representing that the port
    is going to send Discover_Identity or not, it is enough to use that flag
    to prevent the conflict. Also change the timing of the set/clear of
    vdm_sm_running to indicate whether the VDM SM is actually running or
    not.
    
    Fixes: c34e85fa69b9 ("usb: typec: tcpm: Send DISCOVER_IDENTITY from dedicated work")
    Cc: stable <stable@vger.kernel.org>
    Cc: Badhri Jagan Sridharan <badhri@google.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Kyle Tso <kyletso@google.com>
    Link: https://lore.kernel.org/r/20210826124201.1562502-1-kyletso@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6a59c0559d74de6351e77c1e2d78b91ed8aa651d
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Aug 26 14:41:27 2021 +0200

    usb: renesas-xhci: Prefer firmware loading on unknown ROM state
    
    commit c82cacd2f1e622a461a77d275a75d7e19e7635a3 upstream.
    
    The recent attempt to handle an unknown ROM state in the commit
    d143825baf15 ("usb: renesas-xhci: Fix handling of unknown ROM state")
    resulted in a regression and reverted later by the commit 44cf53602f5a
    ("Revert "usb: renesas-xhci: Fix handling of unknown ROM state"").
    The problem of the former fix was that it treated the failure of
    firmware loading as a fatal error.  Since the firmware files aren't
    included in the standard linux-firmware tree, most users don't have
    them, hence they got the non-working system after that.  The revert
    fixed the regression, but also it didn't make the firmware loading
    triggered even on the devices that do need it.  So we need still a fix
    for them.
    
    This is another attempt to handle the unknown ROM state.  Like the
    previous fix, this also tries to load the firmware when ROM shows
    unknown state.  In this patch, however, the failure of a firmware
    loading (such as a missing firmware file) isn't handled as a fatal
    error any longer when ROM has been already detected, but it falls back
    to the ROM mode like before.  The error is returned only when no ROM
    is detected and the firmware loading failed.
    
    Along with it, for simplifying the code flow, the detection and the
    check of ROM is factored out from renesas_fw_check_running() and done
    in the caller side, renesas_xhci_check_request_fw().  It avoids the
    redundant ROM checks.
    
    The patch was tested on Lenovo Thinkpad T14 gen (BIOS 1.34).  Also it
    was confirmed that no regression is seen on another Thinkpad T14
    machine that has worked without the patch, too.
    
    Fixes: 44cf53602f5a ("Revert "usb: renesas-xhci: Fix handling of unknown ROM state"")
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    BugLink: https://bugzilla.opensuse.org/show_bug.cgi?id=1189207
    Link: https://lore.kernel.org/r/20210826124127.14789-1-tiwai@suse.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 155c3c86abdb3dbea176d1f3fb875cec88c5073b
Author: Zhengjun Zhang <zhangzhengjun@aicrobo.com>
Date:   Mon Aug 9 21:35:53 2021 +0800

    USB: serial: option: add new VID/PID to support Fibocom FG150
    
    commit 2829a4e3cf3a6ac2fa3cdb681b37574630fb9c1a upstream.
    
    Fibocom FG150 is a 5G module based on Qualcomm SDX55 platform,
    support Sub-6G band.
    
    Here are the outputs of lsusb -v and usb-devices:
    
    > T:  Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  2 Spd=5000 MxCh= 0
    > D:  Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs=  1
    > P:  Vendor=2cb7 ProdID=010b Rev=04.14
    > S:  Manufacturer=Fibocom
    > S:  Product=Fibocom Modem_SN:XXXXXXXX
    > S:  SerialNumber=XXXXXXXX
    > C:  #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=896mA
    > I:  If#=0x0 Alt= 0 #EPs= 1 Cls=ef(misc ) Sub=04 Prot=01 Driver=rndis_host
    > I:  If#=0x1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host
    > I:  If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
    > I:  If#=0x3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=(none)
    > I:  If#=0x4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
    
    > Bus 002 Device 002: ID 2cb7:010b Fibocom Fibocom Modem_SN:XXXXXXXX
    > Device Descriptor:
    >   bLength                18
    >   bDescriptorType         1
    >   bcdUSB               3.20
    >   bDeviceClass            0
    >   bDeviceSubClass         0
    >   bDeviceProtocol         0
    >   bMaxPacketSize0         9
    >   idVendor           0x2cb7 Fibocom
    >   idProduct          0x010b
    >   bcdDevice            4.14
    >   iManufacturer           1 Fibocom
    >   iProduct                2 Fibocom Modem_SN:XXXXXXXX
    >   iSerial                 3 XXXXXXXX
    >   bNumConfigurations      1
    >   Configuration Descriptor:
    >     bLength                 9
    >     bDescriptorType         2
    >     wTotalLength       0x00e6
    >     bNumInterfaces          5
    >     bConfigurationValue     1
    >     iConfiguration          4 RNDIS_DUN_DIAG_ADB
    >     bmAttributes         0xa0
    >       (Bus Powered)
    >       Remote Wakeup
    >     MaxPower              896mA
    >     Interface Association:
    >       bLength                 8
    >       bDescriptorType        11
    >       bFirstInterface         0
    >       bInterfaceCount         2
    >       bFunctionClass        239 Miscellaneous Device
    >       bFunctionSubClass       4
    >       bFunctionProtocol       1
    >       iFunction               7 RNDIS
    >     Interface Descriptor:
    >       bLength                 9
    >       bDescriptorType         4
    >       bInterfaceNumber        0
    >       bAlternateSetting       0
    >       bNumEndpoints           1
    >       bInterfaceClass       239 Miscellaneous Device
    >       bInterfaceSubClass      4
    >       bInterfaceProtocol      1
    >       iInterface              0
    >       ** UNRECOGNIZED:  05 24 00 10 01
    >       ** UNRECOGNIZED:  05 24 01 00 01
    >       ** UNRECOGNIZED:  04 24 02 00
    >       ** UNRECOGNIZED:  05 24 06 00 01
    >       Endpoint Descriptor:
    >         bLength                 7
    >         bDescriptorType         5
    >         bEndpointAddress     0x81  EP 1 IN
    >         bmAttributes            3
    >           Transfer Type            Interrupt
    >           Synch Type               None
    >           Usage Type               Data
    >         wMaxPacketSize     0x0008  1x 8 bytes
    >         bInterval               9
    >         bMaxBurst               0
    >     Interface Descriptor:
    >       bLength                 9
    >       bDescriptorType         4
    >       bInterfaceNumber        1
    >       bAlternateSetting       0
    >       bNumEndpoints           2
    >       bInterfaceClass        10 CDC Data
    >       bInterfaceSubClass      0
    >       bInterfaceProtocol      0
    >       iInterface              0
    >       Endpoint Descriptor:
    >         bLength                 7
    >         bDescriptorType         5
    >         bEndpointAddress     0x8e  EP 14 IN
    >         bmAttributes            2
    >           Transfer Type            Bulk
    >           Synch Type               None
    >           Usage Type               Data
    >         wMaxPacketSize     0x0400  1x 1024 bytes
    >         bInterval               0
    >         bMaxBurst               6
    >       Endpoint Descriptor:
    >         bLength                 7
    >         bDescriptorType         5
    >         bEndpointAddress     0x0f  EP 15 OUT
    >         bmAttributes            2
    >           Transfer Type            Bulk
    >           Synch Type               None
    >           Usage Type               Data
    >         wMaxPacketSize     0x0400  1x 1024 bytes
    >         bInterval               0
    >         bMaxBurst               6
    >     Interface Descriptor:
    >       bLength                 9
    >       bDescriptorType         4
    >       bInterfaceNumber        2
    >       bAlternateSetting       0
    >       bNumEndpoints           3
    >       bInterfaceClass       255 Vendor Specific Class
    >       bInterfaceSubClass      0
    >       bInterfaceProtocol      0
    >       iInterface              0
    >       ** UNRECOGNIZED:  05 24 00 10 01
    >       ** UNRECOGNIZED:  05 24 01 00 00
    >       ** UNRECOGNIZED:  04 24 02 02
    >       ** UNRECOGNIZED:  05 24 06 00 00
    >       Endpoint Descriptor:
    >         bLength                 7
    >         bDescriptorType         5
    >         bEndpointAddress     0x83  EP 3 IN
    >         bmAttributes            3
    >           Transfer Type            Interrupt
    >           Synch Type               None
    >           Usage Type               Data
    >         wMaxPacketSize     0x000a  1x 10 bytes
    >         bInterval               9
    >         bMaxBurst               0
    >       Endpoint Descriptor:
    >         bLength                 7
    >         bDescriptorType         5
    >         bEndpointAddress     0x82  EP 2 IN
    >         bmAttributes            2
    >           Transfer Type            Bulk
    >           Synch Type               None
    >           Usage Type               Data
    >         wMaxPacketSize     0x0400  1x 1024 bytes
    >         bInterval               0
    >         bMaxBurst               0
    >       Endpoint Descriptor:
    >         bLength                 7
    >         bDescriptorType         5
    >         bEndpointAddress     0x01  EP 1 OUT
    >         bmAttributes            2
    >           Transfer Type            Bulk
    >           Synch Type               None
    >           Usage Type               Data
    >         wMaxPacketSize     0x0400  1x 1024 bytes
    >         bInterval               0
    >         bMaxBurst               0
    >     Interface Descriptor:
    >       bLength                 9
    >       bDescriptorType         4
    >       bInterfaceNumber        3
    >       bAlternateSetting       0
    >       bNumEndpoints           2
    >       bInterfaceClass       255 Vendor Specific Class
    >       bInterfaceSubClass    255 Vendor Specific Subclass
    >       bInterfaceProtocol     48
    >       iInterface              0
    >       Endpoint Descriptor:
    >         bLength                 7
    >         bDescriptorType         5
    >         bEndpointAddress     0x84  EP 4 IN
    >         bmAttributes            2
    >           Transfer Type            Bulk
    >           Synch Type               None
    >           Usage Type               Data
    >         wMaxPacketSize     0x0400  1x 1024 bytes
    >         bInterval               0
    >         bMaxBurst               0
    >       Endpoint Descriptor:
    >         bLength                 7
    >         bDescriptorType         5
    >         bEndpointAddress     0x02  EP 2 OUT
    >         bmAttributes            2
    >           Transfer Type            Bulk
    >           Synch Type               None
    >           Usage Type               Data
    >         wMaxPacketSize     0x0400  1x 1024 bytes
    >         bInterval               0
    >         bMaxBurst               0
    >     Interface Descriptor:
    >       bLength                 9
    >       bDescriptorType         4
    >       bInterfaceNumber        4
    >       bAlternateSetting       0
    >       bNumEndpoints           2
    >       bInterfaceClass       255 Vendor Specific Class
    >       bInterfaceSubClass     66
    >       bInterfaceProtocol      1
    >       iInterface              0
    >       Endpoint Descriptor:
    >         bLength                 7
    >         bDescriptorType         5
    >         bEndpointAddress     0x03  EP 3 OUT
    >         bmAttributes            2
    >           Transfer Type            Bulk
    >           Synch Type               None
    >           Usage Type               Data
    >         wMaxPacketSize     0x0400  1x 1024 bytes
    >         bInterval               0
    >         bMaxBurst               0
    >       Endpoint Descriptor:
    >         bLength                 7
    >         bDescriptorType         5
    >         bEndpointAddress     0x85  EP 5 IN
    >         bmAttributes            2
    >           Transfer Type            Bulk
    >           Synch Type               None
    >           Usage Type               Data
    >         wMaxPacketSize     0x0400  1x 1024 bytes
    >         bInterval               0
    >         bMaxBurst               0
    > Binary Object Store Descriptor:
    >   bLength                 5
    >   bDescriptorType        15
    >   wTotalLength       0x0016
    >   bNumDeviceCaps          2
    >   USB 2.0 Extension Device Capability:
    >     bLength                 7
    >     bDescriptorType        16
    >     bDevCapabilityType      2
    >     bmAttributes   0x00000006
    >       BESL Link Power Management (LPM) Supported
    >   SuperSpeed USB Device Capability:
    >     bLength                10
    >     bDescriptorType        16
    >     bDevCapabilityType      3
    >     bmAttributes         0x00
    >     wSpeedsSupported   0x000f
    >       Device can operate at Low Speed (1Mbps)
    >       Device can operate at Full Speed (12Mbps)
    >       Device can operate at High Speed (480Mbps)
    >       Device can operate at SuperSpeed (5Gbps)
    >     bFunctionalitySupport   1
    >       Lowest fully-functional device speed is Full Speed (12Mbps)
    >     bU1DevExitLat           1 micro seconds
    >     bU2DevExitLat         500 micro seconds
    > Device Status:     0x0000
    >   (Bus Powered)
    
    Signed-off-by: Zhengjun Zhang <zhangzhengjun@aicrobo.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2159dc1c023df729025a184cc01cc60d2014cfec
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Aug 24 14:19:26 2021 +0200

    Revert "USB: serial: ch341: fix character loss at high transfer rates"
    
    commit df7b16d1c00ecb3da3a30c999cdb39f273c99a2f upstream.
    
    This reverts commit 3c18e9baee0ef97510dcda78c82285f52626764b.
    
    These devices do not appear to send a zero-length packet when the
    transfer size is a multiple of the bulk-endpoint max-packet size. This
    means that incoming data may not be processed by the driver until a
    short packet is received or the receive buffer is full.
    
    Revert back to using endpoint-sized receive buffers to avoid stalled
    reads.
    
    Reported-by: Paul Größel <pb.g@gmx.de>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=214131
    Fixes: 3c18e9baee0e ("USB: serial: ch341: fix character loss at high transfer rates")
    Cc: stable@vger.kernel.org
    Cc: Willy Tarreau <w@1wt.eu>
    Link: https://lore.kernel.org/r/20210824121926.19311-1-johan@kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 05366fb0bfd1f19114cb99a6007b79fea9069ed5
Author: Borislav Petkov <bp@suse.de>
Date:   Tue Aug 24 11:42:47 2021 +0200

    drm/amdgpu: Fix build with missing pm_suspend_target_state module export
    
    commit c41a4e877a185241d8e83501453326fb98f67354 upstream.
    
    Building a randconfig here triggered:
    
      ERROR: modpost: "pm_suspend_target_state" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
    
    because the module export of that symbol happens in
    kernel/power/suspend.c which is enabled with CONFIG_SUSPEND.
    
    The ifdef guards in amdgpu_acpi_is_s0ix_supported(), however, test for
    CONFIG_PM_SLEEP which is defined like this:
    
      config PM_SLEEP
              def_bool y
              depends on SUSPEND || HIBERNATE_CALLBACKS
    
    and that randconfig has:
    
      # CONFIG_SUSPEND is not set
      CONFIG_HIBERNATE_CALLBACKS=y
    
    leading to the module export missing.
    
    Change the ifdeffery to depend directly on CONFIG_SUSPEND.
    
    Fixes: 5706cb3c910c ("drm/amdgpu: fix checking pmops when PM_SLEEP is not enabled")
    Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Link: https://lkml.kernel.org/r/YSP6Lv53QV0cOAsd@zn.tnic
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 164f7029a8ca298c8b583af3bff2ae15026065e0
Author: Christian König <christian.koenig@amd.com>
Date:   Wed Aug 18 14:05:28 2021 +0200

    drm/amdgpu: use the preferred pin domain after the check
    
    commit 2a7b9a8437130fd328001f4edfac8eec98dfe298 upstream.
    
    For some reason we run into an use case where a BO is already pinned
    into GTT, but should be pinned into VRAM|GTT again.
    
    Handle that case gracefully as well.
    
    Reviewed-by: Shashank Sharma <Shashank.sharma@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Christian König <christian.koenig@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 49db1b658914aa0223bb5a51535a66b18f8aeeba
Author: Michel Dänzer <mdaenzer@redhat.com>
Date:   Tue Aug 17 10:23:25 2021 +0200

    drm/amdgpu: Cancel delayed work when GFXOFF is disabled
    
    commit 32bc8f8373d2d6a681c96e4b25dca60d4d1c6016 upstream.
    
    schedule_delayed_work does not push back the work if it was already
    scheduled before, so amdgpu_device_delay_enable_gfx_off ran ~100 ms
    after the first time GFXOFF was disabled and re-enabled, even if GFXOFF
    was disabled and re-enabled again during those 100 ms.
    
    This resulted in frame drops / stutter with the upcoming mutter 41
    release on Navi 14, due to constantly enabling GFXOFF in the HW and
    disabling it again (for getting the GPU clock counter).
    
    To fix this, call cancel_delayed_work_sync when the disable count
    transitions from 0 to 1, and only schedule the delayed work on the
    reverse transition, not if the disable count was already 0. This makes
    sure the delayed work doesn't run at unexpected times, and allows it to
    be lock-free.
    
    v2:
    * Use cancel_delayed_work_sync & mutex_trylock instead of
      mod_delayed_work.
    v3:
    * Make amdgpu_device_delay_enable_gfx_off lock-free (Christian König)
    v4:
    * Fix race condition between amdgpu_gfx_off_ctrl incrementing
      adev->gfx.gfx_off_req_count and amdgpu_device_delay_enable_gfx_off
      checking for it to be 0 (Evan Quan)
    
    Cc: stable@vger.kernel.org
    Reviewed-by: Evan Quan <evan.quan@amd.com>
    Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> # v3
    Acked-by: Christian König <christian.koenig@amd.com> # v3
    Signed-off-by: Michel Dänzer <mdaenzer@redhat.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 05c07e76a37c4165019e74aa52b5ac5e8068a9d6
Author: Swati Sharma <swati2.sharma@intel.com>
Date:   Thu Aug 12 18:41:07 2021 +0530

    drm/i915/dp: Drop redundant debug print
    
    commit 71de496cc489b6bae2f51f89da7f28849bf2836e upstream.
    
    drm_dp_dpcd_read/write already has debug error message.
    Drop redundant error messages which gives false
    status even if correct value is read in drm_dp_dpcd_read().
    
    v2: -Added fixes tag (Ankit)
    v3: -Fixed build error (CI)
    
    Fixes: 9488a030ac91 ("drm/i915: Add support for enabling link status and recovery")
    Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
    Cc: Imre Deak <imre.deak@intel.com>
    Cc: Jani Nikula <jani.nikula@intel.com>
    Cc: José Roberto de Souza <jose.souza@intel.com>
    Cc: Manasi Navare <manasi.d.navare@intel.com>
    Cc: Sean Paul <seanpaul@chromium.org>
    Cc: Uma Shankar <uma.shankar@intel.com>
    Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Cc: <stable@vger.kernel.org> # v5.12+
    Reviewed-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Swati Sharma <swati2.sharma@intel.com>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210812131107.5531-1-swati2.sharma@intel.com
    (cherry picked from commit b6dfa416172939edaa46a5a647457b94c6d94119)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 65e526efa21575f104e3d6fbfd8c32a1c450af72
Author: Matthew Brost <matthew.brost@intel.com>
Date:   Fri Jul 30 12:53:42 2021 -0700

    drm/i915: Fix syncmap memory leak
    
    commit a63bcf08f0efb5348105bb8e0e1e8c6671077753 upstream.
    
    A small race exists between intel_gt_retire_requests_timeout and
    intel_timeline_exit which could result in the syncmap not getting
    free'd. Rather than work to hard to seal this race, simply cleanup the
    syncmap on fini.
    
    unreferenced object 0xffff88813bc53b18 (size 96):
      comm "gem_close_race", pid 5410, jiffies 4294917818 (age 1105.600s)
      hex dump (first 32 bytes):
        01 00 00 00 00 00 00 00 00 00 00 00 0a 00 00 00  ................
        00 00 00 00 00 00 00 00 6b 6b 6b 6b 06 00 00 00  ........kkkk....
      backtrace:
        [<00000000120b863a>] __sync_alloc_leaf+0x1e/0x40 [i915]
        [<00000000042f6959>] __sync_set+0x1bb/0x240 [i915]
        [<0000000090f0e90f>] i915_request_await_dma_fence+0x1c7/0x400 [i915]
        [<0000000056a48219>] i915_request_await_object+0x222/0x360 [i915]
        [<00000000aaac4ee3>] i915_gem_do_execbuffer+0x1bd0/0x2250 [i915]
        [<000000003c9d830f>] i915_gem_execbuffer2_ioctl+0x405/0xce0 [i915]
        [<00000000fd7a8e68>] drm_ioctl_kernel+0xb0/0xf0 [drm]
        [<00000000e721ee87>] drm_ioctl+0x305/0x3c0 [drm]
        [<000000008b0d8986>] __x64_sys_ioctl+0x71/0xb0
        [<0000000076c362a4>] do_syscall_64+0x33/0x80
        [<00000000eb7a4831>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    Signed-off-by: Matthew Brost <matthew.brost@intel.com>
    Fixes: 531958f6f357 ("drm/i915/gt: Track timeline activeness in enter/exit")
    Cc: <stable@vger.kernel.org>
    Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
    Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210730195342.110234-1-matthew.brost@intel.com
    (cherry picked from commit faf890985e30d5e88cc3a7c50c1bcad32f89ab7c)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b9d0c15e74cd16f22a78869c125e2e27045c5b3b
Author: Song Yoong Siang <yoong.siang.song@intel.com>
Date:   Wed Aug 25 08:57:42 2021 +0800

    net: stmmac: fix kernel panic due to NULL pointer dereference of buf->xdp
    
    commit 2b9fff64f03219d78044d1ab40dde8e3d42e968a upstream.
    
    Ensure a valid XSK buffer before proceed to free the xdp buffer.
    
    The following kernel panic is observed without this patch:
    
    RIP: 0010:xp_free+0x5/0x40
    Call Trace:
    stmmac_napi_poll_rxtx+0x332/0xb30 [stmmac]
    ? stmmac_tx_timer+0x3c/0xb0 [stmmac]
    net_rx_action+0x13d/0x3d0
    __do_softirq+0xfc/0x2fb
    ? smpboot_register_percpu_thread+0xe0/0xe0
    run_ksoftirqd+0x32/0x70
    smpboot_thread_fn+0x1d8/0x2c0
    kthread+0x169/0x1a0
    ? kthread_park+0x90/0x90
    ret_from_fork+0x1f/0x30
    ---[ end trace 0000000000000002 ]---
    
    Fixes: bba2556efad6 ("net: stmmac: Enable RX via AF_XDP zero-copy")
    Cc: <stable@vger.kernel.org> # 5.13.x
    Suggested-by: Ong Boon Leong <boon.leong.ong@intel.com>
    Signed-off-by: Song Yoong Siang <yoong.siang.song@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d4a399b96e0bb8079b884089dcb6d207537e533b
Author: Song Yoong Siang <yoong.siang.song@intel.com>
Date:   Wed Aug 25 08:55:29 2021 +0800

    net: stmmac: fix kernel panic due to NULL pointer dereference of xsk_pool
    
    commit a6451192da2691dcf39507bd758dde35d4606ee1 upstream.
    
    After free xsk_pool, there is possibility that napi polling is still
    running in the middle, thus causes a kernel crash due to kernel NULL
    pointer dereference of rx_q->xsk_pool and tx_q->xsk_pool.
    
    Fix this by changing the XDP pool setup sequence to:
     1. disable napi before free xsk_pool
     2. enable napi after init xsk_pool
    
    The following kernel panic is observed without this patch:
    
    RIP: 0010:xsk_uses_need_wakeup+0x5/0x10
    Call Trace:
    stmmac_napi_poll_rxtx+0x3a9/0xae0 [stmmac]
    __napi_poll+0x27/0x130
    net_rx_action+0x233/0x280
    __do_softirq+0xe2/0x2b6
    run_ksoftirqd+0x1a/0x20
    smpboot_thread_fn+0xac/0x140
    ? sort_range+0x20/0x20
    kthread+0x124/0x150
    ? set_kthread_struct+0x40/0x40
    ret_from_fork+0x1f/0x30
    ---[ end trace a77c8956b79ac107 ]---
    
    Fixes: bba2556efad6 ("net: stmmac: Enable RX via AF_XDP zero-copy")
    Cc: <stable@vger.kernel.org> # 5.13.x
    Signed-off-by: Song Yoong Siang <yoong.siang.song@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit efc5eb94e7b3b8949bfd825a437129ca64eba46d
Author: Qu Wenruo <wqu@suse.com>
Date:   Wed Aug 25 13:41:42 2021 +0800

    Revert "btrfs: compression: don't try to compress if we don't have enough pages"
    
    commit 4e9655763b82a91e4c341835bb504a2b1590f984 upstream.
    
    This reverts commit f2165627319ffd33a6217275e5690b1ab5c45763.
    
    [BUG]
    It's no longer possible to create compressed inline extent after commit
    f2165627319f ("btrfs: compression: don't try to compress if we don't
    have enough pages").
    
    [CAUSE]
    For compression code, there are several possible reasons we have a range
    that needs to be compressed while it's no more than one page.
    
    - Compressed inline write
      The data is always smaller than one sector and the test lacks the
      condition to properly recognize a non-inline extent.
    
    - Compressed subpage write
      For the incoming subpage compressed write support, we require page
      alignment of the delalloc range.
      And for 64K page size, we can compress just one page into smaller
      sectors.
    
    For those reasons, the requirement for the data to be more than one page
    is not correct, and is already causing regression for compressed inline
    data writeback.  The idea of skipping one page to avoid wasting CPU time
    could be revisited in the future.
    
    [FIX]
    Fix it by reverting the offending commit.
    
    Reported-by: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
    Link: https://lore.kernel.org/linux-btrfs/afa2742.c084f5d6.17b6b08dffc@tnonline.net
    Fixes: f2165627319f ("btrfs: compression: don't try to compress if we don't have enough pages")
    CC: stable@vger.kernel.org # 4.4+
    Signed-off-by: Qu Wenruo <wqu@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dbce1780abeb4236a94378bca2ba9f60700280d8
Author: Miaohe Lin <linmiaohe@huawei.com>
Date:   Wed Aug 25 12:17:55 2021 -0700

    mm/memory_hotplug: fix potential permanent lru cache disable
    
    commit 946746d1ad921e5f493b536533dda02ea22ca609 upstream.
    
    If offline_pages failed after lru_cache_disable(), it forgot to do
    lru_cache_enable() in error path.  So we would have lru cache disabled
    permanently in this case.
    
    Link: https://lkml.kernel.org/r/20210821094246.10149-3-linmiaohe@huawei.com
    Fixes: d479960e44f2 ("mm: disable LRU pagevec during the migration temporarily")
    Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
    Reviewed-by: David Hildenbrand <david@redhat.com>
    Reviewed-by: Oscar Salvador <osalvador@suse.de>
    Reviewed-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
    Cc: Chris Goldsworthy <cgoldswo@codeaurora.org>
    Cc: Michal Hocko <mhocko@suse.com>
    Cc: Minchan Kim <minchan@kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0d1cf894cc24cedc307d6f0072f606be07f42006
Author: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Date:   Thu Aug 19 13:39:54 2021 +0200

    powerpc: Re-enable ARCH_ENABLE_SPLIT_PMD_PTLOCK
    
    commit 310d2e83cb9b7f1e7232319880e3fcb57592fa10 upstream.
    
    Commit 66f24fa766e3 ("mm: drop redundant ARCH_ENABLE_SPLIT_PMD_PTLOCK")
    broke PMD split page table lock for powerpc.
    
    It selects the non-existent config ARCH_ENABLE_PMD_SPLIT_PTLOCK in
    arch/powerpc/platforms/Kconfig.cputype, but clearly intended to
    select ARCH_ENABLE_SPLIT_PMD_PTLOCK (notice the word swapping!), as
    that commit did for all other architectures.
    
    Fix it by selecting the correct symbol ARCH_ENABLE_SPLIT_PMD_PTLOCK.
    
    Fixes: 66f24fa766e3 ("mm: drop redundant ARCH_ENABLE_SPLIT_PMD_PTLOCK")
    Cc: stable@vger.kernel.org # v5.13+
    Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
    Reviewed-by: Daniel Axtens <dja@axtens.net>
    [mpe: Reword change log to make it clear this is a bug fix]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20210819113954.17515-3-lukas.bulwahn@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9e04475feb82cf8e21032336420b5787851f0d87
Author: Vincent Chen <vincent.chen@sifive.com>
Date:   Tue Aug 3 17:27:51 2021 +0800

    riscv: Ensure the value of FP registers in the core dump file is up to date
    
    commit 379eb01c21795edb4ca8d342503bd2183a19ec3a upstream.
    
    The value of FP registers in the core dump file comes from the
    thread.fstate. However, kernel saves the FP registers to the thread.fstate
    only before scheduling out the process. If no process switch happens
    during the exception handling process, kernel will not have a chance to
    save the latest value of FP registers to thread.fstate. It will cause the
    value of FP registers in the core dump file may be incorrect. To solve this
    problem, this patch force lets kernel save the FP register into the
    thread.fstate if the target task_struct equals the current.
    
    Signed-off-by: Vincent Chen <vincent.chen@sifive.com>
    Reviewed-by: Jisheng Zhang <jszhang@kernel.org>
    Fixes: b8c8a9590e4f ("RISC-V: Add FP register ptrace support for gdb.")
    Cc: stable@vger.kernel.org
    Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 31296d4fdbff6d8648c1dbb5eb11be3f960bac6d
Author: Rob Herring <robh@kernel.org>
Date:   Tue Aug 17 12:47:55 2021 -0500

    dt-bindings: sifive-l2-cache: Fix 'select' matching
    
    commit 1c8094e394bceb4f1880f9d539bdd255c130826e upstream.
    
    When the schema fixups are applied to 'select' the result is a single
    entry is required for a match, but that will never match as there should
    be 2 entries. Also, a 'select' schema should have the widest possible
    match, so use 'contains' which matches the compatible string(s) in any
    position and not just the first position.
    
    Fixes: 993dcfac64eb ("dt-bindings: riscv: sifive-l2-cache: convert bindings to json-schema")
    Signed-off-by: Rob Herring <robh@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 904d52e1bedaaa398ef1a8bd982602581eca398a
Author: Xiubo Li <xiubli@redhat.com>
Date:   Wed Aug 18 21:38:42 2021 +0800

    ceph: correctly handle releasing an embedded cap flush
    
    commit b2f9fa1f3bd8846f50b355fc2168236975c4d264 upstream.
    
    The ceph_cap_flush structures are usually dynamically allocated, but
    the ceph_cap_snap has an embedded one.
    
    When force umounting, the client will try to remove all the session
    caps. During this, it will free them, but that should not be done
    with the ones embedded in a capsnap.
    
    Fix this by adding a new boolean that indicates that the cap flush is
    embedded in a capsnap, and skip freeing it if that's set.
    
    At the same time, switch to using list_del_init() when detaching the
    i_list and g_list heads.  It's possible for a forced umount to remove
    these objects but then handle_cap_flushsnap_ack() races in and does the
    list_del_init() again, corrupting memory.
    
    Cc: stable@vger.kernel.org
    URL: https://tracker.ceph.com/issues/52283
    Signed-off-by: Xiubo Li <xiubli@redhat.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dbbf1899c6ffc8d69f17f5f2ebd4b1ce84425547
Author: Stefan Mätje <stefan.maetje@esd.eu>
Date:   Wed Aug 25 23:52:27 2021 +0200

    can: usb: esd_usb2: esd_usb2_rx_event(): fix the interchange of the CAN RX and TX error counters
    
    commit 044012b52029204900af9e4230263418427f4ba4 upstream.
    
    This patch fixes the interchanged fetch of the CAN RX and TX error
    counters from the ESD_EV_CAN_ERROR_EXT message. The RX error counter
    is really in struct rx_msg::data[2] and the TX error counter is in
    struct rx_msg::data[3].
    
    Fixes: 96d8e90382dc ("can: Add driver for esd CAN-USB/2 device")
    Link: https://lore.kernel.org/r/20210825215227.4947-2-stefan.maetje@esd.eu
    Cc: stable@vger.kernel.org
    Signed-off-by: Stefan Mätje <stefan.maetje@esd.eu>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1579b0f1e7bd539e67fbb4ceaa5bb5d1e9b624ce
Author: Mark Brown <broonie@kernel.org>
Date:   Tue Aug 10 13:37:48 2021 +0100

    net: mscc: Fix non-GPL export of regmap APIs
    
    [ Upstream commit 48c812e0327744b4965296f65c23fe2405692afc ]
    
    The ocelot driver makes use of regmap, wrapping it with driver specific
    operations that are thin wrappers around the core regmap APIs. These are
    exported with EXPORT_SYMBOL, dropping the _GPL from the core regmap
    exports which is frowned upon. Add _GPL suffixes to at least the APIs that
    are doing register I/O.
    
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 60c1ed05cba1134c4aa7f5f8ec4782e5141b2593
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Fri Aug 6 10:03:12 2021 +0200

    ovl: fix uninitialized pointer read in ovl_lookup_real_one()
    
    [ Upstream commit 580c610429b3994e8db24418927747cf28443cde ]
    
    One error path can result in release_dentry_name_snapshot() being called
    before "name" was initialized by take_dentry_name_snapshot().
    
    Fix by moving the release_dentry_name_snapshot() to immediately after the
    only use.
    
    Reported-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2514e486faf7a0d995c5e0932935de4029f7e23b
Author: Ming Lei <ming.lei@redhat.com>
Date:   Tue Aug 3 15:06:08 2021 +0800

    blk-iocost: fix lockdep warning on blkcg->lock
    
    [ Upstream commit 11431e26c9c43fa26f6b33ee1a90989f57b86024 ]
    
    blkcg->lock depends on q->queue_lock which may depend on another driver
    lock required in irq context, one example is dm-thin:
    
            Chain exists of:
              &pool->lock#3 --> &q->queue_lock --> &blkcg->lock
    
             Possible interrupt unsafe locking scenario:
    
                   CPU0                    CPU1
                   ----                    ----
              lock(&blkcg->lock);
                                           local_irq_disable();
                                           lock(&pool->lock#3);
                                           lock(&q->queue_lock);
              <Interrupt>
                lock(&pool->lock#3);
    
    Fix the issue by using spin_lock_irq(&blkcg->lock) in ioc_weight_write().
    
    Cc: Tejun Heo <tj@kernel.org>
    Reported-by: Bruno Goncalves <bgoncalv@redhat.com>
    Link: https://lore.kernel.org/linux-block/CA+QYu4rzz6079ighEanS3Qq_Dmnczcf45ZoJoHKVLVATTo1e4Q@mail.gmail.com/T/#u
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Acked-by: Tejun Heo <tj@kernel.org>
    Link: https://lore.kernel.org/r/20210803070608.1766400-1-ming.lei@redhat.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit de14d2fc6a62453e1cec169b476c86b5998e18e0
Author: Jens Axboe <axboe@kernel.dk>
Date:   Mon Aug 9 07:49:41 2021 -0600

    io_uring: rsrc ref lock needs to be IRQ safe
    
    [ Upstream commit 4956b9eaad456a88b0d56947bef036e086250beb ]
    
    Nadav reports running into the below splat on re-enabling softirqs:
    
    WARNING: CPU: 2 PID: 1777 at kernel/softirq.c:364 __local_bh_enable_ip+0xaa/0xe0
    Modules linked in:
    CPU: 2 PID: 1777 Comm: umem Not tainted 5.13.1+ #161
    Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/22/2020
    RIP: 0010:__local_bh_enable_ip+0xaa/0xe0
    Code: a9 00 ff ff 00 74 38 65 ff 0d a2 21 8c 7a e8 ed 1a 20 00 fb 66 0f 1f 44 00 00 5b 41 5c 5d c3 65 8b 05 e6 2d 8c 7a 85 c0 75 9a <0f> 0b eb 96 e8 2d 1f 20 00 eb a5 4c 89 e7 e8 73 4f 0c 00 eb ae 65
    RSP: 0018:ffff88812e58fcc8 EFLAGS: 00010046
    RAX: 0000000000000000 RBX: 0000000000000201 RCX: dffffc0000000000
    RDX: 0000000000000007 RSI: 0000000000000201 RDI: ffffffff8898c5ac
    RBP: ffff88812e58fcd8 R08: ffffffff8575dbbf R09: ffffed1028ef14f9
    R10: ffff88814778a7c3 R11: ffffed1028ef14f8 R12: ffffffff85c9e9ae
    R13: ffff88814778a000 R14: ffff88814778a7b0 R15: ffff8881086db890
    FS:  00007fbcfee17700(0000) GS:ffff8881e0300000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 000000c0402a5008 CR3: 000000011c1ac003 CR4: 00000000003706e0
    Call Trace:
     _raw_spin_unlock_bh+0x31/0x40
     io_rsrc_node_ref_zero+0x13e/0x190
     io_dismantle_req+0x215/0x220
     io_req_complete_post+0x1b8/0x720
     __io_complete_rw.isra.0+0x16b/0x1f0
     io_complete_rw+0x10/0x20
    
    where it's clear we end up calling the percpu count release directly
    from the completion path, as it's in atomic mode and we drop the last
    ref. For file/block IO, this can be from IRQ context already, and the
    softirq locking for rsrc isn't enough.
    
    Just make the lock fully IRQ safe, and ensure we correctly safe state
    from the release path as we don't know the full context there.
    
    Reported-by: Nadav Amit <nadav.amit@gmail.com>
    Tested-by: Nadav Amit <nadav.amit@gmail.com>
    Link: https://lore.kernel.org/io-uring/C187C836-E78B-4A31-B24C-D16919ACA093@gmail.com/
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b8eaf1e595fefb52a8d40ca2303ce901415963dd
Author: Kefeng Wang <wangkefeng.wang@huawei.com>
Date:   Fri Aug 6 16:21:24 2021 +0800

    once: Fix panic when module unload
    
    [ Upstream commit 1027b96ec9d34f9abab69bc1a4dc5b1ad8ab1349 ]
    
    DO_ONCE
    DEFINE_STATIC_KEY_TRUE(___once_key);
    __do_once_done
      once_disable_jump(once_key);
        INIT_WORK(&w->work, once_deferred);
        struct once_work *w;
        w->key = key;
        schedule_work(&w->work);                     module unload
                                                       //*the key is
    destroy*
    process_one_work
      once_deferred
        BUG_ON(!static_key_enabled(work->key));
           static_key_count((struct static_key *)x)    //*access key, crash*
    
    When module uses DO_ONCE mechanism, it could crash due to the above
    concurrency problem, we could reproduce it with link[1].
    
    Fix it by add/put module refcount in the once work process.
    
    [1] https://lore.kernel.org/netdev/eaa6c371-465e-57eb-6be9-f4b16b9d7cbf@huawei.com/
    
    Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Cc: Daniel Borkmann <daniel@iogearbox.net>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Eric Dumazet <edumazet@google.com>
    Reported-by: Minmin chen <chenmingmin@huawei.com>
    Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
    Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7aa03980b21fdc7355e20274a68a69a0b2a45c08
Author: Florian Westphal <fw@strlen.de>
Date:   Tue Jul 27 00:29:19 2021 +0200

    netfilter: conntrack: collect all entries in one cycle
    
    [ Upstream commit 4608fdfc07e116f9fc0895beb40abad7cdb5ee3d ]
    
    Michal Kubecek reports that conntrack gc is responsible for frequent
    wakeups (every 125ms) on idle systems.
    
    On busy systems, timed out entries are evicted during lookup.
    The gc worker is only needed to remove entries after system becomes idle
    after a busy period.
    
    To resolve this, always scan the entire table.
    If the scan is taking too long, reschedule so other work_structs can run
    and resume from next bucket.
    
    After a completed scan, wait for 2 minutes before the next cycle.
    Heuristics for faster re-schedule are removed.
    
    GC_SCAN_INTERVAL could be exposed as a sysctl in the future to allow
    tuning this as-needed or even turn the gc worker off.
    
    Reported-by: Michal Kubecek <mkubecek@suse.cz>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e0f824abe0f412f769fb5468b36c2471430bd885
Author: Jozsef Kadlecsik <kadlec@netfilter.org>
Date:   Wed Jul 28 17:01:15 2021 +0200

    netfilter: ipset: Limit the maximal range of consecutive elements to add/delete
    
    [ Upstream commit 5f7b51bf09baca8e4f80cbe879536842bafb5f31 ]
    
    The range size of consecutive elements were not limited. Thus one could
    define a huge range which may result soft lockup errors due to the long
    execution time. Now the range size is limited to 2^20 entries.
    
    Reported-by: Brad Spengler <spender@grsecurity.net>
    Signed-off-by: Jozsef Kadlecsik <kadlec@netfilter.org>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3ac582bc72d78f1eef92e02d2399f9217e5d2dfb
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Sat Jul 10 07:50:33 2021 -0700

    ARC: Fix CONFIG_STACKDEPOT
    
    [ Upstream commit bf79167fd86f3b97390fe2e70231d383526bd9cc ]
    
    Enabling CONFIG_STACKDEPOT results in the following build error.
    
    arc-elf-ld: lib/stackdepot.o: in function `filter_irq_stacks':
    stackdepot.c:(.text+0x456): undefined reference to `__irqentry_text_start'
    arc-elf-ld: stackdepot.c:(.text+0x456): undefined reference to `__irqentry_text_start'
    arc-elf-ld: stackdepot.c:(.text+0x476): undefined reference to `__irqentry_text_end'
    arc-elf-ld: stackdepot.c:(.text+0x476): undefined reference to `__irqentry_text_end'
    arc-elf-ld: stackdepot.c:(.text+0x484): undefined reference to `__softirqentry_text_start'
    arc-elf-ld: stackdepot.c:(.text+0x484): undefined reference to `__softirqentry_text_start'
    arc-elf-ld: stackdepot.c:(.text+0x48c): undefined reference to `__softirqentry_text_end'
    arc-elf-ld: stackdepot.c:(.text+0x48c): undefined reference to `__softirqentry_text_end'
    
    Other architectures address this problem by adding IRQENTRY_TEXT and
    SOFTIRQENTRY_TEXT to the text segment, so do the same here.
    
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9810910bc686aae3b476dea6da230a890da28603
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Thu Jul 29 10:21:34 2021 +0200

    platform/x86: Add and use a dual_accel_detect() helper
    
    [ Upstream commit 153cca9caa81ca8912a70528daca4b9a523c6898 ]
    
    Various 360 degree hinges (yoga) style 2-in-1 devices use 2 accelerometers
    to allow the OS to determine the angle between the display and the base of
    the device.
    
    On Windows these are read by a special HingeAngleService process which
    calls undocumented ACPI methods, to let the firmware know if the 2-in-1 is
    in tablet- or laptop-mode. The firmware may use this to disable the kbd and
    touchpad to avoid spurious input in tablet-mode as well as to report
    SW_TABLET_MODE info to the OS.
    
    Since Linux does not call these undocumented methods, the SW_TABLET_MODE
    info reported by various pdx86 drivers is incorrect on these devices.
    
    Before this commit the intel-hid and thinkpad_acpi code already had 2
    hardcoded checks for ACPI hardware-ids of dual-accel sensors to avoid
    reporting broken info.
    
    And now we also have a bug-report about the same problem in the intel-vbtn
    code. Since there are at least 3 different ACPI hardware-ids in play, add
    a new dual_accel_detect() helper which checks for all 3, rather then
    adding different hardware-ids to the drivers as bug-reports trickle in.
    Having shared code which checks all known hardware-ids is esp. important
    for the intel-hid and intel-vbtn drivers as these are generic drivers
    which are used on a lot of devices.
    
    The BOSC0200 hardware-id requires special handling, because often it is
    used for a single-accelerometer setup. Only in a few cases it refers to
    a dual-accel setup, in which case there will be 2 I2cSerialBus resources
    in the device's resource-list, so the helper checks for this.
    
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=209011
    Reported-and-tested-by: Julius Lehmann <julius@devpi.de>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Link: https://lore.kernel.org/r/20210729082134.6683-1-hdegoede@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dbd38b275b86c3229377451dd269a380ce8f7000
Author: Mark Brown <broonie@kernel.org>
Date:   Mon Jul 26 20:41:23 2021 +0100

    ASoC: component: Remove misplaced prefix handling in pin control functions
    
    [ Upstream commit 31428c78748cafdd9352e1f622eb89bf453d9700 ]
    
    When the component level pin control functions were added they for some
    no longer obvious reason handled adding prefixing of widget names. This
    meant that when the lack of prefix handling in the DAPM level pin
    operations was fixed by ae4fc532244b3bb4d (ASoC: dapm: use component
    prefix when checking widget names) the one device using the component
    level API ended up with the prefix being applied twice, causing all
    lookups to fail.
    
    Fix this by removing the redundant prefixing from the component code,
    which has the nice side effect of also making that code much simpler.
    
    Reported-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Tested-by: Lucas Tanure <tanureal@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20210726194123.54585-1-broonie@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6f2ec29dfd5e9df75d9c11e56787868f83c6b2f0
Author: Derek Fang <derek.fang@realtek.com>
Date:   Wed Jul 21 21:31:21 2021 +0800

    ASoC: rt5682: Adjust headset volume button threshold
    
    [ Upstream commit 6d20bf7c020f417fdef1810a22da17c126603472 ]
    
    Adjust the threshold of headset button volume+ to fix
    the wrong button detection issue with some brand headsets.
    
    Signed-off-by: Derek Fang <derek.fang@realtek.com>
    Link: https://lore.kernel.org/r/20210721133121.12333-1-derek.fang@realtek.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a31b3b8d3cbfb37f528d77eee94bb8a6afc48999
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Mon Aug 23 21:02:09 2021 +0200

    bpf: Fix ringbuf helper function compatibility
    
    commit 5b029a32cfe4600f5e10e36b41778506b90fd4de upstream.
    
    Commit 457f44363a88 ("bpf: Implement BPF ring buffer and verifier support
    for it") extended check_map_func_compatibility() by enforcing map -> helper
    function match, but not helper -> map type match.
    
    Due to this all of the bpf_ringbuf_*() helper functions could be used with
    a wrong map type such as array or hash map, leading to invalid access due
    to type confusion.
    
    Also, both BPF_FUNC_ringbuf_{submit,discard} have ARG_PTR_TO_ALLOC_MEM as
    argument and not a BPF map. Therefore, their check_map_func_compatibility()
    presence is incorrect since it's only for map type checking.
    
    Fixes: 457f44363a88 ("bpf: Implement BPF ring buffer and verifier support for it")
    Reported-by: Ryota Shiga (Flatt Security)
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d6060df9b53ab8098c954aac9acbacef6915e42a
Author: Xiaolong Huang <butterflyhuangxx@gmail.com>
Date:   Fri Aug 20 03:50:34 2021 +0800

    net: qrtr: fix another OOB Read in qrtr_endpoint_post
    
    commit 7e78c597c3ebfd0cb329aa09a838734147e4f117 upstream.
    
    This check was incomplete, did not consider size is 0:
    
            if (len != ALIGN(size, 4) + hdrlen)
                        goto err;
    
    if size from qrtr_hdr is 0, the result of ALIGN(size, 4)
    will be 0, In case of len == hdrlen and size == 0
    in header this check won't fail and
    
            if (cb->type == QRTR_TYPE_NEW_SERVER) {
                    /* Remote node endpoint can bridge other distant nodes */
                    const struct qrtr_ctrl_pkt *pkt = data + hdrlen;
    
                    qrtr_node_assign(node, le32_to_cpu(pkt->server.node));
            }
    
    will also read out of bound from data, which is hdrlen allocated block.
    
    Fixes: 194ccc88297a ("net: qrtr: Support decoding incoming v2 packets")
    Fixes: ad9d24c9429e ("net: qrtr: fix OOB Read in qrtr_endpoint_post")
    Signed-off-by: Xiaolong Huang <butterflyhuangxx@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>