commit a829146c3fdcf6d0b76d9c54556a223820f1f73b
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Jan 12 20:16:25 2021 +0100

    Linux 5.4.89
    
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Link: https://lore.kernel.org/r/20210111130039.165470698@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 485e21729b1e1235e6075318225c09e76b376e81
Author: David Disseldorp <ddiss@suse.de>
Date:   Tue Nov 3 02:21:58 2020 +0100

    scsi: target: Fix XCOPY NAA identifier lookup
    
    commit 2896c93811e39d63a4d9b63ccf12a8fbc226e5e4 upstream.
    
    When attempting to match EXTENDED COPY CSCD descriptors with corresponding
    se_devices, target_xcopy_locate_se_dev_e4() currently iterates over LIO's
    global devices list which includes all configured backstores.
    
    This change ensures that only initiator-accessible backstores are
    considered during CSCD descriptor lookup, according to the session's
    se_node_acl LUN list.
    
    To avoid LUN removal race conditions, device pinning is changed from being
    configfs based to instead using the se_node_acl lun_ref.
    
    Reference: CVE-2020-28374
    Fixes: cbf031f425fd ("target: Add support for EXTENDED_COPY copy offload emulation")
    Reviewed-by: Lee Duncan <lduncan@suse.com>
    Signed-off-by: David Disseldorp <ddiss@suse.de>
    Signed-off-by: Mike Christie <michael.christie@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7795afa0d7a907df392483efe9a38b4f875169f7
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Tue Dec 22 05:20:43 2020 -0500

    KVM: x86: fix shift out of bounds reported by UBSAN
    
    commit 2f80d502d627f30257ba7e3655e71c373b7d1a5a upstream.
    
    Since we know that e >= s, we can reassociate the left shift,
    changing the shifted number from 1 to 2 in exchange for
    decreasing the right hand side by 1.
    
    Reported-by: syzbot+e87846c48bf72bc85311@syzkaller.appspotmail.com
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a9d49da7edf85b947cf33e2b4217b092aee6a43b
Author: Ying-Tsun Huang <ying-tsun.huang@amd.com>
Date:   Tue Dec 15 15:07:20 2020 +0800

    x86/mtrr: Correct the range check before performing MTRR type lookups
    
    commit cb7f4a8b1fb426a175d1708f05581939c61329d4 upstream.
    
    In mtrr_type_lookup(), if the input memory address region is not in the
    MTRR, over 4GB, and not over the top of memory, a write-back attribute
    is returned. These condition checks are for ensuring the input memory
    address region is actually mapped to the physical memory.
    
    However, if the end address is just aligned with the top of memory,
    the condition check treats the address is over the top of memory, and
    write-back attribute is not returned.
    
    And this hits in a real use case with NVDIMM: the nd_pmem module tries
    to map NVDIMMs as cacheable memories when NVDIMMs are connected. If a
    NVDIMM is the last of the DIMMs, the performance of this NVDIMM becomes
    very low since it is aligned with the top of memory and its memory type
    is uncached-minus.
    
    Move the input end address change to inclusive up into
    mtrr_type_lookup(), before checking for the top of memory in either
    mtrr_type_lookup_{variable,fixed}() helpers.
    
     [ bp: Massage commit message. ]
    
    Fixes: 0cc705f56e40 ("x86/mm/mtrr: Clean up mtrr_type_lookup()")
    Signed-off-by: Ying-Tsun Huang <ying-tsun.huang@amd.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Link: https://lkml.kernel.org/r/20201215070721.4349-1-ying-tsun.huang@amd.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a798b367a066ae1e929d0c5dbef8d28a132afa7c
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Sun Dec 27 12:33:44 2020 +0100

    netfilter: nft_dynset: report EOPNOTSUPP on missing set feature
    
    commit 95cd4bca7b1f4a25810f3ddfc5e767fb46931789 upstream.
    
    If userspace requests a feature which is not available the original set
    definition, then bail out with EOPNOTSUPP. If userspace sends
    unsupported dynset flags (new feature not supported by this kernel),
    then report EOPNOTSUPP to userspace. EINVAL should be only used to
    report malformed netlink messages from userspace.
    
    Fixes: 22fe54d5fefc ("netfilter: nf_tables: add support for dynamic set updates")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5e401ea71676bd7c82ce44eb663fec7678ccffdd
Author: Florian Westphal <fw@strlen.de>
Date:   Tue Dec 22 23:23:56 2020 +0100

    netfilter: xt_RATEEST: reject non-null terminated string from userspace
    
    commit 6cb56218ad9e580e519dcd23bfb3db08d8692e5a upstream.
    
    syzbot reports:
    detected buffer overflow in strlen
    [..]
    Call Trace:
     strlen include/linux/string.h:325 [inline]
     strlcpy include/linux/string.h:348 [inline]
     xt_rateest_tg_checkentry+0x2a5/0x6b0 net/netfilter/xt_RATEEST.c:143
    
    strlcpy assumes src is a c-string. Check info->name before its used.
    
    Reported-by: syzbot+e86f7c428c8c50db65b4@syzkaller.appspotmail.com
    Fixes: 5859034d7eb8793 ("[NETFILTER]: x_tables: add RATEEST target")
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1dd6a790c22063caf3b2b4eb8376ce0625cbc8cd
Author: Vasily Averin <vvs@virtuozzo.com>
Date:   Thu Dec 17 17:53:18 2020 +0300

    netfilter: ipset: fix shift-out-of-bounds in htable_bits()
    
    commit 5c8193f568ae16f3242abad6518dc2ca6c8eef86 upstream.
    
    htable_bits() can call jhash_size(32) and trigger shift-out-of-bounds
    
    UBSAN: shift-out-of-bounds in net/netfilter/ipset/ip_set_hash_gen.h:151:6
    shift exponent 32 is too large for 32-bit type 'unsigned int'
    CPU: 0 PID: 8498 Comm: syz-executor519
     Not tainted 5.10.0-rc7-next-20201208-syzkaller #0
    Call Trace:
     __dump_stack lib/dump_stack.c:79 [inline]
     dump_stack+0x107/0x163 lib/dump_stack.c:120
     ubsan_epilogue+0xb/0x5a lib/ubsan.c:148
     __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:395
     htable_bits net/netfilter/ipset/ip_set_hash_gen.h:151 [inline]
     hash_mac_create.cold+0x58/0x9b net/netfilter/ipset/ip_set_hash_gen.h:1524
     ip_set_create+0x610/0x1380 net/netfilter/ipset/ip_set_core.c:1115
     nfnetlink_rcv_msg+0xecc/0x1180 net/netfilter/nfnetlink.c:252
     netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2494
     nfnetlink_rcv+0x1ac/0x420 net/netfilter/nfnetlink.c:600
     netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline]
     netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1330
     netlink_sendmsg+0x907/0xe40 net/netlink/af_netlink.c:1919
     sock_sendmsg_nosec net/socket.c:652 [inline]
     sock_sendmsg+0xcf/0x120 net/socket.c:672
     ____sys_sendmsg+0x6e8/0x810 net/socket.c:2345
     ___sys_sendmsg+0xf3/0x170 net/socket.c:2399
     __sys_sendmsg+0xe5/0x1b0 net/socket.c:2432
     do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
     entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    This patch replaces htable_bits() by simple fls(hashsize - 1) call:
    it alone returns valid nbits both for round and non-round hashsizes.
    It is normal to set any nbits here because it is validated inside
    following htable_size() call which returns 0 for nbits>31.
    
    Fixes: 1feab10d7e6d("netfilter: ipset: Unified hash type generation")
    Reported-by: syzbot+d66bfadebca46cf61a2b@syzkaller.appspotmail.com
    Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
    Acked-by: Jozsef Kadlecsik <kadlec@netfilter.org>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e0281bb5a82d702cd1e14afac817d37fde130527
Author: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Date:   Wed Dec 16 21:38:02 2020 -0700

    netfilter: x_tables: Update remaining dereference to RCU
    
    commit 443d6e86f821a165fae3fc3fc13086d27ac140b1 upstream.
    
    This fixes the dereference to fetch the RCU pointer when holding
    the appropriate xtables lock.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Fixes: cc00bcaa5899 ("netfilter: x_tables: Switch synchronization to RCU")
    Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
    Reviewed-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 828f2a20f946ff3a2ef2190cfc6118cc629568f1
Author: Matthew Auld <matthew.auld@intel.com>
Date:   Thu Dec 24 15:13:58 2020 +0000

    drm/i915: clear the gpu reloc batch
    
    commit 641382e9b44fba81a0778e1914ee35b8471121f9 upstream.
    
    The reloc batch is short lived but can exist in the user visible ppGTT,
    and since it's backed by an internal object, which lacks page clearing,
    we should take care to clear it upfront.
    
    Signed-off-by: Matthew Auld <matthew.auld@intel.com>
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Link: https://patchwork.freedesktop.org/patch/msgid/20201224151358.401345-2-matthew.auld@intel.com
    Cc: stable@vger.kernel.org
    (cherry picked from commit 26ebc511e799f621357982ccc37a7987a56a00f4)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ef8133b1b47ed67873c291e9248fafd428d1767d
Author: Charan Teja Reddy <charante@codeaurora.org>
Date:   Tue Jan 5 20:06:39 2021 +0530

    dmabuf: fix use-after-free of dmabuf's file->f_inode
    
    commit 05cd84691eafcd7959a1e120d5e72c0dd98c5d91 upstream.
    
    It is observed 'use-after-free' on the dmabuf's file->f_inode with the
    race between closing the dmabuf file and reading the dmabuf's debug
    info.
    
    Consider the below scenario where P1 is closing the dma_buf file
    and P2 is reading the dma_buf's debug info in the system:
    
    P1                                              P2
                                            dma_buf_debug_show()
    dma_buf_put()
      __fput()
        file->f_op->release()
        dput()
        ....
          dentry_unlink_inode()
            iput(dentry->d_inode)
            (where the inode is freed)
                                            mutex_lock(&db_list.lock)
                                            read 'dma_buf->file->f_inode'
                                            (the same inode is freed by P1)
                                            mutex_unlock(&db_list.lock)
          dentry->d_op->d_release()-->
            dma_buf_release()
              .....
              mutex_lock(&db_list.lock)
              removes the dmabuf from the list
              mutex_unlock(&db_list.lock)
    
    In the above scenario, when dma_buf_put() is called on a dma_buf, it
    first frees the dma_buf's file->f_inode(=dentry->d_inode) and then
    removes this dma_buf from the system db_list. In between P2 traversing
    the db_list tries to access this dma_buf's file->f_inode that was freed
    by P1 which is a use-after-free case.
    
    Since, __fput() calls f_op->release first and then later calls the
    d_op->d_release, move the dma_buf's db_list removal from d_release() to
    f_op->release(). This ensures that dma_buf's file->f_inode is not
    accessed after it is released.
    
    Cc: <stable@vger.kernel.org> # 5.4.x-
    Fixes: 4ab59c3c638c ("dma-buf: Move dma_buf_release() from fops to dentry_ops")
    Acked-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Charan Teja Reddy <charante@codeaurora.org>
    Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/1609857399-31549-1-git-send-email-charante@codeaurora.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 284be2b993cabec7c5ee64fc7f4a50d99b1a17d2
