commit 47127fcd287c91397d11bcf697d12c79169528f2
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Apr 28 12:05:48 2021 +0200

    Linux 4.4.268
    
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Jason Self <jason@bluehome.net>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Link: https://lore.kernel.org/r/20210426072816.574319312@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5871761c5f0f20d6e98bf3b6bd7486d857589554
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Apr 26 10:11:49 2021 +0200

    net: hso: fix NULL-deref on disconnect regression
    
    commit 2ad5692db72874f02b9ad551d26345437ea4f7f3 upstream.
    
    Commit 8a12f8836145 ("net: hso: fix null-ptr-deref during tty device
    unregistration") fixed the racy minor allocation reported by syzbot, but
    introduced an unconditional NULL-pointer dereference on every disconnect
    instead.
    
    Specifically, the serial device table must no longer be accessed after
    the minor has been released by hso_serial_tty_unregister().
    
    Fixes: 8a12f8836145 ("net: hso: fix null-ptr-deref during tty device unregistration")
    Cc: stable@vger.kernel.org
    Cc: Anirudh Rayabharam <mail@anirudhrb.com>
    Reported-by: Leonardo Antoniazzi <leoanto@aruba.it>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Reviewed-by: Anirudh Rayabharam <mail@anirudhrb.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cb717a3160ff0c7af33cf06f8c524b70e8e50b44
Author: Mike Galbraith <efault@gmx.de>
Date:   Fri Apr 16 14:02:07 2021 +0200

    x86/crash: Fix crash_setup_memmap_entries() out-of-bounds access
    
    commit 5849cdf8c120e3979c57d34be55b92d90a77a47e upstream.
    
    Commit in Fixes: added support for kexec-ing a kernel on panic using a
    new system call. As part of it, it does prepare a memory map for the new
    kernel.
    
    However, while doing so, it wrongly accesses memory it has not
    allocated: it accesses the first element of the cmem->ranges[] array in
    memmap_exclude_ranges() but it has not allocated the memory for it in
    crash_setup_memmap_entries(). As KASAN reports:
    
      BUG: KASAN: vmalloc-out-of-bounds in crash_setup_memmap_entries+0x17e/0x3a0
      Write of size 8 at addr ffffc90000426008 by task kexec/1187
    
      (gdb) list *crash_setup_memmap_entries+0x17e
      0xffffffff8107cafe is in crash_setup_memmap_entries (arch/x86/kernel/crash.c:322).
      317                                      unsigned long long mend)
      318     {
      319             unsigned long start, end;
      320
      321             cmem->ranges[0].start = mstart;
      322             cmem->ranges[0].end = mend;
      323             cmem->nr_ranges = 1;
      324
      325             /* Exclude elf header region */
      326             start = image->arch.elf_load_addr;
      (gdb)
    
    Make sure the ranges array becomes a single element allocated.
    
     [ bp: Write a proper commit message. ]
    
    Fixes: dd5f726076cc ("kexec: support for kexec on panic using new system call")
    Signed-off-by: Mike Galbraith <efault@gmx.de>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Reviewed-by: Dave Young <dyoung@redhat.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lkml.kernel.org/r/725fa3dc1da2737f0f6188a1a9701bead257ea9d.camel@gmx.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5a6d3197d0cc0cd8751726ca3332e97af3bf334e
Author: Kees Cook <keescook@chromium.org>
Date:   Mon May 7 16:47:02 2018 -0700

    overflow.h: Add allocation size calculation helpers
    
    commit 610b15c50e86eb1e4b77274fabcaea29ac72d6a8 upstream.
    
    In preparation for replacing unchecked overflows for memory allocations,
    this creates helpers for the 3 most common calculations:
    
    array_size(a, b): 2-dimensional array
    array3_size(a, b, c): 3-dimensional array
    struct_size(ptr, member, n): struct followed by n-many trailing members
    
    Each of these return SIZE_MAX on overflow instead of wrapping around.
    
    (Additionally renames a variable named "array_size" to avoid future
    collision.)
    
    Co-developed-by: Matthew Wilcox <mawilcox@microsoft.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f517d00b37d1d0840c7cb91500210f3eade982e6
Author: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Date:   Tue May 8 00:36:27 2018 +0200

    compiler.h: enable builtin overflow checkers and add fallback code
    
    commit f0907827a8a9152aedac2833ed1b674a7b2a44f2 upstream.
    
    This adds wrappers for the __builtin overflow checkers present in gcc
    5.1+ as well as fallback implementations for earlier compilers. It's not
    that easy to implement the fully generic __builtin_X_overflow(T1 a, T2
    b, T3 *d) in macros, so the fallback code assumes that T1, T2 and T3 are
    the same. We obviously don't want the wrappers to have different
    semantics depending on $GCC_VERSION, so we also insist on that even when
    using the builtins.
    
    There are a few problems with the 'a+b < a' idiom for checking for
    overflow: For signed types, it relies on undefined behaviour and is
    not actually complete (it doesn't check underflow;
    e.g. INT_MIN+INT_MIN == 0 isn't caught). Due to type promotion it
    is wrong for all types (signed and unsigned) narrower than
    int. Similarly, when a and b does not have the same type, there are
    subtle cases like
    
      u32 a;
    
      if (a + sizeof(foo) < a)
        return -EOVERFLOW;
      a += sizeof(foo);
    
    where the test is always false on 64 bit platforms. Add to that that it
    is not always possible to determine the types involved at a glance.
    
    The new overflow.h is somewhat bulky, but that's mostly a result of
    trying to be type-generic, complete (e.g. catching not only overflow
    but also signed underflow) and not relying on undefined behaviour.
    
    Linus is of course right [1] that for unsigned subtraction a-b, the
    right way to check for overflow (underflow) is "b > a" and not
    "__builtin_sub_overflow(a, b, &d)", but that's just one out of six cases
    covered here, and included mostly for completeness.
    
    So is it worth it? I think it is, if nothing else for the documentation
    value of seeing
    
      if (check_add_overflow(a, b, &d))
        return -EGOAWAY;
      do_stuff_with(d);
    
    instead of the open-coded (and possibly wrong and/or incomplete and/or
    UBsan-tickling)
    
      if (a+b < a)
        return -EGOAWAY;
      do_stuff_with(a+b);
    
    While gcc does recognize the 'a+b < a' idiom for testing unsigned add
    overflow, it doesn't do nearly as good for unsigned multiplication
    (there's also no single well-established idiom). So using
    check_mul_overflow in kcalloc and friends may also make gcc generate
    slightly better code.
    
    [1] https://lkml.org/lkml/2015/11/2/658
    
    Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1c285a5ab75af9ecb7c58b7c43058d99865b9f81
Author: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Date:   Fri Apr 16 15:46:15 2021 -0700

    ia64: tools: remove duplicate definition of ia64_mf() on ia64
    
    [ Upstream commit f4bf09dc3aaa4b07cd15630f2023f68cb2668809 ]
    
    The ia64_mf() macro defined in tools/arch/ia64/include/asm/barrier.h is
    already defined in <asm/gcc_intrin.h> on ia64 which causes libbpf
    failing to build:
    
        CC       /usr/src/linux/tools/bpf/bpftool//libbpf/staticobjs/libbpf.o
      In file included from /usr/src/linux/tools/include/asm/barrier.h:24,
                       from /usr/src/linux/tools/include/linux/ring_buffer.h:4,
                       from libbpf.c:37:
      /usr/src/linux/tools/include/asm/../../arch/ia64/include/asm/barrier.h:43: error: "ia64_mf" redefined [-Werror]
         43 | #define ia64_mf()       asm volatile ("mf" ::: "memory")
            |
      In file included from /usr/include/ia64-linux-gnu/asm/intrinsics.h:20,
                       from /usr/include/ia64-linux-gnu/asm/swab.h:11,
                       from /usr/include/linux/swab.h:8,
                       from /usr/include/linux/byteorder/little_endian.h:13,
                       from /usr/include/ia64-linux-gnu/asm/byteorder.h:5,
                       from /usr/src/linux/tools/include/uapi/linux/perf_event.h:20,
                       from libbpf.c:36:
      /usr/include/ia64-linux-gnu/asm/gcc_intrin.h:382: note: this is the location of the previous definition
        382 | #define ia64_mf() __asm__ volatile ("mf" ::: "memory")
            |
      cc1: all warnings being treated as errors
    
    Thus, remove the definition from tools/arch/ia64/include/asm/barrier.h.
    
    Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
    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 735f57fe47a32aa5cd1df820d277a244411dcaf5
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Fri Apr 16 15:46:09 2021 -0700

    ia64: fix discontig.c section mismatches
    
    [ Upstream commit e2af9da4f867a1a54f1252bf3abc1a5c63951778 ]
    
    Fix IA64 discontig.c Section mismatch warnings.
    
    When CONFIG_SPARSEMEM=y and CONFIG_MEMORY_HOTPLUG=y, the functions
    computer_pernodesize() and scatter_node_data() should not be marked as
    __meminit because they are needed after init, on any memory hotplug
    event.  Also, early_nr_cpus_node() is called by compute_pernodesize(),
    so early_nr_cpus_node() cannot be __meminit either.
    
      WARNING: modpost: vmlinux.o(.text.unlikely+0x1612): Section mismatch in reference from the function arch_alloc_nodedata() to the function .meminit.text:compute_pernodesize()
      The function arch_alloc_nodedata() references the function __meminit compute_pernodesize().
      This is often because arch_alloc_nodedata lacks a __meminit annotation or the annotation of compute_pernodesize is wrong.
    
      WARNING: modpost: vmlinux.o(.text.unlikely+0x1692): Section mismatch in reference from the function arch_refresh_nodedata() to the function .meminit.text:scatter_node_data()
      The function arch_refresh_nodedata() references the function __meminit scatter_node_data().
      This is often because arch_refresh_nodedata lacks a __meminit annotation or the annotation of scatter_node_data is wrong.
    
      WARNING: modpost: vmlinux.o(.text.unlikely+0x1502): Section mismatch in reference from the function compute_pernodesize() to the function .meminit.text:early_nr_cpus_node()
      The function compute_pernodesize() references the function __meminit early_nr_cpus_node().
      This is often because compute_pernodesize lacks a __meminit annotation or the annotation of early_nr_cpus_node is wrong.
    
    Link: https://lkml.kernel.org/r/20210411001201.3069-1-rdunlap@infradead.org
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: Mike Rapoport <rppt@kernel.org>
    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 d029ea66557e12e0309826029ac4c40833acc723
Author: Wan Jiabing <wanjiabing@vivo.com>
Date:   Wed Apr 14 19:31:48 2021 +0800

    cavium/liquidio: Fix duplicate argument
    
    [ Upstream commit 416dcc5ce9d2a810477171c62ffa061a98f87367 ]
    
    Fix the following coccicheck warning:
    
    ./drivers/net/ethernet/cavium/liquidio/cn66xx_regs.h:413:6-28:
    duplicated argument to & or |
    
    The CN6XXX_INTR_M1UPB0_ERR here is duplicate.
    Here should be CN6XXX_INTR_M1UNB0_ERR.
    
    Signed-off-by: Wan Jiabing <wanjiabing@vivo.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 35edcf73f094fc9879a3a2619ad5328ef0dfc4da
Author: Michael Brown <mbrown@fensystems.co.uk>
Date:   Tue Apr 13 16:25:12 2021 +0100

    xen-netback: Check for hotplug-status existence before watching
    
    [ Upstream commit 2afeec08ab5c86ae21952151f726bfe184f6b23d ]
    
    The logic in connect() is currently written with the assumption that
    xenbus_watch_pathfmt() will return an error for a node that does not
    exist.  This assumption is incorrect: xenstore does allow a watch to
    be registered for a nonexistent node (and will send notifications
    should the node be subsequently created).
    
    As of commit 1f2565780 ("xen-netback: remove 'hotplug-status' once it
    has served its purpose"), this leads to a failure when a domU
    transitions into XenbusStateConnected more than once.  On the first
    domU transition into Connected state, the "hotplug-status" node will
    be deleted by the hotplug_status_changed() callback in dom0.  On the
    second or subsequent domU transition into Connected state, the
    hotplug_status_changed() callback will therefore never be invoked, and
    so the backend will remain stuck in InitWait.
    
    This failure prevents scenarios such as reloading the xen-netfront
    module within a domU, or booting a domU via iPXE.  There is
    unfortunately no way for the domU to work around this dom0 bug.
    
    Fix by explicitly checking for existence of the "hotplug-status" node,
    thereby creating the behaviour that was previously assumed to exist.
    
    Signed-off-by: Michael Brown <mbrown@fensystems.co.uk>
    Reviewed-by: Paul Durrant <paul@xen.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a1ada6f18b294c5c367020f4419decb17cf8f59b
Author: Vasily Gorbik <gor@linux.ibm.com>
Date:   Fri Apr 9 00:15:21 2021 +0200

    s390/entry: save the caller of psw_idle
    
    [ Upstream commit a994eddb947ea9ebb7b14d9a1267001699f0a136 ]
    
    Currently psw_idle does not allocate a stack frame and does not
    save its r14 and r15 into the save area. Even though this is valid from
    call ABI point of view, because psw_idle does not make any calls
    explicitly, in reality psw_idle is an entry point for controlled
    transition into serving interrupts. So, in practice, psw_idle stack
    frame is analyzed during stack unwinding. Depending on build options
    that r14 slot in the save area of psw_idle might either contain a value
    saved by previous sibling call or complete garbage.
    
      [task    0000038000003c28] do_ext_irq+0xd6/0x160
      [task    0000038000003c78] ext_int_handler+0xba/0xe8
      [task   *0000038000003dd8] psw_idle_exit+0x0/0x8 <-- pt_regs
     ([task    0000038000003dd8] 0x0)
      [task    0000038000003e10] default_idle_call+0x42/0x148
      [task    0000038000003e30] do_idle+0xce/0x160
      [task    0000038000003e70] cpu_startup_entry+0x36/0x40
      [task    0000038000003ea0] arch_call_rest_init+0x76/0x80
    
    So, to make a stacktrace nicer and actually point for the real caller of
    psw_idle in this frequently occurring case, make psw_idle save its r14.
    
      [task    0000038000003c28] do_ext_irq+0xd6/0x160
      [task    0000038000003c78] ext_int_handler+0xba/0xe8
      [task   *0000038000003dd8] psw_idle_exit+0x0/0x6 <-- pt_regs
     ([task    0000038000003dd8] arch_cpu_idle+0x3c/0xd0)
      [task    0000038000003e10] default_idle_call+0x42/0x148
      [task    0000038000003e30] do_idle+0xce/0x160
      [task    0000038000003e70] cpu_startup_entry+0x36/0x40
      [task    0000038000003ea0] arch_call_rest_init+0x76/0x80
    
    Reviewed-by: Sven Schnelle <svens@linux.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e18d47d02510e640f9bbef2d1d1d15bed39f5345
Author: Tony Lindgren <tony@atomide.com>
Date:   Wed Mar 24 15:10:32 2021 +0200

    ARM: dts: Fix swapped mmc order for omap3
    
    [ Upstream commit a1ebdb3741993f853865d1bd8f77881916ad53a7 ]
    
    Also some omap3 devices like n900 seem to have eMMC and micro-sd swapped
    around with commit 21b2cec61c04 ("mmc: Set PROBE_PREFER_ASYNCHRONOUS for
    drivers that existed in v4.4").
    
    Let's fix the issue with aliases as discussed on the mailing lists. While
    the mmc aliases should be board specific, let's first fix the issue with
    minimal changes.
    
    Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
    Cc: Peter Ujfalusi <peter.ujfalusi@gmail.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b60a272ffb6a129f2e45fbf08e7c1acd18195167
Author: Zhang Yi <yi.zhang@huawei.com>
Date:   Fri Apr 23 20:35:07 2021 +0800

    ext4: correct error label in ext4_rename()
    
    The backport of upstream patch 5dccdc5a1916 ("ext4: do not iput inode
    under running transaction in ext4_rename()") introduced a regression on
    the stable kernels 4.14 and older. One of the end_rename error label was
    forgetting to change to release_bh, which may trigger below bug.
    
     ------------[ cut here ]------------
     kernel BUG at /home/zhangyi/hulk-4.4/fs/ext4/ext4_jbd2.c:30!
     ...
     Call Trace:
      [<ffffffff8b4207b2>] ext4_rename+0x9e2/0x10c0
      [<ffffffff8b331324>] ? unlazy_walk+0x124/0x2a0
      [<ffffffff8b420eb5>] ext4_rename2+0x25/0x60
      [<ffffffff8b335104>] vfs_rename+0x3a4/0xed0
      [<ffffffff8b33a7ad>] SYSC_renameat2+0x57d/0x7f0
      [<ffffffff8b33c119>] SyS_renameat+0x19/0x30
      [<ffffffff8bc57bb8>] entry_SYSCALL_64_fastpath+0x18/0x78
     ...
     ---[ end trace 75346ce7c76b9f06 ]---
    
    Fixes: 2fc8ce56985d ("ext4: do not iput inode under running transaction in ext4_rename()")
    Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a462067d7c8e6953a733bf5ade8db947b1bb5449
Author: Anirudh Rayabharam <mail@anirudhrb.com>
Date:   Wed Apr 7 22:57:22 2021 +0530

    net: hso: fix null-ptr-deref during tty device unregistration
    
    commit 8a12f8836145ffe37e9c8733dce18c22fb668b66 upstream
    
    Multiple ttys try to claim the same the minor number causing a double
    unregistration of the same device. The first unregistration succeeds
    but the next one results in a null-ptr-deref.
    
    The get_free_serial_index() function returns an available minor number
    but doesn't assign it immediately. The assignment is done by the caller
    later. But before this assignment, calls to get_free_serial_index()
    would return the same minor number.
    
    Fix this by modifying get_free_serial_index to assign the minor number
    immediately after one is found to be and rename it to obtain_minor()
    to better reflect what it does. Similary, rename set_serial_by_index()
    to release_minor() and modify it to free up the minor number of the
    given hso_serial. Every obtain_minor() should have corresponding
    release_minor() call.
    
    Fixes: 72dc1c096c705 ("HSO: add option hso driver")
    Reported-by: syzbot+c49fe6089f295a05e6f8@syzkaller.appspotmail.com
    Tested-by: syzbot+c49fe6089f295a05e6f8@syzkaller.appspotmail.com
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Anirudh Rayabharam <mail@anirudhrb.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [sudip: adjust context]
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f8e8371cf767264ed16bcd6c6fe150d842ce52c7
Author: Fredrik Strupe <fredrik@strupe.net>
Date:   Mon Apr 5 21:52:05 2021 +0100

    ARM: 9071/1: uprobes: Don't hook on thumb instructions
    
    commit d2f7eca60b29006285d57c7035539e33300e89e5 upstream.
    
    Since uprobes is not supported for thumb, check that the thumb bit is
    not set when matching the uprobes instruction hooks.
    
    The Arm UDF instructions used for uprobes triggering
    (UPROBE_SWBP_ARM_INSN and UPROBE_SS_ARM_INSN) coincidentally share the
    same encoding as a pair of unallocated 32-bit thumb instructions (not
    UDF) when the condition code is 0b1111 (0xf). This in effect makes it
    possible to trigger the uprobes functionality from thumb, and at that
    using two unallocated instructions which are not permanently undefined.
    
    Signed-off-by: Fredrik Strupe <fredrik@strupe.net>
    Cc: stable@vger.kernel.org
    Fixes: c7edc9e326d5 ("ARM: add uprobes support")
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 18045accd5388354dc9083fb2b26220c959c7314
Author: Jason Xing <xingwanli@kuaishou.com>
Date:   Wed Apr 14 10:34:28 2021 +0800

    i40e: fix the panic when running bpf in xdpdrv mode
    
    commit 4e39a072a6a0fc422ba7da5e4336bdc295d70211 upstream.
    
    Fix this panic by adding more rules to calculate the value of @rss_size_max
    which could be used in allocating the queues when bpf is loaded, which,
    however, could cause the failure and then trigger the NULL pointer of
    vsi->rx_rings. Prio to this fix, the machine doesn't care about how many
    cpus are online and then allocates 256 queues on the machine with 32 cpus
    online actually.
    
    Once the load of bpf begins, the log will go like this "failed to get
    tracking for 256 queues for VSI 0 err -12" and this "setup of MAIN VSI
    failed".
    
    Thus, I attach the key information of the crash-log here.
    
    BUG: unable to handle kernel NULL pointer dereference at
    0000000000000000
    RIP: 0010:i40e_xdp+0xdd/0x1b0 [i40e]
    Call Trace:
    [2160294.717292]  ? i40e_reconfig_rss_queues+0x170/0x170 [i40e]
    [2160294.717666]  dev_xdp_install+0x4f/0x70
    [2160294.718036]  dev_change_xdp_fd+0x11f/0x230
    [2160294.718380]  ? dev_disable_lro+0xe0/0xe0
    [2160294.718705]  do_setlink+0xac7/0xe70
    [2160294.719035]  ? __nla_parse+0xed/0x120
    [2160294.719365]  rtnl_newlink+0x73b/0x860
    
    Fixes: 41c445ff0f48 ("i40e: main driver core")
    Co-developed-by: Shujin Li <lishujin@kuaishou.com>
    Signed-off-by: Shujin Li <lishujin@kuaishou.com>
    Signed-off-by: Jason Xing <xingwanli@kuaishou.com>
    Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
    Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f528b76bccd39987895a8a8cea59958a65cb9a49
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sun Apr 11 11:02:08 2021 +0200

    net: davicom: Fix regulator not turned off on failed probe
    
    commit 31457db3750c0b0ed229d836f2609fdb8a5b790e upstream.
    
    When the probe fails, we must disable the regulator that was previously
    enabled.
    
    This patch is a follow-up to commit ac88c531a5b3
    ("net: davicom: Fix regulator not turned off on failed probe") which missed
    one case.
    
    Fixes: 7994fe55a4a2 ("dm9000: Add regulator and reset support to dm9000")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d34b892fcf9b20eedf01c29da8ccf951c9eb2469
Author: Jolly Shah <jollys@google.com>
Date:   Thu Mar 18 15:56:32 2021 -0700

    scsi: libsas: Reset num_scatter if libata marks qc as NODATA
    
    commit 176ddd89171ddcf661862d90c5d257877f7326d6 upstream.
    
    When the cache_type for the SCSI device is changed, the SCSI layer issues a
    MODE_SELECT command. The caching mode details are communicated via a
    request buffer associated with the SCSI command with data direction set as
    DMA_TO_DEVICE (scsi_mode_select()). When this command reaches the libata
    layer, as a part of generic initial setup, libata layer sets up the
    scatterlist for the command using the SCSI command (ata_scsi_qc_new()).
    This command is then translated by the libata layer into
    ATA_CMD_SET_FEATURES (ata_scsi_mode_select_xlat()). The libata layer treats
    this as a non-data command (ata_mselect_caching()), since it only needs an
    ATA taskfile to pass the caching on/off information to the device. It does
    not need the scatterlist that has been setup, so it does not perform
    dma_map_sg() on the scatterlist (ata_qc_issue()). Unfortunately, when this
    command reaches the libsas layer (sas_ata_qc_issue()), libsas layer sees it
    as a non-data command with a scatterlist. It cannot extract the correct DMA
    length since the scatterlist has not been mapped with dma_map_sg() for a
    DMA operation. When this partially constructed SAS task reaches pm80xx
    LLDD, it results in the following warning:
    
    "pm80xx_chip_sata_req 6058: The sg list address
    start_addr=0x0000000000000000 data_len=0x0end_addr_high=0xffffffff
    end_addr_low=0xffffffff has crossed 4G boundary"
    
    Update libsas to handle ATA non-data commands separately so num_scatter and
    total_xfer_len remain 0.
    
    Link: https://lore.kernel.org/r/20210318225632.2481291-1-jollys@google.com
    Fixes: 53de092f47ff ("scsi: libsas: Set data_dir as DMA_NONE if libata marks qc as NODATA")
    Tested-by: Luo Jiaxing <luojiaxing@huawei.com>
    Reviewed-by: John Garry <john.garry@huawei.com>
    Signed-off-by: Jolly Shah <jollys@google.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7444a4152ac3334c0149a2a58b6c8a27e734359d
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Mar 23 09:56:34 2021 -0700

    Input: i8042 - fix Pegatron C15B ID entry
    
    commit daa58c8eec0a65ac8e2e77ff3ea8a233d8eec954 upstream.
    
    The Zenbook Flip entry that was added overwrites a previous one
    because of a typo:
    
    In file included from drivers/input/serio/i8042.h:23,
                     from drivers/input/serio/i8042.c:131:
    drivers/input/serio/i8042-x86ia64io.h:591:28: error: initialized field overwritten [-Werror=override-init]
      591 |                 .matches = {
          |                            ^
    drivers/input/serio/i8042-x86ia64io.h:591:28: note: (near initialization for 'i8042_dmi_noselftest_table[0].matches')
    
    Add the missing separator between the two.
    
    Fixes: b5d6e7ab7fe7 ("Input: i8042 - add ASUS Zenbook Flip to noselftest list")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Marcos Paulo de Souza <mpdesouza@suse.com>
    Link: https://lore.kernel.org/r/20210323130623.2302402-1-arnd@kernel.org
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8dc8a0021fd8a16e1c994a4e2553a100fdad50b5
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Mon Apr 5 21:29:22 2021 -0700

    pcnet32: Use pci_resource_len to validate PCI resource
    
    [ Upstream commit 66c3f05ddc538ee796321210c906b6ae6fc0792a ]
    
    pci_resource_start() is not a good indicator to determine if a PCI
    resource exists or not, since the resource may start at address 0.
    This is seen when trying to instantiate the driver in qemu for riscv32
    or riscv64.
    
    pci 0000:00:01.0: reg 0x10: [io  0x0000-0x001f]
    pci 0000:00:01.0: reg 0x14: [mem 0x00000000-0x0000001f]
    ...
    pcnet32: card has no PCI IO resources, aborting
    
    Use pci_resouce_len() instead.
    
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f803e37721125e03478a7a7a75162f584bb72055
Author: Alexander Aring <aahringo@redhat.com>
Date:   Sun Apr 4 20:30:52 2021 -0400

    net: ieee802154: forbid monitor for add llsec seclevel
    
    [ Upstream commit 9ec87e322428d4734ac647d1a8e507434086993d ]
    
    This patch forbids to add llsec seclevel for monitor interfaces which we
    don't support yet. Otherwise we will access llsec mib which isn't
    initialized for monitors.
    
    Signed-off-by: Alexander Aring <aahringo@redhat.com>
    Link: https://lore.kernel.org/r/20210405003054.256017-14-aahringo@redhat.com
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f3af74520457f21d925c45a6bcc821994ebc426a
Author: Alexander Aring <aahringo@redhat.com>
Date:   Sun Apr 4 20:30:51 2021 -0400

    net: ieee802154: stop dump llsec seclevels for monitors
    
    [ Upstream commit 4c9b4f55ad1f5a4b6206ac4ea58f273126d21925 ]
    
    This patch stops dumping llsec seclevels for monitors which we don't
    support yet. Otherwise we will access llsec mib which isn't initialized
    for monitors.
    
    Signed-off-by: Alexander Aring <aahringo@redhat.com>
    Link: https://lore.kernel.org/r/20210405003054.256017-13-aahringo@redhat.com
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 40f542931d7576a637787845cac64514254f9136
Author: Alexander Aring <aahringo@redhat.com>
Date:   Sun Apr 4 20:30:49 2021 -0400

    net: ieee802154: forbid monitor for add llsec devkey
    
    [ Upstream commit a347b3b394868fef15b16f143719df56184be81d ]
    
    This patch forbids to add llsec devkey for monitor interfaces which we
    don't support yet. Otherwise we will access llsec mib which isn't
    initialized for monitors.
    
    Signed-off-by: Alexander Aring <aahringo@redhat.com>
    Link: https://lore.kernel.org/r/20210405003054.256017-11-aahringo@redhat.com
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 89a6f665b25fb3d91d3a1d31f9c3235efe74e05b
Author: Alexander Aring <aahringo@redhat.com>
Date:   Sun Apr 4 20:30:48 2021 -0400

    net: ieee802154: stop dump llsec devkeys for monitors
    
    [ Upstream commit 080d1a57a94d93e70f84b7a360baa351388c574f ]
    
    This patch stops dumping llsec devkeys for monitors which we don't support
    yet. Otherwise we will access llsec mib which isn't initialized for
    monitors.
    
    Signed-off-by: Alexander Aring <aahringo@redhat.com>
    Link: https://lore.kernel.org/r/20210405003054.256017-10-aahringo@redhat.com
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 91a35cfd989b5635adad13909688c1f25ef2afcc
Author: Alexander Aring <aahringo@redhat.com>
Date:   Sun Apr 4 20:30:46 2021 -0400

    net: ieee802154: forbid monitor for add llsec dev
    
    [ Upstream commit 5303f956b05a2886ff42890908156afaec0f95ac ]
    
    This patch forbids to add llsec dev for monitor interfaces which we
    don't support yet. Otherwise we will access llsec mib which isn't
    initialized for monitors.
    
    Signed-off-by: Alexander Aring <aahringo@redhat.com>
    Link: https://lore.kernel.org/r/20210405003054.256017-8-aahringo@redhat.com
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0068d5f0ac1048d68fe838ef51c075bd7d1c510e
Author: Alexander Aring <aahringo@redhat.com>
Date:   Sun Apr 4 20:30:45 2021 -0400

    net: ieee802154: stop dump llsec devs for monitors
    
    [ Upstream commit 5582d641e6740839c9b83efd1fbf9bcd00b6f5fc ]
    
    This patch stops dumping llsec devs for monitors which we don't support
    yet. Otherwise we will access llsec mib which isn't initialized for
    monitors.
    
    Signed-off-by: Alexander Aring <aahringo@redhat.com>
    Link: https://lore.kernel.org/r/20210405003054.256017-7-aahringo@redhat.com
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3479cf505a2c5baadeea543705d14d6e1337539c
Author: Alexander Aring <aahringo@redhat.com>
Date:   Sun Apr 4 20:30:42 2021 -0400

    net: ieee802154: stop dump llsec keys for monitors
    
    [ Upstream commit fb3c5cdf88cd504ef11d59e8d656f4bc896c6922 ]
    
    This patch stops dumping llsec keys for monitors which we don't support
    yet. Otherwise we will access llsec mib which isn't initialized for
    monitors.
    
    Signed-off-by: Alexander Aring <aahringo@redhat.com>
    Link: https://lore.kernel.org/r/20210405003054.256017-4-aahringo@redhat.com
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3e70e67b390b1159b1d3243aec1194e37c4db33b
Author: Alexander Shiyan <shc_work@mail.ru>
Date:   Fri Apr 2 11:14:05 2021 +0300

    ASoC: fsl_esai: Fix TDM slot setup for I2S mode
    
    [ Upstream commit e7a48c710defa0e0fef54d42b7d9e4ab596e2761 ]
    
    When using the driver in I2S TDM mode, the fsl_esai_startup()
    function rewrites the number of slots previously set by the
    fsl_esai_set_dai_tdm_slot() function to 2.
    To fix this, let's use the saved slot count value or, if TDM
    is not used and the number of slots is not set, the driver will use
    the default value (2), which is set by fsl_esai_probe().
    
    Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
    Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
    Link: https://lore.kernel.org/r/20210402081405.9892-1-shc_work@mail.ru
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7c4c43e277deb2377ceb241e5bdcc5db23940fc9
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Mar 23 14:18:05 2021 +0100

    ARM: keystone: fix integer overflow warning
    
    [ Upstream commit 844b85dda2f569943e1e018fdd63b6f7d1d6f08e ]
    
    clang warns about an impossible condition when building with 32-bit
    phys_addr_t:
    
    arch/arm/mach-keystone/keystone.c:79:16: error: result of comparison of constant 51539607551 with expression of type 'phys_addr_t' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
                mem_end   > KEYSTONE_HIGH_PHYS_END) {
                ~~~~~~~   ^ ~~~~~~~~~~~~~~~~~~~~~~
    arch/arm/mach-keystone/keystone.c:78:16: error: result of comparison of constant 34359738368 with expression of type 'phys_addr_t' (aka 'unsigned int') is always true [-Werror,-Wtautological-constant-out-of-range-compare]
            if (mem_start < KEYSTONE_HIGH_PHYS_START ||
                ~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~
    
    Change the temporary variable to a fixed-size u64 to avoid the warning.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Nathan Chancellor <nathan@kernel.org>
    Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
    Link: https://lore.kernel.org/r/20210323131814.2751750-1-arnd@kernel.org'
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 76a798084b81abd03a84bacfb71f7566df1d1ac2
Author: Tong Zhu <zhutong@amazon.com>
Date:   Fri Mar 19 14:33:37 2021 -0400

    neighbour: Disregard DEAD dst in neigh_update
    
    [ Upstream commit d47ec7a0a7271dda08932d6208e4ab65ab0c987c ]
    
    After a short network outage, the dst_entry is timed out and put
    in DST_OBSOLETE_DEAD. We are in this code because arp reply comes
    from this neighbour after network recovers. There is a potential
    race condition that dst_entry is still in DST_OBSOLETE_DEAD.
    With that, another neighbour lookup causes more harm than good.
    
    In best case all packets in arp_queue are lost. This is
    counterproductive to the original goal of finding a better path
    for those packets.
    
    I observed a worst case with 4.x kernel where a dst_entry in
    DST_OBSOLETE_DEAD state is associated with loopback net_device.
    It leads to an ethernet header with all zero addresses.
    A packet with all zero source MAC address is quite deadly with
    mac80211, ath9k and 802.11 block ack.  It fails
    ieee80211_find_sta_by_ifaddr in ath9k (xmit.c). Ath9k flushes tx
    queue (ath_tx_complete_aggr). BAW (block ack window) is not
    updated. BAW logic is damaged and ath9k transmission is disabled.
    
    Signed-off-by: Tong Zhu <zhutong@amazon.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a96e0c78b2cedf6b5f54fcda9d1d312ff6d24ca1
Author: Wang Qing <wangqing@vivo.com>
Date:   Mon Mar 1 20:05:48 2021 +0800

    arc: kernel: Return -EFAULT if copy_to_user() fails
    
    [ Upstream commit 46e152186cd89d940b26726fff11eb3f4935b45a ]
    
    The copy_to_user() function returns the number of bytes remaining to be
    copied, but we want to return -EFAULT if the copy doesn't complete.
    
    Signed-off-by: Wang Qing <wangqing@vivo.com>
    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4e20eb55d6b69bb54856683a34f125c176f20443
Author: Tony Lindgren <tony@atomide.com>
Date:   Mon Mar 8 11:30:45 2021 +0200

    ARM: dts: Fix moving mmc devices with aliases for omap4 & 5
    
    [ Upstream commit 77335a040178a0456d4eabc8bf17a7ca3ee4a327 ]
    
    Fix moving mmc devices with dts aliases as discussed on the lists.
    Without this we now have internal eMMC mmc1 show up as mmc2 compared
    to the earlier order of devices.
    
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 722d1d1de858ec321a8f3816a21213d3c64a23a4
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Wed Mar 24 16:17:57 2021 +0200

    dmaengine: dw: Make it dependent to HAS_IOMEM
    
    [ Upstream commit 88cd1d6191b13689094310c2405394e4ce36d061 ]
    
    Some architectures do not provide devm_*() APIs. Hence make the driver
    dependent on HAVE_IOMEM.
    
    Fixes: dbde5c2934d1 ("dw_dmac: use devm_* functions to simplify code")
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Link: https://lore.kernel.org/r/20210324141757.24710-1-andriy.shevchenko@linux.intel.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c5d86a93796f8f64691fea32530795638f185408
Author: Fabian Vogt <fabian@ritter-vogt.de>
Date:   Tue Mar 23 10:45:55 2021 -0700

    Input: nspire-keypad - enable interrupts only when opened
    
    [ Upstream commit 69d5ff3e9e51e23d5d81bf48480aa5671be67a71 ]
    
    The driver registers an interrupt handler in _probe, but didn't configure
    them until later when the _open function is called. In between, the keypad
    can fire an IRQ due to touchpad activity, which the handler ignores. This
    causes the kernel to disable the interrupt, blocking the keypad from
    working.
    
    Fix this by disabling interrupts before registering the handler.
    Additionally, disable them in _close, so that they're only enabled while
    open.
    
    Fixes: fc4f31461892 ("Input: add TI-Nspire keypad support")
    Signed-off-by: Fabian Vogt <fabian@ritter-vogt.de>
    Link: https://lore.kernel.org/r/3383725.iizBOSrK1V@linux-e202.suse.de
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e2fe67b243806f06e498f69d7c62a2d5497fc15e
Author: Or Cohen <orcohen@paloaltonetworks.com>
Date:   Tue Apr 13 21:10:31 2021 +0300

    net/sctp: fix race condition in sctp_destroy_sock
    
    commit b166a20b07382b8bc1dcee2a448715c9c2c81b5b upstream.
    
    If sctp_destroy_sock is called without sock_net(sk)->sctp.addr_wq_lock
    held and sp->do_auto_asconf is true, then an element is removed
    from the auto_asconf_splist without any proper locking.
    
    This can happen in the following functions:
    1. In sctp_accept, if sctp_sock_migrate fails.
    2. In inet_create or inet6_create, if there is a bpf program
       attached to BPF_CGROUP_INET_SOCK_CREATE which denies
       creation of the sctp socket.
    
    The bug is fixed by acquiring addr_wq_lock in sctp_destroy_sock
    instead of sctp_close.
    
    This addresses CVE-2021-23133.
    
    Reported-by: Or Cohen <orcohen@paloaltonetworks.com>
    Reviewed-by: Xin Long <lucien.xin@gmail.com>
    Fixes: 610236587600 ("bpf: Add new cgroup attach type to enable sock modifications")
    Signed-off-by: Or Cohen <orcohen@paloaltonetworks.com>
    Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>