commit 313e82bbefb3d1d926858b58092f5d50f41d924d
Author: Sasha Levin <sashal@kernel.org>
Date:   Wed Jun 30 09:21:52 2021 -0400

    Linux 4.14.238
    
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Hulk Robot <hulkrobot@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8ab0e49cc8eeabae4f31805e979173bb00ee472e
Author: Johan Hovold <johan@kernel.org>
Date:   Mon May 24 11:09:12 2021 +0200

    i2c: robotfuzz-osif: fix control-request directions
    
    commit 4ca070ef0dd885616ef294d269a9bf8e3b258e1a upstream.
    
    The direction of the pipe argument must match the request-type direction
    bit or control requests may fail depending on the host-controller-driver
    implementation.
    
    Control transfers without a data stage are treated as OUT requests by
    the USB stack and should be using usb_sndctrlpipe(). Failing to do so
    will now trigger a warning.
    
    Fix the OSIFI2C_SET_BIT_RATE and OSIFI2C_STOP requests which erroneously
    used the osif_usb_read() helper and set the IN direction bit.
    
    Reported-by: syzbot+9d7dadd15b8819d73f41@syzkaller.appspotmail.com
    Fixes: 83e53a8f120f ("i2c: Add bus driver for for OSIF USB i2c device.")
    Cc: stable@vger.kernel.org      # 3.14
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 49e3def271f65f893ca37158d902ad168838bcaf
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Thu Jun 24 18:39:33 2021 -0700

    nilfs2: fix memory leak in nilfs_sysfs_delete_device_group
    
    [ Upstream commit 8fd0c1b0647a6bda4067ee0cd61e8395954b6f28 ]
    
    My local syzbot instance hit memory leak in nilfs2.  The problem was in
    missing kobject_put() in nilfs_sysfs_delete_device_group().
    
    kobject_del() does not call kobject_cleanup() for passed kobject and it
    leads to leaking duped kobject name if kobject_put() was not called.
    
    Fail log:
    
      BUG: memory leak
      unreferenced object 0xffff8880596171e0 (size 8):
      comm "syz-executor379", pid 8381, jiffies 4294980258 (age 21.100s)
      hex dump (first 8 bytes):
        6c 6f 6f 70 30 00 00 00                          loop0...
      backtrace:
         kstrdup+0x36/0x70 mm/util.c:60
         kstrdup_const+0x53/0x80 mm/util.c:83
         kvasprintf_const+0x108/0x190 lib/kasprintf.c:48
         kobject_set_name_vargs+0x56/0x150 lib/kobject.c:289
         kobject_add_varg lib/kobject.c:384 [inline]
         kobject_init_and_add+0xc9/0x160 lib/kobject.c:473
         nilfs_sysfs_create_device_group+0x150/0x800 fs/nilfs2/sysfs.c:999
         init_nilfs+0xe26/0x12b0 fs/nilfs2/the_nilfs.c:637
    
    Link: https://lkml.kernel.org/r/20210612140559.20022-1-paskripkin@gmail.com
    Fixes: da7141fb78db ("nilfs2: add /sys/fs/nilfs2/<device> group")
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Acked-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Cc: Michael L. Semon <mlsemon35@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c6dd378a470acd35323497cee36b539ff546138d
Author: Fabien Dessenne <fabien.dessenne@foss.st.com>
Date:   Thu Jun 17 16:46:29 2021 +0200

    pinctrl: stm32: fix the reported number of GPIO lines per bank
    
    [ Upstream commit 67e2996f72c71ebe4ac2fcbcf77e54479bb7aa11 ]
    
    Each GPIO bank supports a variable number of lines which is usually 16, but
    is less in some cases : this is specified by the last argument of the
    "gpio-ranges" bank node property.
    Report to the framework, the actual number of lines, so the libgpiod
    gpioinfo command lists the actually existing GPIO lines.
    
    Fixes: 1dc9d289154b ("pinctrl: stm32: add possibility to use gpio-ranges to declare bank range")
    Signed-off-by: Fabien Dessenne <fabien.dessenne@foss.st.com>
    Link: https://lore.kernel.org/r/20210617144629.2557693-1-fabien.dessenne@foss.st.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 15bec9922c359516340eb7338534fb576fb7ca6d
Author: Esben Haabendal <esben@geanix.com>
Date:   Fri Jun 18 12:52:38 2021 +0200

    net: ll_temac: Avoid ndo_start_xmit returning NETDEV_TX_BUSY
    
    [ Upstream commit f6396341194234e9b01cd7538bc2c6ac4501ab14 ]
    
    As documented in Documentation/networking/driver.rst, the ndo_start_xmit
    method must not return NETDEV_TX_BUSY under any normal circumstances, and
    as recommended, we simply stop the tx queue in advance, when there is a
    risk that the next xmit would cause a NETDEV_TX_BUSY return.
    
    Signed-off-by: Esben Haabendal <esben@geanix.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit be0cfcf7e6988dbff80edec0d0654878f4d6f955
Author: Kees Cook <keescook@chromium.org>
Date:   Thu Jun 17 10:09:53 2021 -0700

    net: qed: Fix memcpy() overflow of qed_dcbx_params()
    
    [ Upstream commit 1c200f832e14420fa770193f9871f4ce2df00d07 ]
    
    The source (&dcbx_info->operational.params) and dest
    (&p_hwfn->p_dcbx_info->set.config.params) are both struct qed_dcbx_params
    (560 bytes), not struct qed_dcbx_admin_params (564 bytes), which is used
    as the memcpy() size.
    
    However it seems that struct qed_dcbx_operational_params
    (dcbx_info->operational)'s layout matches struct qed_dcbx_admin_params
    (p_hwfn->p_dcbx_info->set.config)'s 4 byte difference (3 padding, 1 byte
    for "valid").
    
    On the assumption that the size is wrong (rather than the source structure
    type), adjust the memcpy() size argument to be 4 bytes smaller and add
    a BUILD_BUG_ON() to validate any changes to the structure sizes.
    
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 45d17208cb47604c6d3c6260c96ba87aa9e11058
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Jun 16 12:53:59 2021 -0700

    r8169: Avoid memcpy() over-reading of ETH_SS_STATS
    
    [ Upstream commit da5ac772cfe2a03058b0accfac03fad60c46c24d ]
    
    In preparation for FORTIFY_SOURCE performing compile-time and run-time
    field bounds checking for memcpy(), memmove(), and memset(), avoid
    intentionally reading across neighboring array fields.
    
    The memcpy() is copying the entire structure, not just the first array.
    Adjust the source argument so the compiler can do appropriate bounds
    checking.
    
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c844b7c40a02968e52ab9a5b9d2ae93592970d64
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Jun 16 12:53:33 2021 -0700

    sh_eth: Avoid memcpy() over-reading of ETH_SS_STATS
    
    [ Upstream commit 224004fbb033600715dbd626bceec10bfd9c58bc ]
    
    In preparation for FORTIFY_SOURCE performing compile-time and run-time
    field bounds checking for memcpy(), memmove(), and memset(), avoid
    intentionally reading across neighboring array fields.
    
    The memcpy() is copying the entire structure, not just the first array.
    Adjust the source argument so the compiler can do appropriate bounds
    checking.
    
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a7743a9559b600729d7fe511749fb093cc342ff9
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Jun 16 12:53:03 2021 -0700

    r8152: Avoid memcpy() over-reading of ETH_SS_STATS
    
    [ Upstream commit 99718abdc00e86e4f286dd836408e2834886c16e ]
    
    In preparation for FORTIFY_SOURCE performing compile-time and run-time
    field bounds checking for memcpy(), memmove(), and memset(), avoid
    intentionally reading across neighboring array fields.
    
    The memcpy() is copying the entire structure, not just the first array.
    Adjust the source argument so the compiler can do appropriate bounds
    checking.
    
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f0cc4253846222c30aed8b992bd9b59c0ab00871
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Jun 16 06:42:02 2021 -0700

    net/packet: annotate accesses to po->ifindex
    
    [ Upstream commit e032f7c9c7cefffcfb79b9fc16c53011d2d9d11f ]
    
    Like prior patch, we need to annotate lockless accesses to po->ifindex
    For instance, packet_getname() is reading po->ifindex (twice) while
    another thread is able to change po->ifindex.
    
    KCSAN reported:
    
    BUG: KCSAN: data-race in packet_do_bind / packet_getname
    
    write to 0xffff888143ce3cbc of 4 bytes by task 25573 on cpu 1:
     packet_do_bind+0x420/0x7e0 net/packet/af_packet.c:3191
     packet_bind+0xc3/0xd0 net/packet/af_packet.c:3255
     __sys_bind+0x200/0x290 net/socket.c:1637
     __do_sys_bind net/socket.c:1648 [inline]
     __se_sys_bind net/socket.c:1646 [inline]
     __x64_sys_bind+0x3d/0x50 net/socket.c:1646
     do_syscall_64+0x4a/0x90 arch/x86/entry/common.c:47
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    read to 0xffff888143ce3cbc of 4 bytes by task 25578 on cpu 0:
     packet_getname+0x5b/0x1a0 net/packet/af_packet.c:3525
     __sys_getsockname+0x10e/0x1a0 net/socket.c:1887
     __do_sys_getsockname net/socket.c:1902 [inline]
     __se_sys_getsockname net/socket.c:1899 [inline]
     __x64_sys_getsockname+0x3e/0x50 net/socket.c:1899
     do_syscall_64+0x4a/0x90 arch/x86/entry/common.c:47
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    value changed: 0x00000000 -> 0x00000001
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 0 PID: 25578 Comm: syz-executor.5 Not tainted 5.13.0-rc6-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3d419f6ded7f726cf337a3e383481d8e74783556
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Jun 16 06:42:01 2021 -0700

    net/packet: annotate accesses to po->bind
    
    [ Upstream commit c7d2ef5dd4b03ed0ee1d13bc0c55f9cf62d49bd6 ]
    
    tpacket_snd(), packet_snd(), packet_getname() and packet_seq_show()
    can read po->num without holding a lock. This means other threads
    can change po->num at the same time.
    
    KCSAN complained about this known fact [1]
    Add READ_ONCE()/WRITE_ONCE() to address the issue.
    
    [1] BUG: KCSAN: data-race in packet_do_bind / packet_sendmsg
    
    write to 0xffff888131a0dcc0 of 2 bytes by task 24714 on cpu 0:
     packet_do_bind+0x3ab/0x7e0 net/packet/af_packet.c:3181
     packet_bind+0xc3/0xd0 net/packet/af_packet.c:3255
     __sys_bind+0x200/0x290 net/socket.c:1637
     __do_sys_bind net/socket.c:1648 [inline]
     __se_sys_bind net/socket.c:1646 [inline]
     __x64_sys_bind+0x3d/0x50 net/socket.c:1646
     do_syscall_64+0x4a/0x90 arch/x86/entry/common.c:47
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    read to 0xffff888131a0dcc0 of 2 bytes by task 24719 on cpu 1:
     packet_snd net/packet/af_packet.c:2899 [inline]
     packet_sendmsg+0x317/0x3570 net/packet/af_packet.c:3040
     sock_sendmsg_nosec net/socket.c:654 [inline]
     sock_sendmsg net/socket.c:674 [inline]
     ____sys_sendmsg+0x360/0x4d0 net/socket.c:2350
     ___sys_sendmsg net/socket.c:2404 [inline]
     __sys_sendmsg+0x1ed/0x270 net/socket.c:2433
     __do_sys_sendmsg net/socket.c:2442 [inline]
     __se_sys_sendmsg net/socket.c:2440 [inline]
     __x64_sys_sendmsg+0x42/0x50 net/socket.c:2440
     do_syscall_64+0x4a/0x90 arch/x86/entry/common.c:47
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    value changed: 0x0000 -> 0x1200
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 1 PID: 24719 Comm: syz-executor.5 Not tainted 5.13.0-rc4-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8afbbbbca1f02f925f128f7d7801dbfc84eaaf14
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Sat Jun 12 17:51:22 2021 +0300

    net: caif: fix memory leak in ldisc_open
    
    [ Upstream commit 58af3d3d54e87bfc1f936e16c04ade3369d34011 ]
    
    Syzbot reported memory leak in tty_init_dev().
    The problem was in unputted tty in ldisc_open()
    
    static int ldisc_open(struct tty_struct *tty)
    {
    ...
            ser->tty = tty_kref_get(tty);
    ...
            result = register_netdevice(dev);
            if (result) {
                    rtnl_unlock();
                    free_netdev(dev);
                    return -ENODEV;
            }
    ...
    }
    
    Ser pointer is netdev private_data, so after free_netdev()
    this pointer goes away with unputted tty reference. So, fix
    it by adding tty_kref_put() before freeing netdev.
    
    Reported-and-tested-by: syzbot+f303e045423e617d2cad@syzkaller.appspotmail.com
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c5c9b1fd9b9e1767a691aca98f2b125e8b9d5162
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Jun 10 07:44:11 2021 -0700

    inet: annotate date races around sk->sk_txhash
    
    [ Upstream commit b71eaed8c04f72a919a9c44e83e4ee254e69e7f3 ]
    
    UDP sendmsg() path can be lockless, it is possible for another
    thread to re-connect an change sk->sk_txhash under us.
    
    There is no serious impact, but we can use READ_ONCE()/WRITE_ONCE()
    pair to document the race.
    
    BUG: KCSAN: data-race in __ip4_datagram_connect / skb_set_owner_w
    
    write to 0xffff88813397920c of 4 bytes by task 30997 on cpu 1:
     sk_set_txhash include/net/sock.h:1937 [inline]
     __ip4_datagram_connect+0x69e/0x710 net/ipv4/datagram.c:75
     __ip6_datagram_connect+0x551/0x840 net/ipv6/datagram.c:189
     ip6_datagram_connect+0x2a/0x40 net/ipv6/datagram.c:272
     inet_dgram_connect+0xfd/0x180 net/ipv4/af_inet.c:580
     __sys_connect_file net/socket.c:1837 [inline]
     __sys_connect+0x245/0x280 net/socket.c:1854
     __do_sys_connect net/socket.c:1864 [inline]
     __se_sys_connect net/socket.c:1861 [inline]
     __x64_sys_connect+0x3d/0x50 net/socket.c:1861
     do_syscall_64+0x4a/0x90 arch/x86/entry/common.c:47
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    read to 0xffff88813397920c of 4 bytes by task 31039 on cpu 0:
     skb_set_hash_from_sk include/net/sock.h:2211 [inline]
     skb_set_owner_w+0x118/0x220 net/core/sock.c:2101
     sock_alloc_send_pskb+0x452/0x4e0 net/core/sock.c:2359
     sock_alloc_send_skb+0x2d/0x40 net/core/sock.c:2373
     __ip6_append_data+0x1743/0x21a0 net/ipv6/ip6_output.c:1621
     ip6_make_skb+0x258/0x420 net/ipv6/ip6_output.c:1983
     udpv6_sendmsg+0x160a/0x16b0 net/ipv6/udp.c:1527
     inet6_sendmsg+0x5f/0x80 net/ipv6/af_inet6.c:642
     sock_sendmsg_nosec net/socket.c:654 [inline]
     sock_sendmsg net/socket.c:674 [inline]
     ____sys_sendmsg+0x360/0x4d0 net/socket.c:2350
     ___sys_sendmsg net/socket.c:2404 [inline]
     __sys_sendmmsg+0x315/0x4b0 net/socket.c:2490
     __do_sys_sendmmsg net/socket.c:2519 [inline]
     __se_sys_sendmmsg net/socket.c:2516 [inline]
     __x64_sys_sendmmsg+0x53/0x60 net/socket.c:2516
     do_syscall_64+0x4a/0x90 arch/x86/entry/common.c:47
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    value changed: 0xbca3c43d -> 0xfdb309e0
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 0 PID: 31039 Comm: syz-executor.2 Not tainted 5.13.0-rc3-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e1df54a22b5ced83a6fa49cc05d2912e6607a720
Author: Zheng Yongjun <zhengyongjun3@huawei.com>
Date:   Thu Jun 10 09:41:36 2021 +0800

    ping: Check return value of function 'ping_queue_rcv_skb'
    
    [ Upstream commit 9d44fa3e50cc91691896934d106c86e4027e61ca ]
    
    Function 'ping_queue_rcv_skb' not always return success, which will
    also return fail. If not check the wrong return value of it, lead to function
    `ping_rcv` return success.
    
    Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a1440a9ab87ae6d38a25b740966cc8eb55b6076e
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Jun 9 16:13:06 2021 +0200

    mac80211: drop multicast fragments
    
    [ Upstream commit a9799541ca34652d9996e45f80e8e03144c12949 ]
    
    These are not permitted by the spec, just drop them.
    
    Link: https://lore.kernel.org/r/20210609161305.23def022b750.Ibd6dd3cdce573dae262fcdc47f8ac52b883a9c50@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cb44de1ae03374b9d5c5b87247cef35f0eefdc04
