commit 327f1e7d813c77eceadafbdc498f5eb680fd9fb2
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Mar 16 14:16:03 2022 +0100

    Linux 5.10.106
    
    Link: https://lore.kernel.org/r/20220314112737.929694832@linuxfoundation.org
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Fox Chen <foxhlchen@gmail.com>
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Hulk Robot <hulkrobot@huawei.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 648895da69ced90ca770fd941c3d9479a9d72c16
Author: David Howells <dhowells@redhat.com>
Date:   Fri Mar 11 13:23:31 2022 +0000

    watch_queue: Fix filter limit check
    
    commit c993ee0f9f81caf5767a50d1faeba39a0dc82af2 upstream.
    
    In watch_queue_set_filter(), there are a couple of places where we check
    that the filter type value does not exceed what the type_filter bitmap
    can hold.  One place calculates the number of bits by:
    
       if (tf[i].type >= sizeof(wfilter->type_filter) * 8)
    
    which is fine, but the second does:
    
       if (tf[i].type >= sizeof(wfilter->type_filter) * BITS_PER_LONG)
    
    which is not.  This can lead to a couple of out-of-bounds writes due to
    a too-large type:
    
     (1) __set_bit() on wfilter->type_filter
     (2) Writing more elements in wfilter->filters[] than we allocated.
    
    Fix this by just using the proper WATCH_TYPE__NR instead, which is the
    number of types we actually know about.
    
    The bug may cause an oops looking something like:
    
      BUG: KASAN: slab-out-of-bounds in watch_queue_set_filter+0x659/0x740
      Write of size 4 at addr ffff88800d2c66bc by task watch_queue_oob/611
      ...
      Call Trace:
       <TASK>
       dump_stack_lvl+0x45/0x59
       print_address_description.constprop.0+0x1f/0x150
       ...
       kasan_report.cold+0x7f/0x11b
       ...
       watch_queue_set_filter+0x659/0x740
       ...
       __x64_sys_ioctl+0x127/0x190
       do_syscall_64+0x43/0x90
       entry_SYSCALL_64_after_hwframe+0x44/0xae
    
      Allocated by task 611:
       kasan_save_stack+0x1e/0x40
       __kasan_kmalloc+0x81/0xa0
       watch_queue_set_filter+0x23a/0x740
       __x64_sys_ioctl+0x127/0x190
       do_syscall_64+0x43/0x90
       entry_SYSCALL_64_after_hwframe+0x44/0xae
    
      The buggy address belongs to the object at ffff88800d2c66a0
       which belongs to the cache kmalloc-32 of size 32
      The buggy address is located 28 bytes inside of
       32-byte region [ffff88800d2c66a0, ffff88800d2c66c0)
    
    Fixes: c73be61cede5 ("pipe: Add general notification queue support")
    Reported-by: Jann Horn <jannh@google.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8bb5b72dbd9ab91edf3ae616e7907c83c259beb0
Author: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Date:   Fri Mar 11 17:13:17 2022 +0000

    ARM: fix Thumb2 regression with Spectre BHB
    
    commit 6c7cb60bff7aec24b834343ff433125f469886a3 upstream.
    
    When building for Thumb2, the vectors make use of a local label. Sadly,
    the Spectre BHB code also uses a local label with the same number which
    results in the Thumb2 reference pointing at the wrong place. Fix this
    by changing the number used for the Spectre BHB local label.
    
    Fixes: b9baf5c8c5c3 ("ARM: Spectre-BHB workaround")
    Tested-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b1249db9e1c3be98fa8cae2361f4ed092906d0f
Author: Josh Triplett <josh@joshtriplett.org>
Date:   Mon Jun 7 12:15:24 2021 -0700

    ext4: add check to prevent attempting to resize an fs with sparse_super2
    
    commit b1489186cc8391e0c1e342f9fbc3eedf6b944c61 upstream.
    
    The in-kernel ext4 resize code doesn't support filesystem with the
    sparse_super2 feature. It fails with errors like this and doesn't finish
    the resize:
    EXT4-fs (loop0): resizing filesystem from 16640 to 7864320 blocks
    EXT4-fs warning (device loop0): verify_reserved_gdb:760: reserved GDT 2 missing grp 1 (32770)
    EXT4-fs warning (device loop0): ext4_resize_fs:2111: error (-22) occurred during file system resize
    EXT4-fs (loop0): resized filesystem to 2097152
    
    To reproduce:
    mkfs.ext4 -b 4096 -I 256 -J size=32 -E resize=$((256*1024*1024)) -O sparse_super2 ext4.img 65M
    truncate -s 30G ext4.img
    mount ext4.img /mnt
    python3 -c 'import fcntl, os, struct ; fd = os.open("/mnt", os.O_RDONLY | os.O_DIRECTORY) ; fcntl.ioctl(fd, 0x40086610, struct.pack("Q", 30 * 1024 * 1024 * 1024 // 4096), False) ; os.close(fd)'
    dmesg | tail
    e2fsck ext4.img
    
    The userspace resize2fs tool has a check for this case: it checks if the
    filesystem has sparse_super2 set and if the kernel provides
    /sys/fs/ext4/features/sparse_super2. However, the former check requires
    manually reading and parsing the filesystem superblock.
    
    Detect this case in ext4_resize_begin and error out early with a clear
    error message.
    
    Signed-off-by: Josh Triplett <josh@joshtriplett.org>
    Link: https://lore.kernel.org/r/74b8ae78405270211943cd7393e65586c5faeed1.1623093259.git.josh@joshtriplett.org
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b297cf764d8c22b8b775f540b13c85f1675dc945
Author: Li Huafei <lihuafei1@huawei.com>
Date:   Thu Mar 10 20:09:15 2022 +0800

    x86/traps: Mark do_int3() NOKPROBE_SYMBOL
    
    commit a365a65f9ca1ceb9cf1ac29db4a4f51df7c507ad upstream.
    
    Since kprobe_int3_handler() is called in do_int3(), probing do_int3()
    can cause a breakpoint recursion and crash the kernel. Therefore,
    do_int3() should be marked as NOKPROBE_SYMBOL.
    
    Fixes: 21e28290b317 ("x86/traps: Split int3 handler up")
    Signed-off-by: Li Huafei <lihuafei1@huawei.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220310120915.63349-1-lihuafei1@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 29f6f35001279fad6a1e606eeb41e56b9db32082
Author: Ross Philipson <ross.philipson@oracle.com>
Date:   Wed Feb 23 21:07:36 2022 -0500

    x86/boot: Add setup_indirect support in early_memremap_is_setup_data()
    
    commit 445c1470b6ef96440e7cfc42dfc160f5004fd149 upstream.
    
    The x86 boot documentation describes the setup_indirect structures and
    how they are used. Only one of the two functions in ioremap.c that needed
    to be modified to be aware of the introduction of setup_indirect
    functionality was updated. Adds comparable support to the other function
    where it was missing.
    
    Fixes: b3c72fc9a78e ("x86/boot: Introduce setup_indirect")
    Signed-off-by: Ross Philipson <ross.philipson@oracle.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/1645668456-22036-3-git-send-email-ross.philipson@oracle.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b3444e5b640a41eb35250ac9882cf7ac36fa8f66
Author: Ross Philipson <ross.philipson@oracle.com>
Date:   Wed Feb 23 21:07:35 2022 -0500

    x86/boot: Fix memremap of setup_indirect structures
    
    commit 7228918b34615ef6317edcd9a058a057bc54aa32 upstream.
    
    As documented, the setup_indirect structure is nested inside
    the setup_data structures in the setup_data list. The code currently
    accesses the fields inside the setup_indirect structure but only
    the sizeof(struct setup_data) is being memremapped. No crash
    occurred but this is just due to how the area is remapped under the
    covers.
    
    Properly memremap both the setup_data and setup_indirect structures
    in these cases before accessing them.
    
    Fixes: b3c72fc9a78e ("x86/boot: Introduce setup_indirect")
    Signed-off-by: Ross Philipson <ross.philipson@oracle.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/1645668456-22036-2-git-send-email-ross.philipson@oracle.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 24d268130e3cbbef0f9ebb1f350e4c6fcdfffb65
Author: David Howells <dhowells@redhat.com>
Date:   Fri Mar 11 13:24:47 2022 +0000

    watch_queue: Make comment about setting ->defunct more accurate
    
    commit 4edc0760412b0c4ecefc7e02cb855b310b122825 upstream.
    
    watch_queue_clear() has a comment stating that setting ->defunct to true
    preventing new additions as well as preventing notifications.  Whilst
    the latter is true, the first bit is superfluous since at the time this
    function is called, the pipe cannot be accessed to add new event
    sources.
    
    Remove the "new additions" bit from the comment.
    
    Fixes: c73be61cede5 ("pipe: Add general notification queue support")
    Reported-by: Jann Horn <jannh@google.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec03510e0a7784c4fb5c4b3297878a72cca834d5
Author: David Howells <dhowells@redhat.com>
Date:   Fri Mar 11 13:24:36 2022 +0000

    watch_queue: Fix lack of barrier/sync/lock between post and read
    
    commit 2ed147f015af2b48f41c6f0b6746aa9ea85c19f3 upstream.
    
    There's nothing to synchronise post_one_notification() versus
    pipe_read().  Whilst posting is done under pipe->rd_wait.lock, the
    reader only takes pipe->mutex which cannot bar notification posting as
    that may need to be made from contexts that cannot sleep.
    
    Fix this by setting pipe->head with a barrier in post_one_notification()
    and reading pipe->head with a barrier in pipe_read().
    
    If that's not sufficient, the rd_wait.lock will need to be taken,
    possibly in a ->confirm() op so that it only applies to notifications.
    The lock would, however, have to be dropped before copy_page_to_iter()
    is invoked.
    
    Fixes: c73be61cede5 ("pipe: Add general notification queue support")
    Reported-by: Jann Horn <jannh@google.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 06ab8444392acdbffb57869d6220fb6654a8c95e
Author: David Howells <dhowells@redhat.com>
Date:   Fri Mar 11 13:24:29 2022 +0000

    watch_queue: Free the alloc bitmap when the watch_queue is torn down
    
    commit 7ea1a0124b6da246b5bc8c66cddaafd36acf3ecb upstream.
    
    Free the watch_queue note allocation bitmap when the watch_queue is
    destroyed.
    
    Fixes: c73be61cede5 ("pipe: Add general notification queue support")
    Reported-by: Jann Horn <jannh@google.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 880acbb718e15e46d37fcde75fa52d5cb4336dca
Author: David Howells <dhowells@redhat.com>
Date:   Fri Mar 11 13:24:22 2022 +0000

    watch_queue: Fix the alloc bitmap size to reflect notes allocated
    
    commit 3b4c0371928c17af03e8397ac842346624017ce6 upstream.
    
    Currently, watch_queue_set_size() sets the number of notes available in
    wqueue->nr_notes according to the number of notes allocated, but sets
    the size of the bitmap to the unrounded number of notes originally asked
    for.
    
    Fix this by setting the bitmap size to the number of notes we're
    actually going to make available (ie. the number allocated).
    
    Fixes: c73be61cede5 ("pipe: Add general notification queue support")
    Reported-by: Jann Horn <jannh@google.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e2b52ca4988e12ad75aeece53c4f0af849f0d9dc