Author: Bard Liao <yung-chuan.liao@linux.intel.com>
Date:   Tue Jan 5 17:11:45 2021 +0800

    Revert "device property: Keep secondary firmware node secondary by type"
    
    commit 47f4469970d8861bc06d2d4d45ac8200ff07c693 upstream.
    
    While commit d5dcce0c414f ("device property: Keep secondary firmware
    node secondary by type") describes everything correct in its commit
    message, the change it made does the opposite and original commit
    c15e1bdda436 ("device property: Fix the secondary firmware node handling
    in set_primary_fwnode()") was fully correct.
    
    Revert the former one here and improve documentation in the next patch.
    
    Fixes: d5dcce0c414f ("device property: Keep secondary firmware node secondary by type")
    Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Cc: 5.10+ <stable@vger.kernel.org> # 5.10+
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 64d06c7f2fa2d6a58b1dae0261dee91e060748b5
Author: Filipe Manana <fdmanana@suse.com>
Date:   Thu Dec 10 12:09:02 2020 +0000

    btrfs: send: fix wrong file path when there is an inode with a pending rmdir
    
    commit 0b3f407e6728d990ae1630a02c7b952c21c288d3 upstream.
    
    When doing an incremental send, if we have a new inode that happens to
    have the same number that an old directory inode had in the base snapshot
    and that old directory has a pending rmdir operation, we end up computing
    a wrong path for the new inode, causing the receiver to fail.
    
    Example reproducer:
    
      $ cat test-send-rmdir.sh
      #!/bin/bash
    
      DEV=/dev/sdi
      MNT=/mnt/sdi
    
      mkfs.btrfs -f $DEV >/dev/null
      mount $DEV $MNT
    
      mkdir $MNT/dir
      touch $MNT/dir/file1
      touch $MNT/dir/file2
      touch $MNT/dir/file3
    
      # Filesystem looks like:
      #
      # .                                     (ino 256)
      # |----- dir/                           (ino 257)
      #         |----- file1                  (ino 258)
      #         |----- file2                  (ino 259)
      #         |----- file3                  (ino 260)
      #
    
      btrfs subvolume snapshot -r $MNT $MNT/snap1
      btrfs send -f /tmp/snap1.send $MNT/snap1
    
      # Now remove our directory and all its files.
      rm -fr $MNT/dir
    
      # Unmount the filesystem and mount it again. This is to ensure that
      # the next inode that is created ends up with the same inode number
      # that our directory "dir" had, 257, which is the first free "objectid"
      # available after mounting again the filesystem.
      umount $MNT
      mount $DEV $MNT
    
      # Now create a new file (it could be a directory as well).
      touch $MNT/newfile
    
      # Filesystem now looks like:
      #
      # .                                     (ino 256)
      # |----- newfile                        (ino 257)
      #
    
      btrfs subvolume snapshot -r $MNT $MNT/snap2
      btrfs send -f /tmp/snap2.send -p $MNT/snap1 $MNT/snap2
    
      # Now unmount the filesystem, create a new one, mount it and try to apply
      # both send streams to recreate both snapshots.
      umount $DEV
    
      mkfs.btrfs -f $DEV >/dev/null
    
      mount $DEV $MNT
    
      btrfs receive -f /tmp/snap1.send $MNT
      btrfs receive -f /tmp/snap2.send $MNT
    
      umount $MNT
    
    When running the test, the receive operation for the incremental stream
    fails:
    
      $ ./test-send-rmdir.sh
      Create a readonly snapshot of '/mnt/sdi' in '/mnt/sdi/snap1'
      At subvol /mnt/sdi/snap1
      Create a readonly snapshot of '/mnt/sdi' in '/mnt/sdi/snap2'
      At subvol /mnt/sdi/snap2
      At subvol snap1
      At snapshot snap2
      ERROR: chown o257-9-0 failed: No such file or directory
    
    So fix this by tracking directories that have a pending rmdir by inode
    number and generation number, instead of only inode number.
    
    A test case for fstests follows soon.
    
    Reported-by: Massimo B. <massimo.b@gmx.net>
    Tested-by: Massimo B. <massimo.b@gmx.net>
    Link: https://lore.kernel.org/linux-btrfs/6ae34776e85912960a253a8327068a892998e685.camel@gmx.net/
    CC: stable@vger.kernel.org # 4.19+
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0cb0b876f17fb9e7daf82cb358074200d9ca7f11
Author: PeiSen Hou <pshou@realtek.com>
Date:   Thu Dec 31 11:57:28 2020 +0100

    ALSA: hda/realtek: Add two "Intel Reference board" SSID in the ALC256.
    
    commit ce2e79b223867b9e586021b55dee7035517a236b upstream.
    
    Add two "Intel Reference boad" SSID in the alc256.
    Enable "power saving mode" and Enable "headset jack mode".
    
    Signed-off-by: PeiSen Hou <pshou@realtek.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/5978d2267f034c28973d117925ec9c63@realtek.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 02e59692a6b1cbc6e91fc92f60cd6c5496c8e838
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Wed Dec 30 20:56:35 2020 +0800

    ALSA: hda/realtek: Enable mute and micmute LED on HP EliteBook 850 G7
    
    commit a598098cc9737f612dbab52294433fc26c51cc9b upstream.
    
    HP EliteBook 850 G7 uses the same GPIO pins as ALC285_FIXUP_HP_GPIO_LED
    to enable mute and micmute LED. So apply the quirk to enable the LEDs.
    
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20201230125636.45028-1-kai.heng.feng@canonical.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d63a96f45c4f337f1c4d5e27f44aa732a7e463a9
Author: Kailang Yang <kailang@realtek.com>
Date:   Fri Oct 23 14:46:47 2020 +0800

    ALSA: hda/realtek - Fix speaker volume control on Lenovo C940
    
    commit f86de9b1c0663b0a3ca2dcddec9aa910ff0fbf2c upstream.
    
    Cannot adjust speaker's volume on Lenovo C940.
    Applying the alc298_fixup_speaker_volume function can fix the issue.
    
    [ Additional note: C940 has I2S amp for the speaker and this needs the
      same initialization as Dell machines.
      The patch was slightly modified so that the quirk entry is moved
      next to the corresponding Dell quirk entry. -- tiwai ]
    
    Signed-off-by: Kailang Yang <kailang@realtek.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/ea25b4e5c468491aa2e9d6cb1f2fced3@realtek.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 30fd9778cf8f2c0791072039d3a89e1bbcc1cb5b
Author: bo liu <bo.liu@senarytech.com>
Date:   Tue Dec 29 11:52:26 2020 +0800

    ALSA: hda/conexant: add a new hda codec CX11970
    
    commit 744a11abc56405c5a106e63da30a941b6d27f737 upstream.
    
    The current kernel does not support the cx11970 codec chip.
    Add a codec configuration item to kernel.
    
    [ Minor coding style fix by tiwai ]
    
    Signed-off-by: bo liu <bo.liu@senarytech.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20201229035226.62120-1-bo.liu@senarytech.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 121944484cc4e7d76f0706706a2de178484ada1d
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Jan 4 16:30:46 2021 +0100

    ALSA: hda/via: Fix runtime PM for Clevo W35xSS
    
    commit 4bfd6247fa9164c8e193a55ef9c0ea3ee22f82d8 upstream.
    
    Clevo W35xSS_370SS with VIA codec has had the runtime PM problem that
    looses the power state of some nodes after the runtime resume.  This
    was worked around by disabling the default runtime PM via a denylist
    entry.  Since 5.10.x made the runtime PM applied (casually) even
    though it's disabled in the denylist, this problem was revisited.  The
    result was that disabling power_save_node feature suffices for the
    runtime PM problem.
    
    This patch implements the disablement of power_save_node feature in
    VIA codec for the device.  It also drops the former denylist entry,
    too, as the runtime PM should work in the codec side properly now.
    
    Fixes: b529ef2464ad ("ALSA: hda: Add Clevo W35xSS_370SS to the power_save blacklist")
    Reported-by: Christian Labisch <clnetbox@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20210104153046.19993-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a5c7a456680f00b1c0dc405e758d19c184ba57db
Author: Lai Jiangshan <laijs@linux.alibaba.com>
Date:   Thu Dec 17 23:41:18 2020 +0800

    kvm: check tlbs_dirty directly
    
    commit 88bf56d04bc3564542049ec4ec168a8b60d0b48c upstream.
    
    In kvm_mmu_notifier_invalidate_range_start(), tlbs_dirty is used as:
            need_tlb_flush |= kvm->tlbs_dirty;
    with need_tlb_flush's type being int and tlbs_dirty's type being long.
    
    It means that tlbs_dirty is always used as int and the higher 32 bits
    is useless.  We need to check tlbs_dirty in a correct way and this
    change checks it directly without propagating it to need_tlb_flush.
    
    Note: it's _extremely_ unlikely this neglecting of higher 32 bits can
    cause problems in practice.  It would require encountering tlbs_dirty
    on a 4 billion count boundary, and KVM would need to be using shadow
    paging or be running a nested guest.
    
    Cc: stable@vger.kernel.org
    Fixes: a4ee1ca4a36e ("KVM: MMU: delay flush all tlbs on sync_page path")
    Signed-off-by: Lai Jiangshan <laijs@linux.alibaba.com>
    Message-Id: <20201217154118.16497-1-jiangshanlai@gmail.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 10dcb79ec79eed3a8becfef892d7719f4cd52e11
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Wed Dec 2 22:28:12 2020 -0800

    x86/mm: Fix leak of pmd ptlock
    
    commit d1c5246e08eb64991001d97a3bd119c93edbc79a upstream.
    
    Commit
    
      28ee90fe6048 ("x86/mm: implement free pmd/pte page interfaces")
    
    introduced a new location where a pmd was released, but neglected to
    run the pmd page destructor. In fact, this happened previously for a
    different pmd release path and was fixed by commit:
    
      c283610e44ec ("x86, mm: do not leak page->ptl for pmd page tables").
    
    This issue was hidden until recently because the failure mode is silent,
    but commit:
    
      b2b29d6d0119 ("mm: account PMD tables like PTE tables")
    
    turns the failure mode into this signature:
    
     BUG: Bad page state in process lt-pmem-ns  pfn:15943d
     page:000000007262ed7b refcount:0 mapcount:-1024 mapping:0000000000000000 index:0x0 pfn:0x15943d
     flags: 0xaffff800000000()
     raw: 00affff800000000 dead000000000100 0000000000000000 0000000000000000
     raw: 0000000000000000 ffff913a029bcc08 00000000fffffbff 0000000000000000
     page dumped because: nonzero mapcount
     [..]
      dump_stack+0x8b/0xb0
      bad_page.cold+0x63/0x94
      free_pcp_prepare+0x224/0x270
      free_unref_page+0x18/0xd0
      pud_free_pmd_page+0x146/0x160
      ioremap_pud_range+0xe3/0x350
      ioremap_page_range+0x108/0x160
      __ioremap_caller.constprop.0+0x174/0x2b0
      ? memremap+0x7a/0x110
      memremap+0x7a/0x110
      devm_memremap+0x53/0xa0
      pmem_attach_disk+0x4ed/0x530 [nd_pmem]
      ? __devm_release_region+0x52/0x80
      nvdimm_bus_probe+0x85/0x210 [libnvdimm]
    
    Given this is a repeat occurrence it seemed prudent to look for other
    places where this destructor might be missing and whether a better
    helper is needed. try_to_free_pmd_page() looks like a candidate, but
    testing with setting up and tearing down pmd mappings via the dax unit
    tests is thus far not triggering the failure.
    
    As for a better helper pmd_free() is close, but it is a messy fit
    due to requiring an @mm arg. Also, ___pmd_free_tlb() wants to call
    paravirt_tlb_remove_table() instead of free_page(), so open-coded
    pgtable_pmd_page_dtor() seems the best way forward for now.
    
    Debugged together with Matthew Wilcox <willy@infradead.org>.
    
    Fixes: 28ee90fe6048 ("x86/mm: implement free pmd/pte page interfaces")
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Tested-by: Yi Zhang <yi.zhang@redhat.com>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: <stable@vger.kernel.org>
    Link: https://lkml.kernel.org/r/160697689204.605323.17629854984697045602.stgit@dwillia2-desk3.amr.corp.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d3e5db486fd8363cd4e340036be8659efba4c246
Author: Johan Hovold <johan@kernel.org>
Date:   Fri Jan 8 15:55:28 2021 +0100

    USB: serial: keyspan_pda: remove unused variable
    
    Remove an unused variable which was mistakingly left by commit
    37faf5061541 ("USB: serial: keyspan_pda: fix write-wakeup
    use-after-free") and only removed by a later change.
    
    This is needed to suppress a W=1 warning about the unused variable in
    the stable trees that the build bots triggers.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bcffe2de9dde74174805d5f56a990353e33b8072
Author: Eddie Hung <eddie.hung@mediatek.com>
Date:   Tue Dec 29 18:53:35 2020 +0800

    usb: gadget: configfs: Fix use-after-free issue with udc_name
    
    commit 64e6bbfff52db4bf6785fab9cffab850b2de6870 upstream.
    
    There is a use-after-free issue, if access udc_name
    in function gadget_dev_desc_UDC_store after another context
    free udc_name in function unregister_gadget.
    
    Context 1:
    gadget_dev_desc_UDC_store()->unregister_gadget()->
    free udc_name->set udc_name to NULL
    
    Context 2:
    gadget_dev_desc_UDC_show()-> access udc_name
    
    Call trace:
    dump_backtrace+0x0/0x340
    show_stack+0x14/0x1c
    dump_stack+0xe4/0x134
    print_address_description+0x78/0x478
    __kasan_report+0x270/0x2ec
    kasan_report+0x10/0x18
    __asan_report_load1_noabort+0x18/0x20
    string+0xf4/0x138
    vsnprintf+0x428/0x14d0
    sprintf+0xe4/0x12c
    gadget_dev_desc_UDC_show+0x54/0x64
    configfs_read_file+0x210/0x3a0
    __vfs_read+0xf0/0x49c
    vfs_read+0x130/0x2b4
    SyS_read+0x114/0x208
    el0_svc_naked+0x34/0x38
    
    Add mutex_lock to protect this kind of scenario.
    
    Signed-off-by: Eddie Hung <eddie.hung@mediatek.com>
    Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
    Reviewed-by: Peter Chen <peter.chen@nxp.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/1609239215-21819-1-git-send-email-macpaul.lin@mediatek.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 27682822185219b66bb93d3978c7f92e49f32125
Author: Chandana Kishori Chiluveru <cchiluve@codeaurora.org>
Date:   Tue Dec 29 14:44:43 2020 -0800

    usb: gadget: configfs: Preserve function ordering after bind failure
    
    commit 6cd0fe91387917be48e91385a572a69dfac2f3f7 upstream.
    
    When binding the ConfigFS gadget to a UDC, the functions in each
    configuration are added in list order. However, if usb_add_function()
    fails, the failed function is put back on its configuration's
    func_list and purge_configs_funcs() is called to further clean up.
    
    purge_configs_funcs() iterates over the configurations and functions
    in forward order, calling unbind() on each of the previously added
    functions. But after doing so, each function gets moved to the
    tail of the configuration's func_list. This results in reshuffling
    the original order of the functions within a configuration such
    that the failed function now appears first even though it may have
    originally appeared in the middle or even end of the list. At this
    point if the ConfigFS gadget is attempted to re-bind to the UDC,
    the functions will be added in a different order than intended,
    with the only recourse being to remove and relink the functions all
    over again.
    
    An example of this as follows:
    
    ln -s functions/mass_storage.0 configs/c.1
    ln -s functions/ncm.0 configs/c.1
    ln -s functions/ffs.adb configs/c.1     # oops, forgot to start adbd
    echo "<udc device>" > UDC               # fails
    start adbd
    echo "<udc device>" > UDC               # now succeeds, but...
                                            # bind order is
                                            # "ADB", mass_storage, ncm
    
    [30133.118289] configfs-gadget gadget: adding 'Mass Storage Function'/ffffff810af87200 to config 'c'/ffffff817d6a2520
    [30133.119875] configfs-gadget gadget: adding 'cdc_network'/ffffff80f48d1a00 to config 'c'/ffffff817d6a2520
    [30133.119974] using random self ethernet address
    [30133.120002] using random host ethernet address
    [30133.139604] usb0: HOST MAC 3e:27:46:ba:3e:26
    [30133.140015] usb0: MAC 6e:28:7e:42:66:6a
    [30133.140062] configfs-gadget gadget: adding 'Function FS Gadget'/ffffff80f3868438 to config 'c'/ffffff817d6a2520
    [30133.140081] configfs-gadget gadget: adding 'Function FS Gadget'/ffffff80f3868438 --> -19
    [30133.140098] configfs-gadget gadget: unbind function 'Mass Storage Function'/ffffff810af87200
    [30133.140119] configfs-gadget gadget: unbind function 'cdc_network'/ffffff80f48d1a00
    [30133.173201] configfs-gadget a600000.dwc3: failed to start g1: -19
    [30136.661933] init: starting service 'adbd'...
    [30136.700126] read descriptors
    [30136.700413] read strings
    [30138.574484] configfs-gadget gadget: adding 'Function FS Gadget'/ffffff80f3868438 to config 'c'/ffffff817d6a2520
    [30138.575497] configfs-gadget gadget: adding 'Mass Storage Function'/ffffff810af87200 to config 'c'/ffffff817d6a2520
    [30138.575554] configfs-gadget gadget: adding 'cdc_network'/ffffff80f48d1a00 to config 'c'/ffffff817d6a2520
    [30138.575631] using random self ethernet address
    [30138.575660] using random host ethernet address
    [30138.595338] usb0: HOST MAC 2e:cf:43:cd:ca:c8
    [30138.597160] usb0: MAC 6a:f0:9f:ee:82:a0
    [30138.791490] configfs-gadget gadget: super-speed config #1: c
    
    Fix this by reversing the iteration order of the functions in
    purge_config_funcs() when unbinding them, and adding them back to
    the config's func_list at the head instead of the tail. This
    ensures that we unbind and unwind back to the original list order.
    
    Fixes: 88af8bbe4ef7 ("usb: gadget: the start of the configfs interface")
    Signed-off-by: Chandana Kishori Chiluveru <cchiluve@codeaurora.org>
    Signed-off-by: Jack Pham <jackp@codeaurora.org>
    Reviewed-by: Peter Chen <peter.chen@nxp.com>
    Link: https://lore.kernel.org/r/20201229224443.31623-1-jackp@codeaurora.org
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b2bd36f5449526dd747ce27850d82020baa9a6a7
Author: Sriharsha Allenki <sallenki@codeaurora.org>
Date:   Wed Dec 2 18:32:20 2020 +0530

    usb: gadget: Fix spinlock lockup on usb_function_deactivate
    
    commit 5cc35c224a80aa5a5a539510ef049faf0d6ed181 upstream.
    
    There is a spinlock lockup as part of composite_disconnect
    when it tries to acquire cdev->lock as part of usb_gadget_deactivate.
    This is because the usb_gadget_deactivate is called from
    usb_function_deactivate with the same spinlock held.
    
    This would result in the below call stack and leads to stall.
    
    rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
    rcu:     3-...0: (1 GPs behind) idle=162/1/0x4000000000000000
    softirq=10819/10819 fqs=2356
     (detected by 2, t=5252 jiffies, g=20129, q=3770)
     Task dump for CPU 3:
     task:uvc-gadget_wlhe state:R  running task     stack:    0 pid:  674 ppid:
     636 flags:0x00000202
     Call trace:
      __switch_to+0xc0/0x170
      _raw_spin_lock_irqsave+0x84/0xb0
      composite_disconnect+0x28/0x78
      configfs_composite_disconnect+0x68/0x70
      usb_gadget_disconnect+0x10c/0x128
      usb_gadget_deactivate+0xd4/0x108
      usb_function_deactivate+0x6c/0x80
      uvc_function_disconnect+0x20/0x58
      uvc_v4l2_release+0x30/0x88
      v4l2_release+0xbc/0xf0
      __fput+0x7c/0x230
      ____fput+0x14/0x20
      task_work_run+0x88/0x140
      do_notify_resume+0x240/0x6f0
      work_pending+0x8/0x200
    
    Fix this by doing an unlock on cdev->lock before the usb_gadget_deactivate
    call from usb_function_deactivate.
    
    The same lockup can happen in the usb_gadget_activate path. Fix that path
    as well.
    
    Reported-by: Peter Chen <peter.chen@nxp.com>
    Link: https://lore.kernel.org/linux-usb/20201102094936.GA29581@b29397-desktop/
    Tested-by: Peter Chen <peter.chen@nxp.com>
    Signed-off-by: Sriharsha Allenki <sallenki@codeaurora.org>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20201202130220.24926-1-sallenki@codeaurora.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ce507b55db298acc385857a3cfd2f1c17798ed07
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Tue Nov 17 17:29:55 2020 +0800

    USB: gadget: legacy: fix return error code in acm_ms_bind()
    
    commit c91d3a6bcaa031f551ba29a496a8027b31289464 upstream.
    
    If usb_otg_descriptor_alloc() failed, it need return ENOMEM.
    
    Fixes: 578aa8a2b12c ("usb: gadget: acm_ms: allocate and init otg descriptor by otg capabilities")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20201117092955.4102785-1-yangyingliang@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7f875ea9883cc4410406ec050fe0d3c14bfda1a3
Author: Manish Narani <manish.narani@xilinx.com>
Date:   Tue Nov 17 12:43:35 2020 +0530

    usb: gadget: u_ether: Fix MTU size mismatch with RX packet size
    
    commit 0a88fa221ce911c331bf700d2214c5b2f77414d3 upstream.
    
    Fix the MTU size issue with RX packet size as the host sends the packet
    with extra bytes containing ethernet header. This causes failure when
    user sets the MTU size to the maximum i.e. 15412. In this case the
    ethernet packet received will be of length 15412 plus the ethernet header
    length. This patch fixes the issue where there is a check that RX packet
    length must not be more than max packet length.
    
    Fixes: bba787a860fa ("usb: gadget: ether: Allow jumbo frames")
    Signed-off-by: Manish Narani <manish.narani@xilinx.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/1605597215-122027-1-git-send-email-manish.narani@xilinx.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b89a5f39c2b54dee995626c35518f29cdd595165
Author: Zqiang <qiang.zhang@windriver.com>
Date:   Thu Dec 10 10:01:48 2020 +0800

    usb: gadget: function: printer: Fix a memory leak for interface descriptor
    
    commit 2cc332e4ee4febcbb685e2962ad323fe4b3b750a upstream.
    
    When printer driver is loaded, the printer_func_bind function is called, in
    this function, the interface descriptor be allocated memory, if after that,
    the error occurred, the interface descriptor memory need to be free.
    
    Reviewed-by: Peter Chen <peter.chen@nxp.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Zqiang <qiang.zhang@windriver.com>
    Link: https://lore.kernel.org/r/20201210020148.6691-1-qiang.zhang@windriver.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 692ab0726460367cb293867f31a1cdd1e5f56d1a
Author: Jerome Brunet <jbrunet@baylibre.com>
Date:   Mon Dec 21 18:35:28 2020 +0100

    usb: gadget: f_uac2: reset wMaxPacketSize
    
    commit 9389044f27081d6ec77730c36d5bf9a1288bcda2 upstream.
    
    With commit 913e4a90b6f9 ("usb: gadget: f_uac2: finalize wMaxPacketSize according to bandwidth")
    wMaxPacketSize is computed dynamically but the value is never reset.
    
    Because of this, the actual maximum packet size can only decrease each time
    the audio gadget is instantiated.
    
    Reset the endpoint maximum packet size and mark wMaxPacketSize as dynamic
    to solve the problem.
    
    Fixes: 913e4a90b6f9 ("usb: gadget: f_uac2: finalize wMaxPacketSize according to bandwidth")
    Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20201221173531.215169-2-jbrunet@baylibre.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7ac84fa85ba20a274aeeff9e497275a9f08fbabf
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Sun Jan 3 22:42:17 2021 +0100

    usb: gadget: select CONFIG_CRC32
    
    commit d7889c2020e08caab0d7e36e947f642d91015bd0 upstream.
    
    Without crc32 support, this driver fails to link:
    
    arm-linux-gnueabi-ld: drivers/usb/gadget/function/f_eem.o: in function `eem_unwrap':
    f_eem.c:(.text+0x11cc): undefined reference to `crc32_le'
    arm-linux-gnueabi-ld: drivers/usb/gadget/function/f_ncm.o:f_ncm.c:(.text+0x1e40):
    more undefined references to `crc32_le' follow
    
    Fixes: 6d3865f9d41f ("usb: gadget: NCM: Add transmit multi-frame.")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20210103214224.1996535-1-arnd@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 77a804dd6b461c40ae8a6e996ee7ce2fbea5b8e7
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Dec 23 18:45:57 2020 +0100

    ALSA: usb-audio: Fix UBSAN warnings for MIDI jacks
    
    commit c06ccf3ebb7503706ea49fd248e709287ef385a3 upstream.
    
    The calculation of in_cables and out_cables bitmaps are done with the
    bit shift by the value from the descriptor, which is an arbitrary
    value, and can lead to UBSAN shift-out-of-bounds warnings.
    
    Fix it by filtering the bad descriptor values with the check of the
    upper bound 0x10 (the cable bitmaps are 16 bits).
    
    Reported-by: syzbot+92e45ae45543f89e8c88@syzkaller.appspotmail.com
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20201223174557.10249-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5c263f16822f5fed717484b9239c241dac4b4b9e
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Jan 4 15:53:02 2021 +0100

    USB: usblp: fix DMA to stack
    
    commit 020a1f453449294926ca548d8d5ca970926e8dfd upstream.
    
    Stack-allocated buffers cannot be used for DMA (on all architectures).
    
    Replace the HP-channel macro with a helper function that allocates a
    dedicated transfer buffer so that it can continue to be used with
    arguments from the stack.
    
    Note that the buffer is cleared on allocation as usblp_ctrl_msg()
    returns success also on short transfers (the buffer is only used for
    debugging).
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://lore.kernel.org/r/20210104145302.2087-1-johan@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 41f15da2abd9ccbd3181db632b6bd2b5c606aabf
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Dec 14 11:30:53 2020 +0100

    USB: yurex: fix control-URB timeout handling
    
    commit 372c93131998c0622304bed118322d2a04489e63 upstream.
    
    Make sure to always cancel the control URB in write() so that it can be
    reused after a timeout or spurious CMD_ACK.
    
    Currently any further write requests after a timeout would fail after
    triggering a WARN() in usb_submit_urb() when attempting to submit the
    already active URB.
    
    Reported-by: syzbot+e87ebe0f7913f71f2ea5@syzkaller.appspotmail.com
    Fixes: 6bc235a2e24a ("USB: add driver for Meywa-Denki & Kayac YUREX")
    Cc: stable <stable@vger.kernel.org>     # 2.6.37
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 175f7a5fa7e69122283ec46eb0a931e045f33f82
Author: Bjørn Mork <bjorn@mork.no>
Date:   Wed Dec 30 16:25:34 2020 +0100

    USB: serial: option: add Quectel EM160R-GL
    
    commit d6c1ddd938d84a1adef7e19e8efc10e1b4df5034 upstream.
    
    New modem using ff/ff/30 for QCDM, ff/00/00 for  AT and NMEA,
    and ff/ff/ff for RMNET/QMI.
    
    T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=5000 MxCh= 0
    D: Ver= 3.20 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1
    P: Vendor=2c7c ProdID=0620 Rev= 4.09
    S: Manufacturer=Quectel
    S: Product=EM160R-GL
    S: SerialNumber=e31cedc1
    C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=896mA
    I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=(none)
    E: Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E: Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
    E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
    E: Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E: Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
    E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
    E: Ad=84(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E: Ad=03(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
    E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
    E: Ad=86(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E: Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E: Ad=88(I) Atr=03(Int.) MxPS= 8 Ivl=32ms
    E: Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E: Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    [ johan: add model comment ]
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1a59feb52dc436a8c4a94913556f2a1f453a15ed
Author: Daniel Palmer <daniel@0x0f.com>
Date:   Sun Dec 27 12:17:16 2020 +0900

    USB: serial: option: add LongSung M5710 module support
    
    commit 0e2d6795e8dbe91c2f5473564c6b25d11df3778b upstream.
    
    Add a device-id entry for the LongSung M5710 module.
    
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=2df3 ProdID=9d03 Rev= 1.00
    S:  Manufacturer=Marvell
    S:  Product=Mobile Composite Device Bus
    S:  SerialNumber=<snip>
    C:* #Ifs= 5 Cfg#= 1 Atr=c0 MxPwr=500mA
    A:  FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=03
    I:* If#= 0 Alt= 0 #EPs= 1 Cls=e0(wlcon) Sub=01 Prot=03 Driver=rndis_host
    E:  Ad=87(I) Atr=03(Int.) MxPS=  64 Ivl=4096ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=0c(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=0b(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=89(I) Atr=03(Int.) MxPS=  64 Ivl=4096ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=0f(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=88(I) Atr=03(Int.) MxPS=  64 Ivl=4096ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=0a(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Signed-off-by: Daniel Palmer <daniel@0x0f.com>
    https://lore.kernel.org/r/20201227031716.1343300-1-daniel@0x0f.com
    [ johan: drop id defines, only bind to vendor class ]
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ac48b1dacb077a1b2efa5969f82b936a9d565b18
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Jan 4 15:50:07 2021 +0100

    USB: serial: iuu_phoenix: fix DMA from stack
    
    commit 54d0a3ab80f49f19ee916def62fe067596833403 upstream.
    
    Stack-allocated buffers cannot be used for DMA (on all architectures) so
    allocate the flush command buffer using kmalloc().
    
    Fixes: 60a8fc017103 ("USB: add iuu_phoenix driver")
    Cc: stable <stable@vger.kernel.org>     # 2.6.25
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8a051eaae70801b56326dcccc550df4aefbc9f17
Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Date:   Mon Jan 4 20:07:15 2021 -0800

    usb: uas: Add PNY USB Portable SSD to unusual_uas
    
    commit 96ebc9c871d8a28fb22aa758dd9188a4732df482 upstream.
    
    Here's another variant PNY Pro Elite USB 3.1 Gen 2 portable SSD that
    hangs and doesn't respond to ATA_1x pass-through commands. If it doesn't
    support these commands, it should respond properly to the host. Add it
    to the unusual uas list to be able to move forward with other
    operations.
    
    Cc: stable@vger.kernel.org
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Acked-by: Oliver Neukum <oneukum@suse.com>
    Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/2edc7af892d0913bf06f5b35e49ec463f03d5ed8.1609819418.git.Thinh.Nguyen@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a7b81d0d2e07ae7553b8a49f69fa731b80cc4195
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Mon Dec 28 23:13:09 2020 -0800

    usb: usbip: vhci_hcd: protect shift size
    
    commit 718bf42b119de652ebcc93655a1f33a9c0d04b3c upstream.
    
    Fix shift out-of-bounds in vhci_hcd.c:
    
      UBSAN: shift-out-of-bounds in ../drivers/usb/usbip/vhci_hcd.c:399:41
      shift exponent 768 is too large for 32-bit type 'int'
    
    Fixes: 03cd00d538a6 ("usbip: vhci-hcd: Set the vhci structure up to work")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Reported-by: syzbot+297d20e437b79283bf6d@syzkaller.appspotmail.com
    Cc: Yuyang Du <yuyang.du@intel.com>
    Cc: Shuah Khan <shuahkh@osg.samsung.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: linux-usb@vger.kernel.org
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20201229071309.18418-1-rdunlap@infradead.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f7cc27eb358d2fa8a5234ef7b7da72d0a6e76574
Author: Michael Grzeschik <m.grzeschik@pengutronix.de>
Date:   Tue Dec 15 20:31:47 2020 +0100

    USB: xhci: fix U1/U2 handling for hardware with XHCI_INTEL_HOST quirk set
    
    commit 5d5323a6f3625f101dbfa94ba3ef7706cce38760 upstream.
    
    The commit 0472bf06c6fd ("xhci: Prevent U1/U2 link pm states if exit
    latency is too long") was constraining the xhci code not to allow U1/U2
    sleep states if the latency to wake up from the U-states reached the
    service interval of an periodic endpoint. This fix was not taking into
    account that in case the quirk XHCI_INTEL_HOST is set, the wakeup time
    will be calculated and configured differently.
    
    It checks for u1_params.mel/u2_params.mel as a limit. But the code could
    decide to write another MEL into the hardware. This leads to broken
    cases where not enough bandwidth is available for other devices:
    
    usb 1-2: can't set config #1, error -28
    
    This patch is fixing that case by checking for timeout_ns after the
    wakeup time was calculated depending on the quirks.
    
    Fixes: 0472bf06c6fd ("xhci: Prevent U1/U2 link pm states if exit latency is too long")
    Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20201215193147.11738-1-m.grzeschik@pengutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ea472d839133fa3e396d48f649685f903ad6af2a
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Tue Nov 17 09:14:30 2020 +0800

    usb: chipidea: ci_hdrc_imx: add missing put_device() call in usbmisc_get_init_data()
    
    commit 83a43ff80a566de8718dfc6565545a0080ec1fb5 upstream.
    
    if of_find_device_by_node() succeed, usbmisc_get_init_data() doesn't have
    a corresponding put_device(). Thus add put_device() to fix the exception
    handling for this function implementation.
    
    Fixes: ef12da914ed6 ("usb: chipidea: imx: properly check for usbmisc")
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20201117011430.642589-1-yukuai3@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a37a0667e1e085c3d5ddffb53192dbc24052137b
Author: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Date:   Thu Dec 10 11:50:06 2020 +0300

    usb: dwc3: ulpi: Use VStsDone to detect PHY regs access completion
    
    commit ce722da66d3e9384aa2de9d33d584ee154e5e157 upstream.
    
    In accordance with [1] the DWC_usb3 core sets the GUSB2PHYACCn.VStsDone
    bit when the PHY vendor control access is done and clears it when the
    application initiates a new transaction. The doc doesn't say anything
    about the GUSB2PHYACCn.VStsBsy flag serving for the same purpose. Moreover
    we've discovered that the VStsBsy flag can be cleared before the VStsDone
    bit. So using the former as a signal of the PHY control registers
    completion might be dangerous. Let's have the VStsDone flag utilized
    instead then.
    
    [1] Synopsys DesignWare Cores SuperSpeed USB 3.0 xHCI Host Controller
        Databook, 2.70a, December 2013, p.388
    
    Fixes: 88bc9d194ff6 ("usb: dwc3: add ULPI interface support")
    Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
    Link: https://lore.kernel.org/r/20201210085008.13264-2-Sergey.Semin@baikalelectronics.ru
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5b8e1be9e0c156ef5e1cdb62cd9981c91951f0f3
Author: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Date:   Sun Dec 20 00:25:53 2020 +0900

    USB: cdc-wdm: Fix use after free in service_outstanding_interrupt().
    
    commit 5e5ff0b4b6bcb4d17b7a26ec8bcfc7dd4651684f upstream.
    
    syzbot is reporting UAF at usb_submit_urb() [1], for
    service_outstanding_interrupt() is not checking WDM_DISCONNECTING
    before calling usb_submit_urb(). Close the race by doing same checks
    wdm_read() does upon retry.
    
    Also, while wdm_read() checks WDM_DISCONNECTING with desc->rlock held,
    service_interrupt_work() does not hold desc->rlock. Thus, it is possible
    that usb_submit_urb() is called from service_outstanding_interrupt() from
    service_interrupt_work() after WDM_DISCONNECTING was set and kill_urbs()
     from wdm_disconnect() completed. Thus, move kill_urbs() in
    wdm_disconnect() to after cancel_work_sync() (which makes sure that
    service_interrupt_work() is no longer running) completed.
    
    Although it seems to be safe to dereference desc->intf->dev in
    service_outstanding_interrupt() even if WDM_DISCONNECTING was already set
    because desc->rlock or cancel_work_sync() prevents wdm_disconnect() from
    reaching list_del() before service_outstanding_interrupt() completes,
    let's not emit error message if WDM_DISCONNECTING is set by
    wdm_disconnect() while usb_submit_urb() is in progress.
    
    [1] https://syzkaller.appspot.com/bug?extid=9e04e2df4a32fb661daf
    
    Reported-by: syzbot <syzbot+9e04e2df4a32fb661daf@syzkaller.appspotmail.com>
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/620e2ee0-b9a3-dbda-a25b-a93e0ed03ec5@i-love.sakura.ne.jp
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5445502a344b5fd64b41511e7a4b3a8cecf06eda
Author: Sean Young <sean@mess.org>
Date:   Sun Dec 27 13:45:02 2020 +0000

    USB: cdc-acm: blacklist another IR Droid device
    
    commit 0ffc76539e6e8d28114f95ac25c167c37b5191b3 upstream.
    
    This device is supported by the IR Toy driver.
    
    Reported-by: Georgi Bakalski <georgi.bakalski@gmail.com>
    Signed-off-by: Sean Young <sean@mess.org>
    Acked-by: Oliver Neukum <oneukum@suse.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20201227134502.4548-2-sean@mess.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eeae1d95ce4e3c59a4d0ae9ce59c886a8440db41
Author: taehyun.cho <taehyun.cho@samsung.com>
Date:   Thu Jan 7 00:46:25 2021 +0900

    usb: gadget: enable super speed plus
    
    commit e2459108b5a0604c4b472cae2b3cb8d3444c77fb upstream.
    
    Enable Super speed plus in configfs to support USB3.1 Gen2.
    This ensures that when a USB gadget is plugged in, it is
    enumerated as Gen 2 and connected at 10 Gbps if the host and
    cable are capable of it.
    
    Many in-tree gadget functions (fs, midi, acm, ncm, mass_storage,
    etc.) already have SuperSpeed Plus support.
    
    Tested: plugged gadget into Linux host and saw:
    [284907.385986] usb 8-2: new SuperSpeedPlus Gen 2 USB device number 3 using xhci_hcd
    
    Tested-by: Lorenzo Colitti <lorenzo@google.com>
    Acked-by: Felipe Balbi <balbi@kernel.org>
    Signed-off-by: taehyun.cho <taehyun.cho@samsung.com>
    Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
    Link: https://lore.kernel.org/r/20210106154625.2801030-1-lorenzo@google.com
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 70cf59b8ffb4899b991e4f9668af0ea999ae1b60
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sun Dec 13 16:35:13 2020 +0100

    staging: mt7621-dma: Fix a resource leak in an error handling path
    
    commit d887d6104adeb94d1b926936ea21f07367f0ff9f upstream.
    
    If an error occurs after calling 'mtk_hsdma_init()', it must be undone by
    a corresponding call to 'mtk_hsdma_uninit()' as already done in the
    remove function.
    
    Fixes: 0853c7a53eb3 ("staging: mt7621-dma: ralink: add rt2880 dma engine")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20201213153513.138723-1-christophe.jaillet@wanadoo.fr
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c511f27e130e801e9f5e58d2865bb6f3a5ab5e7c
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Mon Jan 4 13:59:53 2021 -0700

    powerpc: Handle .text.{hot,unlikely}.* in linker script
    
    commit 3ce47d95b7346dcafd9bed3556a8d072cb2b8571 upstream.
    
    Commit eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input
    sections") added ".text.unlikely.*" and ".text.hot.*" due to an LLVM
    change [1].
    
    After another LLVM change [2], these sections are seen in some PowerPC
    builds, where there is a orphan section warning then build failure:
    
    $ make -skj"$(nproc)" \
           ARCH=powerpc CROSS_COMPILE=powerpc64le-linux-gnu- LLVM=1 O=out \
           distclean powernv_defconfig zImage.epapr
    ld.lld: warning: kernel/built-in.a(panic.o):(.text.unlikely.) is being placed in '.text.unlikely.'
    ...
    ld.lld: warning: address (0xc000000000009314) of section .text is not a multiple of alignment (256)
    ...
    ERROR: start_text address is c000000000009400, should be c000000000008000
    ERROR: try to enable LD_HEAD_STUB_CATCH config option
    ERROR: see comments in arch/powerpc/tools/head_check.sh
    ...
    
    Explicitly handle these sections like in the main linker script so
    there is no more build failure.
    
    [1]: https://reviews.llvm.org/D79600
    [2]: https://reviews.llvm.org/D92493
    
    Fixes: 83a092cf95f2 ("powerpc: Link warning for orphan sections")
    Cc: stable@vger.kernel.org
    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://github.com/ClangBuiltLinux/linux/issues/1218
    Link: https://lore.kernel.org/r/20210104205952.1399409-1-natechancellor@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 867c10a03f84599af1c0c4d820b78aabd5308c65
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Dec 4 09:01:36 2020 +0100

    crypto: asym_tpm: correct zero out potential secrets
    
    commit f93274ef0fe972c120c96b3207f8fce376231a60 upstream.
    
    The function derive_pub_key() should be calling memzero_explicit()
    instead of memset() in case the complier decides to optimize away the
    call to memset() because it "knows" no one is going to touch the memory
    anymore.
    
    Cc: stable <stable@vger.kernel.org>
    Reported-by: Ilil Blum Shem-Tov <ilil.blum.shem-tov@intel.com>
    Tested-by: Ilil Blum Shem-Tov <ilil.blum.shem-tov@intel.com>
    Link: https://lore.kernel.org/r/X8ns4AfwjKudpyfe@kroah.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ff7397add93551647269785a03583aec2ba9f99a
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Sat Jan 2 14:59:09 2021 +0100

    crypto: ecdh - avoid buffer overflow in ecdh_set_secret()
    
    commit 0aa171e9b267ce7c52d3a3df7bc9c1fc0203dec5 upstream.
    
    Pavel reports that commit 17858b140bf4 ("crypto: ecdh - avoid unaligned
    accesses in ecdh_set_secret()") fixes one problem but introduces another:
    the unconditional memcpy() introduced by that commit may overflow the
    target buffer if the source data is invalid, which could be the result of
    intentional tampering.
    
    So check params.key_size explicitly against the size of the target buffer
    before validating the key further.
    
    Fixes: 17858b140bf4 ("crypto: ecdh - avoid unaligned accesses in ecdh_set_secret()")
    Reported-by: Pavel Machek <pavel@denx.de>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9e60056b1f532520dae5333c24e2e2b944c929b7
Author: Dexuan Cui <decui@microsoft.com>
Date:   Sat Jan 9 14:53:58 2021 -0800

    video: hyperv_fb: Fix the mmap() regression for v5.4.y and older
    
    db49200b1dad is backported from the mainline commit
    5f1251a48c17 ("video: hyperv_fb: Fix the cache type when mapping the VRAM"),
    to v5.4.y and older stable branches, but unluckily db49200b1dad causes
    mmap() to fail for /dev/fb0 due to EINVAL:
    
    [ 5797.049560] x86/PAT: a.out:1910 map pfn expected mapping type
      uncached-minus for [mem 0xf8200000-0xf85cbfff], got write-back
    
    This means the v5.4.y kernel detects an incompatibility issue about the
    mapping type of the VRAM: db49200b1dad changes to use Write-Back when
    mapping the VRAM, while the mmap() syscall tries to use Uncached-minus.
    That’s to say, the kernel thinks Uncached-minus is incompatible with
    Write-Back: see drivers/video/fbdev/core/fbmem.c: fb_mmap() ->
    vm_iomap_memory() -> io_remap_pfn_range() -> ... -> track_pfn_remap() ->
    reserve_pfn_range().
    
    Note: any v5.5 and newer kernel doesn't have the issue, because they
    have commit
    d21987d709e8 ("video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver")
    , and when the hyperv_fb driver has the deferred_io support,
    fb_deferred_io_init() overrides info->fbops->fb_mmap with
    fb_deferred_io_mmap(), which doesn’t check the mapping type
    incompatibility. Note: since it's VRAM here, the checking is not really
    necessary.
    
    Fix the regression by ioremap_wc(), which uses Write-combining. The kernel
    thinks it's compatible with Uncached-minus. The VRAM mappped by
    ioremap_wc() is slightly slower than mapped by ioremap_cache(), but is
    still significantly faster than by ioremap().
    
    Change the comment accordingly. Linux VM on ARM64 Hyper-V is still not
    working in the latest mainline yet, and when it works in future, the ARM64
    support is unlikely to be backported to v5.4 and older, so using
    ioremap_wc() in v5.4 and older should be ok.
    
    Note: this fix is only targeted at the stable branches:
    v5.4.y, v4.19.y, v4.14.y, v4.9.y and v4.4.y.
    
    Fixes: db49200b1dad ("video: hyperv_fb: Fix the cache type when mapping the VRAM")
    Signed-off-by: Dexuan Cui <decui@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 84d488719b27c21c0378ab51ad4e1569ce42a5fc
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sun Nov 22 13:17:25 2020 +0100

    Bluetooth: revert: hci_h5: close serdev device and free hu in h5_close
    
    commit 5c3b5796866f85354a5ce76a28f8ffba0dcefc7e upstream.
    
    There have been multiple revisions of the patch fix the h5->rx_skb
    leak. Accidentally the first revision (which is buggy) and v5 have
    both been merged:
    
    v1 commit 70f259a3f427 ("Bluetooth: hci_h5: close serdev device and free
    hu in h5_close");
    v5 commit 855af2d74c87 ("Bluetooth: hci_h5: fix memory leak in h5_close")
    
    The correct v5 makes changes slightly higher up in the h5_close()
    function, which allowed both versions to get merged without conflict.
    
    The changes from v1 unconditionally frees the h5 data struct, this
    is wrong because in the serdev enumeration case the memory is
    allocated in h5_serdev_probe() like this:
    
            h5 = devm_kzalloc(dev, sizeof(*h5), GFP_KERNEL);
    
    So its lifetime is tied to the lifetime of the driver being bound
    to the serdev and it is automatically freed when the driver gets
    unbound. In the serdev case the same h5 struct is re-used over
    h5_close() and h5_open() calls and thus MUST not be free-ed in
    h5_close().
    
    The serdev_device_close() added to h5_close() is incorrect in the
    same way, serdev_device_close() is called on driver unbound too and
    also MUST no be called from h5_close().
    
    This reverts the changes made by merging v1 of the patch, so that
    just the changes of the correct v5 remain.
    
    Cc: Anant Thazhemadam <anant.thazhemadam@gmail.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3417067b311146a4cc66944a550a211ca903bff3
Author: Dominique Martinet <asmadeus@codewreck.org>
Date:   Tue Dec 1 14:17:30 2020 +0100

    kbuild: don't hardcode depmod path
    
    commit 436e980e2ed526832de822cbf13c317a458b78e1 upstream.
    
    depmod is not guaranteed to be in /sbin, just let make look for
    it in the path like all the other invoked programs
    
    Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3f2a28930a7eae7a811af0897b4aac7af5238fe6
Author: Davide Caratti <dcaratti@redhat.com>
Date:   Thu Dec 17 22:29:46 2020 +0100

    net/sched: sch_taprio: ensure to reset/destroy all child qdiscs
    
    [ Upstream commit 698285da79f5b0b099db15a37ac661ac408c80eb ]
    
    taprio_graft() can insert a NULL element in the array of child qdiscs. As
    a consquence, taprio_reset() might not reset child qdiscs completely, and
    taprio_destroy() might leak resources. Fix it by ensuring that loops that
    iterate over q->qdiscs[] don't end when they find the first NULL item.
    
    Fixes: 44d4775ca518 ("net/sched: sch_taprio: reset child qdiscs before freeing them")
    Fixes: 5a781ccbd19e ("tc: Add support for configuring the taprio scheduler")
    Suggested-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Davide Caratti <dcaratti@redhat.com>
    Link: https://lore.kernel.org/r/13edef6778fef03adc751582562fba4a13e06d6a.1608240532.git.dcaratti@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c41ea30c3839bce0ad775304a91beeb736d8e2e4
Author: Shannon Nelson <snelson@pensando.io>
Date:   Fri Dec 18 13:50:01 2020 -0800

    ionic: account for vlan tag len in rx buffer len
    
    [ Upstream commit 83469893204281ecf65d572bddf02de29a19787c ]
    
    Let the FW know we have enough receive buffer space for the
    vlan tag if it isn't stripped.
    
    Fixes: 0f3154e6bcb3 ("ionic: Add Tx and Rx handling")
    Signed-off-by: Shannon Nelson <snelson@pensando.io>
    Link: https://lore.kernel.org/r/20201218215001.64696-1-snelson@pensando.io
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5c6eb887e1929eef02c0e52e9312b7232de76c15
Author: Yunjian Wang <wangyunjian@huawei.com>
Date:   Tue Dec 29 10:01:48 2020 +0800

    vhost_net: fix ubuf refcount incorrectly when sendmsg fails
    
    [ Upstream commit 01e31bea7e622f1890c274f4aaaaf8bccd296aa5 ]
    
    Currently the vhost_zerocopy_callback() maybe be called to decrease
    the refcount when sendmsg fails in tun. The error handling in vhost
    handle_tx_zerocopy() will try to decrease the same refcount again.
    This is wrong. To fix this issue, we only call vhost_net_ubuf_put()
    when vq->heads[nvq->desc].len == VHOST_DMA_IN_PROGRESS.
    
    Fixes: bab632d69ee4 ("vhost: vhost TX zero-copy support")
    Signed-off-by: Yunjian Wang <wangyunjian@huawei.com>
    Acked-by: Willem de Bruijn <willemb@google.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Link: https://lore.kernel.org/r/1609207308-20544-1-git-send-email-wangyunjian@huawei.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8f64957fda1280700057cdbc2d785e64901abb79
Author: Bjørn Mork <bjorn@mork.no>
Date:   Wed Dec 30 16:24:51 2020 +0100

    net: usb: qmi_wwan: add Quectel EM160R-GL
    
    [ Upstream commit cfd82dfc9799c53ef109343a23af006a0f6860a9 ]
    
    New modem using ff/ff/30 for QCDM, ff/00/00 for  AT and NMEA,
    and ff/ff/ff for RMNET/QMI.
    
    T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=5000 MxCh= 0
    D: Ver= 3.20 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1
    P: Vendor=2c7c ProdID=0620 Rev= 4.09
    S: Manufacturer=Quectel
    S: Product=EM160R-GL
    S: SerialNumber=e31cedc1
    C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=896mA
    I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=(none)
    E: Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E: Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
    E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
    E: Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E: Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
    E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
    E: Ad=84(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E: Ad=03(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
    E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
    E: Ad=86(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E: Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E: Ad=88(I) Atr=03(Int.) MxPS= 8 Ivl=32ms
    E: Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E: Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Link: https://lore.kernel.org/r/20201230152451.245271-1-bjorn@mork.no
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 12ab7b627d43560842104c0ab5c67c52af22bda6
Author: Roland Dreier <roland@kernel.org>
Date:   Wed Dec 23 19:21:16 2020 -0800

    CDC-NCM: remove "connected" log message
    
    [ Upstream commit 59b4a8fa27f5a895582ada1ae5034af7c94a57b5 ]
    
    The cdc_ncm driver passes network connection notifications up to
    usbnet_link_change(), which is the right place for any logging.
    Remove the netdev_info() duplicating this from the driver itself.
    
    This stops devices such as my "TRENDnet USB 10/100/1G/2.5G LAN"
    (ID 20f4:e02b) adapter from spamming the kernel log with
    
        cdc_ncm 2-2:2.0 enp0s2u2c2: network connection: connected
    
    messages every 60 msec or so.
    
    Signed-off-by: Roland Dreier <roland@kernel.org>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Link: https://lore.kernel.org/r/20201224032116.2453938-1-roland@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 171a2bce9d6ce3bb070b3fc21a3066f1f7d03777
Author: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Date:   Sun Jan 3 02:25:44 2021 +0100

    net: dsa: lantiq_gswip: Fix GSWIP_MII_CFG(p) register access
    
    [ Upstream commit 709a3c9dff2a639966ae7d8ba6239d2b8aba036d ]
    
    There is one GSWIP_MII_CFG register for each switch-port except the CPU
    port. The register offset for the first port is 0x0, 0x02 for the
    second, 0x04 for the third and so on.
    
    Update the driver to not only restrict the GSWIP_MII_CFG registers to
    ports 0, 1 and 5. Handle ports 0..5 instead but skip the CPU port. This
    means we are not overwriting the configuration for the third port (port
    two since we start counting from zero) with the settings for the sixth
    port (with number five) anymore.
    
    The GSWIP_MII_PCDU(p) registers are not updated because there's really
    only three (one for each of the following ports: 0, 1, 5).
    
    Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
    Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c0883010d3b3c59aa6caa1f0034ff47028df6e53
Author: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Date:   Sun Jan 3 02:25:43 2021 +0100

    net: dsa: lantiq_gswip: Enable GSWIP_MII_CFG_EN also for internal PHYs
    
    [ Upstream commit c1a9ec7e5d577a9391660800c806c53287fca991 ]
    
    Enable GSWIP_MII_CFG_EN also for internal PHYs to make traffic flow.
    Without this the PHY link is detected properly and ethtool statistics
    for TX are increasing but there's no RX traffic coming in.
    
    Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
    Suggested-by: Hauke Mehrtens <hauke@hauke-m.de>
    Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 07f26fc52b454e46a6e0769b436685ff121209ac
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Wed Dec 30 19:33:34 2020 +0100

    r8169: work around power-saving bug on some chip versions
    
    [ Upstream commit e80bd76fbf563cc7ed8c9e9f3bbcdf59b0897f69 ]
    
    A user reported failing network with RTL8168dp (a quite rare chip
    version). Realtek confirmed that few chip versions suffer from a PLL
    power-down hw bug.
    
    Fixes: 07df5bd874f0 ("r8169: power down chip in probe")
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Link: https://lore.kernel.org/r/a1c39460-d533-7f9e-fa9d-2b8990b02426@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 106ca9ca9acc8846b40c22128d63bc71717a70e0
Author: Xie He <xie.he.0141@gmail.com>
Date:   Sun Dec 27 18:53:39 2020 -0800

    net: hdlc_ppp: Fix issues when mod_timer is called while timer is running
    
    [ Upstream commit 1fef73597fa545c35fddc953979013882fbd4e55 ]
    
    ppp_cp_event is called directly or indirectly by ppp_rx with "ppp->lock"
    held. It may call mod_timer to add a new timer. However, at the same time
    ppp_timer may be already running and waiting for "ppp->lock". In this
    case, there's no need for ppp_timer to continue running and it can just
    exit.
    
    If we let ppp_timer continue running, it may call add_timer. This causes
    kernel panic because add_timer can't be called with a timer pending.
    This patch fixes this problem.
    
    Fixes: e022c2f07ae5 ("WAN: new synchronous PPP implementation for generic HDLC.")
    Cc: Krzysztof Halasa <khc@pm.waw.pl>
    Signed-off-by: Xie He <xie.he.0141@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2b8aa896b151473d7f661ca5e8a2fecb7c737676
Author: Cong Wang <cong.wang@bytedance.com>
Date:   Sat Dec 26 15:44:53 2020 -0800

    erspan: fix version 1 check in gre_parse_header()
    
    [ Upstream commit 085c7c4e1c0e50d90b7d90f61a12e12b317a91e2 ]
    
    Both version 0 and version 1 use ETH_P_ERSPAN, but version 0 does not
    have an erspan header. So the check in gre_parse_header() is wrong,
    we have to distinguish version 1 from version 0.
    
    We can just check the gre header length like is_erspan_type1().
    
    Fixes: cb73ee40b1b3 ("net: ip_gre: use erspan key field for tunnel lookup")
    Reported-by: syzbot+f583ce3d4ddf9836b27a@syzkaller.appspotmail.com
    Cc: William Tu <u9012063@gmail.com>
    Cc: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
    Signed-off-by: Cong Wang <cong.wang@bytedance.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 606f5412ad86065af6d696f48dc58dab32700e87
Author: Yunjian Wang <wangyunjian@huawei.com>
Date:   Sat Dec 26 16:10:05 2020 +0800

    net: hns: fix return value check in __lb_other_process()
    
    [ Upstream commit 5ede3ada3da7f050519112b81badc058190b9f9f ]
    
    The function skb_copy() could return NULL, the return value
    need to be checked.
    
    Fixes: b5996f11ea54 ("net: add Hisilicon Network Subsystem basic ethernet support")
    Signed-off-by: Yunjian Wang <wangyunjian@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e40b5fc79110d78473a8374e048861c5d204973b
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Thu Dec 24 22:23:44 2020 -0800

    net: sched: prevent invalid Scell_log shift count
    
    [ Upstream commit bd1248f1ddbc48b0c30565fce897a3b6423313b8 ]
    
    Check Scell_log shift size in red_check_params() and modify all callers
    of red_check_params() to pass Scell_log.
    
    This prevents a shift out-of-bounds as detected by UBSAN:
      UBSAN: shift-out-of-bounds in ./include/net/red.h:252:22
      shift exponent 72 is too large for 32-bit type 'int'
    
    Fixes: 8afa10cbe281 ("net_sched: red: Avoid illegal values")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Reported-by: syzbot+97c5bd9cc81eca63d36e@syzkaller.appspotmail.com
    Cc: Nogah Frankel <nogahf@mellanox.com>
    Cc: Jamal Hadi Salim <jhs@mojatatu.com>
    Cc: Cong Wang <xiyou.wangcong@gmail.com>
    Cc: Jiri Pirko <jiri@resnulli.us>
    Cc: netdev@vger.kernel.org
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b16f883e71f31ace4091840babf5e7f47dd047a9
Author: Guillaume Nault <gnault@redhat.com>
Date:   Thu Dec 24 20:01:09 2020 +0100

    ipv4: Ignore ECN bits for fib lookups in fib_compute_spec_dst()
    
    [ Upstream commit 21fdca22eb7df2a1e194b8adb812ce370748b733 ]
    
    RT_TOS() only clears one of the ECN bits. Therefore, when
    fib_compute_spec_dst() resorts to a fib lookup, it can return
    different results depending on the value of the second ECN bit.
    
    For example, ECT(0) and ECT(1) packets could be treated differently.
    
      $ ip netns add ns0
      $ ip netns add ns1
      $ ip link add name veth01 netns ns0 type veth peer name veth10 netns ns1
      $ ip -netns ns0 link set dev lo up
      $ ip -netns ns1 link set dev lo up
      $ ip -netns ns0 link set dev veth01 up
      $ ip -netns ns1 link set dev veth10 up
    
      $ ip -netns ns0 address add 192.0.2.10/24 dev veth01
      $ ip -netns ns1 address add 192.0.2.11/24 dev veth10
    
      $ ip -netns ns1 address add 192.0.2.21/32 dev lo
      $ ip -netns ns1 route add 192.0.2.10/32 tos 4 dev veth10 src 192.0.2.21
      $ ip netns exec ns1 sysctl -wq net.ipv4.icmp_echo_ignore_broadcasts=0
    
    With TOS 4 and ECT(1), ns1 replies using source address 192.0.2.21
    (ping uses -Q to set all TOS and ECN bits):
    
      $ ip netns exec ns0 ping -c 1 -b -Q 5 192.0.2.255
      [...]
      64 bytes from 192.0.2.21: icmp_seq=1 ttl=64 time=0.544 ms
    
    But with TOS 4 and ECT(0), ns1 replies using source address 192.0.2.11
    because the "tos 4" route isn't matched:
    
      $ ip netns exec ns0 ping -c 1 -b -Q 6 192.0.2.255
      [...]
      64 bytes from 192.0.2.11: icmp_seq=1 ttl=64 time=0.597 ms
    
    After this patch the ECN bits don't affect the result anymore:
    
      $ ip netns exec ns0 ping -c 1 -b -Q 6 192.0.2.255
      [...]
      64 bytes from 192.0.2.21: icmp_seq=1 ttl=64 time=0.591 ms
    
    Fixes: 35ebf65e851c ("ipv4: Create and use fib_compute_spec_dst() helper.")
    Signed-off-by: Guillaume Nault <gnault@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a018c071de1413ff4e9585d4d8d848df7020bd7a
Author: Stefan Chulski <stefanc@marvell.com>
Date:   Wed Dec 23 20:35:21 2020 +0200

    net: mvpp2: fix pkt coalescing int-threshold configuration
    
    [ Upstream commit 4f374d2c43a9e5e773f1dee56db63bd6b8a36276 ]
    
    The packet coalescing interrupt threshold has separated registers
    for different aggregated/cpu (sw-thread). The required value should
    be loaded for every thread but not only for 1 current cpu.
    
    Fixes: 213f428f5056 ("net: mvpp2: add support for TX interrupts and RX queue distribution modes")
    Signed-off-by: Stefan Chulski <stefanc@marvell.com>
    Link: https://lore.kernel.org/r/1608748521-11033-1-git-send-email-stefanc@marvell.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 443a71031e49e6ea342586ded25fbf01f91c43be
Author: Yunjian Wang <wangyunjian@huawei.com>
Date:   Fri Dec 25 10:52:16 2020 +0800

    tun: fix return value when the number of iovs exceeds MAX_SKB_FRAGS
    
    [ Upstream commit 950271d7cc0b4546af3549d8143c4132d6e1f138 ]
    
    Currently the tun_napi_alloc_frags() function returns -ENOMEM when the
    number of iovs exceeds MAX_SKB_FRAGS + 1. However this is inappropriate,
    we should use -EMSGSIZE instead of -ENOMEM.
    
    The following distinctions are matters:
    1. the caller need to drop the bad packet when -EMSGSIZE is returned,
       which means meeting a persistent failure.
    2. the caller can try again when -ENOMEM is returned, which means
       meeting a transient failure.
    
    Fixes: 90e33d459407 ("tun: enable napi_gro_frags() for TUN/TAP driver")
    Signed-off-by: Yunjian Wang <wangyunjian@huawei.com>
    Acked-by: Willem de Bruijn <willemb@google.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Link: https://lore.kernel.org/r/1608864736-24332-1-git-send-email-wangyunjian@huawei.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c076e11985546db5e70210592c8baaf56e42e471
Author: Grygorii Strashko <grygorii.strashko@ti.com>
Date:   Thu Dec 24 18:24:05 2020 +0200

    net: ethernet: ti: cpts: fix ethtool output when no ptp_clock registered
    
    [ Upstream commit 4614792eebcbf81c60ad3604c1aeeb2b0899cea4 ]
    
    The CPTS driver registers PTP PHC clock when first netif is going up and
    unregister it when all netif are down. Now ethtool will show:
     - PTP PHC clock index 0 after boot until first netif is up;
     - the last assigned PTP PHC clock index even if PTP PHC clock is not
    registered any more after all netifs are down.
    
    This patch ensures that -1 is returned by ethtool when PTP PHC clock is not
    registered any more.
    
    Fixes: 8a2c9a5ab4b9 ("net: ethernet: ti: cpts: rework initialization/deinitialization")
    Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
    Acked-by: Richard Cochran <richardcochran@gmail.com>
    Link: https://lore.kernel.org/r/20201224162405.28032-1-grygorii.strashko@ti.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8602c20a9160503ef8576490c0e4f879790aeb5d
Author: Antoine Tenart <atenart@kernel.org>
Date:   Wed Dec 23 22:23:23 2020 +0100

    net-sysfs: take the rtnl lock when accessing xps_rxqs_map and num_tc
    
    [ Upstream commit 4ae2bb81649dc03dfc95875f02126b14b773f7ab ]
    
    Accesses to dev->xps_rxqs_map (when using dev->num_tc) should be
    protected by the rtnl lock, like we do for netif_set_xps_queue. I didn't
    see an actual bug being triggered, but let's be safe here and take the
    rtnl lock while accessing the map in sysfs.
    
    Fixes: 8af2c06ff4b1 ("net-sysfs: Add interface for Rx queue(s) map per Tx queue")
    Signed-off-by: Antoine Tenart <atenart@kernel.org>
    Reviewed-by: Alexander Duyck <alexanderduyck@fb.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f6b04a2b2823455a56bf6b8a396d1f1eaeadc24
Author: Antoine Tenart <atenart@kernel.org>
Date:   Wed Dec 23 22:23:22 2020 +0100

    net-sysfs: take the rtnl lock when storing xps_rxqs
    
    [ Upstream commit 2d57b4f142e0b03e854612b8e28978935414bced ]
    
    Two race conditions can be triggered when storing xps rxqs, resulting in
    various oops and invalid memory accesses:
    
    1. Calling netdev_set_num_tc while netif_set_xps_queue:
    
       - netif_set_xps_queue uses dev->tc_num as one of the parameters to
         compute the size of new_dev_maps when allocating it. dev->tc_num is
         also used to access the map, and the compiler may generate code to
         retrieve this field multiple times in the function.
    
       - netdev_set_num_tc sets dev->tc_num.
    
       If new_dev_maps is allocated using dev->tc_num and then dev->tc_num
       is set to a higher value through netdev_set_num_tc, later accesses to
       new_dev_maps in netif_set_xps_queue could lead to accessing memory
       outside of new_dev_maps; triggering an oops.
    
    2. Calling netif_set_xps_queue while netdev_set_num_tc is running:
    
       2.1. netdev_set_num_tc starts by resetting the xps queues,
            dev->tc_num isn't updated yet.
    
       2.2. netif_set_xps_queue is called, setting up the map with the
            *old* dev->num_tc.
    
       2.3. netdev_set_num_tc updates dev->tc_num.
    
       2.4. Later accesses to the map lead to out of bound accesses and
            oops.
    
       A similar issue can be found with netdev_reset_tc.
    
    One way of triggering this is to set an iface up (for which the driver
    uses netdev_set_num_tc in the open path, such as bnx2x) and writing to
    xps_rxqs in a concurrent thread. With the right timing an oops is
    triggered.
    
    Both issues have the same fix: netif_set_xps_queue, netdev_set_num_tc
    and netdev_reset_tc should be mutually exclusive. We do that by taking
    the rtnl lock in xps_rxqs_store.
    
    Fixes: 8af2c06ff4b1 ("net-sysfs: Add interface for Rx queue(s) map per Tx queue")
    Signed-off-by: Antoine Tenart <atenart@kernel.org>
    Reviewed-by: Alexander Duyck <alexanderduyck@fb.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 67ed54a63f4327a66f022580ef6a1c90416f2c23
Author: Antoine Tenart <atenart@kernel.org>
Date:   Wed Dec 23 22:23:21 2020 +0100

    net-sysfs: take the rtnl lock when accessing xps_cpus_map and num_tc
    
    [ Upstream commit fb25038586d0064123e393cadf1fadd70a9df97a ]
    
    Accesses to dev->xps_cpus_map (when using dev->num_tc) should be
    protected by the rtnl lock, like we do for netif_set_xps_queue. I didn't
    see an actual bug being triggered, but let's be safe here and take the
    rtnl lock while accessing the map in sysfs.
    
    Fixes: 184c449f91fe ("net: Add support for XPS with QoS via traffic classes")
    Signed-off-by: Antoine Tenart <atenart@kernel.org>
    Reviewed-by: Alexander Duyck <alexanderduyck@fb.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fb14db9508c030e322f3c97390a8dc48f1669435
Author: Antoine Tenart <atenart@kernel.org>
Date:   Wed Dec 23 22:23:20 2020 +0100

    net-sysfs: take the rtnl lock when storing xps_cpus
    
    [ Upstream commit 1ad58225dba3f2f598d2c6daed4323f24547168f ]
    
    Two race conditions can be triggered when storing xps cpus, resulting in
    various oops and invalid memory accesses:
    
    1. Calling netdev_set_num_tc while netif_set_xps_queue:
    
       - netif_set_xps_queue uses dev->tc_num as one of the parameters to
         compute the size of new_dev_maps when allocating it. dev->tc_num is
         also used to access the map, and the compiler may generate code to
         retrieve this field multiple times in the function.
    
       - netdev_set_num_tc sets dev->tc_num.
    
       If new_dev_maps is allocated using dev->tc_num and then dev->tc_num
       is set to a higher value through netdev_set_num_tc, later accesses to
       new_dev_maps in netif_set_xps_queue could lead to accessing memory
       outside of new_dev_maps; triggering an oops.
    
    2. Calling netif_set_xps_queue while netdev_set_num_tc is running:
    
       2.1. netdev_set_num_tc starts by resetting the xps queues,
            dev->tc_num isn't updated yet.
    
       2.2. netif_set_xps_queue is called, setting up the map with the
            *old* dev->num_tc.
    
       2.3. netdev_set_num_tc updates dev->tc_num.
    
       2.4. Later accesses to the map lead to out of bound accesses and
            oops.
    
       A similar issue can be found with netdev_reset_tc.
    
    One way of triggering this is to set an iface up (for which the driver
    uses netdev_set_num_tc in the open path, such as bnx2x) and writing to
    xps_cpus in a concurrent thread. With the right timing an oops is
    triggered.
    
    Both issues have the same fix: netif_set_xps_queue, netdev_set_num_tc
    and netdev_reset_tc should be mutually exclusive. We do that by taking
    the rtnl lock in xps_cpus_store.
    
    Fixes: 184c449f91fe ("net: Add support for XPS with QoS via traffic classes")
    Signed-off-by: Antoine Tenart <atenart@kernel.org>
    Reviewed-by: Alexander Duyck <alexanderduyck@fb.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e43ec45d45af14cee7fa02850a1002bcd62b7f25
Author: Dinghao Liu <dinghao.liu@zju.edu.cn>
Date:   Wed Dec 23 19:06:12 2020 +0800

    net: ethernet: Fix memleak in ethoc_probe
    
    [ Upstream commit 5d41f9b7ee7a5a5138894f58846a4ffed601498a ]
    
    When mdiobus_register() fails, priv->mdio allocated
    by mdiobus_alloc() has not been freed, which leads
    to memleak.
    
    Fixes: e7f4dc3536a4 ("mdio: Move allocation of interrupts into core")
    Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Link: https://lore.kernel.org/r/20201223110615.31389-1-dinghao.liu@zju.edu.cn
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 56dc7908ed85f03b01938105c3b7768dc07995b5
Author: John Wang <wangzhiqiang.bj@bytedance.com>
Date:   Wed Dec 23 13:55:23 2020 +0800

    net/ncsi: Use real net-device for response handler
    
    [ Upstream commit 427c940558560bff2583d07fc119a21094675982 ]
    
    When aggregating ncsi interfaces and dedicated interfaces to bond
    interfaces, the ncsi response handler will use the wrong net device to
    find ncsi_dev, so that the ncsi interface will not work properly.
    Here, we use the original net device to fix it.
    
    Fixes: 138635cc27c9 ("net/ncsi: NCSI response packet handler")
    Signed-off-by: John Wang <wangzhiqiang.bj@bytedance.com>
    Link: https://lore.kernel.org/r/20201223055523.2069-1-wangzhiqiang.bj@bytedance.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dffef999e484ee749e302ecd333f798ae5c948a8
Author: Jeff Dike <jdike@akamai.com>
Date:   Tue Dec 22 21:54:21 2020 -0500

    virtio_net: Fix recursive call to cpus_read_lock()
    
    [ Upstream commit de33212f768c5d9e2fe791b008cb26f92f0aa31c ]
    
    virtnet_set_channels can recursively call cpus_read_lock if CONFIG_XPS
    and CONFIG_HOTPLUG are enabled.
    
    The path is:
        virtnet_set_channels - calls get_online_cpus(), which is a trivial
    wrapper around cpus_read_lock()
        netif_set_real_num_tx_queues
        netif_reset_xps_queues_gt
        netif_reset_xps_queues - calls cpus_read_lock()
    
    This call chain and potential deadlock happens when the number of TX
    queues is reduced.
    
    This commit the removes netif_set_real_num_[tr]x_queues calls from
    inside the get/put_online_cpus section, as they don't require that it
    be held.
    
    Fixes: 47be24796c13 ("virtio-net: fix the set affinity bug when CPU IDs are not consecutive")
    Signed-off-by: Jeff Dike <jdike@akamai.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Link: https://lore.kernel.org/r/20201223025421.671-1-jdike@akamai.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5404192a8721121f307a8dc05c8259b75e9d44f2
Author: Manish Chopra <manishc@marvell.com>
Date:   Mon Dec 21 06:55:30 2020 -0800

    qede: fix offload for IPIP tunnel packets
    
    [ Upstream commit 5d5647dad259bb416fd5d3d87012760386d97530 ]
    
    IPIP tunnels packets are unknown to device,
    hence these packets are incorrectly parsed and
    caused the packet corruption, so disable offlods
    for such packets at run time.
    
    Signed-off-by: Manish Chopra <manishc@marvell.com>
    Signed-off-by: Sudarsana Kalluru <skalluru@marvell.com>
    Signed-off-by: Igor Russkikh <irusskikh@marvell.com>
    Link: https://lore.kernel.org/r/20201221145530.7771-1-manishc@marvell.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8009f6bb13a33dd4783f8642bf76a27a240ff8ab
Author: Dinghao Liu <dinghao.liu@zju.edu.cn>
Date:   Sun Dec 20 16:29:30 2020 +0800

    net: ethernet: mvneta: Fix error handling in mvneta_probe
    
    [ Upstream commit 58f60329a6be35a5653edb3fd2023ccef9eb9943 ]
    
    When mvneta_port_power_up() fails, we should execute
    cleanup functions after label err_netdev to avoid memleak.
    
    Fixes: 41c2b6b4f0f80 ("net: ethernet: mvneta: Add back interface mode validation")
    Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
    Link: https://lore.kernel.org/r/20201220082930.21623-1-dinghao.liu@zju.edu.cn
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6d003fe7fe87578c64a8845db90ae7f4309e8eb9
Author: Lijun Pan <ljp@linux.ibm.com>
Date:   Sat Dec 19 15:40:34 2020 -0600

    ibmvnic: continue fatal error reset after passive init
    
    [ Upstream commit 1f45dc22066797479072978feeada0852502e180 ]
    
    Commit f9c6cea0b385 ("ibmvnic: Skip fatal error reset after passive init")
    says "If the passive
    CRQ initialization occurs before the FATAL reset task is processed,
    the FATAL error reset task would try to access a CRQ message queue
    that was freed, causing an oops. The problem may be most likely to
    occur during DLPAR add vNIC with a non-default MTU, because the DLPAR
    process will automatically issue a change MTU request.
    Fix this by not processing fatal error reset if CRQ is passively
    initialized after client-driven CRQ initialization fails."
    
    Even with this commit, we still see similar kernel crashes. In order
    to completely solve this problem, we'd better continue the fatal error
    reset, capture the kernel crash, and try to fix it from that end.
    
    Fixes: f9c6cea0b385 ("ibmvnic: Skip fatal error reset after passive init")
    Signed-off-by: Lijun Pan <ljp@linux.ibm.com>
    Link: https://lore.kernel.org/r/20201219214034.21123-1-ljp@linux.ibm.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d16088a9668fa070eba83714b9b162ea0bd4179
Author: Stefan Chulski <stefanc@marvell.com>
Date:   Sun Dec 20 13:02:29 2020 +0200

    net: mvpp2: Fix GoP port 3 Networking Complex Control configurations
    
    [ Upstream commit 2575bc1aa9d52a62342b57a0b7d0a12146cf6aed ]
    
    During GoP port 2 Networking Complex Control mode of operation configurations,
    also GoP port 3 mode of operation was wrongly set.
    Patch removes these configurations.
    
    Fixes: f84bf386f395 ("net: mvpp2: initialize the GoP")
    Acked-by: Marcin Wojtas <mw@semihalf.com>
    Signed-off-by: Stefan Chulski <stefanc@marvell.com>
    Link: https://lore.kernel.org/r/1608462149-1702-1-git-send-email-stefanc@marvell.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8548c96799396fd39aba6ae631f4995ecb17b626
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Sat Dec 19 14:01:44 2020 +0300

    atm: idt77252: call pci_disable_device() on error path
    
    [ Upstream commit 8df66af5c1e5f80562fe728db5ec069b21810144 ]
    
    This error path needs to disable the pci device before returning.
    
    Fixes: ede58ef28e10 ("atm: remove deprecated use of pci api")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Link: https://lore.kernel.org/r/X93dmC4NX0vbTpGp@mwanda
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a006b4fa5cc4d224fd7ac23f26572d405d5152a
Author: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Date:   Fri Dec 18 11:55:36 2020 +0100

    ethernet: ucc_geth: set dev->max_mtu to 1518
    
    [ Upstream commit 1385ae5c30f238f81bc6528d897c6d7a0816783f ]
    
    All the buffers and registers are already set up appropriately for an
    MTU slightly above 1500, so we just need to expose this to the
    networking stack. AFAICT, there's no need to implement .ndo_change_mtu
    when the receive buffers are always set up to support the max_mtu.
    
    This fixes several warnings during boot on our mpc8309-board with an
    embedded mv88e6250 switch:
    
    mv88e6085 mdio@e0102120:10: nonfatal error -34 setting MTU 1500 on port 0
    ...
    mv88e6085 mdio@e0102120:10: nonfatal error -34 setting MTU 1500 on port 4
    ucc_geth e0102000.ethernet eth1: error -22 setting MTU to 1504 to include DSA overhead
    
    The last line explains what the DSA stack tries to do: achieving an MTU
    of 1500 on-the-wire requires that the master netdevice connected to
    the CPU port supports an MTU of 1500+the tagging overhead.
    
    Fixes: bfcb813203e6 ("net: dsa: configure the MTU for switch ports")
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
    Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c2ca14cc6f55cf065c104215c4283bfdf0e48295
Author: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Date:   Fri Dec 18 11:55:38 2020 +0100

    ethernet: ucc_geth: fix use-after-free in ucc_geth_remove()
    
    [ Upstream commit e925e0cd2a705aaacb0b907bb3691fcac3a973a4 ]
    
    ugeth is the netdiv_priv() part of the netdevice. Accessing the memory
    pointed to by ugeth (such as done by ucc_geth_memclean() and the two
    of_node_puts) after free_netdev() is thus use-after-free.
    
    Fixes: 80a9fad8e89a ("ucc_geth: fix module removal")
    Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit af99cae96fdc550404cb428d2d8e6f2082e1670a
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Fri Dec 18 09:38:43 2020 -0800

    net: systemport: set dev->max_mtu to UMAC_MAX_MTU_SIZE
    
    [ Upstream commit 54ddbdb024882e226055cc4c3c246592ddde2ee5 ]
    
    The driver is already allocating receive buffers of 2KiB and the
    Ethernet MAC is configured to accept frames up to UMAC_MAX_MTU_SIZE.
    
    Fixes: bfcb813203e6 ("net: dsa: configure the MTU for switch ports")
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
    Link: https://lore.kernel.org/r/20201218173843.141046-1-f.fainelli@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8dd98d5d2ba455b57d79c632cec05d8823e6a5fb
Author: Stefan Chulski <stefanc@marvell.com>
Date:   Thu Dec 17 20:37:46 2020 +0200

    net: mvpp2: prs: fix PPPoE with ipv6 packet parse
    
    [ Upstream commit fec6079b2eeab319d9e3d074f54d3b6f623e9701 ]
    
    Current PPPoE+IPv6 entry is jumping to 'next-hdr'
    field and not to 'DIP' field as done for IPv4.
    
    Fixes: 3f518509dedc ("ethernet: Add new driver for Marvell Armada 375 network unit")
    Reported-by: Liron Himi <lironh@marvell.com>
    Signed-off-by: Stefan Chulski <stefanc@marvell.com>
    Link: https://lore.kernel.org/r/1608230266-22111-1-git-send-email-stefanc@marvell.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 73445f29575a9cdf5eacf780a8d8f42c536f9d18
Author: Stefan Chulski <stefanc@marvell.com>
Date:   Thu Dec 17 20:30:17 2020 +0200

    net: mvpp2: Add TCAM entry to drop flow control pause frames
    
    [ Upstream commit 3f48fab62bb81a7f9d01e9d43c40395fad011dd5 ]
    
    Issue:
    Flow control frame used to pause GoP(MAC) was delivered to the CPU
    and created a load on the CPU. Since XOFF/XON frames are used only
    by MAC, these frames should be dropped inside MAC.
    
    Fix:
    According to 802.3-2012 - IEEE Standard for Ethernet pause frame
    has unique destination MAC address 01-80-C2-00-00-01.
    Add TCAM parser entry to track and drop pause frames by destination MAC.
    
    Fixes: 3f518509dedc ("ethernet: Add new driver for Marvell Armada 375 network unit")
    Signed-off-by: Stefan Chulski <stefanc@marvell.com>
    Link: https://lore.kernel.org/r/1608229817-21951-1-git-send-email-stefanc@marvell.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a5a6dc4dc2938bd185593d1c5c40c29967b29fb4
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Wed Dec 2 18:18:06 2020 -0800

    iavf: fix double-release of rtnl_lock
    
    [ Upstream commit f1340265726e0edf8a8cef28e665b28ad6302ce9 ]
    
    This code does not jump to exit on an error in iavf_lan_add_device(),
    so the rtnl_unlock() from the normal path will follow.
    
    Fixes: b66c7bc1cd4d ("iavf: Refactor init state machine")
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Reviewed-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6aba31a7c72e521bb089fd8a209587d62ffdfaca
Author: Sylwester Dziedziuch <sylwesterx.dziedziuch@intel.com>
Date:   Thu Oct 22 12:39:36 2020 +0200

    i40e: Fix Error I40E_AQ_RC_EINVAL when removing VFs
    
    [ Upstream commit 3ac874fa84d1baaf0c0175f2a1499f5d88d528b2 ]
    
    When removing VFs for PF added to bridge there was
    an error I40E_AQ_RC_EINVAL. It was caused by not properly
    resetting and reinitializing PF when adding/removing VFs.
    Changed how reset is performed when adding/removing VFs
    to properly reinitialize PFs VSI.
    
    Fixes: fc60861e9b00 ("i40e: start up in VEPA mode by default")
    Signed-off-by: Sylwester Dziedziuch <sylwesterx.dziedziuch@intel.com>
    Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9ea03f6890ceee39f03655814097c8933a22725d
Author: Alexey Dobriyan <adobriyan@gmail.com>
Date:   Tue Dec 15 20:42:39 2020 -0800

    proc: fix lookup in /proc/net subdirectories after setns(2)
    
    [ Upstream commit c6c75deda81344c3a95d1d1f606d5cee109e5d54 ]
    
    Commit 1fde6f21d90f ("proc: fix /proc/net/* after setns(2)") only forced
    revalidation of regular files under /proc/net/
    
    However, /proc/net/ is unusual in the sense of /proc/net/foo handlers
    take netns pointer from parent directory which is old netns.
    
    Steps to reproduce:
    
            (void)open("/proc/net/sctp/snmp", O_RDONLY);
            unshare(CLONE_NEWNET);
    
            int fd = open("/proc/net/sctp/snmp", O_RDONLY);
            read(fd, &c, 1);
    
    Read will read wrong data from original netns.
    
    Patch forces lookup on every directory under /proc/net .
    
    Link: https://lkml.kernel.org/r/20201205160916.GA109739@localhost.localdomain
    Fixes: 1da4d377f943 ("proc: revalidate misc dentries")
    Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
    Reported-by: "Rantala, Tommi T. (Nokia - FI/Espoo)" <tommi.t.rantala@nokia.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d2942e958f26cb9d3b7ef2726783004ad1177749
Author: Alexey Dobriyan <adobriyan@gmail.com>
Date:   Wed Dec 4 16:49:59 2019 -0800

    proc: change ->nlink under proc_subdir_lock
    
    [ Upstream commit e06689bf57017ac022ccf0f2a5071f760821ce0f ]
    
    Currently gluing PDE into global /proc tree is done under lock, but
    changing ->nlink is not.  Additionally struct proc_dir_entry::nlink is
    not atomic so updates can be lost.
    
    Link: http://lkml.kernel.org/r/20190925202436.GA17388@avx2
    Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 59b10c8a59a1593f0620f32437df97b4ddfe1d00
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon Dec 28 11:40:22 2020 -0800

    depmod: handle the case of /sbin/depmod without /sbin in PATH
    
    [ Upstream commit cedd1862be7e666be87ec824dabc6a2b05618f36 ]
    
    Commit 436e980e2ed5 ("kbuild: don't hardcode depmod path") stopped
    hard-coding the path of depmod, but in the process caused trouble for
    distributions that had that /sbin location, but didn't have it in the
    PATH (generally because /sbin is limited to the super-user path).
    
    Work around it for now by just adding /sbin to the end of PATH in the
    depmod.sh script.
    
    Reported-and-tested-by: Sedat Dilek <sedat.dilek@gmail.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 663a0bcb3fa5dc9a5091394f6f54e9bf51974188
Author: Huang Shijie <sjhuang@iluvatar.ai>
Date:   Tue Dec 29 15:14:58 2020 -0800

    lib/genalloc: fix the overflow when size is too big
    
    [ Upstream commit 36845663843fc59c5d794e3dc0641472e3e572da ]
    
    Some graphic card has very big memory on chip, such as 32G bytes.
    
    In the following case, it will cause overflow:
    
        pool = gen_pool_create(PAGE_SHIFT, NUMA_NO_NODE);
        ret = gen_pool_add(pool, 0x1000000, SZ_32G, NUMA_NO_NODE);
    
        va = gen_pool_alloc(pool, SZ_4G);
    
    The overflow occurs in gen_pool_alloc_algo_owner():
    
                    ....
                    size = nbits << order;
                    ....
    
    The @nbits is "int" type, so it will overflow.
    Then the gen_pool_avail() will return the wrong value.
    
    This patch converts some "int" to "unsigned long", and
    changes the compare code in while.
    
    Link: https://lkml.kernel.org/r/20201229060657.3389-1-sjhuang@iluvatar.ai
    Signed-off-by: Huang Shijie <sjhuang@iluvatar.ai>
    Reported-by: Shi Jiasheng <jiasheng.shi@iluvatar.ai>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 19e0cf8fc48135e44780cd1983bbed0c02e1ddaa
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Tue Dec 8 21:29:48 2020 -0800

    scsi: scsi_transport_spi: Set RQF_PM for domain validation commands
    
    [ Upstream commit cfefd9f8240a7b9fdd96fcd54cb029870b6d8d88 ]
    
    Disable runtime power management during domain validation. Since a later
    patch removes RQF_PREEMPT, set RQF_PM for domain validation commands such
    that these are executed in the quiesced SCSI device state.
    
    Link: https://lore.kernel.org/r/20201209052951.16136-6-bvanassche@acm.org
    Cc: Alan Stern <stern@rowland.harvard.edu>
    Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
    Cc: Woody Suwalski <terraluna977@gmail.com>
    Cc: Can Guo <cang@codeaurora.org>
    Cc: Stanley Chu <stanley.chu@mediatek.com>
    Cc: Ming Lei <ming.lei@redhat.com>
    Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Cc: Stan Johnson <userm57@yahoo.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Jens Axboe <axboe@kernel.dk>
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eb3e975ac2a3a6de0c83bdd638216e91b754baee
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Tue Dec 8 21:29:46 2020 -0800

    scsi: ide: Do not set the RQF_PREEMPT flag for sense requests
    
    [ Upstream commit 96d86e6a80a3ab9aff81d12f9f1f2a0da2917d38 ]
    
    RQF_PREEMPT is used for two different purposes in the legacy IDE code:
    
     1. To mark power management requests.
    
     2. To mark requests that should preempt another request. An (old)
        explanation of that feature is as follows: "The IDE driver in the Linux
        kernel normally uses a series of busywait delays during its
        initialization. When the driver executes these busywaits, the kernel
        does nothing for the duration of the wait. The time spent in these
        waits could be used for other initialization activities, if they could
        be run concurrently with these waits.
    
        More specifically, busywait-style delays such as udelay() in module
        init functions inhibit kernel preemption because the Big Kernel Lock is
        held, while yielding APIs such as schedule_timeout() allow
        preemption. This is true because the kernel handles the BKL specially
        and releases and reacquires it across reschedules allowed by the
        current thread.
    
        This IDE-preempt specification requires that the driver eliminate these
        busywaits and replace them with a mechanism that allows other work to
        proceed while the IDE driver is initializing."
    
    Since I haven't found an implementation of (2), do not set the PREEMPT flag
    for sense requests. This patch causes sense requests to be postponed while
    a drive is suspended instead of being submitted to ide_queue_rq().
    
    If it would ever be necessary to restore the IDE PREEMPT functionality,
    that can be done by introducing a new flag in struct ide_request.
    
    Link: https://lore.kernel.org/r/20201209052951.16136-4-bvanassche@acm.org
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Alan Stern <stern@rowland.harvard.edu>
    Cc: Can Guo <cang@codeaurora.org>
    Cc: Stanley Chu <stanley.chu@mediatek.com>
    Cc: Ming Lei <ming.lei@redhat.com>
    Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Reviewed-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4ae3573c571e598c0d3325a54ddf69ea7b3c023f
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Mon Dec 7 10:31:18 2020 +0200

    scsi: ufs-pci: Ensure UFS device is in PowerDown mode for suspend-to-disk ->poweroff()
    
    [ Upstream commit af423534d2de86cd0db729a5ac41f056ca8717de ]
    
    The expectation for suspend-to-disk is that devices will be powered-off, so
    the UFS device should be put in PowerDown mode. If spm_lvl is not 5, then
    that will not happen. Change the pm callbacks to force spm_lvl 5 for
    suspend-to-disk poweroff.
    
    Link: https://lore.kernel.org/r/20201207083120.26732-3-adrian.hunter@intel.com
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5f9c3d64050504d3f4bd85660949464ce086f6eb
Author: Bean Huo <beanhuo@micron.com>
Date:   Mon Dec 7 20:01:37 2020 +0100

    scsi: ufs: Fix wrong print message in dev_err()
    
    [ Upstream commit 1fa0570002e3f66db9b58c32c60de4183b857a19 ]
    
    Change dev_err() print message from "dme-reset" to "dme_enable" in function
    ufshcd_dme_enable().
    
    Link: https://lore.kernel.org/r/20201207190137.6858-3-huobean@gmail.com
    Acked-by: Alim Akhtar <alim.akhtar@samsung.com>
    Acked-by: Avri Altman <avri.altman@wdc.com>
    Signed-off-by: Bean Huo <beanhuo@micron.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 515dc635eb76c655dce29c0aef655c5b332aa5b1
Author: Yunfeng Ye <yeyunfeng@huawei.com>
Date:   Thu Nov 19 14:21:25 2020 +0800

    workqueue: Kick a worker based on the actual activation of delayed works
    
    [ Upstream commit 01341fbd0d8d4e717fc1231cdffe00343088ce0b ]
    
    In realtime scenario, We do not want to have interference on the
    isolated cpu cores. but when invoking alloc_workqueue() for percpu wq
    on the housekeeping cpu, it kick a kworker on the isolated cpu.
    
      alloc_workqueue
        pwq_adjust_max_active
          wake_up_worker
    
    The comment in pwq_adjust_max_active() said:
      "Need to kick a worker after thawed or an unbound wq's
       max_active is bumped"
    
    So it is unnecessary to kick a kworker for percpu's wq when invoking
    alloc_workqueue(). this patch only kick a worker based on the actual
    activation of delayed works.
    
    Signed-off-by: Yunfeng Ye <yeyunfeng@huawei.com>
    Reviewed-by: Lai Jiangshan <jiangshanlai@gmail.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>