Author: Du Cheng <ducheng2@gmail.com>
Date:   Wed Apr 28 14:39:41 2021 +0800

    cfg80211: call cfg80211_leave_ocb when switching away from OCB
    
    [ Upstream commit a64b6a25dd9f984ed05fade603a00e2eae787d2f ]
    
    If the userland switches back-and-forth between NL80211_IFTYPE_OCB and
    NL80211_IFTYPE_ADHOC via send_msg(NL80211_CMD_SET_INTERFACE), there is a
    chance where the cleanup cfg80211_leave_ocb() is not called. This leads
    to initialization of in-use memory (e.g. init u.ibss while in-use by
    u.ocb) due to a shared struct/union within ieee80211_sub_if_data:
    
    struct ieee80211_sub_if_data {
        ...
        union {
            struct ieee80211_if_ap ap;
            struct ieee80211_if_vlan vlan;
            struct ieee80211_if_managed mgd;
            struct ieee80211_if_ibss ibss; // <- shares address
            struct ieee80211_if_mesh mesh;
            struct ieee80211_if_ocb ocb; // <- shares address
            struct ieee80211_if_mntr mntr;
            struct ieee80211_if_nan nan;
        } u;
        ...
    }
    
    Therefore add handling of otype == NL80211_IFTYPE_OCB, during
    cfg80211_change_iface() to perform cleanup when leaving OCB mode.
    
    link to syzkaller bug:
    https://syzkaller.appspot.com/bug?id=0612dbfa595bf4b9b680ff7b4948257b8e3732d5
    
    Reported-by: syzbot+105896fac213f26056f9@syzkaller.appspotmail.com
    Signed-off-by: Du Cheng <ducheng2@gmail.com>
    Link: https://lore.kernel.org/r/20210428063941.105161-1-ducheng2@gmail.com
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a7abf2f48669fafe7324bf0ad19bd0d9c88d0ce1
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon May 17 16:47:17 2021 +0200

    mac80211: remove warning in ieee80211_get_sband()
    
    [ Upstream commit 0ee4d55534f82a0624701d0bb9fc2304d4529086 ]
    
    Syzbot reports that it's possible to hit this from userspace,
    by trying to add a station before any other connection setup
    has been done. Instead of trying to catch this in some other
    way simply remove the warning, that will appropriately reject
    the call from userspace.
    
    Reported-by: syzbot+7716dbc401d9a437890d@syzkaller.appspotmail.com
    Link: https://lore.kernel.org/r/20210517164715.f537da276d17.Id05f40ec8761d6a8cc2df87f1aa09c651988a586@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e9695e4d26d210b81c9c8a11f6983c1190a3a9cc
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Tue Jun 22 17:35:18 2021 +0200

    Revert "PCI: PM: Do not read power state in pci_enable_device_flags()"
    
    [ Upstream commit 4d6035f9bf4ea12776322746a216e856dfe46698 ]
    
    Revert commit 4514d991d992 ("PCI: PM: Do not read power state in
    pci_enable_device_flags()") that is reported to cause PCI device
    initialization issues on some systems.
    
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=213481
    Link: https://lore.kernel.org/linux-acpi/YNDoGICcg0V8HhpQ@eldamar.lan
    Reported-by: Michael <phyre@rogers.com>
    Reported-by: Salvatore Bonaccorso <carnil@debian.org>
    Fixes: 4514d991d992 ("PCI: PM: Do not read power state in pci_enable_device_flags()")
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d4f08316ad339b7c3b0fd55c2947f4c320ee32d0
Author: Suzuki K Poulose <suzuki.poulose@arm.com>
Date:   Tue Jul 10 09:58:03 2018 +0100

    arm64: perf: Disable PMU while processing counter overflows
    
    commit 3cce50dfec4a5b0414c974190940f47dd32c6dee upstream.
    
    The arm64 PMU updates the event counters and reprograms the
    counters in the overflow IRQ handler without disabling the
    PMU. This could potentially cause skews in for group counters,
    where the overflowed counters may potentially loose some event
    counts, while they are reprogrammed. To prevent this, disable
    the PMU while we process the counter overflows and enable it
    right back when we are done.
    
    This patch also moves the PMU stop/start routines to avoid a
    forward declaration.
    
    Suggested-by: Mark Rutland <mark.rutland@arm.com>
    Cc: Will Deacon <will.deacon@arm.com>
    Acked-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Aman Priyadarshi <apeureka@amazon.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f43d0bcb387fdd87c516bd58ce4fd01c0f689035
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Fri Apr 9 12:21:28 2021 -0700

    MIPS: generic: Update node names to avoid unit addresses
    
    commit e607ff630c6053ecc67502677c0e50053d7892d4 upstream.
    
    With the latest mkimage from U-Boot 2021.04, the generic defconfigs no
    longer build, failing with:
    
    /usr/bin/mkimage: verify_header failed for FIT Image support with exit code 1
    
    This is expected after the linked U-Boot commits because '@' is
    forbidden in the node names due to the way that libfdt treats nodes with
    the same prefix but different unit addresses.
    
    Switch the '@' in the node name to '-'. Drop the unit addresses from the
    hash and kernel child nodes because there is only one node so they do
    not need to have a number to differentiate them.
    
    Cc: stable@vger.kernel.org
    Link: https://source.denx.de/u-boot/u-boot/-/commit/79af75f7776fc20b0d7eb6afe1e27c00fdb4b9b4
    Link: https://source.denx.de/u-boot/u-boot/-/commit/3f04db891a353f4b127ed57279279f851c6b4917
    Suggested-by: Simon Glass <sjg@chromium.org>
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Reviewed-by: Tom Rini <trini@konsulko.com>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    [nathan: Backport to 4.14, only apply to .its.S files that exist]
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8e64fac312b258681988d0330cad911fa27c980f
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Wed Apr 28 18:23:50 2021 -0700

    Makefile: Move -Wno-unused-but-set-variable out of GCC only block
    
    commit 885480b084696331bea61a4f7eba10652999a9c1 upstream.
    
    Currently, -Wunused-but-set-variable is only supported by GCC so it is
    disabled unconditionally in a GCC only block (it is enabled with W=1).
    clang currently has its implementation for this warning in review so
    preemptively move this statement out of the GCC only block and wrap it
    with cc-disable-warning so that both compilers function the same.
    
    Cc: stable@vger.kernel.org
    Link: https://reviews.llvm.org/D100581
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Tested-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    [nc: Backport, workaround lack of e2079e93f562 in older branches]
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit af115fa3d6fc530f10f3045d889ee4488c756675
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri May 14 11:26:37 2021 +0100

    ARM: 9081/1: fix gcc-10 thumb2-kernel regression
    
    commit dad7b9896a5dbac5da8275d5a6147c65c81fb5f2 upstream.
    
    When building the kernel wtih gcc-10 or higher using the
    CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y flag, the compiler picks a slightly
    different set of registers for the inline assembly in cpu_init() that
    subsequently results in a corrupt kernel stack as well as remaining in
    FIQ mode. If a banked register is used for the last argument, the wrong
    version of that register gets loaded into CPSR_c.  When building in Arm
    mode, the arguments are passed as immediate values and the bug cannot
    happen.
    
    This got introduced when Daniel reworked the FIQ handling and was
    technically always broken, but happened to work with both clang and gcc
    before gcc-10 as long as they picked one of the lower registers.
    This is probably an indication that still very few people build the
    kernel in Thumb2 mode.
    
    Marek pointed out the problem on IRC, Arnd narrowed it down to this
    inline assembly and Russell pinpointed the exact bug.
    
    Change the constraints to force the final mode switch to use a non-banked
    register for the argument to ensure that the correct constant gets loaded.
    Another alternative would be to always use registers for the constant
    arguments to avoid the #ifdef that has now become more complex.
    
    Cc: <stable@vger.kernel.org> # v3.18+
    Cc: Daniel Thompson <daniel.thompson@linaro.org>
    Reported-by: Marek Vasut <marek.vasut@gmail.com>
    Acked-by: Ard Biesheuvel <ardb@kernel.org>
    Fixes: c0e7f7ee717e ("ARM: 8150/3: fiq: Replace default FIQ handler")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 206c3f8c6996861e645b846a3d2f3b8b34838c71
Author: Christian König <christian.koenig@amd.com>
Date:   Mon Jun 21 13:43:05 2021 +0200

    drm/radeon: wait for moving fence after pinning
    
    commit 4b41726aae563273bb4b4a9462ba51ce4d372f78 upstream.
    
    We actually need to wait for the moving fence after pinning
    the BO to make sure that the pin is completed.
    
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    References: https://lore.kernel.org/dri-devel/20210621151758.2347474-1-daniel.vetter@ffwll.ch/
    CC: stable@kernel.org
    Link: https://patchwork.freedesktop.org/patch/msgid/20210622114506.106349-2-christian.koenig@amd.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 94fc53e655e465787d104ef7a4bd8970f7cd8bec
Author: Christian König <christian.koenig@amd.com>
Date:   Mon Jun 21 13:36:35 2021 +0200

    drm/nouveau: wait for moving fence after pinning v2
    
    commit 17b11f71795abdce46f62a808f906857e525cea8 upstream.
    
    We actually need to wait for the moving fence after pinning
    the BO to make sure that the pin is completed.
    
    v2: grab the lock while waiting
    
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    References: https://lore.kernel.org/dri-devel/20210621151758.2347474-1-daniel.vetter@ffwll.ch/
    CC: stable@kernel.org
    Link: https://patchwork.freedesktop.org/patch/msgid/20210622114506.106349-1-christian.koenig@amd.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3267c5454e54c9678ebe0c483fdd56ee1b3ae9af
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Wed Jun 9 21:18:00 2021 +0200

    x86/fpu: Reset state for all signal restore failures
    
    commit efa165504943f2128d50f63de0c02faf6dcceb0d upstream.
    
    If access_ok() or fpregs_soft_set() fails in __fpu__restore_sig() then the
    function just returns but does not clear the FPU state as it does for all
    other fatal failures.
    
    Clear the FPU state for these failures as well.
    
    Fixes: 72a671ced66d ("x86, fpu: Unify signal handling code paths for x86 and x86_64 kernels")
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/87mtryyhhz.ffs@nanos.tec.linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 68fed0725820073d37e487bfa7eeb73eb0e63478
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Mon May 14 00:03:34 2018 -0400

    unfuck sysfs_mount()
    
    commit 7b745a4e4051e1bbce40e0b1c2cf636c70583aa4 upstream.
    
    new_sb is left uninitialized in case of early failures in kernfs_mount_ns(),
    and while IS_ERR(root) is true in all such cases, using IS_ERR(root) || !new_sb
    is not a solution - IS_ERR(root) is true in some cases when new_sb is true.
    
    Make sure new_sb is initialized (and matches the reality) in all cases and
    fix the condition for dropping kobj reference - we want it done precisely
    in those situations where the reference has not been transferred into a new
    super_block instance.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Guilherme G. Piccoli <gpiccoli@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e83ca3bdb895e581a6c541515e9fd2cfb9e60ed4
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Tue Apr 3 00:22:29 2018 -0400

    kernfs: deal with kernfs_fill_super() failures
    
    commit 82382acec0c97b91830fff7130d0acce4ac4f3f3 upstream.
    
    make sure that info->node is initialized early, so that kernfs_kill_sb()
    can list_del() it safely.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Guilherme G. Piccoli <gpiccoli@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 58b5e02c6ca0e2b7c87cd8023ff786ef3c0eef74
Author: Peter Chen <peter.chen@kernel.org>
Date:   Tue Jun 8 18:56:56 2021 +0800

    usb: dwc3: core: fix kernel panic when do reboot
    
    commit 4bf584a03eec674975ee9fe36c8583d9d470dab1 upstream.
    
    When do system reboot, it calls dwc3_shutdown and the whole debugfs
    for dwc3 has removed first, when the gadget tries to do deinit, and
    remove debugfs for its endpoints, it meets NULL pointer dereference
    issue when call debugfs_lookup. Fix it by removing the whole dwc3
    debugfs later than dwc3_drd_exit.
    
    [ 2924.958838] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000002
    ....
    [ 2925.030994] pstate: 60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--)
    [ 2925.037005] pc : inode_permission+0x2c/0x198
    [ 2925.041281] lr : lookup_one_len_common+0xb0/0xf8
    [ 2925.045903] sp : ffff80001276ba70
    [ 2925.049218] x29: ffff80001276ba70 x28: ffff0000c01f0000 x27: 0000000000000000
    [ 2925.056364] x26: ffff800011791e70 x25: 0000000000000008 x24: dead000000000100
    [ 2925.063510] x23: dead000000000122 x22: 0000000000000000 x21: 0000000000000001
    [ 2925.070652] x20: ffff8000122c6188 x19: 0000000000000000 x18: 0000000000000000
    [ 2925.077797] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000004
    [ 2925.084943] x14: ffffffffffffffff x13: 0000000000000000 x12: 0000000000000030
    [ 2925.092087] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f x9 : ffff8000102b2420
    [ 2925.099232] x8 : 7f7f7f7f7f7f7f7f x7 : feff73746e2f6f64 x6 : 0000000000008080
    [ 2925.106378] x5 : 61c8864680b583eb x4 : 209e6ec2d263dbb7 x3 : 000074756f307065
    [ 2925.113523] x2 : 0000000000000001 x1 : 0000000000000000 x0 : ffff8000122c6188
    [ 2925.120671] Call trace:
    [ 2925.123119]  inode_permission+0x2c/0x198
    [ 2925.127042]  lookup_one_len_common+0xb0/0xf8
    [ 2925.131315]  lookup_one_len_unlocked+0x34/0xb0
    [ 2925.135764]  lookup_positive_unlocked+0x14/0x50
    [ 2925.140296]  debugfs_lookup+0x68/0xa0
    [ 2925.143964]  dwc3_gadget_free_endpoints+0x84/0xb0
    [ 2925.148675]  dwc3_gadget_exit+0x28/0x78
    [ 2925.152518]  dwc3_drd_exit+0x100/0x1f8
    [ 2925.156267]  dwc3_remove+0x11c/0x120
    [ 2925.159851]  dwc3_shutdown+0x14/0x20
    [ 2925.163432]  platform_shutdown+0x28/0x38
    [ 2925.167360]  device_shutdown+0x15c/0x378
    [ 2925.171291]  kernel_restart_prepare+0x3c/0x48
    [ 2925.175650]  kernel_restart+0x1c/0x68
    [ 2925.179316]  __do_sys_reboot+0x218/0x240
    [ 2925.183247]  __arm64_sys_reboot+0x28/0x30
    [ 2925.187262]  invoke_syscall+0x48/0x100
    [ 2925.191017]  el0_svc_common.constprop.0+0x48/0xc8
    [ 2925.195726]  do_el0_svc+0x28/0x88
    [ 2925.199045]  el0_svc+0x20/0x30
    [ 2925.202104]  el0_sync_handler+0xa8/0xb0
    [ 2925.205942]  el0_sync+0x148/0x180
    [ 2925.209270] Code: a9025bf5 2a0203f5 121f0056 370802b5 (79400660)
    [ 2925.215372] ---[ end trace 124254d8e485a58b ]---
    [ 2925.220012] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
    [ 2925.227676] Kernel Offset: disabled
    [ 2925.231164] CPU features: 0x00001001,20000846
    [ 2925.235521] Memory Limit: none
    [ 2925.238580] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
    
    Fixes: 8d396bb0a5b6 ("usb: dwc3: debugfs: Add and remove endpoint dirs dynamically")
    Cc: Jack Pham <jackp@codeaurora.org>
    Tested-by: Jack Pham <jackp@codeaurora.org>
    Signed-off-by: Peter Chen <peter.chen@kernel.org>
    Link: https://lore.kernel.org/r/20210608105656.10795-1-peter.chen@kernel.org
    (cherry picked from commit 2a042767814bd0edf2619f06fecd374e266ea068)
    Link: https://lore.kernel.org/r/20210615080847.GA10432@jackp-linux.qualcomm.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ba51ed2c3ac36aa947d0b250d318de6ed7cf552
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Mar 24 14:53:37 2021 -0700

    inet: use bigger hash table for IP ID generation
    
    commit aa6dd211e4b1dde9d5dc25d699d35f789ae7eeba upstream.
    
    In commit 73f156a6e8c1 ("inetpeer: get rid of ip_id_count")
    I used a very small hash table that could be abused
    by patient attackers to reveal sensitive information.
    
    Switch to a dynamic sizing, depending on RAM size.
    
    Typical big hosts will now use 128x more storage (2 MB)
    to get a similar increase in security and reduction
    of hash collisions.
    
    As a bonus, use of alloc_large_system_hash() spreads
    allocated memory among all NUMA nodes.
    
    Fixes: 73f156a6e8c1 ("inetpeer: get rid of ip_id_count")
    Reported-by: Amit Klein <aksecurity@gmail.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Willy Tarreau <w@1wt.eu>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec38df244597b0b798b455aface83b84893e4939