Author: David Howells <dhowells@redhat.com>
Date:   Fri Mar 11 13:24:08 2022 +0000

    watch_queue: Fix to always request a pow-of-2 pipe ring size
    
    commit 96a4d8912b28451cd62825fd7caa0e66e091d938 upstream.
    
    The pipe ring size must always be a power of 2 as the head and tail
    pointers are masked off by AND'ing with the size of the ring - 1.
    watch_queue_set_size(), however, lets you specify any number of notes
    between 1 and 511.  This number is passed through to pipe_resize_ring()
    without checking/forcing its alignment.
    
    Fix this by rounding the number of slots required up to the nearest
    power of two.  The request is meant to guarantee that at least that many
    notifications can be generated before the queue is full, so rounding
    down isn't an option, but, alternatively, it may be better to give an
    error if we aren't allowed to allocate that much ring space.
    
    Fixes: c73be61cede5 ("pipe: Add general notification queue support")
    Reported-by: Jann Horn <jannh@google.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2039900aadba14f438b04d262721ffebc4d33547
Author: David Howells <dhowells@redhat.com>
Date:   Fri Mar 11 13:23:46 2022 +0000

    watch_queue: Fix to release page in ->release()
    
    commit c1853fbadcba1497f4907971e7107888e0714c81 upstream.
    
    When a pipe ring descriptor points to a notification message, the
    refcount on the backing page is incremented by the generic get function,
    but the release function, which marks the bitmap, doesn't drop the page
    ref.
    
    Fix this by calling generic_pipe_buf_release() at the end of
    watch_queue_pipe_buf_release().
    
    Fixes: c73be61cede5 ("pipe: Add general notification queue support")
    Reported-by: Jann Horn <jannh@google.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d729d4e99fb85f734805ff37dd79f38e7db21c0f
Author: David Howells <dhowells@redhat.com>
Date:   Fri Mar 11 13:23:38 2022 +0000

    watch_queue, pipe: Free watchqueue state after clearing pipe ring
    
    commit db8facfc9fafacefe8a835416a6b77c838088f8b upstream.
    
    In free_pipe_info(), free the watchqueue state after clearing the pipe
    ring as each pipe ring descriptor has a release function, and in the
    case of a notification message, this is watch_queue_pipe_buf_release()
    which tries to mark the allocation bitmap that was previously released.
    
    Fix this by moving the put of the pipe's ref on the watch queue to after
    the ring has been cleared.  We still need to call watch_queue_clear()
    before doing that to make sure that the pipe is disconnected from any
    notification sources first.
    
    Fixes: c73be61cede5 ("pipe: Add general notification queue support")
    Reported-by: Jann Horn <jannh@google.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 573a3228ca3268441ce334251cb9fec0d69ca574