Author: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Date:   Sat Jun 5 19:26:35 2021 +0900

    can: bcm/raw/isotp: use per module netdevice notifier
    
    commit 8d0caedb759683041d9db82069937525999ada53 upstream.
    
    syzbot is reporting hung task at register_netdevice_notifier() [1] and
    unregister_netdevice_notifier() [2], for cleanup_net() might perform
    time consuming operations while CAN driver's raw/bcm/isotp modules are
    calling {register,unregister}_netdevice_notifier() on each socket.
    
    Change raw/bcm/isotp modules to call register_netdevice_notifier() from
    module's __init function and call unregister_netdevice_notifier() from
    module's __exit function, as with gw/j1939 modules are doing.
    
    Link: https://syzkaller.appspot.com/bug?id=391b9498827788b3cc6830226d4ff5be87107c30 [1]
    Link: https://syzkaller.appspot.com/bug?id=1724d278c83ca6e6df100a2e320c10d991cf2bce [2]
    Link: https://lore.kernel.org/r/54a5f451-05ed-f977-8534-79e7aa2bcc8f@i-love.sakura.ne.jp
    Cc: linux-stable <stable@vger.kernel.org>
    Reported-by: syzbot <syzbot+355f8edb2ff45d5f95fa@syzkaller.appspotmail.com>
    Reported-by: syzbot <syzbot+0f1827363a305f74996f@syzkaller.appspotmail.com>
    Reviewed-by: Kirill Tkhai <ktkhai@virtuozzo.com>
    Tested-by: syzbot <syzbot+355f8edb2ff45d5f95fa@syzkaller.appspotmail.com>
    Tested-by: Oliver Hartkopp <socketcan@hartkopp.net>
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fcb34a99ed2a334292419881f65bf68aab6eb39c
Author: Fugang Duan <fugang.duan@nxp.com>
Date:   Wed Jun 16 17:14:25 2021 +0800

    net: fec_ptp: add clock rate zero check
    
    commit cb3cefe3f3f8af27c6076ef7d1f00350f502055d upstream.
    
    Add clock rate zero check to fix coverity issue of "divide by 0".
    
    Fixes: commit 85bd1798b24a ("net: fec: fix spin_lock dead lock")
    Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
    Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 44a05a27ff5585dc1ff1b457675842f65be61246
Author: Andrew Morton <akpm@linux-foundation.org>
Date:   Tue Jun 15 18:23:39 2021 -0700

    mm/slub.c: include swab.h
    
    commit 1b3865d016815cbd69a1879ca1c8a8901fda1072 upstream.
    
    Fixes build with CONFIG_SLAB_FREELIST_HARDENED=y.
    
    Hopefully.  But it's the right thing to do anwyay.
    
    Fixes: 1ad53d9fa3f61 ("slub: improve bit diffusion for freelist ptr obfuscation")
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=213417
    Reported-by: <vannguye@cisco.com>
    Acked-by: Kees Cook <keescook@chromium.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 42020f7f37a90d24b9551f5f7eba3f7c7c102968
Author: Nikolay Aleksandrov <nikolay@nvidia.com>
Date:   Thu Jun 10 15:04:11 2021 +0300

    net: bridge: fix vlan tunnel dst refcnt when egressing
    
    commit cfc579f9d89af4ada58c69b03bcaa4887840f3b3 upstream.
    
    The egress tunnel code uses dst_clone() and directly sets the result
    which is wrong because the entry might have 0 refcnt or be already deleted,
    causing number of problems. It also triggers the WARN_ON() in dst_hold()[1]
    when a refcnt couldn't be taken. Fix it by using dst_hold_safe() and
    checking if a reference was actually taken before setting the dst.
    
    [1] dmesg WARN_ON log and following refcnt errors
     WARNING: CPU: 5 PID: 38 at include/net/dst.h:230 br_handle_egress_vlan_tunnel+0x10b/0x134 [bridge]
     Modules linked in: 8021q garp mrp bridge stp llc bonding ipv6 virtio_net
     CPU: 5 PID: 38 Comm: ksoftirqd/5 Kdump: loaded Tainted: G        W         5.13.0-rc3+ #360
     Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014
     RIP: 0010:br_handle_egress_vlan_tunnel+0x10b/0x134 [bridge]
     Code: e8 85 bc 01 e1 45 84 f6 74 90 45 31 f6 85 db 48 c7 c7 a0 02 19 a0 41 0f 94 c6 31 c9 31 d2 44 89 f6 e8 64 bc 01 e1 85 db 75 02 <0f> 0b 31 c9 31 d2 44 89 f6 48 c7 c7 70 02 19 a0 e8 4b bc 01 e1 49
     RSP: 0018:ffff8881003d39e8 EFLAGS: 00010246
     RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
     RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffffa01902a0
     RBP: ffff8881040c6700 R08: 0000000000000000 R09: 0000000000000001
     R10: 2ce93d0054fe0d00 R11: 54fe0d00000e0000 R12: ffff888109515000
     R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000401
     FS:  0000000000000000(0000) GS:ffff88822bf40000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 00007f42ba70f030 CR3: 0000000109926000 CR4: 00000000000006e0
     Call Trace:
      br_handle_vlan+0xbc/0xca [bridge]
      __br_forward+0x23/0x164 [bridge]
      deliver_clone+0x41/0x48 [bridge]
      br_handle_frame_finish+0x36f/0x3aa [bridge]
      ? skb_dst+0x2e/0x38 [bridge]
      ? br_handle_ingress_vlan_tunnel+0x3e/0x1c8 [bridge]
      ? br_handle_frame_finish+0x3aa/0x3aa [bridge]
      br_handle_frame+0x2c3/0x377 [bridge]
      ? __skb_pull+0x33/0x51
      ? vlan_do_receive+0x4f/0x36a
      ? br_handle_frame_finish+0x3aa/0x3aa [bridge]
      __netif_receive_skb_core+0x539/0x7c6
      ? __list_del_entry_valid+0x16e/0x1c2
      __netif_receive_skb_list_core+0x6d/0xd6
      netif_receive_skb_list_internal+0x1d9/0x1fa
      gro_normal_list+0x22/0x3e
      dev_gro_receive+0x55b/0x600
      ? detach_buf_split+0x58/0x140
      napi_gro_receive+0x94/0x12e
      virtnet_poll+0x15d/0x315 [virtio_net]
      __napi_poll+0x2c/0x1c9
      net_rx_action+0xe6/0x1fb
      __do_softirq+0x115/0x2d8
      run_ksoftirqd+0x18/0x20
      smpboot_thread_fn+0x183/0x19c
      ? smpboot_unregister_percpu_thread+0x66/0x66
      kthread+0x10a/0x10f
      ? kthread_mod_delayed_work+0xb6/0xb6
      ret_from_fork+0x22/0x30
     ---[ end trace 49f61b07f775fd2b ]---
     dst_release: dst:00000000c02d677a refcnt:-1
     dst_release underflow
    
    Cc: stable@vger.kernel.org
    Fixes: 11538d039ac6 ("bridge: vlan dst_metadata hooks in ingress and egress paths")
    Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ad7feefe7164892db424c45687472db803d87f79
Author: Nikolay Aleksandrov <nikolay@nvidia.com>
Date:   Thu Jun 10 15:04:10 2021 +0300

    net: bridge: fix vlan tunnel dst null pointer dereference
    
    commit 58e2071742e38f29f051b709a5cca014ba51166f upstream.
    
    This patch fixes a tunnel_dst null pointer dereference due to lockless
    access in the tunnel egress path. When deleting a vlan tunnel the
    tunnel_dst pointer is set to NULL without waiting a grace period (i.e.
    while it's still usable) and packets egressing are dereferencing it
    without checking. Use READ/WRITE_ONCE to annotate the lockless use of
    tunnel_id, use RCU for accessing tunnel_dst and make sure it is read
    only once and checked in the egress path. The dst is already properly RCU
    protected so we don't need to do anything fancy than to make sure
    tunnel_id and tunnel_dst are read only once and checked in the egress path.
    
    Cc: stable@vger.kernel.org
    Fixes: 11538d039ac6 ("bridge: vlan dst_metadata hooks in ingress and egress paths")
    Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d7899e123882b551bcd8e220aabae70dda93f8c2
Author: Bumyong Lee <bumyong.lee@samsung.com>
Date:   Fri May 7 15:36:47 2021 +0900

    dmaengine: pl330: fix wrong usage of spinlock flags in dma_cyclc
    
    commit 4ad5dd2d7876d79507a20f026507d1a93b8fff10 upstream.
    
    flags varible which is the input parameter of pl330_prep_dma_cyclic()
    should not be used by spinlock_irq[save/restore] function.
    
    Signed-off-by: Jongho Park <jongho7.park@samsung.com>
    Signed-off-by: Bumyong Lee <bumyong.lee@samsung.com>
    Signed-off-by: Chanho Park <chanho61.park@samsung.com>
    Link: https://lore.kernel.org/r/20210507063647.111209-1-chanho61.park@samsung.com
    Fixes: f6f2421c0a1c ("dmaengine: pl330: Merge dma_pl330_dmac and pl330_dmac structs")
    Cc: stable@vger.kernel.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1c3e3f6d88437844e2edd22e4d1ae074bac7e352
Author: Vineet Gupta <vgupta@synopsys.com>
Date:   Tue Jun 8 19:39:25 2021 -0700

    ARCv2: save ABI registers across signal handling
    
    commit 96f1b00138cb8f04c742c82d0a7c460b2202e887 upstream.
    
    ARCv2 has some configuration dependent registers (r30, r58, r59) which
    could be targetted by the compiler. To keep the ABI stable, these were
    unconditionally part of the glibc ABI
    (sysdeps/unix/sysv/linux/arc/sys/ucontext.h:mcontext_t) however we
    missed populating them (by saving/restoring them across signal
    handling).
    
    This patch fixes the issue by
     - adding arcv2 ABI regs to kernel struct sigcontext
     - populating them during signal handling
    
    Change to struct sigcontext might seem like a glibc ABI change (although
    it primarily uses ucontext_t:mcontext_t) but the fact is
     - it has only been extended (existing fields are not touched)
     - the old sigcontext was ABI incomplete to begin with anyways
    
    Fixes: https://github.com/foss-for-synopsys-dwc-arc-processors/linux/issues/53
    Cc: <stable@vger.kernel.org>
    Tested-by: kernel test robot <lkp@intel.com>
    Reported-by: Vladimir Isaev <isaev@synopsys.com>
    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5e6cbd2a05f525a5803bfbb163288b564163dc37
Author: Chiqijun <chiqijun@huawei.com>
Date:   Mon May 24 17:44:07 2021 -0500

    PCI: Work around Huawei Intelligent NIC VF FLR erratum
    
    commit ce00322c2365e1f7b0312f2f493539c833465d97 upstream.
    
    pcie_flr() starts a Function Level Reset (FLR), waits 100ms (the maximum
    time allowed for FLR completion by PCIe r5.0, sec 6.6.2), and waits for the
    FLR to complete.  It assumes the FLR is complete when a config read returns
    valid data.
    
    When we do an FLR on several Huawei Intelligent NIC VFs at the same time,
    firmware on the NIC processes them serially.  The VF may respond to config
    reads before the firmware has completed its reset processing.  If we bind a
    driver to the VF (e.g., by assigning the VF to a virtual machine) in the
    interval between the successful config read and completion of the firmware
    reset processing, the NIC VF driver may fail to load.
    
    Prevent this driver failure by waiting for the NIC firmware to complete its
    reset processing.  Not all NIC firmware supports this feature.
    
    [bhelgaas: commit log]
    Link: https://support.huawei.com/enterprise/en/doc/EDOC1100063073/87950645/vm-oss-occasionally-fail-to-load-the-in200-driver-when-the-vf-performs-flr
    Link: https://lore.kernel.org/r/20210414132301.1793-1-chiqijun@huawei.com
    Signed-off-by: Chiqijun <chiqijun@huawei.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3aceaeefedfb88df35fcd67ff861f0973b86639e
Author: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
Date:   Fri May 21 21:13:17 2021 -0400

    PCI: Add ACS quirk for Broadcom BCM57414 NIC
    
    commit db2f77e2bd99dbd2fb23ddde58f0fae392fe3338 upstream.
    
    The Broadcom BCM57414 NIC may be a multi-function device.  While it does
    not advertise an ACS capability, peer-to-peer transactions are not possible
    between the individual functions, so it is safe to treat them as fully
    isolated.
    
    Add an ACS quirk for this device so the functions can be in independent
    IOMMU groups and attached individually to userspace applications using
    VFIO.
    
    [bhelgaas: commit log]
    Link: https://lore.kernel.org/r/1621645997-16251-1-git-send-email-michael.chan@broadcom.com
    Signed-off-by: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0deb965d5bed0c367f175b988487c8b524bb061e
Author: Shanker Donthineni <sdonthineni@nvidia.com>
Date:   Tue Jun 8 11:18:56 2021 +0530

    PCI: Mark some NVIDIA GPUs to avoid bus reset
    
    commit 4c207e7121fa92b66bf1896bf8ccb9edfb0f9731 upstream.
    
    Some NVIDIA GPU devices do not work with SBR.  Triggering SBR leaves the
    device inoperable for the current system boot. It requires a system
    hard-reboot to get the GPU device back to normal operating condition
    post-SBR. For the affected devices, enable NO_BUS_RESET quirk to avoid the
    issue.
    
    This issue will be fixed in the next generation of hardware.
    
    Link: https://lore.kernel.org/r/20210608054857.18963-8-ameynarkhede03@gmail.com
    Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Sinan Kaya <okaya@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 159111174439c1ca280372e1aa10429b9b22043f
Author: Antti Järvinen <antti.jarvinen@gmail.com>
Date:   Mon Mar 15 10:26:06 2021 +0000

    PCI: Mark TI C667X to avoid bus reset
    
    commit b5cf198e74a91073d12839a3e2db99994a39995d upstream.
    
    Some TI KeyStone C667X devices do not support bus/hot reset.  The PCIESS
    automatically disables LTSSM when Secondary Bus Reset is received and
    device stops working.  Prevent bus reset for these devices.  With this
    change, the device can be assigned to VMs with VFIO, but it will leak state
    between VMs.
    
    Reference: https://e2e.ti.com/support/processors/f/791/t/954382
    Link: https://lore.kernel.org/r/20210315102606.17153-1-antti.jarvinen@gmail.com
    Signed-off-by: Antti Järvinen <antti.jarvinen@gmail.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 43e1f748476db29003fb155c2f9696f5b25a7da1
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Thu Jun 17 17:12:35 2021 -0400

    tracing: Do no increment trace_clock_global() by one
    
    commit 89529d8b8f8daf92d9979382b8d2eb39966846ea upstream.
    
    The trace_clock_global() tries to make sure the events between CPUs is
    somewhat in order. A global value is used and updated by the latest read
    of a clock. If one CPU is ahead by a little, and is read by another CPU, a
    lock is taken, and if the timestamp of the other CPU is behind, it will
    simply use the other CPUs timestamp.
    
    The lock is also only taken with a "trylock" due to tracing, and strange
    recursions can happen. The lock is not taken at all in NMI context.
    
    In the case where the lock is not able to be taken, the non synced
    timestamp is returned. But it will not be less than the saved global
    timestamp.
    
    The problem arises because when the time goes "backwards" the time
    returned is the saved timestamp plus 1. If the lock is not taken, and the
    plus one to the timestamp is returned, there's a small race that can cause
    the time to go backwards!
    
            CPU0                            CPU1
            ----                            ----
                                    trace_clock_global() {
                                        ts = clock() [ 1000 ]
                                        trylock(clock_lock) [ success ]
                                        global_ts = ts; [ 1000 ]
    
                                        <interrupted by NMI>
     trace_clock_global() {
        ts = clock() [ 999 ]
        if (ts < global_ts)
            ts = global_ts + 1 [ 1001 ]
    
        trylock(clock_lock) [ fail ]
    
        return ts [ 1001]
     }
                                        unlock(clock_lock);
                                        return ts; [ 1000 ]
                                    }
    
     trace_clock_global() {
        ts = clock() [ 1000 ]
        if (ts < global_ts) [ false 1000 == 1000 ]
    
        trylock(clock_lock) [ success ]
        global_ts = ts; [ 1000 ]
        unlock(clock_lock)
    
        return ts; [ 1000 ]
     }
    
    The above case shows to reads of trace_clock_global() on the same CPU, but
    the second read returns one less than the first read. That is, time when
    backwards, and this is not what is allowed by trace_clock_global().
    
    This was triggered by heavy tracing and the ring buffer checker that tests
    for the clock going backwards:
    
     Ring buffer clock went backwards: 20613921464 -> 20613921463
     ------------[ cut here ]------------
     WARNING: CPU: 2 PID: 0 at kernel/trace/ring_buffer.c:3412 check_buffer+0x1b9/0x1c0
     Modules linked in:
     [..]
     [CPU: 2]TIME DOES NOT MATCH expected:20620711698 actual:20620711697 delta:6790234 before:20613921463 after:20613921463
       [20613915818] PAGE TIME STAMP
       [20613915818] delta:0
       [20613915819] delta:1
       [20613916035] delta:216
       [20613916465] delta:430
       [20613916575] delta:110
       [20613916749] delta:174
       [20613917248] delta:499
       [20613917333] delta:85
       [20613917775] delta:442
       [20613917921] delta:146
       [20613918321] delta:400
       [20613918568] delta:247
       [20613918768] delta:200
       [20613919306] delta:538
       [20613919353] delta:47
       [20613919980] delta:627
       [20613920296] delta:316
       [20613920571] delta:275
       [20613920862] delta:291
       [20613921152] delta:290
       [20613921464] delta:312
       [20613921464] delta:0 TIME EXTEND
       [20613921464] delta:0
    
    This happened more than once, and always for an off by one result. It also
    started happening after commit aafe104aa9096 was added.
    
    Cc: stable@vger.kernel.org
    Fixes: aafe104aa9096 ("tracing: Restructure trace_clock_global() to never block")
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5ad487e6fa6a6452d289d584f4f2275a45a04196
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Thu Jun 17 14:32:34 2021 -0400

    tracing: Do not stop recording comms if the trace file is being read
    
    commit 4fdd595e4f9a1ff6d93ec702eaecae451cfc6591 upstream.
    
    A while ago, when the "trace" file was opened, tracing was stopped, and
    code was added to stop recording the comms to saved_cmdlines, for mapping
    of the pids to the task name.
    
    Code has been added that only records the comm if a trace event occurred,
    and there's no reason to not trace it if the trace file is opened.
    
    Cc: stable@vger.kernel.org
    Fixes: 7ffbd48d5cab2 ("tracing: Cache comms only after an event occurred")
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit de4c5eef11e0d2b70b7e8c02216aecf802857182
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Thu Jun 17 13:47:25 2021 -0400

    tracing: Do not stop recording cmdlines when tracing is off
    
    commit 85550c83da421fb12dc1816c45012e1e638d2b38 upstream.
    
    The saved_cmdlines is used to map pids to the task name, such that the
    output of the tracing does not just show pids, but also gives a human
    readable name for the task.
    
    If the name is not mapped, the output looks like this:
    
        <...>-1316          [005] ...2   132.044039: ...
    
    Instead of this:
    
        gnome-shell-1316    [005] ...2   132.044039: ...
    
    The names are updated when tracing is running, but are skipped if tracing
    is stopped. Unfortunately, this stops the recording of the names if the
    top level tracer is stopped, and not if there's other tracers active.
    
    The recording of a name only happens when a new event is written into a
    ring buffer, so there is no need to test if tracing is on or not. If
    tracing is off, then no event is written and no need to test if tracing is
    off or not.
    
    Remove the check, as it hides the names of tasks for events in the
    instance buffers.
    
    Cc: stable@vger.kernel.org
    Fixes: 7ffbd48d5cab2 ("tracing: Cache comms only after an event occurred")
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fb28ec5c76c1252c8654f2e8209e9d71ab3a3931
Author: Andrew Lunn <andrew@lunn.ch>
Date:   Mon Jun 14 17:55:23 2021 +0200

    usb: core: hub: Disable autosuspend for Cypress CY7C65632
    
    commit a7d8d1c7a7f73e780aa9ae74926ae5985b2f895f upstream.
    
    The Cypress CY7C65632 appears to have an issue with auto suspend and
    detecting devices, not too dissimilar to the SMSC 5534B hub. It is
    easiest to reproduce by connecting multiple mass storage devices to
    the hub at the same time. On a Lenovo Yoga, around 1 in 3 attempts
    result in the devices not being detected. It is however possible to
    make them appear using lsusb -v.
    
    Disabling autosuspend for this hub resolves the issue.
    
    Fixes: 1208f9e1d758 ("USB: hub: Fix the broken detection of USB3 device in SMSC hub")
    Cc: stable@vger.kernel.org
    Signed-off-by: Andrew Lunn <andrew@lunn.ch>
    Link: https://lore.kernel.org/r/20210614155524.2228800-1-andrew@lunn.ch
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 89df95ce32be204eef2e7d4b2f6fb552fb191a68
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Thu Jun 10 00:58:33 2021 +0300

    can: mcba_usb: fix memory leak in mcba_usb
    
    commit 91c02557174be7f72e46ed7311e3bea1939840b0 upstream.
    
    Syzbot reported memory leak in SocketCAN driver for Microchip CAN BUS
    Analyzer Tool. The problem was in unfreed usb_coherent.
    
    In mcba_usb_start() 20 coherent buffers are allocated and there is
    nothing, that frees them:
    
    1) In callback function the urb is resubmitted and that's all
    2) In disconnect function urbs are simply killed, but URB_FREE_BUFFER
       is not set (see mcba_usb_start) and this flag cannot be used with
       coherent buffers.
    
    Fail log:
    | [ 1354.053291][ T8413] mcba_usb 1-1:0.0 can0: device disconnected
    | [ 1367.059384][ T8420] kmemleak: 20 new suspected memory leaks (see /sys/kernel/debug/kmem)
    
    So, all allocated buffers should be freed with usb_free_coherent()
    explicitly
    
    NOTE:
    The same pattern for allocating and freeing coherent buffers
    is used in drivers/net/can/usb/kvaser_usb/kvaser_usb_core.c
    
    Fixes: 51f3baad7de9 ("can: mcba_usb: Add support for Microchip CAN BUS Analyzer")
    Link: https://lore.kernel.org/r/20210609215833.30393-1-paskripkin@gmail.com
    Cc: linux-stable <stable@vger.kernel.org>
    Reported-and-tested-by: syzbot+57281c762a3922e14dfe@syzkaller.appspotmail.com
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4fa028860bb1656f370851c2c26de15fc67da300
Author: Norbert Slusarek <nslusarek@gmx.net>
Date:   Sat Jun 12 22:18:54 2021 +0200

    can: bcm: fix infoleak in struct bcm_msg_head
    
    commit 5e87ddbe3942e27e939bdc02deb8579b0cbd8ecc upstream.
    
    On 64-bit systems, struct bcm_msg_head has an added padding of 4 bytes between
    struct members count and ival1. Even though all struct members are initialized,
    the 4-byte hole will contain data from the kernel stack. This patch zeroes out
    struct bcm_msg_head before usage, preventing infoleaks to userspace.
    
    Fixes: ffd980f976e7 ("[CAN]: Add broadcast manager (bcm) protocol")
    Link: https://lore.kernel.org/r/trinity-7c1b2e82-e34f-4885-8060-2cd7a13769ce-1623532166177@3c-app-gmx-bs52
    Cc: linux-stable <stable@vger.kernel.org>
    Signed-off-by: Norbert Slusarek <nslusarek@gmx.net>
    Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 23f97d0f3176636dbb2ffd10a1a03efd70be5290