Author: Michael S. Tsirkin <mst@redhat.com>
Date:   Fri Jan 14 14:58:41 2022 -0500

    virtio: acknowledge all features before access
    
    commit 4fa59ede95195f267101a1b8916992cf3f245cdb upstream.
    
    The feature negotiation was designed in a way that
    makes it possible for devices to know which config
    fields will be accessed by drivers.
    
    This is broken since commit 404123c2db79 ("virtio: allow drivers to
    validate features") with fallout in at least block and net.  We have a
    partial work-around in commit 2f9a174f918e ("virtio: write back
    F_VERSION_1 before validate") which at least lets devices find out which
    format should config space have, but this is a partial fix: guests
    should not access config space without acknowledging features since
    otherwise we'll never be able to change the config space format.
    
    To fix, split finalize_features from virtio_finalize_features and
    call finalize_features with all feature bits before validation,
    and then - if validation changed any bits - once again after.
    
    Since virtio_finalize_features no longer writes out features
    rename it to virtio_features_ok - since that is what it does:
    checks that features are ok with the device.
    
    As a side effect, this also reduces the amount of hypervisor accesses -
    we now only acknowledge features once unless we are clearing any
    features when validating (which is uncommon).
    
    IRC I think that this was more or less always the intent in the spec but
    unfortunately the way the spec is worded does not say this explicitly, I
    plan to address this at the spec level, too.
    
    Acked-by: Jason Wang <jasowang@redhat.com>
    Cc: stable@vger.kernel.org
    Fixes: 404123c2db79 ("virtio: allow drivers to validate features")
    Fixes: 2f9a174f918e ("virtio: write back F_VERSION_1 before validate")
    Cc: "Halil Pasic" <pasic@linux.ibm.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bf52b627cf4745cde774e0bb678c304a3f535142
Author: Michael S. Tsirkin <mst@redhat.com>
Date:   Fri Jan 14 14:56:15 2022 -0500

    virtio: unexport virtio_finalize_features
    
    commit 838d6d3461db0fdbf33fc5f8a69c27b50b4a46da upstream.
    
    virtio_finalize_features is only used internally within virtio.
    No reason to export it.
    
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Reviewed-by: Cornelia Huck <cohuck@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8bfb959ea28df90b00485b49513d05fffd48ad75
Author: Pali Rohár <pali@kernel.org>
Date:   Thu Mar 10 11:39:23 2022 +0100

    arm64: dts: marvell: armada-37xx: Remap IO space to bus address 0x0
    
    commit a1cc1697bb56cdf880ad4d17b79a39ef2c294bc9 upstream.
    
    Legacy and old PCI I/O based cards do not support 32-bit I/O addressing.
    
    Since commit 64f160e19e92 ("PCI: aardvark: Configure PCIe resources from
    'ranges' DT property") kernel can set different PCIe address on CPU and
    different on the bus for the one A37xx address mapping without any firmware
    support in case the bus address does not conflict with other A37xx mapping.
    
    So remap I/O space to the bus address 0x0 to enable support for old legacy
    I/O port based cards which have hardcoded I/O ports in low address space.
    
    Note that DDR on A37xx is mapped to bus address 0x0. And mapping of I/O
    space can be set to address 0x0 too because MEM space and I/O space are
    separate and so do not conflict.
    
    Remapping IO space on Turris Mox to different address is not possible to
    due bootloader bug.
    
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Reported-by: Arnd Bergmann <arnd@arndb.de>
    Fixes: 76f6386b25cc ("arm64: dts: marvell: Add Aardvark PCIe support for Armada 3700")
    Cc: stable@vger.kernel.org # 64f160e19e92 ("PCI: aardvark: Configure PCIe resources from 'ranges' DT property")
    Cc: stable@vger.kernel.org # 514ef1e62d65 ("arm64: dts: marvell: armada-37xx: Extend PCIe MEM space")
    Reviewed-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1ef5fe3dba2a15a9a94c2bc1fe6cb03002343a28
Author: Emil Renner Berthing <kernel@esmil.dk>
Date:   Wed Feb 23 20:12:57 2022 +0100

    riscv: Fix auipc+jalr relocation range checks
    
    commit 0966d385830de3470b7131db8e86c0c5bc9c52dc upstream.
    
    RISC-V can do PC-relative jumps with a 32bit range using the following
    two instructions:
    
            auipc   t0, imm20       ; t0 = PC + imm20 * 2^12
            jalr    ra, t0, imm12   ; ra = PC + 4, PC = t0 + imm12
    
    Crucially both the 20bit immediate imm20 and the 12bit immediate imm12
    are treated as two's-complement signed values. For this reason the
    immediates are usually calculated like this:
    
            imm20 = (offset + 0x800) >> 12
            imm12 = offset & 0xfff
    
    ..where offset is the signed offset from the auipc instruction. When
    the 11th bit of offset is 0 the addition of 0x800 doesn't change the top
    20 bits and imm12 considered positive. When the 11th bit is 1 the carry
    of the addition by 0x800 means imm20 is one higher, but since imm12 is
    then considered negative the two's complement representation means it
    all cancels out nicely.
    
    However, this addition by 0x800 (2^11) means an offset greater than or
    equal to 2^31 - 2^11 would overflow so imm20 is considered negative and
    result in a backwards jump. Similarly the lower range of offset is also
    moved down by 2^11 and hence the true 32bit range is
    
            [-2^31 - 2^11, 2^31 - 2^11)
    
    Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
    Fixes: e2c0cdfba7f6 ("RISC-V: User-facing API")
    Cc: stable@vger.kernel.org
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a69aa422b478592539201a70cab9146b2a9e53bb
Author: Rong Chen <rong.chen@amlogic.com>
Date:   Wed Feb 16 20:42:39 2022 +0800

    mmc: meson: Fix usage of meson_mmc_post_req()
    
    commit f0d2f15362f02444c5d7ffd5a5eb03e4aa54b685 upstream.
    
    Currently meson_mmc_post_req() is called in meson_mmc_request() right
    after meson_mmc_start_cmd(). This could lead to DMA unmapping before the request
    is actually finished.
    
    To fix, don't call meson_mmc_post_req() until meson_mmc_request_done().
    
    Signed-off-by: Rong Chen <rong.chen@amlogic.com>
    Reviewed-by: Kevin Hilman <khilman@baylibre.com>
    Fixes: 79ed05e329c3 ("mmc: meson-gx: add support for descriptor chain mode")
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20220216124239.4007667-1-rong.chen@amlogic.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0c6eeaf8c168c8f48fc89c2795741f655d00ec5c
Author: Robert Hancock <robert.hancock@calian.com>
Date:   Thu Mar 3 12:10:27 2022 -0600

    net: macb: Fix lost RX packet wakeup race in NAPI receive
    
    commit 0bf476fc3624e3a72af4ba7340d430a91c18cd67 upstream.
    
    There is an oddity in the way the RSR register flags propagate to the
    ISR register (and the actual interrupt output) on this hardware: it
    appears that RSR register bits only result in ISR being asserted if the
    interrupt was actually enabled at the time, so enabling interrupts with
    RSR bits already set doesn't trigger an interrupt to be raised. There
    was already a partial fix for this race in the macb_poll function where
    it checked for RSR bits being set and re-triggered NAPI receive.
    However, there was a still a race window between checking RSR and
    actually enabling interrupts, where a lost wakeup could happen. It's
    necessary to check again after enabling interrupts to see if RSR was set
    just prior to the interrupt being enabled, and re-trigger receive in that
    case.
    
    This issue was noticed in a point-to-point UDP request-response protocol
    which periodically saw timeouts or abnormally high response times due to
    received packets not being processed in a timely fashion. In many
    applications, more packets arriving, including TCP retransmissions, would
    cause the original packet to be processed, thus masking the issue.
    
    Fixes: 02f7a34f34e3 ("net: macb: Re-enable RX interrupt only when RX is done")
    Cc: stable@vger.kernel.org
    Co-developed-by: Scott McNutt <scott.mcnutt@siriusxm.com>
    Signed-off-by: Scott McNutt <scott.mcnutt@siriusxm.com>
    Signed-off-by: Robert Hancock <robert.hancock@calian.com>
    Tested-by: Claudiu Beznea <claudiu.beznea@microchip.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6d9700b445098dbbce0caff4b8cfca214cf1e757
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Feb 28 10:43:31 2022 +0300

    staging: gdm724x: fix use after free in gdm_lte_rx()
    
    commit fc7f750dc9d102c1ed7bbe4591f991e770c99033 upstream.
    
    The netif_rx_ni() function frees the skb so we can't dereference it to
    save the skb->len.
    
    Fixes: 61e121047645 ("staging: gdm7240: adding LTE USB driver")
    Cc: stable <stable@vger.kernel.org>
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Link: https://lore.kernel.org/r/20220228074331.GA13685@kili
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8c1bc04c8c8252e964de2c60a456545cdc810ad3
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Wed Mar 2 11:16:36 2022 +0100

    staging: rtl8723bs: Fix access-point mode deadlock
    
    commit 8f4347081be32e67b0873827e0138ab0fdaaf450 upstream.
    
    Commit 54659ca026e5 ("staging: rtl8723bs: remove possible deadlock when
    disconnect (v2)") split the locking of pxmitpriv->lock vs sleep_q/lock
    into 2 locks in attempt to fix a lockdep reported issue with the locking
    order of the sta_hash_lock vs pxmitpriv->lock.
    
    But in the end this turned out to not fully solve the sta_hash_lock issue
    so commit a7ac783c338b ("staging: rtl8723bs: remove a second possible
    deadlock") was added to fix this in another way.
    
    The original fix was kept as it was still seen as a good thing to have,
    but now it turns out that it creates a deadlock in access-point mode:
    
    [Feb20 23:47] ======================================================
    [  +0.074085] WARNING: possible circular locking dependency detected
    [  +0.074077] 5.16.0-1-amd64 #1 Tainted: G         C  E
    [  +0.064710] ------------------------------------------------------
    [  +0.074075] ksoftirqd/3/29 is trying to acquire lock:
    [  +0.060542] ffffb8b30062ab00 (&pxmitpriv->lock){+.-.}-{2:2}, at: rtw_xmit_classifier+0x8a/0x140 [r8723bs]
    [  +0.114921]
                  but task is already holding lock:
    [  +0.069908] ffffb8b3007ab704 (&psta->sleep_q.lock){+.-.}-{2:2}, at: wakeup_sta_to_xmit+0x3b/0x300 [r8723bs]
    [  +0.116976]
                  which lock already depends on the new lock.
    
    [  +0.098037]
                  the existing dependency chain (in reverse order) is:
    [  +0.089704]
                  -> #1 (&psta->sleep_q.lock){+.-.}-{2:2}:
    [  +0.077232]        _raw_spin_lock_bh+0x34/0x40
    [  +0.053261]        xmitframe_enqueue_for_sleeping_sta+0xc1/0x2f0 [r8723bs]
    [  +0.082572]        rtw_xmit+0x58b/0x940 [r8723bs]
    [  +0.056528]        _rtw_xmit_entry+0xba/0x350 [r8723bs]
    [  +0.062755]        dev_hard_start_xmit+0xf1/0x320
    [  +0.056381]        sch_direct_xmit+0x9e/0x360
    [  +0.052212]        __dev_queue_xmit+0xce4/0x1080
    [  +0.055334]        ip6_finish_output2+0x18f/0x6e0
    [  +0.056378]        ndisc_send_skb+0x2c8/0x870
    [  +0.052209]        ndisc_send_ns+0xd3/0x210
    [  +0.050130]        addrconf_dad_work+0x3df/0x5a0
    [  +0.055338]        process_one_work+0x274/0x5a0
    [  +0.054296]        worker_thread+0x52/0x3b0
    [  +0.050124]        kthread+0x16c/0x1a0
    [  +0.044925]        ret_from_fork+0x1f/0x30
    [  +0.049092]
                  -> #0 (&pxmitpriv->lock){+.-.}-{2:2}:
    [  +0.074101]        __lock_acquire+0x10f5/0x1d80
    [  +0.054298]        lock_acquire+0xd7/0x300
    [  +0.049088]        _raw_spin_lock_bh+0x34/0x40
    [  +0.053248]        rtw_xmit_classifier+0x8a/0x140 [r8723bs]
    [  +0.066949]        rtw_xmitframe_enqueue+0xa/0x20 [r8723bs]
    [  +0.066946]        rtl8723bs_hal_xmitframe_enqueue+0x14/0x50 [r8723bs]
    [  +0.078386]        wakeup_sta_to_xmit+0xa6/0x300 [r8723bs]
    [  +0.065903]        rtw_recv_entry+0xe36/0x1160 [r8723bs]
    [  +0.063809]        rtl8723bs_recv_tasklet+0x349/0x6c0 [r8723bs]
    [  +0.071093]        tasklet_action_common.constprop.0+0xe5/0x110
    [  +0.070966]        __do_softirq+0x16f/0x50a
    [  +0.050134]        __irq_exit_rcu+0xeb/0x140
    [  +0.051172]        irq_exit_rcu+0xa/0x20
    [  +0.047006]        common_interrupt+0xb8/0xd0
    [  +0.052214]        asm_common_interrupt+0x1e/0x40
    [  +0.056381]        finish_task_switch.isra.0+0x100/0x3a0
    [  +0.063670]        __schedule+0x3ad/0xd20
    [  +0.048047]        schedule+0x4e/0xc0
    [  +0.043880]        smpboot_thread_fn+0xc4/0x220
    [  +0.054298]        kthread+0x16c/0x1a0
    [  +0.044922]        ret_from_fork+0x1f/0x30
    [  +0.049088]
                  other info that might help us debug this:
    
    [  +0.095950]  Possible unsafe locking scenario:
    
    [  +0.070952]        CPU0                    CPU1
    [  +0.054282]        ----                    ----
    [  +0.054285]   lock(&psta->sleep_q.lock);
    [  +0.047004]                                lock(&pxmitpriv->lock);
    [  +0.074082]                                lock(&psta->sleep_q.lock);
    [  +0.077209]   lock(&pxmitpriv->lock);
    [  +0.043873]
                   *** DEADLOCK ***
    
    [  +0.070950] 1 lock held by ksoftirqd/3/29:
    [  +0.049082]  #0: ffffb8b3007ab704 (&psta->sleep_q.lock){+.-.}-{2:2}, at: wakeup_sta_to_xmit+0x3b/0x300 [r8723bs]
    
    Analysis shows that in hindsight the splitting of the lock was not
    a good idea, so revert this to fix the access-point mode deadlock.
    
    Note this is a straight-forward revert done with git revert, the commented
    out "/* spin_lock_bh(&psta_bmc->sleep_q.lock); */" lines were part of the
    code before the reverted changes.
    
    Fixes: 54659ca026e5 ("staging: rtl8723bs: remove possible deadlock when disconnect (v2)")
    Cc: stable <stable@vger.kernel.org>
    Cc: Fabio Aiuto <fabioaiuto83@gmail.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215542
    Link: https://lore.kernel.org/r/20220302101637.26542-1-hdegoede@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ab5595b45f732212b3b1974041b43a257153edb7
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Mon Mar 7 16:30:44 2022 +0100

    fuse: fix pipe buffer lifetime for direct_io
    
    commit 0c4bcfdecb1ac0967619ee7ff44871d93c08c909 upstream.
    
    In FOPEN_DIRECT_IO mode, fuse_file_write_iter() calls
    fuse_direct_write_iter(), which normally calls fuse_direct_io(), which then
    imports the write buffer with fuse_get_user_pages(), which uses
    iov_iter_get_pages() to grab references to userspace pages instead of
    actually copying memory.
    
    On the filesystem device side, these pages can then either be read to
    userspace (via fuse_dev_read()), or splice()d over into a pipe using
    fuse_dev_splice_read() as pipe buffers with &nosteal_pipe_buf_ops.
    
    This is wrong because after fuse_dev_do_read() unlocks the FUSE request,
    the userspace filesystem can mark the request as completed, causing write()
    to return. At that point, the userspace filesystem should no longer have
    access to the pipe buffer.
    
    Fix by copying pages coming from the user address space to new pipe
    buffers.
    
    Reported-by: Jann Horn <jannh@google.com>
    Fixes: c3021629a0d8 ("fuse: support splice() reading from fuse device")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f2c52a4baf5637f6bf5dd952b047dedc619efd56
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Fri Mar 11 11:49:12 2022 -0800

    ARM: Spectre-BHB: provide empty stub for non-config
    
    commit 68453767131a5deec1e8f9ac92a9042f929e585d upstream.
    
    When CONFIG_GENERIC_CPU_VULNERABILITIES is not set, references
    to spectre_v2_update_state() cause a build error, so provide an
    empty stub for that function when the Kconfig option is not set.
    
    Fixes this build error:
    
      arm-linux-gnueabi-ld: arch/arm/mm/proc-v7-bugs.o: in function `cpu_v7_bugs_init':
      proc-v7-bugs.c:(.text+0x52): undefined reference to `spectre_v2_update_state'
      arm-linux-gnueabi-ld: proc-v7-bugs.c:(.text+0x82): undefined reference to `spectre_v2_update_state'
    
    Fixes: b9baf5c8c5c3 ("ARM: Spectre-BHB workaround")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Reported-by: kernel test robot <lkp@intel.com>
    Cc: Russell King <rmk+kernel@armlinux.org.uk>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: patches@armlinux.org.uk
    Acked-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f1f5d089fcc60a13986d279e500bfe2f652d3340
Author: Mike Kravetz <mike.kravetz@oracle.com>
Date:   Fri Feb 25 19:11:26 2022 -0800

    selftests/memfd: clean up mapping in mfd_fail_write
    
    [ Upstream commit fda153c89af344d21df281009a9d046cf587ea0f ]
    
    Running the memfd script ./run_hugetlbfs_test.sh will often end in error
    as follows:
    
        memfd-hugetlb: CREATE
        memfd-hugetlb: BASIC
        memfd-hugetlb: SEAL-WRITE
        memfd-hugetlb: SEAL-FUTURE-WRITE
        memfd-hugetlb: SEAL-SHRINK
        fallocate(ALLOC) failed: No space left on device
        ./run_hugetlbfs_test.sh: line 60: 166855 Aborted                 (core dumped) ./memfd_test hugetlbfs
        opening: ./mnt/memfd
        fuse: DONE
    
    If no hugetlb pages have been preallocated, run_hugetlbfs_test.sh will
    allocate 'just enough' pages to run the test.  In the SEAL-FUTURE-WRITE
    test the mfd_fail_write routine maps the file, but does not unmap.  As a
    result, two hugetlb pages remain reserved for the mapping.  When the
    fallocate call in the SEAL-SHRINK test attempts allocate all hugetlb
    pages, it is short by the two reserved pages.
    
    Fix by making sure to unmap in mfd_fail_write.
    
    Link: https://lkml.kernel.org/r/20220219004340.56478-1-mike.kravetz@oracle.com
    Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
    Cc: Joel Fernandes <joel@joelfernandes.org>
    Cc: Shuah Khan <shuah@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 71013d071b505c0fec2d86b30fbd44ec7f515e5c
Author: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Date:   Fri Feb 25 19:11:08 2022 -0800

    selftest/vm: fix map_fixed_noreplace test failure
    
    [ Upstream commit f39c58008dee7ab5fc94c3f1995a21e886801df0 ]
    
    On the latest RHEL the test fails due to executable mapped at 256MB
    address
    
         # ./map_fixed_noreplace
        mmap() @ 0x10000000-0x10050000 p=0xffffffffffffffff result=File exists
        10000000-10010000 r-xp 00000000 fd:04 34905657                           /root/rpmbuild/BUILD/kernel-5.14.0-56.el9/linux-5.14.0-56.el9.ppc64le/tools/testing/selftests/vm/map_fixed_noreplace
        10010000-10020000 r--p 00000000 fd:04 34905657                           /root/rpmbuild/BUILD/kernel-5.14.0-56.el9/linux-5.14.0-56.el9.ppc64le/tools/testing/selftests/vm/map_fixed_noreplace
        10020000-10030000 rw-p 00010000 fd:04 34905657                           /root/rpmbuild/BUILD/kernel-5.14.0-56.el9/linux-5.14.0-56.el9.ppc64le/tools/testing/selftests/vm/map_fixed_noreplace
        10029b90000-10029bc0000 rw-p 00000000 00:00 0                            [heap]
        7fffbb510000-7fffbb750000 r-xp 00000000 fd:04 24534                      /usr/lib64/libc.so.6
        7fffbb750000-7fffbb760000 r--p 00230000 fd:04 24534                      /usr/lib64/libc.so.6
        7fffbb760000-7fffbb770000 rw-p 00240000 fd:04 24534                      /usr/lib64/libc.so.6
        7fffbb780000-7fffbb7a0000 r--p 00000000 00:00 0                          [vvar]
        7fffbb7a0000-7fffbb7b0000 r-xp 00000000 00:00 0                          [vdso]
        7fffbb7b0000-7fffbb800000 r-xp 00000000 fd:04 24514                      /usr/lib64/ld64.so.2
        7fffbb800000-7fffbb810000 r--p 00040000 fd:04 24514                      /usr/lib64/ld64.so.2
        7fffbb810000-7fffbb820000 rw-p 00050000 fd:04 24514                      /usr/lib64/ld64.so.2
        7fffd93f0000-7fffd9420000 rw-p 00000000 00:00 0                          [stack]
        Error: couldn't map the space we need for the test
    
    Fix this by finding a free address using mmap instead of hardcoding
    BASE_ADDRESS.
    
    Link: https://lkml.kernel.org/r/20220217083417.373823-1-aneesh.kumar@linux.ibm.com
    Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
    Cc: Michael Ellerman <mpe@ellerman.id.au>
    Cc: Jann Horn <jannh@google.com>
    Cc: Shuah Khan <shuah@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 8d276f10e84a10941d7815aa061891f5f82d4e5b
Author: Sven Schnelle <svens@linux.ibm.com>
Date:   Mon Feb 14 14:44:56 2022 +0100

    tracing: Ensure trace buffer is at least 4096 bytes large
    
    [ Upstream commit 7acf3a127bb7c65ff39099afd78960e77b2ca5de ]
    
    Booting the kernel with 'trace_buf_size=1' give a warning at
    boot during the ftrace selftests:
    
    [    0.892809] Running postponed tracer tests:
    [    0.892893] Testing tracer function:
    [    0.901899] Callback from call_rcu_tasks_trace() invoked.
    [    0.983829] Callback from call_rcu_tasks_rude() invoked.
    [    1.072003] .. bad ring buffer .. corrupted trace buffer ..
    [    1.091944] Callback from call_rcu_tasks() invoked.
    [    1.097695] PASSED
    [    1.097701] Testing dynamic ftrace: .. filter failed count=0 ..FAILED!
    [    1.353474] ------------[ cut here ]------------
    [    1.353478] WARNING: CPU: 0 PID: 1 at kernel/trace/trace.c:1951 run_tracer_selftest+0x13c/0x1b0
    
    Therefore enforce a minimum of 4096 bytes to make the selftest pass.
    
    Link: https://lkml.kernel.org/r/20220214134456.1751749-1-svens@linux.ibm.com
    
    Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ae7597b47dda2cd9294b8d26443ea7a5abd33880
Author: Niels Dossche <dossche.niels@gmail.com>
Date:   Wed Feb 23 14:19:56 2022 +0100

    ipv6: prevent a possible race condition with lifetimes
    
    [ Upstream commit 6c0d8833a605e195ae219b5042577ce52bf71fff ]
    
    valid_lft, prefered_lft and tstamp are always accessed under the lock
    "lock" in other places. Reading these without taking the lock may result
    in inconsistencies regarding the calculation of the valid and preferred
    variables since decisions are taken on these fields for those variables.
    
    Signed-off-by: Niels Dossche <dossche.niels@gmail.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Signed-off-by: Niels Dossche <niels.dossche@ugent.be>
    Link: https://lore.kernel.org/r/20220223131954.6570-1-niels.dossche@ugent.be
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8c0c50e9fcff7db3257721537d52575a1a636dc2
Author: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Date:   Tue Feb 22 01:18:17 2022 +0100

    Revert "xen-netback: Check for hotplug-status existence before watching"
    
    [ Upstream commit e8240addd0a3919e0fd7436416afe9aa6429c484 ]
    
    This reverts commit 2afeec08ab5c86ae21952151f726bfe184f6b23d.
    
    The reasoning in the commit was wrong - the code expected to setup the
    watch even if 'hotplug-status' didn't exist. In fact, it relied on the
    watch being fired the first time - to check if maybe 'hotplug-status' is
    already set to 'connected'. Not registering a watch for non-existing
    path (which is the case if hotplug script hasn't been executed yet),
    made the backend not waiting for the hotplug script to execute. This in
    turns, made the netfront think the interface is fully operational, while
    in fact it was not (the vif interface on xen-netback side might not be
    configured yet).
    
    This was a workaround for 'hotplug-status' erroneously being removed.
    But since that is reverted now, the workaround is not necessary either.
    
    More discussion at
    https://lore.kernel.org/xen-devel/afedd7cb-a291-e773-8b0d-4db9b291fa98@ipxe.org/T/#u
    
    Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
    Reviewed-by: Paul Durrant <paul@xen.org>
    Reviewed-by: Michael Brown <mbrown@fensystems.co.uk>
    Link: https://lore.kernel.org/r/20220222001817.2264967-2-marmarek@invisiblethingslab.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 625c04b523ca5a3a5fb8f4ec68977fee111beafe
Author: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Date:   Tue Feb 22 01:18:16 2022 +0100

    Revert "xen-netback: remove 'hotplug-status' once it has served its purpose"
    
    [ Upstream commit 0f4558ae91870692ce7f509c31c9d6ee721d8cdc ]
    
    This reverts commit 1f2565780e9b7218cf92c7630130e82dcc0fe9c2.
    
    The 'hotplug-status' node should not be removed as long as the vif
    device remains configured. Otherwise the xen-netback would wait for
    re-running the network script even if it was already called (in case of
    the frontent re-connecting). But also, it _should_ be removed when the
    vif device is destroyed (for example when unbinding the driver) -
    otherwise hotplug script would not configure the device whenever it
    re-appear.
    
    Moving removal of the 'hotplug-status' node was a workaround for nothing
    calling network script after xen-netback module is reloaded. But when
    vif interface is re-created (on xen-netback unbind/bind for example),
    the script should be called, regardless of who does that - currently
    this case is not handled by the toolstack, and requires manual
    script call. Keeping hotplug-status=connected to skip the call is wrong
    and leads to not configured interface.
    
    More discussion at
    https://lore.kernel.org/xen-devel/afedd7cb-a291-e773-8b0d-4db9b291fa98@ipxe.org/T/#u
    
    Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
    Reviewed-by: Paul Durrant <paul@xen.org>
    Link: https://lore.kernel.org/r/20220222001817.2264967-1-marmarek@invisiblethingslab.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a0e2768fb901093eff7d4cad1603659ae38a2449
Author: Shreeya Patel <shreeya.patel@collabora.com>
Date:   Thu Feb 17 01:56:55 2022 +0530

    gpio: Return EPROBE_DEFER if gc->to_irq is NULL
    
    [ Upstream commit ae42f9288846353982e2eab181fb41e7fd8bf60f ]
    
    We are racing the registering of .to_irq when probing the
    i2c driver. This results in random failure of touchscreen
    devices.
    
    Following explains the race condition better.
    
    [gpio driver] gpio driver registers gpio chip
    [gpio consumer] gpio is acquired
    [gpio consumer] gpiod_to_irq() fails with -ENXIO
    [gpio driver] gpio driver registers irqchip
    gpiod_to_irq works at this point, but -ENXIO is fatal
    
    We could see the following errors in dmesg logs when gc->to_irq is NULL
    
    [2.101857] i2c_hid i2c-FTS3528:00: HID over i2c has not been provided an Int IRQ
    [2.101953] i2c_hid: probe of i2c-FTS3528:00 failed with error -22
    
    To avoid this situation, defer probing until to_irq is registered.
    Returning -EPROBE_DEFER would be the first step towards avoiding
    the failure of devices due to the race in registration of .to_irq.
    Final solution to this issue would be to avoid using gc irq members
    until they are fully initialized.
    
    This issue has been reported many times in past and people have been
    using workarounds like changing the pinctrl_amd to built-in instead
    of loading it as a module or by adding a softdep for pinctrl_amd into
    the config file.
    
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=209413
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Shreeya Patel <shreeya.patel@collabora.com>
    Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 65d4e9d130fb3c05b3fad61f35572966083fefdb
Author: Vikash Chandola <vikash.chandola@linux.intel.com>
Date:   Tue Feb 22 13:12:53 2022 +0000

    hwmon: (pmbus) Clear pmbus fault/warning bits after read
    
    [ Upstream commit 35f165f08950a876f1b95a61d79c93678fba2fd6 ]
    
    Almost all fault/warning bits in pmbus status registers remain set even
    after fault/warning condition are removed. As per pmbus specification
    these faults must be cleared by user.
    Modify hwmon behavior to clear fault/warning bit after fetching data if
    fault/warning bit was set. This allows to get fresh data in next read.
    
    Signed-off-by: Vikash Chandola <vikash.chandola@linux.intel.com>
    Link: https://lore.kernel.org/r/20220222131253.2426834-1-vikash.chandola@linux.intel.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d15c9f6e3335002fea1c33bc8f71a705fa96976c
Author: suresh kumar <suresh2514@gmail.com>
Date:   Thu Feb 17 07:25:18 2022 +0530

    net-sysfs: add check for netdevice being present to speed_show
    
    [ Upstream commit 4224cfd7fb6523f7a9d1c8bb91bb5df1e38eb624 ]
    
    When bringing down the netdevice or system shutdown, a panic can be
    triggered while accessing the sysfs path because the device is already
    removed.
    
        [  755.549084] mlx5_core 0000:12:00.1: Shutdown was called
        [  756.404455] mlx5_core 0000:12:00.0: Shutdown was called
        ...
        [  757.937260] BUG: unable to handle kernel NULL pointer dereference at           (null)
        [  758.031397] IP: [<ffffffff8ee11acb>] dma_pool_alloc+0x1ab/0x280
    
        crash> bt
        ...
        PID: 12649  TASK: ffff8924108f2100  CPU: 1   COMMAND: "amsd"
        ...
         #9 [ffff89240e1a38b0] page_fault at ffffffff8f38c778
            [exception RIP: dma_pool_alloc+0x1ab]
            RIP: ffffffff8ee11acb  RSP: ffff89240e1a3968  RFLAGS: 00010046
            RAX: 0000000000000246  RBX: ffff89243d874100  RCX: 0000000000001000
            RDX: 0000000000000000  RSI: 0000000000000246  RDI: ffff89243d874090
            RBP: ffff89240e1a39c0   R8: 000000000001f080   R9: ffff8905ffc03c00
            R10: ffffffffc04680d4  R11: ffffffff8edde9fd  R12: 00000000000080d0
            R13: ffff89243d874090  R14: ffff89243d874080  R15: 0000000000000000
            ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
        #10 [ffff89240e1a39c8] mlx5_alloc_cmd_msg at ffffffffc04680f3 [mlx5_core]
        #11 [ffff89240e1a3a18] cmd_exec at ffffffffc046ad62 [mlx5_core]
        #12 [ffff89240e1a3ab8] mlx5_cmd_exec at ffffffffc046b4fb [mlx5_core]
        #13 [ffff89240e1a3ae8] mlx5_core_access_reg at ffffffffc0475434 [mlx5_core]
        #14 [ffff89240e1a3b40] mlx5e_get_fec_caps at ffffffffc04a7348 [mlx5_core]
        #15 [ffff89240e1a3bb0] get_fec_supported_advertised at ffffffffc04992bf [mlx5_core]
        #16 [ffff89240e1a3c08] mlx5e_get_link_ksettings at ffffffffc049ab36 [mlx5_core]
        #17 [ffff89240e1a3ce8] __ethtool_get_link_ksettings at ffffffff8f25db46
        #18 [ffff89240e1a3d48] speed_show at ffffffff8f277208
        #19 [ffff89240e1a3dd8] dev_attr_show at ffffffff8f0b70e3
        #20 [ffff89240e1a3df8] sysfs_kf_seq_show at ffffffff8eedbedf
        #21 [ffff89240e1a3e18] kernfs_seq_show at ffffffff8eeda596
        #22 [ffff89240e1a3e28] seq_read at ffffffff8ee76d10
        #23 [ffff89240e1a3e98] kernfs_fop_read at ffffffff8eedaef5
        #24 [ffff89240e1a3ed8] vfs_read at ffffffff8ee4e3ff
        #25 [ffff89240e1a3f08] sys_read at ffffffff8ee4f27f
        #26 [ffff89240e1a3f50] system_call_fastpath at ffffffff8f395f92
    
        crash> net_device.state ffff89443b0c0000
          state = 0x5  (__LINK_STATE_START| __LINK_STATE_NOCARRIER)
    
    To prevent this scenario, we also make sure that the netdevice is present.
    
    Signed-off-by: suresh kumar <suresh2514@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8c023c303978ca1aefe3994630af9b9fd76f18aa
Author: Jon Lin <jon.lin@rock-chips.com>
Date:   Wed Feb 16 09:40:24 2022 +0800

    spi: rockchip: terminate dma transmission when slave abort
    
    [ Upstream commit 80808768e41324d2e23de89972b5406c1020e6e4 ]
    
    After slave abort, all DMA should be stopped, or it will affect the
    next transmission and maybe abort again.
    
    Signed-off-by: Jon Lin <jon.lin@rock-chips.com>
    Link: https://lore.kernel.org/r/20220216014028.8123-3-jon.lin@rock-chips.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 889254f98e99f824abc76c8fcac5652e140255c3
Author: Jon Lin <jon.lin@rock-chips.com>
Date:   Wed Feb 16 09:40:23 2022 +0800

    spi: rockchip: Fix error in getting num-cs property
    
    [ Upstream commit 9382df0a98aad5bbcd4d634790305a1d786ad224 ]
    
    Get num-cs u32 from dts of_node property rather than u16.
    
    Signed-off-by: Jon Lin <jon.lin@rock-chips.com>
    Link: https://lore.kernel.org/r/20220216014028.8123-2-jon.lin@rock-chips.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4fb9be675be8360bede6fb8f0cad7948393fbef8
Author: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Date:   Wed Feb 9 12:33:24 2022 +0530

    selftests/bpf: Add test for bpf_timer overwriting crash
    
    [ Upstream commit a7e75016a0753c24d6c995bc02501ae35368e333 ]
    
    Add a test that validates that timer value is not overwritten when doing
    a copy_map_value call in the kernel. Without the prior fix, this test
    triggers a crash.
    
    Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Link: https://lore.kernel.org/bpf/20220209070324.1093182-3-memxor@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dc1c2b47b539b17fd7144513d6e23f00477dcb11
Author: Jeremy Linton <jeremy.linton@arm.com>
Date:   Wed Mar 9 22:55:35 2022 -0600

    net: bcmgenet: Don't claim WOL when its not available
    
    [ Upstream commit 00b022f8f876a3a036b0df7f971001bef6398605 ]
    
    Some of the bcmgenet platforms don't correctly support WOL, yet
    ethtool returns:
    
    "Supports Wake-on: gsf"
    
    which is false.
    
    Ideally if there isn't a wol_irq, or there is something else that
    keeps the device from being able to wakeup it should display:
    
    "Supports Wake-on: d"
    
    This patch checks whether the device can wakup, before using the
    hard-coded supported flags. This corrects the ethtool reporting, as
    well as the WOL configuration because ethtool verifies that the mode
    is supported before attempting it.
    
    Fixes: c51de7f3976b ("net: bcmgenet: add Wake-on-LAN support code")
    Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
    Tested-by: Peter Robinson <pbrobinson@gmail.com>
    Acked-by: Florian Fainelli <f.fainelli@gmail.com>
    Link: https://lore.kernel.org/r/20220310045535.224450-1-jeremy.linton@arm.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b7e4d9ba2ddb78801488b4c623875b81fb46b545
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Mar 9 16:11:45 2022 -0800

    sctp: fix kernel-infoleak for SCTP sockets
    
    [ Upstream commit 633593a808980f82d251d0ca89730d8bb8b0220c ]
    
    syzbot reported a kernel infoleak [1] of 4 bytes.
    
    After analysis, it turned out r->idiag_expires is not initialized
    if inet_sctp_diag_fill() calls inet_diag_msg_common_fill()
    
    Make sure to clear idiag_timer/idiag_retrans/idiag_expires
    and let inet_diag_msg_sctpasoc_fill() fill them again if needed.
    
    [1]
    
    BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline]
    BUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:154 [inline]
    BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668
     instrument_copy_to_user include/linux/instrumented.h:121 [inline]
     copyout lib/iov_iter.c:154 [inline]
     _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668
     copy_to_iter include/linux/uio.h:162 [inline]
     simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519
     __skb_datagram_iter+0x2d5/0x11b0 net/core/datagram.c:425
     skb_copy_datagram_iter+0xdc/0x270 net/core/datagram.c:533
     skb_copy_datagram_msg include/linux/skbuff.h:3696 [inline]
     netlink_recvmsg+0x669/0x1c80 net/netlink/af_netlink.c:1977
     sock_recvmsg_nosec net/socket.c:948 [inline]
     sock_recvmsg net/socket.c:966 [inline]
     __sys_recvfrom+0x795/0xa10 net/socket.c:2097
     __do_sys_recvfrom net/socket.c:2115 [inline]
     __se_sys_recvfrom net/socket.c:2111 [inline]
     __x64_sys_recvfrom+0x19d/0x210 net/socket.c:2111
     do_syscall_x64 arch/x86/entry/common.c:51 [inline]
     do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    Uninit was created at:
     slab_post_alloc_hook mm/slab.h:737 [inline]
     slab_alloc_node mm/slub.c:3247 [inline]
     __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4975
     kmalloc_reserve net/core/skbuff.c:354 [inline]
     __alloc_skb+0x545/0xf90 net/core/skbuff.c:426
     alloc_skb include/linux/skbuff.h:1158 [inline]
     netlink_dump+0x3e5/0x16c0 net/netlink/af_netlink.c:2248
     __netlink_dump_start+0xcf8/0xe90 net/netlink/af_netlink.c:2373
     netlink_dump_start include/linux/netlink.h:254 [inline]
     inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1341
     sock_diag_rcv_msg+0x24a/0x620
     netlink_rcv_skb+0x40c/0x7e0 net/netlink/af_netlink.c:2494
     sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:277
     netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
     netlink_unicast+0x1093/0x1360 net/netlink/af_netlink.c:1343
     netlink_sendmsg+0x14d9/0x1720 net/netlink/af_netlink.c:1919
     sock_sendmsg_nosec net/socket.c:705 [inline]
     sock_sendmsg net/socket.c:725 [inline]
     sock_write_iter+0x594/0x690 net/socket.c:1061
     do_iter_readv_writev+0xa7f/0xc70
     do_iter_write+0x52c/0x1500 fs/read_write.c:851
     vfs_writev fs/read_write.c:924 [inline]
     do_writev+0x645/0xe00 fs/read_write.c:967
     __do_sys_writev fs/read_write.c:1040 [inline]
     __se_sys_writev fs/read_write.c:1037 [inline]
     __x64_sys_writev+0xe5/0x120 fs/read_write.c:1037
     do_syscall_x64 arch/x86/entry/common.c:51 [inline]
     do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    Bytes 68-71 of 2508 are uninitialized
    Memory access of size 2508 starts at ffff888114f9b000
    Data copied to user address 00007f7fe09ff2e0
    
    CPU: 1 PID: 3478 Comm: syz-executor306 Not tainted 5.17.0-rc4-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    
    Fixes: 8f840e47f190 ("sctp: add the sctp_diag.c file")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Cc: Vlad Yasevich <vyasevich@gmail.com>
    Cc: Neil Horman <nhorman@tuxdriver.com>
    Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Reviewed-by: Xin Long <lucien.xin@gmail.com>
    Link: https://lore.kernel.org/r/20220310001145.297371-1-eric.dumazet@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3cf533f1200195fcc3bc4d7b4cfc76a8724c506c
Author: Clément Léger <clement.leger@bootlin.com>
Date:   Wed Mar 9 15:22:28 2022 +0100

    net: phy: DP83822: clear MISR2 register to disable interrupts
    
    [ Upstream commit 37c9d66c95564c85a001d8a035354f0220a1e1c3 ]
    
    MISR1 was cleared twice but the original author intention was probably
    to clear MISR1 & MISR2 to completely disable interrupts. Fix it to
    clear MISR2.
    
    Fixes: 87461f7a58ab ("net: phy: DP83822 initial driver submission")
    Signed-off-by: Clément Léger <clement.leger@bootlin.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Link: https://lore.kernel.org/r/20220309142228.761153-1-clement.leger@bootlin.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 21044e679ed535345042d2023f7df0ca8e897e2a
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Thu Mar 10 01:53:13 2022 +0000

    gianfar: ethtool: Fix refcount leak in gfar_get_ts_info
    
    [ Upstream commit 2ac5b58e645c66932438bb021cb5b52097ce70b0 ]
    
    The of_find_compatible_node() function returns a node pointer with
    refcount incremented, We should use of_node_put() on it when done
    Add the missing of_node_put() to release the refcount.
    
    Fixes: 7349a74ea75c ("net: ethernet: gianfar_ethtool: get phc index through drvdata")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
    Reviewed-by: Claudiu Manoil <claudiu.manoil@nxp.com>
    Link: https://lore.kernel.org/r/20220310015313.14938-1-linmq006@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3a4cd1c51eea2e24d5ca5a312509138629c06171
Author: Mark Featherston <mark@embeddedTS.com>
Date:   Wed Mar 9 17:16:16 2022 -0800

    gpio: ts4900: Do not set DAT and OE together
    
    [ Upstream commit 03fe003547975680fdb9ff5ab0e41cb68276c4f2 ]
    
    This works around an issue with the hardware where both OE and
    DAT are exposed in the same register. If both are updated
    simultaneously, the harware makes no guarantees that OE or DAT
    will actually change in any given order and may result in a
    glitch of a few ns on a GPIO pin when changing direction and value
    in a single write.
    
    Setting direction to input now only affects OE bit. Setting
    direction to output updates DAT first, then OE.
    
    Fixes: 9c6686322d74 ("gpio: add Technologic I2C-FPGA gpio support")
    Signed-off-by: Mark Featherston <mark@embeddedTS.com>
    Signed-off-by: Kris Bahnsen <kris@embeddedTS.com>
    Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7702e7e9e396bbd1dfb1b8a5e04a9d6134991aa8
Author: Guillaume Nault <gnault@redhat.com>
Date:   Tue Mar 8 23:15:00 2022 +0100

    selftests: pmtu.sh: Kill tcpdump processes launched by subshell.
    
    [ Upstream commit 18dfc667550fe9c032a6dcc3402b50e691e18029 ]
    
    The cleanup() function takes care of killing processes launched by the
    test functions. It relies on variables like ${tcpdump_pids} to get the
    relevant PIDs. But tests are run in their own subshell, so updated
    *_pids values are invisible to other shells. Therefore cleanup() never
    sees any process to kill:
    
    $ ./tools/testing/selftests/net/pmtu.sh -t pmtu_ipv4_exception
    TEST: ipv4: PMTU exceptions                                         [ OK ]
    TEST: ipv4: PMTU exceptions - nexthop objects                       [ OK ]
    
    $ pgrep -af tcpdump
    6084 tcpdump -s 0 -i veth_A-R1 -w pmtu_ipv4_exception_veth_A-R1.pcap
    6085 tcpdump -s 0 -i veth_R1-A -w pmtu_ipv4_exception_veth_R1-A.pcap
    6086 tcpdump -s 0 -i veth_R1-B -w pmtu_ipv4_exception_veth_R1-B.pcap
    6087 tcpdump -s 0 -i veth_B-R1 -w pmtu_ipv4_exception_veth_B-R1.pcap
    6088 tcpdump -s 0 -i veth_A-R2 -w pmtu_ipv4_exception_veth_A-R2.pcap
    6089 tcpdump -s 0 -i veth_R2-A -w pmtu_ipv4_exception_veth_R2-A.pcap
    6090 tcpdump -s 0 -i veth_R2-B -w pmtu_ipv4_exception_veth_R2-B.pcap
    6091 tcpdump -s 0 -i veth_B-R2 -w pmtu_ipv4_exception_veth_B-R2.pcap
    6228 tcpdump -s 0 -i veth_A-R1 -w pmtu_ipv4_exception_veth_A-R1.pcap
    6229 tcpdump -s 0 -i veth_R1-A -w pmtu_ipv4_exception_veth_R1-A.pcap
    6230 tcpdump -s 0 -i veth_R1-B -w pmtu_ipv4_exception_veth_R1-B.pcap
    6231 tcpdump -s 0 -i veth_B-R1 -w pmtu_ipv4_exception_veth_B-R1.pcap
    6232 tcpdump -s 0 -i veth_A-R2 -w pmtu_ipv4_exception_veth_A-R2.pcap
    6233 tcpdump -s 0 -i veth_R2-A -w pmtu_ipv4_exception_veth_R2-A.pcap
    6234 tcpdump -s 0 -i veth_R2-B -w pmtu_ipv4_exception_veth_R2-B.pcap
    6235 tcpdump -s 0 -i veth_B-R2 -w pmtu_ipv4_exception_veth_B-R2.pcap
    
    Fix this by running cleanup() in the context of the test subshell.
    Now that each test cleans the environment after completion, there's no
    need for calling cleanup() again when the next test starts. So let's
    drop it from the setup() function. This is okay because cleanup() is
    also called when pmtu.sh starts, so even the first test starts in a
    clean environment.
    
    Also, use tcpdump's immediate mode. Otherwise it might not have time to
    process buffered packets, resulting in missing packets or even empty
    pcap files for short tests.
    
    Note: PAUSE_ON_FAIL is still evaluated before cleanup(), so one can
    still inspect the test environment upon failure when using -p.
    
    Fixes: a92a0a7b8e7c ("selftests: pmtu: Simplify cleanup and namespace names")
    Signed-off-by: Guillaume Nault <gnault@redhat.com>
    Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2b1c85f56512d49e43bc53741fce2f508cd90029
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Tue Mar 8 21:50:07 2022 +0300

    NFC: port100: fix use-after-free in port100_send_complete
    
    [ Upstream commit f80cfe2f26581f188429c12bd937eb905ad3ac7b ]
    
    Syzbot reported UAF in port100_send_complete(). The root case is in
    missing usb_kill_urb() calls on error handling path of ->probe function.
    
    port100_send_complete() accesses devm allocated memory which will be
    freed on probe failure. We should kill this urbs before returning an
    error from probe function to prevent reported use-after-free
    
    Fail log:
    
    BUG: KASAN: use-after-free in port100_send_complete+0x16e/0x1a0 drivers/nfc/port100.c:935
    Read of size 1 at addr ffff88801bb59540 by task ksoftirqd/2/26
    ...
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
     print_address_description.constprop.0.cold+0x8d/0x303 mm/kasan/report.c:255
     __kasan_report mm/kasan/report.c:442 [inline]
     kasan_report.cold+0x83/0xdf mm/kasan/report.c:459
     port100_send_complete+0x16e/0x1a0 drivers/nfc/port100.c:935
     __usb_hcd_giveback_urb+0x2b0/0x5c0 drivers/usb/core/hcd.c:1670
    
    ...
    
    Allocated by task 1255:
     kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
     kasan_set_track mm/kasan/common.c:45 [inline]
     set_alloc_info mm/kasan/common.c:436 [inline]
     ____kasan_kmalloc mm/kasan/common.c:515 [inline]
     ____kasan_kmalloc mm/kasan/common.c:474 [inline]
     __kasan_kmalloc+0xa6/0xd0 mm/kasan/common.c:524
     alloc_dr drivers/base/devres.c:116 [inline]
     devm_kmalloc+0x96/0x1d0 drivers/base/devres.c:823
     devm_kzalloc include/linux/device.h:209 [inline]
     port100_probe+0x8a/0x1320 drivers/nfc/port100.c:1502
    
    Freed by task 1255:
     kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
     kasan_set_track+0x21/0x30 mm/kasan/common.c:45
     kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370
     ____kasan_slab_free mm/kasan/common.c:366 [inline]
     ____kasan_slab_free+0xff/0x140 mm/kasan/common.c:328
     kasan_slab_free include/linux/kasan.h:236 [inline]
     __cache_free mm/slab.c:3437 [inline]
     kfree+0xf8/0x2b0 mm/slab.c:3794
     release_nodes+0x112/0x1a0 drivers/base/devres.c:501
     devres_release_all+0x114/0x190 drivers/base/devres.c:530
     really_probe+0x626/0xcc0 drivers/base/dd.c:670
    
    Reported-and-tested-by: syzbot+16bcb127fb73baeecb14@syzkaller.appspotmail.com
    Fixes: 0347a6ab300a ("NFC: port100: Commands mechanism implementation")
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
    Link: https://lore.kernel.org/r/20220308185007.6987-1-paskripkin@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1fdabf2cf42b401c2525dc0420bc9bbe45a7e1f2
Author: Roi Dayan <roid@nvidia.com>
Date:   Wed Feb 16 13:56:57 2022 +0200

    net/mlx5e: Lag, Only handle events from highest priority multipath entry
    
    [ Upstream commit ad11c4f1d8fd1f03639460e425a36f7fd0ea83f5 ]
    
    There could be multiple multipath entries but changing the port affinity
    for each one doesn't make much sense and there should be a default one.
    So only track the entry with lowest priority value.
    The commit doesn't affect existing users with a single entry.
    
    Fixes: 544fe7c2e654 ("net/mlx5e: Activate HW multipath and handle port affinity based on FIB events")
    Signed-off-by: Roi Dayan <roid@nvidia.com>
    Reviewed-by: Maor Dickman <maord@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f3331bc17449f15832c31823f27573f4c0e13e5f
Author: Moshe Shemesh <moshe@nvidia.com>
Date:   Fri Feb 4 11:47:44 2022 +0200

    net/mlx5: Fix a race on command flush flow
    
    [ Upstream commit 063bd355595428750803d8736a9bb7c8db67d42d ]
    
    Fix a refcount use after free warning due to a race on command entry.
    Such race occurs when one of the commands releases its last refcount and
    frees its index and entry while another process running command flush
    flow takes refcount to this command entry. The process which handles
    commands flush may see this command as needed to be flushed if the other
    process released its refcount but didn't release the index yet. Fix it
    by adding the needed spin lock.
    
    It fixes the following warning trace:
    
    refcount_t: addition on 0; use-after-free.
    WARNING: CPU: 11 PID: 540311 at lib/refcount.c:25 refcount_warn_saturate+0x80/0xe0
    ...
    RIP: 0010:refcount_warn_saturate+0x80/0xe0
    ...
    Call Trace:
     <TASK>
     mlx5_cmd_trigger_completions+0x293/0x340 [mlx5_core]
     mlx5_cmd_flush+0x3a/0xf0 [mlx5_core]
     enter_error_state+0x44/0x80 [mlx5_core]
     mlx5_fw_fatal_reporter_err_work+0x37/0xe0 [mlx5_core]
     process_one_work+0x1be/0x390
     worker_thread+0x4d/0x3d0
     ? rescuer_thread+0x350/0x350
     kthread+0x141/0x160
     ? set_kthread_struct+0x40/0x40
     ret_from_fork+0x1f/0x30
     </TASK>
    
    Fixes: 50b2412b7e78 ("net/mlx5: Avoid possible free of command entry while timeout comp handler")
    Signed-off-by: Moshe Shemesh <moshe@nvidia.com>
    Reviewed-by: Eran Ben Elisha <eranbe@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5f1340963b11bb03a5b2fc5b9f577eeeabb0d71c
Author: Mohammad Kabat <mohammadkab@nvidia.com>
Date:   Thu Mar 25 14:38:55 2021 +0200

    net/mlx5: Fix size field in bufferx_reg struct
    
    [ Upstream commit ac77998b7ac3044f0509b097da9637184598980d ]
    
    According to HW spec the field "size" should be 16 bits
    in bufferx register.
    
    Fixes: e281682bf294 ("net/mlx5_core: HW data structs/types definitions cleanup")
    Signed-off-by: Mohammad Kabat <mohammadkab@nvidia.com>
    Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e2201ef32f933944ee02e59205adb566bafcdf91
Author: Duoming Zhou <duoming@zju.edu.cn>
Date:   Tue Mar 8 16:12:23 2022 +0800

    ax25: Fix NULL pointer dereference in ax25_kill_by_device
    
    [ Upstream commit 71171ac8eb34ce7fe6b3267dce27c313ab3cb3ac ]
    
    When two ax25 devices attempted to establish connection, the requester use ax25_create(),
    ax25_bind() and ax25_connect() to initiate connection. The receiver use ax25_rcv() to
    accept connection and use ax25_create_cb() in ax25_rcv() to create ax25_cb, but the
    ax25_cb->sk is NULL. When the receiver is detaching, a NULL pointer dereference bug
    caused by sock_hold(sk) in ax25_kill_by_device() will happen. The corresponding
    fail log is shown below:
    
    ===============================================================
    BUG: KASAN: null-ptr-deref in ax25_device_event+0xfd/0x290
    Call Trace:
    ...
    ax25_device_event+0xfd/0x290
    raw_notifier_call_chain+0x5e/0x70
    dev_close_many+0x174/0x220
    unregister_netdevice_many+0x1f7/0xa60
    unregister_netdevice_queue+0x12f/0x170
    unregister_netdev+0x13/0x20
    mkiss_close+0xcd/0x140
    tty_ldisc_release+0xc0/0x220
    tty_release_struct+0x17/0xa0
    tty_release+0x62d/0x670
    ...
    
    This patch add condition check in ax25_kill_by_device(). If s->sk is
    NULL, it will goto if branch to kill device.
    
    Fixes: 4e0f718daf97 ("ax25: improve the incomplete fix to avoid UAF and NPD bugs")
    Reported-by: Thomas Osterried <thomas@osterried.de>
    Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cc7679079c7e9f6e555f17d6600cee4c00398c04
Author: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Date:   Tue Mar 8 14:57:39 2022 +0800

    net: ethernet: lpc_eth: Handle error for clk_enable
    
    [ Upstream commit 2169b79258c8be803d2595d6456b1e77129fe154 ]
    
    As the potential failure of the clk_enable(),
    it should be better to check it and return error
    if fails.
    
    Fixes: b7370112f519 ("lpc32xx: Added ethernet driver")
    Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b3e4fcb53921f397cebe2acc833e1372e1e40923
Author: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Date:   Tue Mar 8 14:40:07 2022 +0800

    net: ethernet: ti: cpts: Handle error for clk_enable
    
    [ Upstream commit 6babfc6e6fab068018c36e8f6605184b8c0b349d ]
    
    As the potential failure of the clk_enable(),
    it should be better to check it and return error
    if fails.
    
    Fixes: 8a2c9a5ab4b9 ("net: ethernet: ti: cpts: rework initialization/deinitialization")
    Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5e42f90d7220f1956767be16c620c28ffaa55369
Author: Tung Nguyen <tung.q.nguyen@dektech.com.au>
Date:   Tue Mar 8 02:11:59 2022 +0000

    tipc: fix incorrect order of state message data sanity check
    
    [ Upstream commit c79fcc27be90b308b3fa90811aefafdd4078668c ]
    
    When receiving a state message, function tipc_link_validate_msg()
    is called to validate its header portion. Then, its data portion
    is validated before it can be accessed correctly. However, current
    data sanity  check is done after the message header is accessed to
    update some link variables.
    
    This commit fixes this issue by moving the data sanity check to
    the beginning of state message handling and right after the header
    sanity check.
    
    Fixes: 9aa422ad3266 ("tipc: improve size validations for received domain records")
    Acked-by: Jon Maloy <jmaloy@redhat.com>
    Signed-off-by: Tung Nguyen <tung.q.nguyen@dektech.com.au>
    Link: https://lore.kernel.org/r/20220308021200.9245-1-tung.q.nguyen@dektech.com.au
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 979b418b96e35f07136f77962ccfaa54cf3e30e1
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Tue Mar 8 02:47:49 2022 +0000

    ethernet: Fix error handling in xemaclite_of_probe
    
    [ Upstream commit b19ab4b38b06aae12442b2de95ccf58b5dc53584 ]
    
    This node pointer is returned by of_parse_phandle() with refcount
    incremented in this function. Calling of_node_put() to avoid the
    refcount leak. As the remove function do.
    
    Fixes: 5cdaaa12866e ("net: emaclite: adding MDIO and phy lib support")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Link: https://lore.kernel.org/r/20220308024751.2320-1-linmq006@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 506d61bc1b50f2f5166d1bf7c2958e243e722c92
Author: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
Date:   Tue Feb 22 11:43:04 2022 +0000

    ice: Fix curr_link_speed advertised speed
    
    [ Upstream commit ad35ffa252af67d4cc7c744b9377a2b577748e3f ]
    
    Change curr_link_speed advertised speed, due to
    link_info.link_speed is not equal phy.curr_user_speed_req.
    Without this patch it is impossible to set advertised
    speed to same as link_speed.
    
    Testing Hints: Try to set advertised speed
    to 25G only with 25G default link (use ethtool -s 0x80000000)
    
    Fixes: 48cb27f2fd18 ("ice: Implement handlers for ethtool PHY/link operations")
    Signed-off-by: Grzegorz Siwik <grzegorz.siwik@intel.com>
    Signed-off-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
    Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 852a9e97d396101b8bc224e876cdaaa2bbab4ce4
Author: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Date:   Thu Mar 25 15:35:09 2021 -0700

    ice: Rename a couple of variables
    
    [ Upstream commit 0be39bb4c7c8c358f7baf10296db2426f7cf814c ]
    
    In ice_set_link_ksettings, change 'abilities' to 'phy_caps' and 'p' to
    'pi'. This is more consistent with similar usages elsewhere in the
    driver.
    
    Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
    Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b21ffd5469a9051227aef2ddfac18c14259576fb
Author: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Date:   Thu Mar 25 15:35:08 2021 -0700

    ice: Remove unnecessary checker loop
    
    [ Upstream commit fd3dc1655eda6173566d56eaeb54f27ab4c9e33c ]
    
    The loop checking for PF VSI doesn't make any sense. The VSI type
    backing the netdev passed to ice_set_link_ksettings will always be
    of type ICE_PF_VSI. Remove it.
    
    Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
    Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 875967aff5a654e78539339899c54a76c212ef5d
Author: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Date:   Thu Mar 25 15:35:06 2021 -0700

    ice: Align macro names to the specification
    
    [ Upstream commit d6730a871e68f10c786cdee59aebd6f92d49d249 ]
    
    For get PHY abilities AQ, the specification defines "report modes"
    as "with media", "without media" and "active configuration". For
    clarity, rename macros to align with the specification.
    
    Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
    Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8c613f7cd3ca0cf056c6232a3e48f1eeba5ce62e
Author: Jacob Keller <jacob.e.keller@intel.com>
Date:   Wed Feb 16 16:51:36 2022 -0800

    ice: stop disabling VFs due to PF error responses
    
    [ Upstream commit 79498d5af8e458102242d1667cf44df1f1564e63 ]
    
    The ice_vc_send_msg_to_vf function has logic to detect "failure"
    responses being sent to a VF. If a VF is sent more than
    ICE_DFLT_NUM_INVAL_MSGS_ALLOWED then the VF is marked as disabled.
    Almost identical logic also existed in the i40e driver.
    
    This logic was added to the ice driver in commit 1071a8358a28 ("ice:
    Implement virtchnl commands for AVF support") which itself copied from
    the i40e implementation in commit 5c3c48ac6bf5 ("i40e: implement virtual
    device interface").
    
    Neither commit provides a proper explanation or justification of the
    check. In fact, later commits to i40e changed the logic to allow
    bypassing the check in some specific instances.
    
    The "logic" for this seems to be that error responses somehow indicate a
    malicious VF. This is not really true. The PF might be sending an error
    for any number of reasons such as lack of resources, etc.
    
    Additionally, this causes the PF to log an info message for every failed
    VF response which may confuse users, and can spam the kernel log.
    
    This behavior is not documented as part of any requirement for our
    products and other operating system drivers such as the FreeBSD
    implementation of our drivers do not include this type of check.
    
    In fact, the change from dev_err to dev_info in i40e commit 18b7af57d9c1
    ("i40e: Lower some message levels") explains that these messages
    typically don't actually indicate a real issue. It is quite likely that
    a user who hits this in practice will be very confused as the VF will be
    disabled without an obvious way to recover.
    
    We already have robust malicious driver detection logic using actual
    hardware detection mechanisms that detect and prevent invalid device
    usage. Remove the logic since its not a documented requirement and the
    behavior is not intuitive.
    
    Fixes: 1071a8358a28 ("ice: Implement virtchnl commands for AVF support")
    Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
    Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d9ee2cbff2e9fb71ca2deac43997adaab4df15cf
Author: Jacob Keller <jacob.e.keller@intel.com>
Date:   Wed Feb 16 16:51:35 2022 -0800

    i40e: stop disabling VFs due to PF error responses
    
    [ Upstream commit 5710ab79166504013f7c0ae6a57e7d2fd26e5c43 ]
    
    The i40e_vc_send_msg_to_vf_ex (and its wrapper i40e_vc_send_msg_to_vf)
    function has logic to detect "failure" responses sent to the VF. If a VF
    is sent more than I40E_DEFAULT_NUM_INVALID_MSGS_ALLOWED, then the VF is
    marked as disabled. In either case, a dev_info message is printed
    stating that a VF opcode failed.
    
    This logic originates from the early implementation of VF support in
    commit 5c3c48ac6bf5 ("i40e: implement virtual device interface").
    
    That commit did not go far enough. The "logic" for this behavior seems
    to be that error responses somehow indicate a malicious VF. This is not
    really true. The PF might be sending an error for any number of reasons
    such as lacking resources, an unsupported operation, etc. This does not
    indicate a malicious VF. We already have a separate robust malicious VF
    detection which relies on hardware logic to detect and prevent a variety
    of behaviors.
    
    There is no justification for this behavior in the original
    implementation. In fact, a later commit 18b7af57d9c1 ("i40e: Lower some
    message levels") reduced the opcode failure message from a dev_err to a
    dev_info. In addition, recent commit 01cbf50877e6 ("i40e: Fix to not
    show opcode msg on unsuccessful VF MAC change") changed the logic to
    allow quieting it for expected failures.
    
    That commit prevented this logic from kicking in for specific
    circumstances. This change did not go far enough. The behavior is not
    documented nor is it part of any requirement for our products. Other
    operating systems such as the FreeBSD implementation of our driver do
    not include this logic.
    
    It is clear this check does not make sense, and causes problems which
    led to ugly workarounds.
    
    Fix this by just removing the entire logic and the need for the
    i40e_vc_send_msg_to_vf_ex function.
    
    Fixes: 01cbf50877e6 ("i40e: Fix to not show opcode msg on unsuccessful VF MAC change")
    Fixes: 5c3c48ac6bf5 ("i40e: implement virtual device interface")
    Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
    Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 965070a2b71d8debcfd60ce73a3ce42aa90da8ca
Author: Joel Stanley <joel@jms.id.au>
Date:   Tue Mar 8 10:36:31 2022 +1030

    ARM: dts: aspeed: Fix AST2600 quad spi group
    
    [ Upstream commit 2f6edb6bcb2f3f41d876e0eba2ba97f87a0296ea ]
    
    Requesting quad mode for the FMC resulted in an error:
    
      &fmc {
             status = "okay";
     +       pinctrl-names = "default";
     +       pinctrl-0 = <&pinctrl_fwqspi_default>'
    
    [    0.742963] aspeed-g6-pinctrl 1e6e2000.syscon:pinctrl: invalid function FWQSPID in map table
    
    
    This is because the quad mode pins are a group of pins, not a function.
    
    After applying this patch we can request the pins and the QSPI data
    lines are muxed:
    
     # cat /sys/kernel/debug/pinctrl/1e6e2000.syscon\:pinctrl-aspeed-g6-pinctrl/pinmux-pins |grep 1e620000.spi
     pin 196 (AE12): device 1e620000.spi function FWSPID group FWQSPID
     pin 197 (AF12): device 1e620000.spi function FWSPID group FWQSPID
     pin 240 (Y1): device 1e620000.spi function FWSPID group FWQSPID
     pin 241 (Y2): device 1e620000.spi function FWSPID group FWQSPID
     pin 242 (Y3): device 1e620000.spi function FWSPID group FWQSPID
     pin 243 (Y4): device 1e620000.spi function FWSPID group FWQSPID
    
    Fixes: f510f04c8c83 ("ARM: dts: aspeed: Add AST2600 pinmux nodes")
    Signed-off-by: Joel Stanley <joel@jms.id.au>
    Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
    Link: https://lore.kernel.org/r/20220304011010.974863-1-joel@jms.id.au
    Link: https://lore.kernel.org/r/20220304011010.974863-1-joel@jms.id.au'
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 96b01b8541515009ea81e4c4efd362e07ecb7d33
Author: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Date:   Mon Mar 7 12:13:30 2022 +0000

    net: dsa: mt7530: fix incorrect test in mt753x_phylink_validate()
    
    [ Upstream commit e5417cbf7ab5df1632e68fe7d9e6331fc0e7dbd6 ]
    
    Discussing one of the tests in mt753x_phylink_validate() with Landen
    Chao confirms that the "||" should be "&&". Fix this.
    
    Fixes: c288575f7810 ("net: dsa: mt7530: Add the support of MT7531 switch")
    Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Link: https://lore.kernel.org/r/E1nRCF0-00CiXD-7q@rmk-PC.armlinux.org.uk
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ed5bb00d860411e3f87e4956b682bddd4b92d128
Author: Jernej Skrabec <jernej.skrabec@gmail.com>
Date:   Mon Feb 28 19:14:36 2022 +0100

    drm/sun4i: mixer: Fix P010 and P210 format numbers
    
    [ Upstream commit 9470c29faa91c804aa04de4c10634bf02462bfa5 ]
    
    It turns out that DE3 manual has inverted YUV and YVU format numbers for
    P010 and P210. Invert them.
    
    This was tested by playing video decoded to P010 and additionally
    confirmed by looking at BSP driver source.
    
    Fixes: 169ca4b38932 ("drm/sun4i: Add separate DE3 VI layer formats")
    Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220228181436.1424550-1-jernej.skrabec@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 93223495bce53a1a6c30c358bc522d8ea125e359
Author: Tom Rix <trix@redhat.com>
Date:   Sat Mar 5 07:06:42 2022 -0800

    qed: return status of qed_iov_get_link
    
    [ Upstream commit d9dc0c84ad2d4cc911ba252c973d1bf18d5eb9cf ]
    
    Clang static analysis reports this issue
    qed_sriov.c:4727:19: warning: Assigned value is
      garbage or undefined
      ivi->max_tx_rate = tx_rate ? tx_rate : link.speed;
                       ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    link is only sometimes set by the call to qed_iov_get_link()
    qed_iov_get_link fails without setting link or returning
    status.  So change the decl to return status.
    
    Fixes: 73390ac9d82b ("qed*: support ndo_get_vf_config")
    Signed-off-by: Tom Rix <trix@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5bee2ed0508b0b0ea6b2e2284d575386bd396c94
Author: Steffen Klassert <steffen.klassert@secunet.com>
Date:   Mon Mar 7 13:11:40 2022 +0100

    esp: Fix BEET mode inter address family tunneling on GSO
    
    [ Upstream commit 053c8fdf2c930efdff5496960842bbb5c34ad43a ]
    
    The xfrm{4,6}_beet_gso_segment() functions did not correctly set the
    SKB_GSO_IPXIP4 and SKB_GSO_IPXIP6 gso types for the address family
    tunneling case. Fix this by setting these gso types.
    
    Fixes: 384a46ea7bdc7 ("esp4: add gso_segment for esp4 beet mode")
    Fixes: 7f9e40eb18a99 ("esp6: add gso_segment for esp6 beet mode")
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 16386479ef596e69f7ef6c887765e04002449c30
Author: Jia-Ju Bai <baijiaju1990@gmail.com>
Date:   Sat Mar 5 01:14:11 2022 -0800

    net: qlogic: check the return value of dma_alloc_coherent() in qed_vf_hw_prepare()
    
    [ Upstream commit e0058f0fa80f6e09c4d363779c241c45a3c56b94 ]
    
    The function dma_alloc_coherent() in qed_vf_hw_prepare() can fail, so
    its return value should be checked.
    
    Fixes: 1408cc1fa48c ("qed: Introduce VFs")
    Reported-by: TOTE Robot <oslab@tsinghua.edu.cn>
    Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 33c74f8085961308249c2d27097bb6d393305cbc
Author: Jia-Ju Bai <baijiaju1990@gmail.com>
Date:   Sat Mar 5 00:58:16 2022 -0800

    isdn: hfcpci: check the return value of dma_set_mask() in setup_hw()
    
    [ Upstream commit d0aeb0d4a3f7d2a0df7e9545892bbeede8f2ac7e ]
    
    The function dma_set_mask() in setup_hw() can fail, so its return value
    should be checked.
    
    Fixes: 1700fe1a10dc ("Add mISDN HFC PCI driver")
    Reported-by: TOTE Robot <oslab@tsinghua.edu.cn>
    Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cca9d5035bd055a8824ae9e8e1e144eb22ae4b0b
Author: Xie Yongji <xieyongji@bytedance.com>
Date:   Fri Mar 4 18:00:57 2022 +0800

    virtio-blk: Don't use MAX_DISCARD_SEGMENTS if max_discard_seg is zero
    
    [ Upstream commit dacc73ed0b88f1a787ec20385f42ca9dd9eddcd0 ]
    
    Currently the value of max_discard_segment will be set to
    MAX_DISCARD_SEGMENTS (256) with no basis in hardware if device
    set 0 to max_discard_seg in configuration space. It's incorrect
    since the device might not be able to handle such large descriptors.
    To fix it, let's follow max_segments restrictions in this case.
    
    Fixes: 1f23816b8eb8 ("virtio_blk: add discard and write zeroes support")
    Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
    Link: https://lore.kernel.org/r/20220304100058.116-1-xieyongji@bytedance.com
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a3d5fcc6cf2ecbba5a269631092570aa285a24cb
Author: Alexey Khoroshilov <khoroshilov@ispras.ru>
Date:   Fri Mar 4 21:25:36 2022 +0300

    mISDN: Fix memory leak in dsp_pipeline_build()
    
    [ Upstream commit c6a502c2299941c8326d029cfc8a3bc8a4607ad5 ]
    
    dsp_pipeline_build() allocates dup pointer by kstrdup(cfg),
    but then it updates dup variable by strsep(&dup, "|").
    As a result when it calls kfree(dup), the dup variable contains NULL.
    
    Found by Linux Driver Verification project (linuxtesting.org) with SVACE.
    
    Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
    Fixes: 960366cf8dbb ("Add mISDN DSP")
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f97ad179d12ff6789118cf3de3e0236075c5f48b
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date:   Thu May 20 10:14:11 2021 +0800

    mISDN: Remove obsolete PIPELINE_DEBUG debugging information
    
    [ Upstream commit 2682ea324b000709dafec7e9210caa5189377c45 ]
    
    As Leon Romanovsky's tips:
    The definition of macro PIPELINE_DEBUG is commented more than 10 years ago
    and can be seen as a dead code that should be removed.
    
    Suggested-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
    Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2de76d37d4a6dca9b96ea51da24d4290e6cfa1a5
Author: Tung Nguyen <tung.q.nguyen@dektech.com.au>
Date:   Fri Mar 4 03:25:18 2022 +0000

    tipc: fix kernel panic when enabling bearer
    
    [ Upstream commit be4977b847f5d5cedb64d50eaaf2218c3a55a3a3 ]
    
    When enabling a bearer on a node, a kernel panic is observed:
    
    [    4.498085] RIP: 0010:tipc_mon_prep+0x4e/0x130 [tipc]
    ...
    [    4.520030] Call Trace:
    [    4.520689]  <IRQ>
    [    4.521236]  tipc_link_build_proto_msg+0x375/0x750 [tipc]
    [    4.522654]  tipc_link_build_state_msg+0x48/0xc0 [tipc]
    [    4.524034]  __tipc_node_link_up+0xd7/0x290 [tipc]
    [    4.525292]  tipc_rcv+0x5da/0x730 [tipc]
    [    4.526346]  ? __netif_receive_skb_core+0xb7/0xfc0
    [    4.527601]  tipc_l2_rcv_msg+0x5e/0x90 [tipc]
    [    4.528737]  __netif_receive_skb_list_core+0x20b/0x260
    [    4.530068]  netif_receive_skb_list_internal+0x1bf/0x2e0
    [    4.531450]  ? dev_gro_receive+0x4c2/0x680
    [    4.532512]  napi_complete_done+0x6f/0x180
    [    4.533570]  virtnet_poll+0x29c/0x42e [virtio_net]
    ...
    
    The node in question is receiving activate messages in another
    thread after changing bearer status to allow message sending/
    receiving in current thread:
    
             thread 1           |              thread 2
             --------           |              --------
                                |
    tipc_enable_bearer()        |
      test_and_set_bit_lock()   |
        tipc_bearer_xmit_skb()  |
                                | tipc_l2_rcv_msg()
                                |   tipc_rcv()
                                |     __tipc_node_link_up()
                                |       tipc_link_build_state_msg()
                                |         tipc_link_build_proto_msg()
                                |           tipc_mon_prep()
                                |           {
                                |             ...
                                |             // null-pointer dereference
                                |             u16 gen = mon->dom_gen;
                                |             ...
                                |           }
      // Not being executed yet |
      tipc_mon_create()         |
      {                         |
        ...                     |
        // allocate             |
        mon = kzalloc();        |
        ...                     |
      }                         |
    
    Monitoring pointer in thread 2 is dereferenced before monitoring data
    is allocated in thread 1. This causes kernel panic.
    
    This commit fixes it by allocating the monitoring data before enabling
    the bearer to receive messages.
    
    Fixes: 35c55c9877f8 ("tipc: add neighbor monitoring framework")
    Reported-by: Shuang Li <shuali@redhat.com>
    Acked-by: Jon Maloy <jmaloy@redhat.com>
    Signed-off-by: Tung Nguyen <tung.q.nguyen@dektech.com.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ea3a5e6df5127fcd1e31462e64a35e0e7c7ed9f9
Author: Pali Rohár <pali@kernel.org>
Date:   Mon Jan 17 19:20:06 2022 +0100

    arm64: dts: armada-3720-turris-mox: Add missing ethernet0 alias
    
    [ Upstream commit a0e897d1b36793fe0ab899f2fe93dff25c82f418 ]
    
    U-Boot uses ethernet* aliases for setting MAC addresses. Therefore define
    also alias for ethernet0.
    
    Fixes: 7109d817db2e ("arm64: dts: marvell: add DTS for Turris Mox")
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2c6a75ea32f99ba4b315d7b58f579493d7ac2a9a
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Fri Feb 25 17:18:58 2022 -0800

    HID: vivaldi: fix sysfs attributes leak
    
    [ Upstream commit cc71d37fd1f11e0495b1cf580909ebea37eaa886 ]
    
    The driver creates the top row map sysfs attribute in input_configured()
    method; unfortunately we do not have a callback that is executed when HID
    interface is unbound, thus we are leaking these sysfs attributes, for
    example when device is disconnected.
    
    To fix it let's switch to managed version of adding sysfs attributes which
    will ensure that they are destroyed when the driver is unbound.
    
    Fixes: 14c9c014babe ("HID: add vivaldi HID driver")
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Tested-by: Stephen Boyd <swboyd@chromium.org>
    Reviewed-by: Stephen Boyd <swboyd@chromium.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2a18a38cbc3bc05b4aea1ef5eea14842972cbfa4
Author: Taniya Das <tdas@codeaurora.org>
Date:   Thu Feb 24 00:26:05 2022 +0530

    clk: qcom: gdsc: Add support to update GDSC transition delay
    
    [ Upstream commit 4e7c4d3652f96f41179aab3ff53025c7a550d689 ]
    
    GDSCs have multiple transition delays which are used for the GDSC FSM
    states. Older targets/designs required these values to be updated from
    gdsc code to certain default values for the FSM state to work as
    expected. But on the newer targets/designs the values updated from the
    GDSC driver can hamper the FSM state to not work as expected.
    
    On SC7180 we observe black screens because the gdsc is being
    enabled/disabled very rapidly and the GDSC FSM state does not work as
    expected. This is due to the fact that the GDSC reset value is being
    updated from SW.
    
    Thus add support to update the transition delay from the clock
    controller gdscs as required.
    
    Fixes: 45dd0e55317cc ("clk: qcom: Add support for GDSCs)
    Signed-off-by: Taniya Das <tdas@codeaurora.org>
    Link: https://lore.kernel.org/r/20220223185606.3941-1-tdas@codeaurora.org
    Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0d6882dd158e559b291a2d1b045a65bc2fa4fc58
Author: Maxime Ripard <maxime@cerno.tech>
Date:   Sat Feb 19 13:07:55 2022 +0100

    ARM: boot: dts: bcm2711: Fix HVS register range
    
    [ Upstream commit 515415d316168c6521d74ea8280287e28d7303e6 ]
    
    While the HVS has the same context memory size in the BCM2711 than in
    the previous SoCs, the range allocated to the registers doubled and it
    now takes 16k + 16k, compared to 8k + 16k before.
    
    The KMS driver will use the whole context RAM though, eventually
    resulting in a pointer dereference error when we access the higher half
    of the context memory since it hasn't been mapped.
    
    Fixes: 4564363351e2 ("ARM: dts: bcm2711: Enable the display pipeline")
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>