Author: Riwen Lu <luriwen@kylinos.cn>
Date:   Fri Jun 4 11:09:59 2021 +0800

    hwmon: (scpi-hwmon) shows the negative temperature properly
    
    [ Upstream commit 78d13552346289bad4a9bf8eabb5eec5e5a321a5 ]
    
    The scpi hwmon shows the sub-zero temperature in an unsigned integer,
    which would confuse the users when the machine works in low temperature
    environment. This shows the sub-zero temperature in an signed value and
    users can get it properly from sensors.
    
    Signed-off-by: Riwen Lu <luriwen@kylinos.cn>
    Tested-by: Xin Chen <chenxin@kylinos.cn>
    Link: https://lore.kernel.org/r/20210604030959.736379-1-luriwen@kylinos.cn
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 596ca7e388c30052a179d0e641fcfb24ec744988
Author: Chen Li <chenli@uniontech.com>
Date:   Fri Jun 4 16:43:02 2021 +0800

    radeon: use memcpy_to/fromio for UVD fw upload
    
    [ Upstream commit ab8363d3875a83f4901eb1cc00ce8afd24de6c85 ]
    
    I met a gpu addr bug recently and the kernel log
    tells me the pc is memcpy/memset and link register is
    radeon_uvd_resume.
    
    As we know, in some architectures, optimized memcpy/memset
    may not work well on device memory. Trival memcpy_toio/memset_io
    can fix this problem.
    
    BTW, amdgpu has already done it in:
    commit ba0b2275a678 ("drm/amdgpu: use memcpy_to/fromio for UVD fw upload"),
    that's why it has no this issue on the same gpu and platform.
    
    Signed-off-by: Chen Li <chenli@uniontech.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b1ad283755095a4b9d1431aeb357d7df1a33d3bb
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Fri Jun 18 16:49:02 2021 +0300

    net: ethernet: fix potential use-after-free in ec_bhf_remove
    
    [ Upstream commit 9cca0c2d70149160407bda9a9446ce0c29b6e6c6 ]
    
    static void ec_bhf_remove(struct pci_dev *dev)
    {
    ...
            struct ec_bhf_priv *priv = netdev_priv(net_dev);
    
            unregister_netdev(net_dev);
            free_netdev(net_dev);
    
            pci_iounmap(dev, priv->dma_io);
            pci_iounmap(dev, priv->io);
    ...
    }
    
    priv is netdev private data, but it is used
    after free_netdev(). It can cause use-after-free when accessing priv
    pointer. So, fix it by moving free_netdev() after pci_iounmap()
    calls.
    
    Fixes: 6af55ff52b02 ("Driver for Beckhoff CX5020 EtherCAT master module.")
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6ae141218d681ffccc477959c3bcc8a5dbe9969a
Author: Toke Høiland-Jørgensen <toke@redhat.com>
Date:   Fri Jun 18 13:04:35 2021 +0200

    icmp: don't send out ICMP messages with a source address of 0.0.0.0
    
    [ Upstream commit 321827477360934dc040e9d3c626bf1de6c3ab3c ]
    
    When constructing ICMP response messages, the kernel will try to pick a
    suitable source address for the outgoing packet. However, if no IPv4
    addresses are configured on the system at all, this will fail and we end up
    producing an ICMP message with a source address of 0.0.0.0. This can happen
    on a box routing IPv4 traffic via v6 nexthops, for instance.
    
    Since 0.0.0.0 is not generally routable on the internet, there's a good
    chance that such ICMP messages will never make it back to the sender of the
    original packet that the ICMP message was sent in response to. This, in
    turn, can create connectivity and PMTUd problems for senders. Fortunately,
    RFC7600 reserves a dummy address to be used as a source for ICMP
    messages (192.0.0.8/32), so let's teach the kernel to substitute that
    address as a last resort if the regular source address selection procedure
    fails.
    
    Below is a quick example reproducing this issue with network namespaces:
    
    ip netns add ns0
    ip l add type veth peer netns ns0
    ip l set dev veth0 up
    ip a add 10.0.0.1/24 dev veth0
    ip a add fc00:dead:cafe:42::1/64 dev veth0
    ip r add 10.1.0.0/24 via inet6 fc00:dead:cafe:42::2
    ip -n ns0 l set dev veth0 up
    ip -n ns0 a add fc00:dead:cafe:42::2/64 dev veth0
    ip -n ns0 r add 10.0.0.0/24 via inet6 fc00:dead:cafe:42::1
    ip netns exec ns0 sysctl -w net.ipv4.icmp_ratelimit=0
    ip netns exec ns0 sysctl -w net.ipv4.ip_forward=1
    tcpdump -tpni veth0 -c 2 icmp &
    ping -w 1 10.1.0.1 > /dev/null
    tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
    listening on veth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
    IP 10.0.0.1 > 10.1.0.1: ICMP echo request, id 29, seq 1, length 64
    IP 0.0.0.0 > 10.0.0.1: ICMP net 10.1.0.1 unreachable, length 92
    2 packets captured
    2 packets received by filter
    0 packets dropped by kernel
    
    With this patch the above capture changes to:
    IP 10.0.0.1 > 10.1.0.1: ICMP echo request, id 31127, seq 1, length 64
    IP 192.0.0.8 > 10.0.0.1: ICMP net 10.1.0.1 unreachable, length 92
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: Juliusz Chroboczek <jch@irif.fr>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1bcacd6088d61c0ac6a990d87975600a81f3247e
Author: Linyu Yuan <linyyuan@codeaurora.org>
Date:   Thu Jun 17 07:32:32 2021 +0800

    net: cdc_eem: fix tx fixup skb leak
    
    [ Upstream commit c3b26fdf1b32f91c7a3bc743384b4a298ab53ad7 ]
    
    when usbnet transmit a skb, eem fixup it in eem_tx_fixup(),
    if skb_copy_expand() failed, it return NULL,
    usbnet_start_xmit() will have no chance to free original skb.
    
    fix it by free orginal skb in eem_tx_fixup() first,
    then check skb clone status, if failed, return NULL to usbnet.
    
    Fixes: 9f722c0978b0 ("usbnet: CDC EEM support (v5)")
    Signed-off-by: Linyu Yuan <linyyuan@codeaurora.org>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 765a8a04f828db7222b36a42b1031f576bfe95c3
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Wed Jun 16 22:09:06 2021 +0300

    net: hamradio: fix memory leak in mkiss_close
    
    [ Upstream commit 7edcc682301492380fbdd604b4516af5ae667a13 ]
    
    My local syzbot instance hit memory leak in
    mkiss_open()[1]. The problem was in missing
    free_netdev() in mkiss_close().
    
    In mkiss_open() netdevice is allocated and then
    registered, but in mkiss_close() netdevice was
    only unregistered, but not freed.
    
    Fail log:
    
    BUG: memory leak
    unreferenced object 0xffff8880281ba000 (size 4096):
      comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s)
      hex dump (first 32 bytes):
        61 78 30 00 00 00 00 00 00 00 00 00 00 00 00 00  ax0.............
        00 27 fa 2a 80 88 ff ff 00 00 00 00 00 00 00 00  .'.*............
      backtrace:
        [<ffffffff81a27201>] kvmalloc_node+0x61/0xf0
        [<ffffffff8706e7e8>] alloc_netdev_mqs+0x98/0xe80
        [<ffffffff84e64192>] mkiss_open+0xb2/0x6f0 [1]
        [<ffffffff842355db>] tty_ldisc_open+0x9b/0x110
        [<ffffffff84236488>] tty_set_ldisc+0x2e8/0x670
        [<ffffffff8421f7f3>] tty_ioctl+0xda3/0x1440
        [<ffffffff81c9f273>] __x64_sys_ioctl+0x193/0x200
        [<ffffffff8911263a>] do_syscall_64+0x3a/0xb0
        [<ffffffff89200068>] entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    BUG: memory leak
    unreferenced object 0xffff8880141a9a00 (size 96):
      comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s)
      hex dump (first 32 bytes):
        e8 a2 1b 28 80 88 ff ff e8 a2 1b 28 80 88 ff ff  ...(.......(....
        98 92 9c aa b0 40 02 00 00 00 00 00 00 00 00 00  .....@..........
      backtrace:
        [<ffffffff8709f68b>] __hw_addr_create_ex+0x5b/0x310
        [<ffffffff8709fb38>] __hw_addr_add_ex+0x1f8/0x2b0
        [<ffffffff870a0c7b>] dev_addr_init+0x10b/0x1f0
        [<ffffffff8706e88b>] alloc_netdev_mqs+0x13b/0xe80
        [<ffffffff84e64192>] mkiss_open+0xb2/0x6f0 [1]
        [<ffffffff842355db>] tty_ldisc_open+0x9b/0x110
        [<ffffffff84236488>] tty_set_ldisc+0x2e8/0x670
        [<ffffffff8421f7f3>] tty_ioctl+0xda3/0x1440
        [<ffffffff81c9f273>] __x64_sys_ioctl+0x193/0x200
        [<ffffffff8911263a>] do_syscall_64+0x3a/0xb0
        [<ffffffff89200068>] entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    BUG: memory leak
    unreferenced object 0xffff8880219bfc00 (size 512):
      comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s)
      hex dump (first 32 bytes):
        00 a0 1b 28 80 88 ff ff 80 8f b1 8d ff ff ff ff  ...(............
        80 8f b1 8d ff ff ff ff 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<ffffffff81a27201>] kvmalloc_node+0x61/0xf0
        [<ffffffff8706eec7>] alloc_netdev_mqs+0x777/0xe80
        [<ffffffff84e64192>] mkiss_open+0xb2/0x6f0 [1]
        [<ffffffff842355db>] tty_ldisc_open+0x9b/0x110
        [<ffffffff84236488>] tty_set_ldisc+0x2e8/0x670
        [<ffffffff8421f7f3>] tty_ioctl+0xda3/0x1440
        [<ffffffff81c9f273>] __x64_sys_ioctl+0x193/0x200
        [<ffffffff8911263a>] do_syscall_64+0x3a/0xb0
        [<ffffffff89200068>] entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    BUG: memory leak
    unreferenced object 0xffff888029b2b200 (size 256):
      comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<ffffffff81a27201>] kvmalloc_node+0x61/0xf0
        [<ffffffff8706f062>] alloc_netdev_mqs+0x912/0xe80
        [<ffffffff84e64192>] mkiss_open+0xb2/0x6f0 [1]
        [<ffffffff842355db>] tty_ldisc_open+0x9b/0x110
        [<ffffffff84236488>] tty_set_ldisc+0x2e8/0x670
        [<ffffffff8421f7f3>] tty_ioctl+0xda3/0x1440
        [<ffffffff81c9f273>] __x64_sys_ioctl+0x193/0x200
        [<ffffffff8911263a>] do_syscall_64+0x3a/0xb0
        [<ffffffff89200068>] entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    Fixes: 815f62bf7427 ("[PATCH] SMP rewrite of mkiss")
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 92c6f44142fb93731ccd4d9bdfea3e7453a285d1
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Wed Jun 16 20:43:37 2021 +0200

    be2net: Fix an error handling path in 'be_probe()'
    
    [ Upstream commit c19c8c0e666f9259e2fc4d2fa4b9ff8e3b40ee5d ]
    
    If an error occurs after a 'pci_enable_pcie_error_reporting()' call, it
    must be undone by a corresponding 'pci_disable_pcie_error_reporting()'
    call, as already done in the remove function.
    
    Fixes: d6b6d9877878 ("be2net: use PCIe AER capability")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Acked-by: Somnath Kotur <somnath.kotur@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2726f3cf4dd0363253fe873f9f8b7ae3cb09945f
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Jun 16 07:47:15 2021 -0700

    net/af_unix: fix a data-race in unix_dgram_sendmsg / unix_release_sock
    
    [ Upstream commit a494bd642d9120648b06bb7d28ce6d05f55a7819 ]
    
    While unix_may_send(sk, osk) is called while osk is locked, it appears
    unix_release_sock() can overwrite unix_peer() after this lock has been
    released, making KCSAN unhappy.
    
    Changing unix_release_sock() to access/change unix_peer()
    before lock is released should fix this issue.
    
    BUG: KCSAN: data-race in unix_dgram_sendmsg / unix_release_sock
    
    write to 0xffff88810465a338 of 8 bytes by task 20852 on cpu 1:
     unix_release_sock+0x4ed/0x6e0 net/unix/af_unix.c:558
     unix_release+0x2f/0x50 net/unix/af_unix.c:859
     __sock_release net/socket.c:599 [inline]
     sock_close+0x6c/0x150 net/socket.c:1258
     __fput+0x25b/0x4e0 fs/file_table.c:280
     ____fput+0x11/0x20 fs/file_table.c:313
     task_work_run+0xae/0x130 kernel/task_work.c:164
     tracehook_notify_resume include/linux/tracehook.h:189 [inline]
     exit_to_user_mode_loop kernel/entry/common.c:175 [inline]
     exit_to_user_mode_prepare+0x156/0x190 kernel/entry/common.c:209
     __syscall_exit_to_user_mode_work kernel/entry/common.c:291 [inline]
     syscall_exit_to_user_mode+0x20/0x40 kernel/entry/common.c:302
     do_syscall_64+0x56/0x90 arch/x86/entry/common.c:57
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    read to 0xffff88810465a338 of 8 bytes by task 20888 on cpu 0:
     unix_may_send net/unix/af_unix.c:189 [inline]
     unix_dgram_sendmsg+0x923/0x1610 net/unix/af_unix.c:1712
     sock_sendmsg_nosec net/socket.c:654 [inline]
     sock_sendmsg net/socket.c:674 [inline]
     ____sys_sendmsg+0x360/0x4d0 net/socket.c:2350
     ___sys_sendmsg net/socket.c:2404 [inline]
     __sys_sendmmsg+0x315/0x4b0 net/socket.c:2490
     __do_sys_sendmmsg net/socket.c:2519 [inline]
     __se_sys_sendmmsg net/socket.c:2516 [inline]
     __x64_sys_sendmmsg+0x53/0x60 net/socket.c:2516
     do_syscall_64+0x4a/0x90 arch/x86/entry/common.c:47
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    value changed: 0xffff888167905400 -> 0x0000000000000000
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 0 PID: 20888 Comm: syz-executor.0 Not tainted 5.13.0-rc5-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6cff57eea3347f79f1867cc53e1093b6614138d8
Author: Chengyang Fan <cy.fan@huawei.com>
Date:   Wed Jun 16 17:59:25 2021 +0800

    net: ipv4: fix memory leak in ip_mc_add1_src
    
    [ Upstream commit d8e2973029b8b2ce477b564824431f3385c77083 ]
    
    BUG: memory leak
    unreferenced object 0xffff888101bc4c00 (size 32):
      comm "syz-executor527", pid 360, jiffies 4294807421 (age 19.329s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
        01 00 00 00 00 00 00 00 ac 14 14 bb 00 00 02 00 ................
      backtrace:
        [<00000000f17c5244>] kmalloc include/linux/slab.h:558 [inline]
        [<00000000f17c5244>] kzalloc include/linux/slab.h:688 [inline]
        [<00000000f17c5244>] ip_mc_add1_src net/ipv4/igmp.c:1971 [inline]
        [<00000000f17c5244>] ip_mc_add_src+0x95f/0xdb0 net/ipv4/igmp.c:2095
        [<000000001cb99709>] ip_mc_source+0x84c/0xea0 net/ipv4/igmp.c:2416
        [<0000000052cf19ed>] do_ip_setsockopt net/ipv4/ip_sockglue.c:1294 [inline]
        [<0000000052cf19ed>] ip_setsockopt+0x114b/0x30c0 net/ipv4/ip_sockglue.c:1423
        [<00000000477edfbc>] raw_setsockopt+0x13d/0x170 net/ipv4/raw.c:857
        [<00000000e75ca9bb>] __sys_setsockopt+0x158/0x270 net/socket.c:2117
        [<00000000bdb993a8>] __do_sys_setsockopt net/socket.c:2128 [inline]
        [<00000000bdb993a8>] __se_sys_setsockopt net/socket.c:2125 [inline]
        [<00000000bdb993a8>] __x64_sys_setsockopt+0xba/0x150 net/socket.c:2125
        [<000000006a1ffdbd>] do_syscall_64+0x40/0x80 arch/x86/entry/common.c:47
        [<00000000b11467c4>] entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    In commit 24803f38a5c0 ("igmp: do not remove igmp souce list info when set
    link down"), the ip_mc_clear_src() in ip_mc_destroy_dev() was removed,
    because it was also called in igmpv3_clear_delrec().
    
    Rough callgraph:
    
    inetdev_destroy
    -> ip_mc_destroy_dev
         -> igmpv3_clear_delrec
            -> ip_mc_clear_src
    -> RCU_INIT_POINTER(dev->ip_ptr, NULL)
    
    However, ip_mc_clear_src() called in igmpv3_clear_delrec() doesn't
    release in_dev->mc_list->sources. And RCU_INIT_POINTER() assigns the
    NULL to dev->ip_ptr. As a result, in_dev cannot be obtained through
    inetdev_by_index() and then in_dev->mc_list->sources cannot be released
    by ip_mc_del1_src() in the sock_close. Rough call sequence goes like:
    
    sock_close
    -> __sock_release
       -> inet_release
          -> ip_mc_drop_socket
             -> inetdev_by_index
             -> ip_mc_leave_src
                -> ip_mc_del_src
                   -> ip_mc_del1_src
    
    So we still need to call ip_mc_clear_src() in ip_mc_destroy_dev() to free
    in_dev->mc_list->sources.
    
    Fixes: 24803f38a5c0 ("igmp: do not remove igmp souce list info ...")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Chengyang Fan <cy.fan@huawei.com>
    Acked-by: Hangbin Liu <liuhangbin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c4e3be2e7742863e454ce31faf8fd0109c00050b
Author: Dongliang Mu <mudongliangabcd@gmail.com>
Date:   Wed Jun 16 10:48:33 2021 +0800

    net: usb: fix possible use-after-free in smsc75xx_bind
    
    [ Upstream commit 56b786d86694e079d8aad9b314e015cd4ac02a3d ]
    
    The commit 46a8b29c6306 ("net: usb: fix memory leak in smsc75xx_bind")
    fails to clean up the work scheduled in smsc75xx_reset->
    smsc75xx_set_multicast, which leads to use-after-free if the work is
    scheduled to start after the deallocation. In addition, this patch
    also removes a dangling pointer - dev->data[0].
    
    This patch calls cancel_work_sync to cancel the scheduled work and set
    the dangling pointer to NULL.
    
    Fixes: 46a8b29c6306 ("net: usb: fix memory leak in smsc75xx_bind")
    Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bc0ed22faee92abb80b3cd838d65577e1464da0c
Author: Maciej Żenczykowski <maze@google.com>
Date:   Tue Jun 15 01:05:49 2021 -0700

    net: cdc_ncm: switch to eth%d interface naming
    
    [ Upstream commit c1a3d4067309451e68c33dbd356032549cc0bd8e ]
    
    This is meant to make the host side cdc_ncm interface consistently
    named just like the older CDC protocols: cdc_ether & cdc_ecm
    (and even rndis_host), which all use 'FLAG_ETHER | FLAG_POINTTOPOINT'.
    
    include/linux/usb/usbnet.h:
      #define FLAG_ETHER    0x0020          /* maybe use "eth%d" names */
      #define FLAG_WLAN     0x0080          /* use "wlan%d" names */
      #define FLAG_WWAN     0x0400          /* use "wwan%d" names */
      #define FLAG_POINTTOPOINT 0x1000      /* possibly use "usb%d" names */
    
    drivers/net/usb/usbnet.c @ line 1711:
      strcpy (net->name, "usb%d");
      ...
      // heuristic:  "usb%d" for links we know are two-host,
      // else "eth%d" when there's reasonable doubt.  userspace
      // can rename the link if it knows better.
      if ((dev->driver_info->flags & FLAG_ETHER) != 0 &&
          ((dev->driver_info->flags & FLAG_POINTTOPOINT) == 0 ||
           (net->dev_addr [0] & 0x02) == 0))
              strcpy (net->name, "eth%d");
      /* WLAN devices should always be named "wlan%d" */
      if ((dev->driver_info->flags & FLAG_WLAN) != 0)
              strcpy(net->name, "wlan%d");
      /* WWAN devices should always be named "wwan%d" */
      if ((dev->driver_info->flags & FLAG_WWAN) != 0)
              strcpy(net->name, "wwan%d");
    
    So by using ETHER | POINTTOPOINT the interface naming is
    either usb%d or eth%d based on the global uniqueness of the
    mac address of the device.
    
    Without this 2.5gbps ethernet dongles which all seem to use the cdc_ncm
    driver end up being called usb%d instead of eth%d even though they're
    definitely not two-host.  (All 1gbps & 5gbps ethernet usb dongles I've
    tested don't hit this problem due to use of different drivers, primarily
    r8152 and aqc111)
    
    Fixes tag is based purely on git blame, and is really just here to make
    sure this hits LTS branches newer than v4.5.
    
    Cc: Lorenzo Colitti <lorenzo@google.com>
    Fixes: 4d06dd537f95 ("cdc_ncm: do not call usbnet_link_change from cdc_ncm_bind")
    Signed-off-by: Maciej Żenczykowski <maze@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3215ac6dafab9d1270761fb400453e4a33342c9c
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Jun 12 14:53:12 2021 +0200

    netxen_nic: Fix an error handling path in 'netxen_nic_probe()'
    
    [ Upstream commit 49a10c7b176295f8fafb338911cf028e97f65f4d ]
    
    If an error occurs after a 'pci_enable_pcie_error_reporting()' call, it
    must be undone by a corresponding 'pci_disable_pcie_error_reporting()'
    call, as already done in the remove function.
    
    Fixes: e87ad5539343 ("netxen: support pci error handlers")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8ace33c0f12d2506fd141ab72b60c1a876372184
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Jun 12 14:37:46 2021 +0200

    qlcnic: Fix an error handling path in 'qlcnic_probe()'
    
    [ Upstream commit cb3376604a676e0302258b01893911bdd7aa5278 ]
    
    If an error occurs after a 'pci_enable_pcie_error_reporting()' call, it
    must be undone by a corresponding 'pci_disable_pcie_error_reporting()'
    call, as already done in the remove function.
    
    Fixes: 451724c821c1 ("qlcnic: aer support")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit de513ff9bd4b3d9d4e89c2e43fca682a2c1e8286
Author: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Date:   Fri Jun 11 15:16:11 2021 +0800

    net: stmmac: dwmac1000: Fix extended MAC address registers definition
    
    [ Upstream commit 1adb20f0d496b2c61e9aa1f4761b8d71f93d258e ]
    
    The register starts from 0x800 is the 16th MAC address register rather
    than the first one.
    
    Fixes: cffb13f4d6fb ("stmmac: extend mac addr reg and fix perfect filering")
    Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7fdb2534c6c8e7bba7e31062a8fcea12e5cef4ba
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Fri Jun 11 08:13:39 2021 +0200

    alx: Fix an error handling path in 'alx_probe()'
    
    [ Upstream commit 33e381448cf7a05d76ac0b47d4a6531ecd0e5c53 ]
    
    If an error occurs after a 'pci_enable_pcie_error_reporting()' call, it
    must be undone by a corresponding 'pci_disable_pcie_error_reporting()'
    call, as already done in the remove function.
    
    Fixes: ab69bde6b2e9 ("alx: add a simple AR816x/AR817x device driver")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 674b5f0c6a4fc5d3abce877048290cea6091fcb1
Author: Maxim Mikityanskiy <maximmi@nvidia.com>
Date:   Thu Jun 10 19:40:29 2021 +0300

    netfilter: synproxy: Fix out of bounds when parsing TCP options
    
    [ Upstream commit 5fc177ab759418c9537433e63301096e733fb915 ]
    
    The TCP option parser in synproxy (synproxy_parse_options) could read
    one byte out of bounds. When the length is 1, the execution flow gets
    into the loop, reads one byte of the opcode, and if the opcode is
    neither TCPOPT_EOL nor TCPOPT_NOP, it reads one more byte, which exceeds
    the length of 1.
    
    This fix is inspired by commit 9609dad263f8 ("ipv4: tcp_input: fix stack
    out of bounds when parsing TCP options.").
    
    v2 changes:
    
    Added an early return when length < 0 to avoid calling
    skb_header_pointer with negative length.
    
    Cc: Young Xiao <92siuyang@gmail.com>
    Fixes: 48b1de4c110a ("netfilter: add SYNPROXY core/target")
    Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com>
    Reviewed-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 88cfd542f4390f992f47ab876accb2ab789e4056
Author: Ido Schimmel <idosch@nvidia.com>
Date:   Wed Jun 9 14:17:53 2021 +0300

    rtnetlink: Fix regression in bridge VLAN configuration
    
    [ Upstream commit d2e381c4963663bca6f30c3b996fa4dbafe8fcb5 ]
    
    Cited commit started returning errors when notification info is not
    filled by the bridge driver, resulting in the following regression:
    
     # ip link add name br1 type bridge vlan_filtering 1
     # bridge vlan add dev br1 vid 555 self pvid untagged
     RTNETLINK answers: Invalid argument
    
    As long as the bridge driver does not fill notification info for the
    bridge device itself, an empty notification should not be considered as
    an error. This is explained in commit 59ccaaaa49b5 ("bridge: dont send
    notification when skb->len == 0 in rtnl_bridge_notify").
    
    Fix by removing the error and add a comment to avoid future bugs.
    
    Fixes: a8db57c1d285 ("rtnetlink: Fix missing error code in rtnl_bridge_notify()")
    Signed-off-by: Ido Schimmel <idosch@nvidia.com>
    Reviewed-by: Nikolay Aleksandrov <nikolay@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a0882f68f54f7a8b6308261acee9bd4faab5a69e
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Wed Jun 9 11:49:01 2021 +0200

    udp: fix race between close() and udp_abort()
    
    [ Upstream commit a8b897c7bcd47f4147d066e22cc01d1026d7640e ]
    
    Kaustubh reported and diagnosed a panic in udp_lib_lookup().
    The root cause is udp_abort() racing with close(). Both
    racing functions acquire the socket lock, but udp{v6}_destroy_sock()
    release it before performing destructive actions.
    
    We can't easily extend the socket lock scope to avoid the race,
    instead use the SOCK_DEAD flag to prevent udp_abort from doing
    any action when the critical race happens.
    
    Diagnosed-and-tested-by: Kaustubh Pandey <kapandey@codeaurora.org>
    Fixes: 5d77dca82839 ("net: diag: support SOCK_DESTROY for UDP sockets")
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1f79bc8ae81c05eb112a53f981cb2c244ee50d02
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Tue Jun 8 11:06:41 2021 +0300

    net: rds: fix memory leak in rds_recvmsg
    
    [ Upstream commit 49bfcbfd989a8f1f23e705759a6bb099de2cff9f ]
    
    Syzbot reported memory leak in rds. The problem
    was in unputted refcount in case of error.
    
    int rds_recvmsg(struct socket *sock, struct msghdr *msg, size_t size,
                    int msg_flags)
    {
    ...
    
            if (!rds_next_incoming(rs, &inc)) {
                    ...
            }
    
    After this "if" inc refcount incremented and
    
            if (rds_cmsg_recv(inc, msg, rs)) {
                    ret = -EFAULT;
                    goto out;
            }
    ...
    out:
            return ret;
    }
    
    in case of rds_cmsg_recv() fail the refcount won't be
    decremented. And it's easy to see from ftrace log, that
    rds_inc_addref() don't have rds_inc_put() pair in
    rds_recvmsg() after rds_cmsg_recv()
    
     1)               |  rds_recvmsg() {
     1)   3.721 us    |    rds_inc_addref();
     1)   3.853 us    |    rds_message_inc_copy_to_user();
     1) + 10.395 us   |    rds_cmsg_recv();
     1) + 34.260 us   |  }
    
    Fixes: bdbe6fbc6a2f ("RDS: recv.c")
    Reported-and-tested-by: syzbot+5134cdf021c4ed5aaa5f@syzkaller.appspotmail.com
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Reviewed-by: Håkon Bugge <haakon.bugge@oracle.com>
    Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6dcea66d3bb519b426282588f38e884e07893c1f
Author: Nanyong Sun <sunnanyong@huawei.com>
Date:   Tue Jun 8 09:51:58 2021 +0800

    net: ipv4: fix memory leak in netlbl_cipsov4_add_std
    
    [ Upstream commit d612c3f3fae221e7ea736d196581c2217304bbbc ]
    
    Reported by syzkaller:
    BUG: memory leak
    unreferenced object 0xffff888105df7000 (size 64):
    comm "syz-executor842", pid 360, jiffies 4294824824 (age 22.546s)
    hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
    backtrace:
    [<00000000e67ed558>] kmalloc include/linux/slab.h:590 [inline]
    [<00000000e67ed558>] kzalloc include/linux/slab.h:720 [inline]
    [<00000000e67ed558>] netlbl_cipsov4_add_std net/netlabel/netlabel_cipso_v4.c:145 [inline]
    [<00000000e67ed558>] netlbl_cipsov4_add+0x390/0x2340 net/netlabel/netlabel_cipso_v4.c:416
    [<0000000006040154>] genl_family_rcv_msg_doit.isra.0+0x20e/0x320 net/netlink/genetlink.c:739
    [<00000000204d7a1c>] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline]
    [<00000000204d7a1c>] genl_rcv_msg+0x2bf/0x4f0 net/netlink/genetlink.c:800
    [<00000000c0d6a995>] netlink_rcv_skb+0x134/0x3d0 net/netlink/af_netlink.c:2504
    [<00000000d78b9d2c>] genl_rcv+0x24/0x40 net/netlink/genetlink.c:811
    [<000000009733081b>] netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]
    [<000000009733081b>] netlink_unicast+0x4a0/0x6a0 net/netlink/af_netlink.c:1340
    [<00000000d5fd43b8>] netlink_sendmsg+0x789/0xc70 net/netlink/af_netlink.c:1929
    [<000000000a2d1e40>] sock_sendmsg_nosec net/socket.c:654 [inline]
    [<000000000a2d1e40>] sock_sendmsg+0x139/0x170 net/socket.c:674
    [<00000000321d1969>] ____sys_sendmsg+0x658/0x7d0 net/socket.c:2350
    [<00000000964e16bc>] ___sys_sendmsg+0xf8/0x170 net/socket.c:2404
    [<000000001615e288>] __sys_sendmsg+0xd3/0x190 net/socket.c:2433
    [<000000004ee8b6a5>] do_syscall_64+0x37/0x90 arch/x86/entry/common.c:47
    [<00000000171c7cee>] entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    The memory of doi_def->map.std pointing is allocated in
    netlbl_cipsov4_add_std, but no place has freed it. It should be
    freed in cipso_v4_doi_free which frees the cipso DOI resource.
    
    Fixes: 96cb8e3313c7a ("[NetLabel]: CIPSOv4 and Unlabeled packet integration")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Nanyong Sun <sunnanyong@huawei.com>
    Acked-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 77a99aad5bc3ea105806ebae6be3cbadc2fc615e
Author: Sven Eckelmann <sven@narfation.org>
Date:   Tue May 18 21:00:27 2021 +0200

    batman-adv: Avoid WARN_ON timing related checks
    
    [ Upstream commit 9f460ae31c4435fd022c443a6029352217a16ac1 ]
    
    The soft/batadv interface for a queued OGM can be changed during the time
    the OGM was queued for transmission and when the OGM is actually
    transmitted by the worker.
    
    But WARN_ON must be used to denote kernel bugs and not to print simple
    warnings. A warning can simply be printed using pr_warn.
    
    Reported-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
    Reported-by: syzbot+c0b807de416427ff3dd1@syzkaller.appspotmail.com
    Fixes: ef0a937f7a14 ("batman-adv: consider outgoing interface in OGM sending")
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d05267fd27a5c4f54e06daefa3035995d765ca0c
Author: yangerkun <yangerkun@huawei.com>
Date:   Tue Jun 15 18:23:32 2021 -0700

    mm/memory-failure: make sure wait for page writeback in memory_failure
    
    [ Upstream commit e8675d291ac007e1c636870db880f837a9ea112a ]
    
    Our syzkaller trigger the "BUG_ON(!list_empty(&inode->i_wb_list))" in
    clear_inode:
    
      kernel BUG at fs/inode.c:519!
      Internal error: Oops - BUG: 0 [#1] SMP
      Modules linked in:
      Process syz-executor.0 (pid: 249, stack limit = 0x00000000a12409d7)
      CPU: 1 PID: 249 Comm: syz-executor.0 Not tainted 4.19.95
      Hardware name: linux,dummy-virt (DT)
      pstate: 80000005 (Nzcv daif -PAN -UAO)
      pc : clear_inode+0x280/0x2a8
      lr : clear_inode+0x280/0x2a8
      Call trace:
        clear_inode+0x280/0x2a8
        ext4_clear_inode+0x38/0xe8
        ext4_free_inode+0x130/0xc68
        ext4_evict_inode+0xb20/0xcb8
        evict+0x1a8/0x3c0
        iput+0x344/0x460
        do_unlinkat+0x260/0x410
        __arm64_sys_unlinkat+0x6c/0xc0
        el0_svc_common+0xdc/0x3b0
        el0_svc_handler+0xf8/0x160
        el0_svc+0x10/0x218
      Kernel panic - not syncing: Fatal exception
    
    A crash dump of this problem show that someone called __munlock_pagevec
    to clear page LRU without lock_page: do_mmap -> mmap_region -> do_munmap
    -> munlock_vma_pages_range -> __munlock_pagevec.
    
    As a result memory_failure will call identify_page_state without
    wait_on_page_writeback.  And after truncate_error_page clear the mapping
    of this page.  end_page_writeback won't call sb_clear_inode_writeback to
    clear inode->i_wb_list.  That will trigger BUG_ON in clear_inode!
    
    Fix it by checking PageWriteback too to help determine should we skip
    wait_on_page_writeback.
    
    Link: https://lkml.kernel.org/r/20210604084705.3729204-1-yangerkun@huawei.com
    Fixes: 0bc1f8b0682c ("hwpoison: fix the handling path of the victimized page frame that belong to non-LRU")
    Signed-off-by: yangerkun <yangerkun@huawei.com>
    Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
    Cc: Jan Kara <jack@suse.cz>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: Oscar Salvador <osalvador@suse.de>
    Cc: Yu Kuai <yukuai3@huawei.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2abf4d090d7132243a3c3205ab79175c32673874
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Tue May 18 22:11:08 2021 +0800

    dmaengine: stedma40: add missing iounmap() on error in d40_probe()
    
    [ Upstream commit fffdaba402cea79b8d219355487d342ec23f91c6 ]
    
    Add the missing iounmap() before return from d40_probe()
    in the error handling case.
    
    Fixes: 8d318a50b3d7 ("DMAENGINE: Support for ST-Ericssons DMA40 block v3")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Link: https://lore.kernel.org/r/20210518141108.1324127-1-yangyingliang@huawei.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bba419257210b08a68d7389ef01fbf3f4f91e496
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Fri May 21 19:13:11 2021 -0700

    dmaengine: QCOM_HIDMA_MGMT depends on HAS_IOMEM
    
    [ Upstream commit 0cfbb589d67f16fa55b26ae02b69c31b52e344b1 ]
    
    When CONFIG_HAS_IOMEM is not set/enabled, certain iomap() family
    functions [including ioremap(), devm_ioremap(), etc.] are not
    available.
    Drivers that use these functions should depend on HAS_IOMEM so that
    they do not cause build errors.
    
    Rectifies these build errors:
    s390-linux-ld: drivers/dma/qcom/hidma_mgmt.o: in function `hidma_mgmt_probe':
    hidma_mgmt.c:(.text+0x780): undefined reference to `devm_ioremap_resource'
    s390-linux-ld: drivers/dma/qcom/hidma_mgmt.o: in function `hidma_mgmt_init':
    hidma_mgmt.c:(.init.text+0x126): undefined reference to `of_address_to_resource'
    s390-linux-ld: hidma_mgmt.c:(.init.text+0x16e): undefined reference to `of_address_to_resource'
    
    Fixes: 67a2003e0607 ("dmaengine: add Qualcomm Technologies HIDMA channel driver")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Reported-by: kernel test robot <lkp@intel.com>
    Cc: Sinan Kaya <okaya@codeaurora.org>
    Cc: Vinod Koul <vkoul@kernel.org>
    Cc: dmaengine@vger.kernel.org
    Link: https://lore.kernel.org/r/20210522021313.16405-3-rdunlap@infradead.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e5747870e3b349f0d4654871bd2620f65d6d5b47
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Fri May 21 19:13:10 2021 -0700

    dmaengine: ALTERA_MSGDMA depends on HAS_IOMEM
    
    [ Upstream commit 253697b93c2a1c237d34d3ae326e394aeb0ca7b3 ]
    
    When CONFIG_HAS_IOMEM is not set/enabled, certain iomap() family
    functions [including ioremap(), devm_ioremap(), etc.] are not
    available.
    Drivers that use these functions should depend on HAS_IOMEM so that
    they do not cause build errors.
    
    Repairs this build error:
    s390-linux-ld: drivers/dma/altera-msgdma.o: in function `request_and_map':
    altera-msgdma.c:(.text+0x14b0): undefined reference to `devm_ioremap'
    
    Fixes: a85c6f1b2921 ("dmaengine: Add driver for Altera / Intel mSGDMA IP core")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Reported-by: kernel test robot <lkp@intel.com>
    Cc: Stefan Roese <sr@denx.de>
    Cc: Vinod Koul <vkoul@kernel.org>
    Cc: dmaengine@vger.kernel.org
    Reviewed-by: Stefan Roese <sr@denx.de>
    Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr@denx.de
    Link: https://lore.kernel.org/r/20210522021313.16405-2-rdunlap@infradead.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 337b6a80b996a5acd49b9f77d75d0e41469b42af
Author: Zheng Yongjun <zhengyongjun3@huawei.com>
Date:   Wed Jun 2 22:06:58 2021 +0800

    fib: Return the correct errno code
    
    [ Upstream commit 59607863c54e9eb3f69afc5257dfe71c38bb751e ]
    
    When kalloc or kmemdup failed, should return ENOMEM rather than ENOBUF.
    
    Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 666273bc36b98a28e577527018f2dd38cc700fef
Author: Zheng Yongjun <zhengyongjun3@huawei.com>
Date:   Wed Jun 2 22:06:40 2021 +0800

    net: Return the correct errno code
    
    [ Upstream commit 49251cd00228a3c983651f6bb2f33f6a0b8f152e ]
    
    When kalloc or kmemdup failed, should return ENOMEM rather than ENOBUF.
    
    Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d0a1561cbdc3a66dd7460bae19a13efd1291cea0
Author: Zheng Yongjun <zhengyongjun3@huawei.com>
Date:   Wed Jun 2 22:06:30 2021 +0800

    net/x25: Return the correct errno code
    
    [ Upstream commit d7736958668c4facc15f421e622ffd718f5be80a ]
    
    When kalloc or kmemdup failed, should return ENOMEM rather than ENOBUF.
    
    Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 908e53138e71d1719416565d555684d387baa096
Author: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Date:   Wed Jun 2 18:15:04 2021 +0800

    rtnetlink: Fix missing error code in rtnl_bridge_notify()
    
    [ Upstream commit a8db57c1d285c758adc7fb43d6e2bad2554106e1 ]
    
    The error code is missing in this code scenario, add the error code
    '-EINVAL' to the return value 'err'.
    
    Eliminate the follow smatch warning:
    
    net/core/rtnetlink.c:4834 rtnl_bridge_notify() warn: missing error code
    'err'.
    
    Reported-by: Abaci Robot <abaci@linux.alibaba.com>
    Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c97aafab4bfab12493b3eed6a3e0c74519bdd21b
Author: Josh Triplett <josh@joshtriplett.org>
Date:   Tue Jun 1 18:38:41 2021 -0700

    net: ipconfig: Don't override command-line hostnames or domains
    
    [ Upstream commit b508d5fb69c2211a1b860fc058aafbefc3b3c3cd ]
    
    If the user specifies a hostname or domain name as part of the ip=
    command-line option, preserve it and don't overwrite it with one
    supplied by DHCP/BOOTP.
    
    For instance, ip=::::myhostname::dhcp will use "myhostname" rather than
    ignoring and overwriting it.
    
    Fix the comment on ic_bootp_string that suggests it only copies a string
    "if not already set"; it doesn't have any such logic.
    
    Signed-off-by: Josh Triplett <josh@joshtriplett.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4b2e0ac757bc0deb1f1115ea84ebb6928bbd9c55
Author: Hannes Reinecke <hare@suse.de>
Date:   Wed May 26 17:23:17 2021 +0200

    nvme-loop: check for NVME_LOOP_Q_LIVE in nvme_loop_destroy_admin_queue()
    
    [ Upstream commit 4237de2f73a669e4f89ac0aa2b44fb1a1d9ec583 ]
    
    We need to check the NVME_LOOP_Q_LIVE flag in
    nvme_loop_destroy_admin_queue() to protect against duplicate
    invocations eg during concurrent reset and remove calls.
    
    Signed-off-by: Hannes Reinecke <hare@suse.de>
    Reviewed-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 089970144e0390bd3a246b5305966045bca14891
Author: Hannes Reinecke <hare@suse.de>
Date:   Wed May 26 17:23:16 2021 +0200

    nvme-loop: clear NVME_LOOP_Q_LIVE when nvme_loop_configure_admin_queue() fails
    
    [ Upstream commit 1c5f8e882a05de5c011e8c3fbeceb0d1c590eb53 ]
    
    When the call to nvme_enable_ctrl() in nvme_loop_configure_admin_queue()
    fails the NVME_LOOP_Q_LIVE flag is not cleared.
    
    Signed-off-by: Hannes Reinecke <hare@suse.de>
    Reviewed-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 41e4946a5b4405b264243d2119a0aee313d0c1af
Author: Hannes Reinecke <hare@suse.de>
Date:   Wed May 26 17:23:15 2021 +0200

    nvme-loop: reset queue count to 1 in nvme_loop_destroy_io_queues()
    
    [ Upstream commit a6c144f3d2e230f2b3ac5ed8c51e0f0391556197 ]
    
    The queue count is increased in nvme_loop_init_io_queues(), so we
    need to reset it to 1 at the end of nvme_loop_destroy_io_queues().
    Otherwise the function is not re-entrant safe, and crash will happen
    during concurrent reset and remove calls.
    
    Signed-off-by: Hannes Reinecke <hare@suse.de>
    Reviewed-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 46ce76b0bc3949b39e45eb19733712b946e5e3f3
Author: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Date:   Tue Jun 1 19:04:51 2021 +0800

    ethernet: myri10ge: Fix missing error code in myri10ge_probe()
    
    [ Upstream commit f336d0b93ae978f12c5e27199f828da89b91e56a ]
    
    The error code is missing in this code scenario, add the error code
    '-EINVAL' to the return value 'status'.
    
    Eliminate the follow smatch warning:
    
    drivers/net/ethernet/myricom/myri10ge/myri10ge.c:3818 myri10ge_probe()
    warn: missing error code 'status'.
    
    Reported-by: Abaci Robot <abaci@linux.alibaba.com>
    Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 376a4d9cbdb6f666083a6c37eaf63b50ad18704c
Author: Maurizio Lombardi <mlombard@redhat.com>
Date:   Mon May 31 14:13:26 2021 +0200

    scsi: target: core: Fix warning on realtime kernels
    
    [ Upstream commit 515da6f4295c2c42b8c54572cce3d2dd1167c41e ]
    
    On realtime kernels, spin_lock_irq*(spinlock_t) do not disable the
    interrupts, a call to irqs_disabled() will return false thus firing a
    warning in __transport_wait_for_tasks().
    
    Remove the warning and also replace assert_spin_locked() with
    lockdep_assert_held()
    
    Link: https://lore.kernel.org/r/20210531121326.3649-1-mlombard@redhat.com
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0364742decb0f02bc183404868b82896f7992595
Author: Hillf Danton <hdanton@sina.com>
Date:   Tue May 18 16:46:25 2021 +0800

    gfs2: Fix use-after-free in gfs2_glock_shrink_scan
    
    [ Upstream commit 1ab19c5de4c537ec0d9b21020395a5b5a6c059b2 ]
    
    The GLF_LRU flag is checked under lru_lock in gfs2_glock_remove_from_lru() to
    remove the glock from the lru list in __gfs2_glock_put().
    
    On the shrink scan path, the same flag is cleared under lru_lock but because
    of cond_resched_lock(&lru_lock) in gfs2_dispose_glock_lru(), progress on the
    put side can be made without deleting the glock from the lru list.
    
    Keep GLF_LRU across the race window opened by cond_resched_lock(&lru_lock) to
    ensure correct behavior on both sides - clear GLF_LRU after list_del under
    lru_lock.
    
    Reported-by: syzbot <syzbot+34ba7ddbf3021981a228@syzkaller.appspotmail.com>
    Signed-off-by: Hillf Danton <hdanton@sina.com>
    Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b5496f3da6b5b6c91e6990ebbb243415e95f7f83
Author: Bixuan Cui <cuibixuan@huawei.com>
Date:   Sat May 8 11:14:48 2021 +0800

    HID: gt683r: add missing MODULE_DEVICE_TABLE
    
    [ Upstream commit a4b494099ad657f1cb85436d333cf38870ee95bc ]
    
    This patch adds missing MODULE_DEVICE_TABLE definition which generates
    correct modalias for automatic loading of this driver when it is built
    as an external module.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Bixuan Cui <cuibixuan@huawei.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9b550cc32a85404f67f51ce3c47d5d8f80a5a9ca
Author: Yongqiang Liu <liuyongqiang13@huawei.com>
Date:   Thu Apr 1 13:15:33 2021 +0000

    ARM: OMAP2+: Fix build warning when mmc_omap is not built
    
    [ Upstream commit 040ab72ee10ea88e1883ad143b3e2b77596abc31 ]
    
    GCC reports the following warning with W=1:
    
    arch/arm/mach-omap2/board-n8x0.c:325:19: warning:
    variable 'index' set but not used [-Wunused-but-set-variable]
    325 |  int bit, *openp, index;
        |                   ^~~~~
    
    Fix this by moving CONFIG_MMC_OMAP to cover the rest codes
    in the n8x0_mmc_callback().
    
    Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8c064eece9a51856f3f275104520c7e3017fc5c0
Author: Anirudh Rayabharam <mail@anirudhrb.com>
Date:   Sun Apr 25 23:03:53 2021 +0530

    HID: usbhid: fix info leak in hid_submit_ctrl
    
    [ Upstream commit 6be388f4a35d2ce5ef7dbf635a8964a5da7f799f ]
    
    In hid_submit_ctrl(), the way of calculating the report length doesn't
    take into account that report->size can be zero. When running the
    syzkaller reproducer, a report of size 0 causes hid_submit_ctrl) to
    calculate transfer_buffer_length as 16384. When this urb is passed to
    the usb core layer, KMSAN reports an info leak of 16384 bytes.
    
    To fix this, first modify hid_report_len() to account for the zero
    report size case by using DIV_ROUND_UP for the division. Then, call it
    from hid_submit_ctrl().
    
    Reported-by: syzbot+7c2bb71996f95a82524c@syzkaller.appspotmail.com
    Signed-off-by: Anirudh Rayabharam <mail@anirudhrb.com>
    Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 43ab41d973e3e3be389a2819477d8054b9e61903
Author: Mark Bolhuis <mark@bolhuis.dev>
Date:   Mon May 3 17:39:38 2021 +0100

    HID: Add BUS_VIRTUAL to hid_connect logging
    
    [ Upstream commit 48e33befe61a7d407753c53d1a06fc8d6b5dab80 ]
    
    Add BUS_VIRTUAL to hid_connect logging since it's a valid hid bus type and it
    should not print <UNKNOWN>
    
    Signed-off-by: Mark Bolhuis <mark@bolhuis.dev>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ca59ef64aebe65c62517aecb19d956addd507f43
Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Date:   Thu Apr 15 11:52:31 2021 -0700

    HID: hid-sensor-hub: Return error for hid_set_field() failure
    
    [ Upstream commit edb032033da0dc850f6e7740fa1023c73195bc89 ]
    
    In the function sensor_hub_set_feature(), return error when hid_set_field()
    fails.
    
    Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c6998ccfefa652bac3f9b236821e392af43efa1e
Author: Dan Robertson <dan@dlrobertson.com>
Date:   Fri Apr 23 00:02:13 2021 -0400

    net: ieee802154: fix null deref in parse dev addr
    
    [ Upstream commit 9fdd04918a452980631ecc499317881c1d120b70 ]
    
    Fix a logic error that could result in a null deref if the user sets
    the mode incorrectly for the given addr type.
    
    Signed-off-by: Dan Robertson <dan@dlrobertson.com>
    Acked-by: Alexander Aring <aahringo@redhat.com>
    Link: https://lore.kernel.org/r/20210423040214.15438-2-dan@dlrobertson.com
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>