commit 6fdb13a7e573640853c481ddabf7a192fff42bba
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Jul 28 14:37:42 2021 +0200

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

commit 2db604ff60dd8a4747c10a17fd56ec829b06c3a2
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Wed Jul 7 21:10:51 2021 -0700

    skbuff: Fix build with SKB extensions disabled
    
    commit 9615fe36b31d926f1c5107013b772dc226a6a7ca upstream.
    
    We will fail to build with CONFIG_SKB_EXTENSIONS disabled after
    8550ff8d8c75 ("skbuff: Release nfct refcount on napi stolen or re-used
    skbs") since there is an unconditionally use of skb_ext_find() without
    an appropriate stub. Simply build the code conditionally and properly
    guard against both COFNIG_SKB_EXTENSIONS as well as
    CONFIG_NET_TC_SKB_EXT being disabled.
    
    Fixes: Fixes: 8550ff8d8c75 ("skbuff: Release nfct refcount on napi stolen or re-used skbs")
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Reviewed-by: Roi Dayan <roid@nvidia.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 429826249d801235140b0e779308c2c9e9705d5a
Author: Íñigo Huguet <ihuguet@redhat.com>
Date:   Tue Jul 13 16:21:28 2021 +0200

    sfc: ensure correct number of XDP queues
    
    [ Upstream commit 788bc000d4c2f25232db19ab3a0add0ba4e27671 ]
    
    Commit 99ba0ea616aa ("sfc: adjust efx->xdp_tx_queue_count with the real
    number of initialized queues") intended to fix a problem caused by a
    round up when calculating the number of XDP channels and queues.
    However, this was not the real problem. The real problem was that the
    number of XDP TX queues had been reduced to half in
    commit e26ca4b53582 ("sfc: reduce the number of requested xdp ev queues"),
    but the variable xdp_tx_queue_count had remained the same.
    
    Once the correct number of XDP TX queues is created again in the
    previous patch of this series, this also can be reverted since the error
    doesn't actually exist.
    
    Only in the case that there is a bug in the code we can have different
    values in xdp_queue_number and efx->xdp_tx_queue_count. Because of this,
    and per Edward Cree's suggestion, I add instead a WARN_ON to catch if it
    happens again in the future.
    
    Note that the number of allocated queues can be higher than the number
    of used ones due to the round up, as explained in the existing comment
    in the code. That's why we also have to stop increasing xdp_queue_number
    beyond efx->xdp_tx_queue_count.
    
    Signed-off-by: Íñigo Huguet <ihuguet@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b1ea64337fde1a3ee2e98a20c9b83ac9b3fda17c
Author: Yoshitaka Ikeda <ikeda@nskint.co.jp>
Date:   Fri Jul 16 14:35:13 2021 +0000

    spi: spi-cadence-quadspi: Fix division by zero warning - try2
    
    commit 0e85ee897858b1c7a5de53f496d016899d9639c5 upstream.
    
    Fix below division by zero warning:
    - The reason for dividing by zero is because the dummy bus width is zero,
      but if the dummy n bytes is zero, it indicates that there is no data transfer,
      so we can just return zero without doing any calculations.
    
    [    0.795337] Division by zero in kernel.
       :
    [    0.834051] [<807fd40c>] (__div0) from [<804e1acc>] (Ldiv0+0x8/0x10)
    [    0.839097] [<805f0710>] (cqspi_exec_mem_op) from [<805edb4c>] (spi_mem_exec_op+0x3b0/0x3f8)
    
    Fixes: 7512eaf54190 ("spi: cadence-quadspi: Fix dummy cycle calculation when buswidth > 1")
    Signed-off-by: Yoshitaka Ikeda <ikeda@nskint.co.jp>
    Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
    Link: https://lore.kernel.org/r/92eea403-9b21-2488-9cc1-664bee760c5e@nskint.co.jp
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c4443564f8f6e8a1570780c945f53b1aa1bb159d
Author: Colin Xu <colin.xu@intel.com>
Date:   Wed Jul 7 08:45:31 2021 +0800

    drm/i915/gvt: Clear d3_entered on elsp cmd submission.
    
    commit c90b4503ccf42d9d367e843c223df44aa550e82a upstream.
    
    d3_entered flag is used to mark for vgpu_reset a previous power
    transition from D3->D0, typically for VM resume from S3, so that gvt
    could skip PPGTT invalidation in current vgpu_reset during resuming.
    
    In case S0ix exit, although there is D3->D0, guest driver continue to
    use vgpu as normal, with d3_entered set, until next shutdown/reboot or
    power transition.
    
    If a reboot follows a S0ix exit, device power state transite as:
    D0->D3->D0->D0(reboot), while system power state transites as:
    S0->S0 (reboot). There is no vgpu_reset until D0(reboot), thus
    d3_entered won't be cleared, the vgpu_reset will skip PPGTT invalidation
    however those PPGTT entries are no longer valid. Err appears like:
    
    gvt: vgpu 2: vfio_pin_pages failed for gfn 0xxxxx, ret -22
    gvt: vgpu 2: fail: spt xxxx guest entry 0xxxxx type 2
    gvt: vgpu 2: fail: shadow page xxxx guest entry 0xxxxx type 2.
    
    Give gvt a chance to clear d3_entered on elsp cmd submission so that the
    states before & after S0ix enter/exit are consistent.
    
    Fixes: ba25d977571e ("drm/i915/gvt: Do not destroy ppgtt_mm during vGPU D3->D0.")
    Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
    Signed-off-by: Colin Xu <colin.xu@intel.com>
    Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
    Link: http://patchwork.freedesktop.org/patch/msgid/20210707004531.4873-1-colin.xu@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9bad2eae08e227d7c3a7cbe5c73b1cc18ef25260
Author: Riccardo Mancini <rickyman7@gmail.com>
Date:   Thu Jul 15 18:07:15 2021 +0200

    perf inject: Close inject.output on exit
    
    commit 02e6246f5364d5260a6ea6f92ab6f409058b162f upstream.
    
    ASan reports a memory leak when running:
    
      # perf test "83: Zstd perf.data compression/decompression"
    
    which happens inside 'perf inject'.
    
    The bug is caused by inject.output never being closed.
    
    This patch adds the missing perf_data__close().
    
    Signed-off-by: Riccardo Mancini <rickyman7@gmail.com>
    Fixes: 6ef81c55a2b6584c ("perf session: Return error code for perf_session__new() function on failure")
    Cc: Ian Rogers <irogers@google.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Mamatha Inamdar <mamatha4@linux.vnet.ibm.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lore.kernel.org/lkml/c06f682afa964687367cf6e92a64ceb49aec76a5.1626343282.git.rickyman7@gmail.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5cf3d397fcf63488866b019c84e5e193ae299f25
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Thu Jul 15 13:30:49 2021 +0100

    arm64: entry: fix KCOV suppression
    
    commit e6f85cbeb23bd74b8966cf1f15bf7d01399ff625 upstream.
    
    We suppress KCOV for entry.o rather than entry-common.o. As entry.o is
    built from entry.S, this is pointless, and permits instrumentation of
    entry-common.o, which is built from entry-common.c.
    
    Fix the Makefile to suppress KCOV for entry-common.o, as we had intended
    to begin with. I've verified with objdump that this is working as
    expected.
    
    Fixes: bf6fa2c0dda7 ("arm64: entry: don't instrument entry code with KCOV")
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: James Morse <james.morse@arm.com>
    Cc: Marc Zyngier <maz@kernel.org>
    Cc: Will Deacon <will@kernel.org>
    Link: https://lore.kernel.org/r/20210715123049.9990-1-mark.rutland@arm.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 12b4399333021a6f4c8a9e6e61f552f47e20d1f8
Author: Robert Richter <rrichter@amd.com>
Date:   Thu Jul 15 11:26:02 2021 +0200

    Documentation: Fix intiramfs script name
    
    commit 5e60f363b38fd40e4d8838b5d6f4d4ecee92c777 upstream.
    
    Documentation was not changed when renaming the script in commit
    80e715a06c2d ("initramfs: rename gen_initramfs_list.sh to
    gen_initramfs.sh"). Fixing this.
    
    Basically does:
    
     $ sed -i -e s/gen_initramfs_list.sh/gen_initramfs.sh/g $(git grep -l gen_initramfs_list.sh)
    
    Fixes: 80e715a06c2d ("initramfs: rename gen_initramfs_list.sh to gen_initramfs.sh")
    Signed-off-by: Robert Richter <rrichter@amd.com>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 337deea6460da584d44725dd5b16b08a03e1c550
Author: Stefan Wahren <stefan.wahren@i2se.com>
Date:   Sat Jul 10 13:04:55 2021 +0200

    ARM: multi_v7_defconfig: Make NOP_USB_XCEIV driver built-in
    
    commit ab37a7a890c1176144a4c66ff3d51ef2c20ed486 upstream.
    
    The usage of usb-nop-xceiv PHY on Raspberry Pi boards with BCM283x has
    been a "regression source" a lot of times. The last case is breakage of
    USB mass storage boot has been commit e590474768f1 ("driver core: Set
    fw_devlink=on by default") for multi_v7_defconfig. As long as
    NOP_USB_XCEIV is configured as module, the dwc2 USB driver defer probing
    endlessly and prevent booting from USB mass storage device. So make
    the driver built-in as in bcm2835_defconfig and arm64/defconfig.
    
    Fixes: e590474768f1 ("driver core: Set fw_devlink=on by default")
    Reported-by: Ojaswin Mujoo <ojaswin98@gmail.com>
    Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
    Link: https://lore.kernel.org/r/1625915095-23077-1-git-send-email-stefan.wahren@i2se.com'
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a5fd9d3d35bc0d1b2c8db722c0bd7ce8d08d9d7a
Author: Paul Blakey <paulb@nvidia.com>
Date:   Mon Jul 5 13:54:51 2021 +0300

    skbuff: Release nfct refcount on napi stolen or re-used skbs
    
    commit 8550ff8d8c75416e984d9c4b082845e57e560984 upstream.
    
    When multiple SKBs are merged to a new skb under napi GRO,
    or SKB is re-used by napi, if nfct was set for them in the
    driver, it will not be released while freeing their stolen
    head state or on re-use.
    
    Release nfct on napi's stolen or re-used SKBs, and
    in gro_list_prepare, check conntrack metadata diff.
    
    Fixes: 5c6b94604744 ("net/mlx5e: CT: Handle misses after executing CT action")
    Reviewed-by: Roi Dayan <roid@nvidia.com>
    Signed-off-by: Paul Blakey <paulb@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8f738d2d51cf50411609942ccffb8b69ba61f799
Author: Matthieu Baerts <matthieu.baerts@tessares.net>
Date:   Fri Jun 25 14:25:22 2021 -0700

    mptcp: fix 'masking a bool' warning
    
    commit c4512c63b1193c73b3f09c598a6d0a7f88da1dd8 upstream.
    
    Dan Carpenter reported an issue introduced in
    commit fde56eea01f9 ("mptcp: refine mptcp_cleanup_rbuf") where a new
    boolean (ack_pending) is masked with 0x9.
    
    This is not the intention to ignore values by using a boolean. This
    variable should not have a 'bool' type: we should keep the 'u8' to allow
    this comparison.
    
    Fixes: fde56eea01f9 ("mptcp: refine mptcp_cleanup_rbuf")
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
    Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
    Acked-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ecc9318db5ffa96902cfccebff00d5ba080b3366
Author: Mahesh Bandewar <maheshb@google.com>
Date:   Fri Jul 16 16:09:41 2021 -0700

    bonding: fix build issue
    
    commit 5b69874f74cc5707edd95fcdaa757c507ac8af0f upstream.
    
    The commit 9a5605505d9c (" bonding: Add struct bond_ipesc to manage SA") is causing
    following build error when XFRM is not selected in kernel config.
    
    lld: error: undefined symbol: xfrm_dev_state_flush
    >>> referenced by bond_main.c:3453 (drivers/net/bonding/bond_main.c:3453)
    >>>               net/bonding/bond_main.o:(bond_netdev_event) in archive drivers/built-in.a
    
    Fixes: 9a5605505d9c (" bonding: Add struct bond_ipesc to manage SA")
    Signed-off-by: Mahesh Bandewar <maheshb@google.com>
    CC: Taehee Yoo <ap420073@gmail.com>
    CC: Jay Vosburgh <jay.vosburgh@canonical.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit da510a38cb609390e581cbc68994621021fd6797
Author: Yoshitaka Ikeda <ikeda@nskint.co.jp>
Date:   Fri Jul 16 14:33:12 2021 +0000

    spi: spi-cadence-quadspi: Revert "Fix division by zero warning"
    
    commit 0ccfd1ba84a4503b509250941af149e9ebd605ca upstream.
    
    Revert to change to a better code.
    
    This reverts commit 55cef88bbf12f3bfbe5c2379a8868a034707e755.
    
    Signed-off-by: Yoshitaka Ikeda <ikeda@nskint.co.jp>
    Link: https://lore.kernel.org/r/bd30bdb4-07c4-f713-5648-01c898d51f1b@nskint.co.jp
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bc93e9909cc8f8c23d5f2f09c52dc3bacec50d74
Author: Likun Gao <Likun.Gao@amd.com>
Date:   Thu Jul 15 11:08:48 2021 +0800

    drm/amdgpu: update golden setting for sienna_cichlid
    
    commit 3e94b5965e624f7e6d8dd18eb8f3bf2bb99ba30d upstream.
    
    Update GFX golden setting for sienna_cichlid.
    
    Signed-off-by: Likun Gao <Likun.Gao@amd.com>
    Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 52ee22ce8af269e8fab7bf3d29bc162ac99b52e0
Author: Xiaojian Du <Xiaojian.Du@amd.com>
Date:   Wed Jul 14 15:07:22 2021 +0800

    drm/amdgpu: update the golden setting for vangogh
    
    commit 4fff6fbca12524358a32e56f125ae738141f62b4 upstream.
    
    This patch is to update the golden setting for vangogh.
    
    Signed-off-by: Xiaojian Du <Xiaojian.Du@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 72097f7beefdf3bcf0800d3e08bceb2dab31dd12
Author: Tao Zhou <tao.zhou1@amd.com>
Date:   Thu Jul 15 14:49:08 2021 +0800

    drm/amdgpu: update gc golden setting for dimgrey_cavefish
    
    commit cfe4e8f00f8f19ba305800f64962d1949ab5d4ca upstream.
    
    Update gc_10_3_4 golden setting.
    
    Signed-off-by: Tao Zhou <tao.zhou1@amd.com>
    Reviewed-by: Guchun Chen <guchun.chen@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 75ab00b813e4b6372c8da582363d872c2b9c2a4b
Author: Charles Baylis <cb-kernel@fishzet.co.uk>
Date:   Fri Jul 16 17:43:12 2021 +0100

    drm: Return -ENOTTY for non-drm ioctls
    
    commit 3abab27c322e0f2acf981595aa8040c9164dc9fb upstream.
    
    drm: Return -ENOTTY for non-drm ioctls
    
    Return -ENOTTY from drm_ioctl() when userspace passes in a cmd number
    which doesn't relate to the drm subsystem.
    
    Glibc uses the TCGETS ioctl to implement isatty(), and without this
    change isatty() returns it incorrectly returns true for drm devices.
    
    To test run this command:
    $ if [ -t 0 ]; then echo is a tty; fi < /dev/dri/card0
    which shows "is a tty" without this patch.
    
    This may also modify memory which the userspace application is not
    expecting.
    
    Signed-off-by: Charles Baylis <cb-kernel@fishzet.co.uk>
    Cc: stable@vger.kernel.org
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/YPG3IBlzaMhfPqCr@stando.fishzet.co.uk
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c9d31f7d17e43eb02571f20bbc3959c388467eb8
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Fri Jul 16 14:44:07 2021 +0300

    driver core: Prevent warning when removing a device link from unregistered consumer
    
    commit e64daad660a0c9ace3acdc57099fffe5ed83f977 upstream.
    
    sysfs_remove_link() causes a warning if the parent directory does not
    exist. That can happen if the device link consumer has not been registered.
    So do not attempt sysfs_remove_link() in that case.
    
    Fixes: 287905e68dd29 ("driver core: Expose device link details in sysfs")
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: stable@vger.kernel.org # 5.9+
    Reviewed-by: Rafael J. Wysocki <rafael@kernel.org>
    Link: https://lore.kernel.org/r/20210716114408.17320-2-adrian.hunter@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9d06d3d2a16d009bfbf1025ca6732f900b79f468
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Jun 29 12:40:24 2021 +0200

    nds32: fix up stack guard gap
    
    commit c453db6cd96418c79702eaf38259002755ab23ff upstream.
    
    Commit 1be7107fbe18 ("mm: larger stack guard gap, between vmas") fixed
    up all architectures to deal with the stack guard gap.  But when nds32
    was added to the tree, it forgot to do the same thing.
    
    Resolve this by properly fixing up the nsd32's version of
    arch_get_unmapped_area()
    
    Cc: Nick Hu <nickhu@andestech.com>
    Cc: Greentime Hu <green.hu@gmail.com>
    Cc: Vincent Chen <deanbo422@gmail.com>
    Cc: Michal Hocko <mhocko@suse.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Qiang Liu <cyruscyliu@gmail.com>
    Cc: stable <stable@vger.kernel.org>
    Reported-by: iLifetruth <yixiaonn@gmail.com>
    Acked-by: Hugh Dickins <hughd@google.com>
    Link: https://lore.kernel.org/r/20210629104024.2293615-1-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7544d21b40147f34adbff5fba07527a9e3ac8d4e
Author: Jérôme Glisse <jglisse@redhat.com>
Date:   Thu Jul 1 08:28:25 2021 -0700

    misc: eeprom: at24: Always append device id even if label property is set.
    
    commit c36748ac545421d94a5091c754414c0f3664bf10 upstream.
    
    We need to append device id even if eeprom have a label property set as some
    platform can have multiple eeproms with same label and we can not register
    each of those with same label. Failing to register those eeproms trigger
    cascade failures on such platform (system is no longer working).
    
    This fix regression on such platform introduced with 4e302c3b568e
    
    Reported-by: Alexander Fomichev <fomichev.ru@gmail.com>
    Fixes: 4e302c3b568e ("misc: eeprom: at24: fix NVMEM name with custom AT24 device name")
    Cc: stable@vger.kernel.org
    Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
    Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ef92931cc5bf7fcc4d7702cb975fdd817c51eb9
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Sat Jul 3 11:56:55 2021 +0200

    rbd: always kick acquire on "acquired" and "released" notifications
    
    commit 8798d070d416d18a75770fc19787e96705073f43 upstream.
    
    Skipping the "lock has been released" notification if the lock owner
    is not what we expect based on owner_cid can lead to I/O hangs.
    One example is our own notifications: because owner_cid is cleared
    in rbd_unlock(), when we get our own notification it is processed as
    unexpected/duplicate and maybe_kick_acquire() isn't called.  If a peer
    that requested the lock then doesn't go through with acquiring it,
    I/O requests that came in while the lock was being quiesced would
    be stalled until another I/O request is submitted and kicks acquire
    from rbd_img_exclusive_lock().
    
    This makes the comment in rbd_release_lock() actually true: prior to
    this change the canceled work was being requeued in response to the
    "lock has been acquired" notification from rbd_handle_acquired_lock().
    
    Cc: stable@vger.kernel.org # 5.3+
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Tested-by: Robin Geuze <robin.geuze@nl.team.blue>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8b334d74fbbd1c7dbdf18dffbf589169954a54a0
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Sat Jul 3 11:31:26 2021 +0200

    rbd: don't hold lock_rwsem while running_list is being drained
    
    commit ed9eb71085ecb7ded9a5118cec2ab70667cc7350 upstream.
    
    Currently rbd_quiesce_lock() holds lock_rwsem for read while blocking
    on releasing_wait completion.  On the I/O completion side, each image
    request also needs to take lock_rwsem for read.  Because rw_semaphore
    implementation doesn't allow new readers after a writer has indicated
    interest in the lock, this can result in a deadlock if something that
    needs to take lock_rwsem for write gets involved.  For example:
    
    1. watch error occurs
    2. rbd_watch_errcb() takes lock_rwsem for write, clears owner_cid and
       releases lock_rwsem
    3. after reestablishing the watch, rbd_reregister_watch() takes
       lock_rwsem for write and calls rbd_reacquire_lock()
    4. rbd_quiesce_lock() downgrades lock_rwsem to for read and blocks on
       releasing_wait until running_list becomes empty
    5. another watch error occurs
    6. rbd_watch_errcb() blocks trying to take lock_rwsem for write
    7. no in-flight image request can complete and delete itself from
       running_list because lock_rwsem won't be granted anymore
    
    A similar scenario can occur with "lock has been acquired" and "lock
    has been released" notification handers which also take lock_rwsem for
    write to update owner_cid.
    
    We don't actually get anything useful from sitting on lock_rwsem in
    rbd_quiesce_lock() -- owner_cid updates certainly don't need to be
    synchronized with.  In fact the whole owner_cid tracking logic could
    probably be removed from the kernel client because we don't support
    proxied maintenance operations.
    
    Cc: stable@vger.kernel.org # 5.3+
    URL: https://tracker.ceph.com/issues/42757
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Tested-by: Robin Geuze <robin.geuze@nl.team.blue>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 79da14fac0b5fbf0b2810c47b103f29ff9e16f97
Author: Mike Kravetz <mike.kravetz@oracle.com>
Date:   Fri Jul 23 15:50:44 2021 -0700

    hugetlbfs: fix mount mode command line processing
    
    commit e0f7e2b2f7e7864238a4eea05cc77ae1be2bf784 upstream.
    
    In commit 32021982a324 ("hugetlbfs: Convert to fs_context") processing
    of the mount mode string was changed from match_octal() to fsparam_u32.
    
    This changed existing behavior as match_octal does not require octal
    values to have a '0' prefix, but fsparam_u32 does.
    
    Use fsparam_u32oct which provides the same behavior as match_octal.
    
    Link: https://lkml.kernel.org/r/20210721183326.102716-1-mike.kravetz@oracle.com
    Fixes: 32021982a324 ("hugetlbfs: Convert to fs_context")
    Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
    Reported-by: Dennis Camera <bugs+kernel.org@dtnr.ch>
    Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Cc: David Howells <dhowells@redhat.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4861f6d3b90f81b4c5e3817c9092885962b369bc
Author: Qi Zheng <zhengqi.arch@bytedance.com>
Date:   Fri Jul 23 15:50:41 2021 -0700

    mm: fix the deadlock in finish_fault()
    
    commit e4dc3489143f84f7ed30be58b886bb6772f229b9 upstream.
    
    Commit 63f3655f9501 ("mm, memcg: fix reclaim deadlock with writeback")
    fix the following ABBA deadlock by pre-allocating the pte page table
    without holding the page lock.
    
                                            lock_page(A)
                                            SetPageWriteback(A)
                                            unlock_page(A)
      lock_page(B)
                                            lock_page(B)
      pte_alloc_one
        shrink_page_list
          wait_on_page_writeback(A)
                                            SetPageWriteback(B)
                                            unlock_page(B)
    
                                            # flush A, B to clear the writeback
    
    Commit f9ce0be71d1f ("mm: Cleanup faultaround and finish_fault()
    codepaths") reworked the relevant code but ignored this race.  This will
    cause the deadlock above to appear again, so fix it.
    
    Link: https://lkml.kernel.org/r/20210721074849.57004-1-zhengqi.arch@bytedance.com
    Fixes: f9ce0be71d1f ("mm: Cleanup faultaround and finish_fault() codepaths")
    Signed-off-by: Qi Zheng <zhengqi.arch@bytedance.com>
    Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Michal Hocko <mhocko@kernel.org>
    Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
    Cc: Muchun Song <songmuchun@bytedance.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5d4b4d2e3c8d5bc3bf62f94a594cd02ca7e7b65c
Author: Mike Rapoport <rppt@kernel.org>
Date:   Fri Jul 23 15:50:26 2021 -0700

    memblock: make for_each_mem_range() traverse MEMBLOCK_HOTPLUG regions
    
    commit 79e482e9c3ae86e849c701c846592e72baddda5a upstream.
    
    Commit b10d6bca8720 ("arch, drivers: replace for_each_membock() with
    for_each_mem_range()") didn't take into account that when there is
    movable_node parameter in the kernel command line, for_each_mem_range()
    would skip ranges marked with MEMBLOCK_HOTPLUG.
    
    The page table setup code in POWER uses for_each_mem_range() to create
    the linear mapping of the physical memory and since the regions marked
    as MEMORY_HOTPLUG are skipped, they never make it to the linear map.
    
    A later access to the memory in those ranges will fail:
    
      BUG: Unable to handle kernel data access on write at 0xc000000400000000
      Faulting instruction address: 0xc00000000008a3c0
      Oops: Kernel access of bad area, sig: 11 [#1]
      LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
      Modules linked in:
      CPU: 0 PID: 53 Comm: kworker/u2:0 Not tainted 5.13.0 #7
      NIP:  c00000000008a3c0 LR: c0000000003c1ed8 CTR: 0000000000000040
      REGS: c000000008a57770 TRAP: 0300   Not tainted  (5.13.0)
      MSR:  8000000002009033 <SF,VEC,EE,ME,IR,DR,RI,LE>  CR: 84222202  XER: 20040000
      CFAR: c0000000003c1ed4 DAR: c000000400000000 DSISR: 42000000 IRQMASK: 0
      GPR00: c0000000003c1ed8 c000000008a57a10 c0000000019da700 c000000400000000
      GPR04: 0000000000000280 0000000000000180 0000000000000400 0000000000000200
      GPR08: 0000000000000100 0000000000000080 0000000000000040 0000000000000300
      GPR12: 0000000000000380 c000000001bc0000 c0000000001660c8 c000000006337e00
      GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      GPR20: 0000000040000000 0000000020000000 c000000001a81990 c000000008c30000
      GPR24: c000000008c20000 c000000001a81998 000fffffffff0000 c000000001a819a0
      GPR28: c000000001a81908 c00c000001000000 c000000008c40000 c000000008a64680
      NIP clear_user_page+0x50/0x80
      LR __handle_mm_fault+0xc88/0x1910
      Call Trace:
        __handle_mm_fault+0xc44/0x1910 (unreliable)
        handle_mm_fault+0x130/0x2a0
        __get_user_pages+0x248/0x610
        __get_user_pages_remote+0x12c/0x3e0
        get_arg_page+0x54/0xf0
        copy_string_kernel+0x11c/0x210
        kernel_execve+0x16c/0x220
        call_usermodehelper_exec_async+0x1b0/0x2f0
        ret_from_kernel_thread+0x5c/0x70
      Instruction dump:
      79280fa4 79271764 79261f24 794ae8e2 7ca94214 7d683a14 7c893a14 7d893050
      7d4903a6 60000000 60000000 60000000 <7c001fec> 7c091fec 7c081fec 7c051fec
      ---[ end trace 490b8c67e6075e09 ]---
    
    Making for_each_mem_range() include MEMBLOCK_HOTPLUG regions in the
    traversal fixes this issue.
    
    Link: https://bugzilla.redhat.com/show_bug.cgi?id=1976100
    Link: https://lkml.kernel.org/r/20210712071132.20902-1-rppt@kernel.org
    Fixes: b10d6bca8720 ("arch, drivers: replace for_each_membock() with for_each_mem_range()")
    Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
    Tested-by: Greg Kurz <groug@kaod.org>
    Reviewed-by: David Hildenbrand <david@redhat.com>
    Cc: <stable@vger.kernel.org>    [5.10+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e88a5bee0f585889cc0d6e634930bf82a5db0dd
Author: Sergei Trofimovich <slyfox@gentoo.org>
Date:   Fri Jul 23 15:50:23 2021 -0700

    mm: page_alloc: fix page_poison=1 / INIT_ON_ALLOC_DEFAULT_ON interaction
    
    commit 69e5d322a2fb86173fde8bad26e8eb38cad1b1e9 upstream.
    
    To reproduce the failure we need the following system:
    
     - kernel command: page_poison=1 init_on_free=0 init_on_alloc=0
    
     - kernel config:
        * CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y
        * CONFIG_INIT_ON_FREE_DEFAULT_ON=y
        * CONFIG_PAGE_POISONING=y
    
    Resulting in:
    
        0000000085629bdd: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        0000000022861832: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        00000000c597f5b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        CPU: 11 PID: 15195 Comm: bash Kdump: loaded Tainted: G     U     O      5.13.1-gentoo-x86_64 #1
        Hardware name: System manufacturer System Product Name/PRIME Z370-A, BIOS 2801 01/13/2021
        Call Trace:
         dump_stack+0x64/0x7c
         __kernel_unpoison_pages.cold+0x48/0x84
         post_alloc_hook+0x60/0xa0
         get_page_from_freelist+0xdb8/0x1000
         __alloc_pages+0x163/0x2b0
         __get_free_pages+0xc/0x30
         pgd_alloc+0x2e/0x1a0
         mm_init+0x185/0x270
         dup_mm+0x6b/0x4f0
         copy_process+0x190d/0x1b10
         kernel_clone+0xba/0x3b0
         __do_sys_clone+0x8f/0xb0
         do_syscall_64+0x68/0x80
         entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    Before commit 51cba1ebc60d ("init_on_alloc: Optimize static branches")
    init_on_alloc never enabled static branch by default.  It could only be
    enabed explicitly by init_mem_debugging_and_hardening().
    
    But after commit 51cba1ebc60d, a static branch could already be enabled
    by default.  There was no code to ever disable it.  That caused
    page_poison=1 / init_on_free=1 conflict.
    
    This change extends init_mem_debugging_and_hardening() to also disable
    static branch disabling.
    
    Link: https://lkml.kernel.org/r/20210714031935.4094114-1-keescook@chromium.org
    Link: https://lore.kernel.org/r/20210712215816.1512739-1-slyfox@gentoo.org
    Fixes: 51cba1ebc60d ("init_on_alloc: Optimize static branches")
    Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Co-developed-by: Kees Cook <keescook@chromium.org>
    Reported-by: Mikhail Morfikov <mmorfikov@gmail.com>
    Reported-by: <bowsingbetee@pm.me>
    Tested-by: <bowsingbetee@protonmail.com>
    Reviewed-by: David Hildenbrand <david@redhat.com>
    Cc: Alexander Potapenko <glider@google.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ee791f0bba88799396463e38b6877e66bc160c52
Author: Christoph Hellwig <hch@lst.de>
Date:   Fri Jul 23 15:50:17 2021 -0700

    mm: call flush_dcache_page() in memcpy_to_page() and memzero_page()
    
    commit 8dad53a11f8d94dceb540a5f8f153484f42be84b upstream.
    
    memcpy_to_page and memzero_page can write to arbitrary pages, which
    could be in the page cache or in high memory, so call
    flush_kernel_dcache_pages to flush the dcache.
    
    This is a problem when using these helpers on dcache challeneged
    architectures.  Right now there are just a few users, chances are no one
    used the PC floppy driver, the aha1542 driver for an ISA SCSI HBA, and a
    few advanced and optional btrfs and ext4 features on those platforms yet
    since the conversion.
    
    Link: https://lkml.kernel.org/r/20210713055231.137602-2-hch@lst.de
    Fixes: bb90d4bc7b6a ("mm/highmem: Lift memcpy_[to|from]_page to core")
    Fixes: 28961998f858 ("iov_iter: lift memzero_page() to highmem.h")
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Ira Weiny <ira.weiny@intel.com>
    Cc: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5040926bc22d8cee69a494aad60278a27042adc6
Author: Alexander Potapenko <glider@google.com>
Date:   Fri Jul 23 15:50:14 2021 -0700

    kfence: skip all GFP_ZONEMASK allocations
    
    commit 236e9f1538523d3d380dda1cc99571d587058f37 upstream.
    
    Allocation requests outside ZONE_NORMAL (MOVABLE, HIGHMEM or DMA) cannot
    be fulfilled by KFENCE, because KFENCE memory pool is located in a zone
    different from the requested one.
    
    Because callers of kmem_cache_alloc() may actually rely on the
    allocation to reside in the requested zone (e.g.  memory allocations
    done with __GFP_DMA must be DMAable), skip all allocations done with
    GFP_ZONEMASK and/or respective SLAB flags (SLAB_CACHE_DMA and
    SLAB_CACHE_DMA32).
    
    Link: https://lkml.kernel.org/r/20210714092222.1890268-2-glider@google.com
    Fixes: 0ce20dd84089 ("mm: add Kernel Electric-Fence infrastructure")
    Signed-off-by: Alexander Potapenko <glider@google.com>
    Reviewed-by: Marco Elver <elver@google.com>
    Acked-by: Souptick Joarder <jrdr.linux@gmail.com>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Souptick Joarder <jrdr.linux@gmail.com>
    Cc: <stable@vger.kernel.org>    [5.12+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e9adaed2f12647998fa6eb694aa096c6f79fe507
Author: Alexander Potapenko <glider@google.com>
Date:   Fri Jul 23 15:50:11 2021 -0700

    kfence: move the size check to the beginning of __kfence_alloc()
    
    commit 235a85cb32bb123854ad31de46fdbf04c1d57cda upstream.
    
    Check the allocation size before toggling kfence_allocation_gate.
    
    This way allocations that can't be served by KFENCE will not result in
    waiting for another CONFIG_KFENCE_SAMPLE_INTERVAL without allocating
    anything.
    
    Link: https://lkml.kernel.org/r/20210714092222.1890268-1-glider@google.com
    Signed-off-by: Alexander Potapenko <glider@google.com>
    Suggested-by: Marco Elver <elver@google.com>
    Reviewed-by: Marco Elver <elver@google.com>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Cc: Marco Elver <elver@google.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: <stable@vger.kernel.org>    [5.12+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 60e7f63de337296f1da05da08e142021fd4cf6a4
Author: Peter Collingbourne <pcc@google.com>
Date:   Fri Jul 23 15:50:01 2021 -0700

    userfaultfd: do not untag user pointers
    
    commit e71e2ace5721a8b921dca18b045069e7bb411277 upstream.
    
    Patch series "userfaultfd: do not untag user pointers", v5.
    
    If a user program uses userfaultfd on ranges of heap memory, it may end
    up passing a tagged pointer to the kernel in the range.start field of
    the UFFDIO_REGISTER ioctl.  This can happen when using an MTE-capable
    allocator, or on Android if using the Tagged Pointers feature for MTE
    readiness [1].
    
    When a fault subsequently occurs, the tag is stripped from the fault
    address returned to the application in the fault.address field of struct
    uffd_msg.  However, from the application's perspective, the tagged
    address *is* the memory address, so if the application is unaware of
    memory tags, it may get confused by receiving an address that is, from
    its point of view, outside of the bounds of the allocation.  We observed
    this behavior in the kselftest for userfaultfd [2] but other
    applications could have the same problem.
    
    Address this by not untagging pointers passed to the userfaultfd ioctls.
    Instead, let the system call fail.  Also change the kselftest to use
    mmap so that it doesn't encounter this problem.
    
    [1] https://source.android.com/devices/tech/debug/tagged-pointers
    [2] tools/testing/selftests/vm/userfaultfd.c
    
    This patch (of 2):
    
    Do not untag pointers passed to the userfaultfd ioctls.  Instead, let
    the system call fail.  This will provide an early indication of problems
    with tag-unaware userspace code instead of letting the code get confused
    later, and is consistent with how we decided to handle brk/mmap/mremap
    in commit dcde237319e6 ("mm: Avoid creating virtual address aliases in
    brk()/mmap()/mremap()"), as well as being consistent with the existing
    tagged address ABI documentation relating to how ioctl arguments are
    handled.
    
    The code change is a revert of commit 7d0325749a6c ("userfaultfd: untag
    user pointers") plus some fixups to some additional calls to
    validate_range that have appeared since then.
    
    [1] https://source.android.com/devices/tech/debug/tagged-pointers
    [2] tools/testing/selftests/vm/userfaultfd.c
    
    Link: https://lkml.kernel.org/r/20210714195437.118982-1-pcc@google.com
    Link: https://lkml.kernel.org/r/20210714195437.118982-2-pcc@google.com
    Link: https://linux-review.googlesource.com/id/I761aa9f0344454c482b83fcfcce547db0a25501b
    Fixes: 63f0c6037965 ("arm64: Introduce prctl() options to control the tagged user addresses ABI")
    Signed-off-by: Peter Collingbourne <pcc@google.com>
    Reviewed-by: Andrey Konovalov <andreyknvl@gmail.com>
    Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Alistair Delva <adelva@google.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Dave Martin <Dave.Martin@arm.com>
    Cc: Evgenii Stepanov <eugenis@google.com>
    Cc: Lokesh Gidra <lokeshgidra@google.com>
    Cc: Mitch Phillips <mitchp@google.com>
    Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
    Cc: Will Deacon <will@kernel.org>
    Cc: William McVicker <willmcvicker@google.com>
    Cc: <stable@vger.kernel.org>    [5.4]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a6ead78130ad6b3eadaaa5811be1ddaf1f6ec405
Author: Jens Axboe <axboe@kernel.dk>
Date:   Thu Jul 22 17:08:07 2021 -0600

    io_uring: fix early fdput() of file
    
    commit 0cc936f74bcacb039b7533aeac0a887dfc896bf6 upstream.
    
    A previous commit shuffled some code around, and inadvertently used
    struct file after fdput() had been called on it. As we can't touch
    the file post fdput() dropping our reference, move the fdput() to
    after that has been done.
    
    Cc: Pavel Begunkov <asml.silence@gmail.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/io-uring/YPnqM0fY3nM5RdRI@zeniv-ca.linux.org.uk/
    Fixes: f2a48dd09b8e ("io_uring: refactor io_sq_offload_create()")
    Reported-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 81cebadedc37c7b961382e90eca487d2c7bf75f7
Author: Pavel Begunkov <asml.silence@gmail.com>
Date:   Tue Jul 20 10:50:44 2021 +0100

    io_uring: remove double poll entry on arm failure
    
    commit 46fee9ab02cb24979bbe07631fc3ae95ae08aa3e upstream.
    
    __io_queue_proc() can enqueue both poll entries and still fail
    afterwards, so the callers trying to cancel it should also try to remove
    the second poll entry (if any).
    
    For example, it may leave the request alive referencing a io_uring
    context but not accessible for cancellation:
    
    [  282.599913][ T1620] task:iou-sqp-23145   state:D stack:28720 pid:23155 ppid:  8844 flags:0x00004004
    [  282.609927][ T1620] Call Trace:
    [  282.613711][ T1620]  __schedule+0x93a/0x26f0
    [  282.634647][ T1620]  schedule+0xd3/0x270
    [  282.638874][ T1620]  io_uring_cancel_generic+0x54d/0x890
    [  282.660346][ T1620]  io_sq_thread+0xaac/0x1250
    [  282.696394][ T1620]  ret_from_fork+0x1f/0x30
    
    Cc: stable@vger.kernel.org
    Fixes: 18bceab101add ("io_uring: allow POLL_ADD with double poll_wait() users")
    Reported-and-tested-by: syzbot+ac957324022b7132accf@syzkaller.appspotmail.com
    Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
    Link: https://lore.kernel.org/r/0ec1228fc5eda4cb524eeda857da8efdc43c331c.1626774457.git.asml.silence@gmail.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0d80ae099a495e011a993666df017141d7d67cdc
Author: Pavel Begunkov <asml.silence@gmail.com>
Date:   Tue Jul 20 10:50:43 2021 +0100

    io_uring: explicitly count entries for poll reqs
    
    commit 68b11e8b1562986c134764433af64e97d30c9fc0 upstream.
    
    If __io_queue_proc() fails to add a second poll entry, e.g. kmalloc()
    failed, but it goes on with a third waitqueue, it may succeed and
    overwrite the error status. Count the number of poll entries we added,
    so we can set pt->error to zero at the beginning and find out when the
    mentioned scenario happens.
    
    Cc: stable@vger.kernel.org
    Fixes: 18bceab101add ("io_uring: allow POLL_ADD with double poll_wait() users")
    Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
    Link: https://lore.kernel.org/r/9d6b9e561f88bcc0163623b74a76c39f712151c3.1626774457.git.asml.silence@gmail.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2f13b6fece9a2d75f0dad816b3ae778e452034b8
Author: Peter Collingbourne <pcc@google.com>
Date:   Fri Jul 23 15:50:04 2021 -0700

    selftest: use mmap instead of posix_memalign to allocate memory
    
    commit 0db282ba2c12c1515d490d14a1ff696643ab0f1b upstream.
    
    This test passes pointers obtained from anon_allocate_area to the
    userfaultfd and mremap APIs.  This causes a problem if the system
    allocator returns tagged pointers because with the tagged address ABI
    the kernel rejects tagged addresses passed to these APIs, which would
    end up causing the test to fail.  To make this test compatible with such
    system allocators, stop using the system allocator to allocate memory in
    anon_allocate_area, and instead just use mmap.
    
    Link: https://lkml.kernel.org/r/20210714195437.118982-3-pcc@google.com
    Link: https://linux-review.googlesource.com/id/Icac91064fcd923f77a83e8e133f8631c5b8fc241
    Fixes: c47174fc362a ("userfaultfd: selftest")
    Co-developed-by: Lokesh Gidra <lokeshgidra@google.com>
    Signed-off-by: Lokesh Gidra <lokeshgidra@google.com>
    Signed-off-by: Peter Collingbourne <pcc@google.com>
    Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
    Cc: Dave Martin <Dave.Martin@arm.com>
    Cc: Will Deacon <will@kernel.org>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Alistair Delva <adelva@google.com>
    Cc: William McVicker <willmcvicker@google.com>
    Cc: Evgenii Stepanov <eugenis@google.com>
    Cc: Mitch Phillips <mitchp@google.com>
    Cc: Andrey Konovalov <andreyknvl@gmail.com>
    Cc: <stable@vger.kernel.org>    [5.4]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fae0c4bb0366f618e2e241e2ce79f707d24f483a
Author: Frederic Weisbecker <frederic@kernel.org>
Date:   Thu Jun 3 01:15:59 2021 +0200

    posix-cpu-timers: Fix rearm racing against process tick
    
    commit 1a3402d93c73bf6bb4df6d7c2aac35abfc3c50e2 upstream.
    
    Since the process wide cputime counter is started locklessly from
    posix_cpu_timer_rearm(), it can be concurrently stopped by operations
    on other timers from the same thread group, such as in the following
    unlucky scenario:
    
             CPU 0                                CPU 1
             -----                                -----
                                               timer_settime(TIMER B)
       posix_cpu_timer_rearm(TIMER A)
           cpu_clock_sample_group()
               (pct->timers_active already true)
    
                                               handle_posix_cpu_timers()
                                                   check_process_timers()
                                                       stop_process_timers()
                                                           pct->timers_active = false
           arm_timer(TIMER A)
    
       tick -> run_posix_cpu_timers()
           // sees !pct->timers_active, ignore
           // our TIMER A
    
    Fix this with simply locking process wide cputime counting start and
    timer arm in the same block.
    
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
    Fixes: 60f2ceaa8111 ("posix-cpu-timers: Remove unnecessary locking around cpu_clock_sample_group")
    Cc: stable@vger.kernel.org
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Eric W. Biederman <ebiederm@xmission.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 52db60a983d2da3a037f2000e22301d40e125bec
Author: Loic Poulain <loic.poulain@linaro.org>
Date:   Fri Jul 16 13:21:06 2021 +0530

    bus: mhi: pci_generic: Fix inbound IPCR channel
    
    commit b8a97f2a65388394f433bf0730293a94f7d49046 upstream.
    
    The qrtr-mhi client driver assumes that inbound buffers are
    automatically allocated and queued by the MHI core, but this
    doesn't happen for mhi pci devices since IPCR inbound channel is
    not flagged with auto_queue, causing unusable IPCR (qrtr)
    feature. Fix that.
    
    Link: https://lore.kernel.org/r/1625736749-24947-1-git-send-email-loic.poulain@linaro.org
    [mani: fixed a spelling mistake in commit description]
    Fixes: 855a70c12021 ("bus: mhi: Add MHI PCI support for WWAN modems")
    Cc: stable@vger.kernel.org #5.10
    Reviewed-by: Hemant kumar <hemantk@codeaurora.org>
    Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
    Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
    Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Link: https://lore.kernel.org/r/20210716075106.49938-4-manivannan.sadhasivam@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aed4f5b51aba41e2afd7cfda20a0571a6a67dfe9
Author: Bhaumik Bhatt <bbhatt@codeaurora.org>
Date:   Fri Jul 16 13:21:05 2021 +0530

    bus: mhi: core: Validate channel ID when processing command completions
    
    commit 546362a9ef2ef40b57c6605f14e88ced507f8dd0 upstream.
    
    MHI reads the channel ID from the event ring element sent by the
    device which can be any value between 0 and 255. In order to
    prevent any out of bound accesses, add a check against the maximum
    number of channels supported by the controller and those channels
    not configured yet so as to skip processing of that event ring
    element.
    
    Link: https://lore.kernel.org/r/1624558141-11045-1-git-send-email-bbhatt@codeaurora.org
    Fixes: 1d3173a3bae7 ("bus: mhi: core: Add support for processing events from client device")
    Cc: stable@vger.kernel.org #5.10
    Reviewed-by: Hemant Kumar <hemantk@codeaurora.org>
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
    Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
    Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Link: https://lore.kernel.org/r/20210716075106.49938-3-manivannan.sadhasivam@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a88270680663c6ca74c77d072fc52f264762ac42
Author: Bhaumik Bhatt <bbhatt@codeaurora.org>
Date:   Fri Jul 16 13:21:04 2021 +0530

    bus: mhi: pci_generic: Apply no-op for wake using sideband wake boolean
    
    commit 56f6f4c4eb2a710ec8878dd9373d3d2b2eb75f5c upstream.
    
    Devices such as SDX24 do not have the provision for inband wake
    doorbell in the form of channel 127 and instead have a sideband
    GPIO for it. Newer devices such as SDX55 or SDX65 support inband
    wake method by default. Ensure the functionality is used based on
    this such that device wake stays held when a client driver uses
    mhi_device_get() API or the equivalent debugfs entry.
    
    Link: https://lore.kernel.org/r/1624560809-30610-1-git-send-email-bbhatt@codeaurora.org
    Fixes: e3e5e6508fc1 ("bus: mhi: pci_generic: No-Op for device_wake operations")
    Cc: stable@vger.kernel.org #5.12
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
    Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Link: https://lore.kernel.org/r/20210716075106.49938-2-manivannan.sadhasivam@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ce5b3de58fc21303722df46551f7eb9a91afb409
Author: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Date:   Tue Jul 13 12:34:38 2021 +0300

    driver core: auxiliary bus: Fix memory leak when driver_register() fail
    
    commit 4afa0c22eed33cfe0c590742387f0d16f32412f3 upstream.
    
    If driver_register() returns with error we need to free the memory
    allocated for auxdrv->driver.name before returning from
    __auxiliary_driver_register()
    
    Fixes: 7de3697e9cbd4 ("Add auxiliary bus support")
    Reviewed-by: Dan Williams <dan.j.williams@intel.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Link: https://lore.kernel.org/r/20210713093438.3173-1-peter.ujfalusi@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 423123e428a1773f81332307af9cdcad1b74cef7
Author: Markus Boehme <markubo@amazon.com>
Date:   Tue Jul 20 16:26:19 2021 -0700

    ixgbe: Fix packet corruption due to missing DMA sync
    
    commit 09cfae9f13d51700b0fecf591dcd658fc5375428 upstream.
    
    When receiving a packet with multiple fragments, hardware may still
    touch the first fragment until the entire packet has been received. The
    driver therefore keeps the first fragment mapped for DMA until end of
    packet has been asserted, and delays its dma_sync call until then.
    
    The driver tries to fit multiple receive buffers on one page. When using
    3K receive buffers (e.g. using Jumbo frames and legacy-rx is turned
    off/build_skb is being used) on an architecture with 4K pages, the
    driver allocates an order 1 compound page and uses one page per receive
    buffer. To determine the correct offset for a delayed DMA sync of the
    first fragment of a multi-fragment packet, the driver then cannot just
    use PAGE_MASK on the DMA address but has to construct a mask based on
    the actual size of the backing page.
    
    Using PAGE_MASK in the 3K RX buffer/4K page architecture configuration
    will always sync the first page of a compound page. With the SWIOTLB
    enabled this can lead to corrupted packets (zeroed out first fragment,
    re-used garbage from another packet) and various consequences, such as
    slow/stalling data transfers and connection resets. For example, testing
    on a link with MTU exceeding 3058 bytes on a host with SWIOTLB enabled
    (e.g. "iommu=soft swiotlb=262144,force") TCP transfers quickly fizzle
    out without this patch.
    
    Cc: stable@vger.kernel.org
    Fixes: 0c5661ecc5dd7 ("ixgbe: fix crash in build_skb Rx code path")
    Signed-off-by: Markus Boehme <markubo@amazon.com>
    Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b9a178f189bb6d75293573e181928735f5e3e070
Author: Gustavo A. R. Silva <gustavoars@kernel.org>
Date:   Mon Apr 19 18:43:32 2021 -0500

    media: ngene: Fix out-of-bounds bug in ngene_command_config_free_buf()
    
    commit 8d4abca95ecc82fc8c41912fa0085281f19cc29f upstream.
    
    Fix an 11-year old bug in ngene_command_config_free_buf() while
    addressing the following warnings caught with -Warray-bounds:
    
    arch/alpha/include/asm/string.h:22:16: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds]
    arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds]
    
    The problem is that the original code is trying to copy 6 bytes of
    data into a one-byte size member _config_ of the wrong structue
    FW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a
    legitimate compiler warning because memcpy() overruns the length
    of &com.cmd.ConfigureBuffers.config. It seems that the right
    structure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains
    6 more members apart from the header _hdr_. Also, the name of
    the function ngene_command_config_free_buf() suggests that the actual
    intention is to ConfigureFreeBuffers, instead of ConfigureBuffers
    (which takes place in the function ngene_command_config_buf(), above).
    
    Fix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS
    into new struct config, and use &com.cmd.ConfigureFreeBuffers.config as
    the destination address, instead of &com.cmd.ConfigureBuffers.config,
    when calling memcpy().
    
    This also helps with the ongoing efforts to globally enable
    -Warray-bounds and get us closer to being able to tighten the
    FORTIFY_SOURCE routines on memcpy().
    
    Link: https://github.com/KSPP/linux/issues/109
    Fixes: dae52d009fc9 ("V4L/DVB: ngene: Initial check-in")
    Cc: stable@vger.kernel.org
    Reported-by: kernel test robot <lkp@intel.com>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
    Link: https://lore.kernel.org/linux-hardening/20210420001631.GA45456@embeddedor/
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f5ef2fe05d386995b951476ffc8d6a6023888d99
Author: Filipe Manana <fdmanana@suse.com>
Date:   Wed Jul 21 17:31:48 2021 +0100

    btrfs: fix lock inversion problem when doing qgroup extent tracing
    
    commit 8949b9a114019b03fbd0d03d65b8647cba4feef3 upstream.
    
    At btrfs_qgroup_trace_extent_post() we call btrfs_find_all_roots() with a
    NULL value as the transaction handle argument, which makes that function
    take the commit_root_sem semaphore, which is necessary when we don't hold
    a transaction handle or any other mechanism to prevent a transaction
    commit from wiping out commit roots.
    
    However btrfs_qgroup_trace_extent_post() can be called in a context where
    we are holding a write lock on an extent buffer from a subvolume tree,
    namely from btrfs_truncate_inode_items(), called either during truncate
    or unlink operations. In this case we end up with a lock inversion problem
    because the commit_root_sem is a higher level lock, always supposed to be
    acquired before locking any extent buffer.
    
    Lockdep detects this lock inversion problem since we switched the extent
    buffer locks from custom locks to semaphores, and when running btrfs/158
    from fstests, it reported the following trace:
    
    [ 9057.626435] ======================================================
    [ 9057.627541] WARNING: possible circular locking dependency detected
    [ 9057.628334] 5.14.0-rc2-btrfs-next-93 #1 Not tainted
    [ 9057.628961] ------------------------------------------------------
    [ 9057.629867] kworker/u16:4/30781 is trying to acquire lock:
    [ 9057.630824] ffff8e2590f58760 (btrfs-tree-00){++++}-{3:3}, at: __btrfs_tree_read_lock+0x24/0x110 [btrfs]
    [ 9057.632542]
                   but task is already holding lock:
    [ 9057.633551] ffff8e25582d4b70 (&fs_info->commit_root_sem){++++}-{3:3}, at: iterate_extent_inodes+0x10b/0x280 [btrfs]
    [ 9057.635255]
                   which lock already depends on the new lock.
    
    [ 9057.636292]
                   the existing dependency chain (in reverse order) is:
    [ 9057.637240]
                   -> #1 (&fs_info->commit_root_sem){++++}-{3:3}:
    [ 9057.638138]        down_read+0x46/0x140
    [ 9057.638648]        btrfs_find_all_roots+0x41/0x80 [btrfs]
    [ 9057.639398]        btrfs_qgroup_trace_extent_post+0x37/0x70 [btrfs]
    [ 9057.640283]        btrfs_add_delayed_data_ref+0x418/0x490 [btrfs]
    [ 9057.641114]        btrfs_free_extent+0x35/0xb0 [btrfs]
    [ 9057.641819]        btrfs_truncate_inode_items+0x424/0xf70 [btrfs]
    [ 9057.642643]        btrfs_evict_inode+0x454/0x4f0 [btrfs]
    [ 9057.643418]        evict+0xcf/0x1d0
    [ 9057.643895]        do_unlinkat+0x1e9/0x300
    [ 9057.644525]        do_syscall_64+0x3b/0xc0
    [ 9057.645110]        entry_SYSCALL_64_after_hwframe+0x44/0xae
    [ 9057.645835]
                   -> #0 (btrfs-tree-00){++++}-{3:3}:
    [ 9057.646600]        __lock_acquire+0x130e/0x2210
    [ 9057.647248]        lock_acquire+0xd7/0x310
    [ 9057.647773]        down_read_nested+0x4b/0x140
    [ 9057.648350]        __btrfs_tree_read_lock+0x24/0x110 [btrfs]
    [ 9057.649175]        btrfs_read_lock_root_node+0x31/0x40 [btrfs]
    [ 9057.650010]        btrfs_search_slot+0x537/0xc00 [btrfs]
    [ 9057.650849]        scrub_print_warning_inode+0x89/0x370 [btrfs]
    [ 9057.651733]        iterate_extent_inodes+0x1e3/0x280 [btrfs]
    [ 9057.652501]        scrub_print_warning+0x15d/0x2f0 [btrfs]
    [ 9057.653264]        scrub_handle_errored_block.isra.0+0x135f/0x1640 [btrfs]
    [ 9057.654295]        scrub_bio_end_io_worker+0x101/0x2e0 [btrfs]
    [ 9057.655111]        btrfs_work_helper+0xf8/0x400 [btrfs]
    [ 9057.655831]        process_one_work+0x247/0x5a0
    [ 9057.656425]        worker_thread+0x55/0x3c0
    [ 9057.656993]        kthread+0x155/0x180
    [ 9057.657494]        ret_from_fork+0x22/0x30
    [ 9057.658030]
                   other info that might help us debug this:
    
    [ 9057.659064]  Possible unsafe locking scenario:
    
    [ 9057.659824]        CPU0                    CPU1
    [ 9057.660402]        ----                    ----
    [ 9057.660988]   lock(&fs_info->commit_root_sem);
    [ 9057.661581]                                lock(btrfs-tree-00);
    [ 9057.662348]                                lock(&fs_info->commit_root_sem);
    [ 9057.663254]   lock(btrfs-tree-00);
    [ 9057.663690]
                    *** DEADLOCK ***
    
    [ 9057.664437] 4 locks held by kworker/u16:4/30781:
    [ 9057.665023]  #0: ffff8e25922a1148 ((wq_completion)btrfs-scrub){+.+.}-{0:0}, at: process_one_work+0x1c7/0x5a0
    [ 9057.666260]  #1: ffffabb3451ffe70 ((work_completion)(&work->normal_work)){+.+.}-{0:0}, at: process_one_work+0x1c7/0x5a0
    [ 9057.667639]  #2: ffff8e25922da198 (&ret->mutex){+.+.}-{3:3}, at: scrub_handle_errored_block.isra.0+0x5d2/0x1640 [btrfs]
    [ 9057.669017]  #3: ffff8e25582d4b70 (&fs_info->commit_root_sem){++++}-{3:3}, at: iterate_extent_inodes+0x10b/0x280 [btrfs]
    [ 9057.670408]
                   stack backtrace:
    [ 9057.670976] CPU: 7 PID: 30781 Comm: kworker/u16:4 Not tainted 5.14.0-rc2-btrfs-next-93 #1
    [ 9057.672030] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
    [ 9057.673492] Workqueue: btrfs-scrub btrfs_work_helper [btrfs]
    [ 9057.674258] Call Trace:
    [ 9057.674588]  dump_stack_lvl+0x57/0x72
    [ 9057.675083]  check_noncircular+0xf3/0x110
    [ 9057.675611]  __lock_acquire+0x130e/0x2210
    [ 9057.676132]  lock_acquire+0xd7/0x310
    [ 9057.676605]  ? __btrfs_tree_read_lock+0x24/0x110 [btrfs]
    [ 9057.677313]  ? lock_is_held_type+0xe8/0x140
    [ 9057.677849]  down_read_nested+0x4b/0x140
    [ 9057.678349]  ? __btrfs_tree_read_lock+0x24/0x110 [btrfs]
    [ 9057.679068]  __btrfs_tree_read_lock+0x24/0x110 [btrfs]
    [ 9057.679760]  btrfs_read_lock_root_node+0x31/0x40 [btrfs]
    [ 9057.680458]  btrfs_search_slot+0x537/0xc00 [btrfs]
    [ 9057.681083]  ? _raw_spin_unlock+0x29/0x40
    [ 9057.681594]  ? btrfs_find_all_roots_safe+0x11f/0x140 [btrfs]
    [ 9057.682336]  scrub_print_warning_inode+0x89/0x370 [btrfs]
    [ 9057.683058]  ? btrfs_find_all_roots_safe+0x11f/0x140 [btrfs]
    [ 9057.683834]  ? scrub_write_block_to_dev_replace+0xb0/0xb0 [btrfs]
    [ 9057.684632]  iterate_extent_inodes+0x1e3/0x280 [btrfs]
    [ 9057.685316]  scrub_print_warning+0x15d/0x2f0 [btrfs]
    [ 9057.685977]  ? ___ratelimit+0xa4/0x110
    [ 9057.686460]  scrub_handle_errored_block.isra.0+0x135f/0x1640 [btrfs]
    [ 9057.687316]  scrub_bio_end_io_worker+0x101/0x2e0 [btrfs]
    [ 9057.688021]  btrfs_work_helper+0xf8/0x400 [btrfs]
    [ 9057.688649]  ? lock_is_held_type+0xe8/0x140
    [ 9057.689180]  process_one_work+0x247/0x5a0
    [ 9057.689696]  worker_thread+0x55/0x3c0
    [ 9057.690175]  ? process_one_work+0x5a0/0x5a0
    [ 9057.690731]  kthread+0x155/0x180
    [ 9057.691158]  ? set_kthread_struct+0x40/0x40
    [ 9057.691697]  ret_from_fork+0x22/0x30
    
    Fix this by making btrfs_find_all_roots() never attempt to lock the
    commit_root_sem when it is called from btrfs_qgroup_trace_extent_post().
    
    We can't just pass a non-NULL transaction handle to btrfs_find_all_roots()
    from btrfs_qgroup_trace_extent_post(), because that would make backref
    lookup not use commit roots and acquire read locks on extent buffers, and
    therefore could deadlock when btrfs_qgroup_trace_extent_post() is called
    from the btrfs_truncate_inode_items() code path which has acquired a write
    lock on an extent buffer of the subvolume btree.
    
    CC: stable@vger.kernel.org # 4.19+
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6f919907e92e8bed7cd0472b26106ba7c16b9d3f
Author: Filipe Manana <fdmanana@suse.com>
Date:   Tue Jul 6 15:41:15 2021 +0100

    btrfs: fix unpersisted i_size on fsync after expanding truncate
    
    commit 9acc8103ab594f72250788cb45a43427f36d685d upstream.
    
    If we have an inode that does not have the full sync flag set, was changed
    in the current transaction, then it is logged while logging some other
    inode (like its parent directory for example), its i_size is increased by
    a truncate operation, the log is synced through an fsync of some other
    inode and then finally we explicitly call fsync on our inode, the new
    i_size is not persisted.
    
    The following example shows how to trigger it, with comments explaining
    how and why the issue happens:
    
      $ mkfs.btrfs -f /dev/sdc
      $ mount /dev/sdc /mnt
    
      $ touch /mnt/foo
      $ xfs_io -f -c "pwrite -S 0xab 0 1M" /mnt/bar
    
      $ sync
    
      # Fsync bar, this will be a noop since the file has not yet been
      # modified in the current transaction. The goal here is to clear
      # BTRFS_INODE_NEEDS_FULL_SYNC from the inode's runtime flags.
      $ xfs_io -c "fsync" /mnt/bar
    
      # Now rename both files, without changing their parent directory.
      $ mv /mnt/bar /mnt/bar2
      $ mv /mnt/foo /mnt/foo2
    
      # Increase the size of bar2 with a truncate operation.
      $ xfs_io -c "truncate 2M" /mnt/bar2
    
      # Now fsync foo2, this results in logging its parent inode (the root
      # directory), and logging the parent results in logging the inode of
      # file bar2 (its inode item and the new name). The inode of file bar2
      # is logged with an i_size of 0 bytes since it's logged in
      # LOG_INODE_EXISTS mode, meaning we are only logging its names (and
      # xattrs if it had any) and the i_size of the inode will not be changed
      # when the log is replayed.
      $ xfs_io -c "fsync" /mnt/foo2
    
      # Now explicitly fsync bar2. This resulted in doing nothing, not
      # logging the inode with the new i_size of 2M and the hole from file
      # offset 1M to 2M. Because the inode did not have the flag
      # BTRFS_INODE_NEEDS_FULL_SYNC set, when it was logged through the
      # fsync of file foo2, its last_log_commit field was updated,
      # resulting in this explicit of file bar2 not doing anything.
      $ xfs_io -c "fsync" /mnt/bar2
    
      # File bar2 content and size before a power failure.
      $ od -A d -t x1 /mnt/bar2
      0000000 ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab
      *
      1048576 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      *
      2097152
    
      <power failure>
    
      # Mount the filesystem to replay the log.
      $ mount /dev/sdc /mnt
    
      # Read the file again, should have the same content and size as before
      # the power failure happened, but it doesn't, i_size is still at 1M.
      $ od -A d -t x1 /mnt/bar2
      0000000 ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab
      *
      1048576
    
    This started to happen after commit 209ecbb8585bf6 ("btrfs: remove stale
    comment and logic from btrfs_inode_in_log()"), since btrfs_inode_in_log()
    no longer checks if the inode's list of modified extents is not empty.
    However, checking that list is not the right way to address this case
    and the check was added long time ago in commit 125c4cf9f37c98
    ("Btrfs: set inode's logged_trans/last_log_commit after ranged fsync")
    for a different purpose, to address consecutive ranged fsyncs.
    
    The reason that checking for the list emptiness makes this test pass is
    because during an expanding truncate we create an extent map to represent
    a hole from the old i_size to the new i_size, and add that extent map to
    the list of modified extents in the inode. However if we are low on
    available memory and we can not allocate a new extent map, then we don't
    treat it as an error and just set the full sync flag on the inode, so that
    the next fsync does not rely on the list of modified extents - so checking
    for the emptiness of the list to decide if the inode needs to be logged is
    not reliable, and results in not logging the inode if it was not possible
    to allocate the extent map for the hole.
    
    Fix this by ensuring that if we are only logging that an inode exists
    (inode item, names/references and xattrs), we don't update the inode's
    last_log_commit even if it does not have the full sync runtime flag set.
    
    A test case for fstests follows soon.
    
    CC: stable@vger.kernel.org # 5.13+
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a02b54480573dc45976f55f1b9c50b19dc94e70d
Author: Anand Jain <anand.jain@oracle.com>
Date:   Sun Jul 4 19:14:39 2021 +0800

    btrfs: check for missing device in btrfs_trim_fs
    
    commit 16a200f66ede3f9afa2e51d90ade017aaa18d213 upstream.
    
    A fstrim on a degraded raid1 can trigger the following null pointer
    dereference:
    
      BTRFS info (device loop0): allowing degraded mounts
      BTRFS info (device loop0): disk space caching is enabled
      BTRFS info (device loop0): has skinny extents
      BTRFS warning (device loop0): devid 2 uuid 97ac16f7-e14d-4db1-95bc-3d489b424adb is missing
      BTRFS warning (device loop0): devid 2 uuid 97ac16f7-e14d-4db1-95bc-3d489b424adb is missing
      BTRFS info (device loop0): enabling ssd optimizations
      BUG: kernel NULL pointer dereference, address: 0000000000000620
      PGD 0 P4D 0
      Oops: 0000 [#1] SMP NOPTI
      CPU: 0 PID: 4574 Comm: fstrim Not tainted 5.13.0-rc7+ #31
      Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      RIP: 0010:btrfs_trim_fs+0x199/0x4a0 [btrfs]
      RSP: 0018:ffff959541797d28 EFLAGS: 00010293
      RAX: 0000000000000000 RBX: ffff946f84eca508 RCX: a7a67937adff8608
      RDX: ffff946e8122d000 RSI: 0000000000000000 RDI: ffffffffc02fdbf0
      RBP: ffff946ea4615000 R08: 0000000000000001 R09: 0000000000000000
      R10: 0000000000000000 R11: ffff946e8122d960 R12: 0000000000000000
      R13: ffff959541797db8 R14: ffff946e8122d000 R15: ffff959541797db8
      FS:  00007f55917a5080(0000) GS:ffff946f9bc00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000620 CR3: 000000002d2c8001 CR4: 00000000000706f0
      Call Trace:
      btrfs_ioctl_fitrim+0x167/0x260 [btrfs]
      btrfs_ioctl+0x1c00/0x2fe0 [btrfs]
      ? selinux_file_ioctl+0x140/0x240
      ? syscall_trace_enter.constprop.0+0x188/0x240
      ? __x64_sys_ioctl+0x83/0xb0
      __x64_sys_ioctl+0x83/0xb0
    
    Reproducer:
    
      $ mkfs.btrfs -fq -d raid1 -m raid1 /dev/loop0 /dev/loop1
      $ mount /dev/loop0 /btrfs
      $ umount /btrfs
      $ btrfs dev scan --forget
      $ mount -o degraded /dev/loop0 /btrfs
    
      $ fstrim /btrfs
    
    The reason is we call btrfs_trim_free_extents() for the missing device,
    which uses device->bdev (NULL for missing device) to find if the device
    supports discard.
    
    Fix is to check if the device is missing before calling
    btrfs_trim_free_extents().
    
    CC: stable@vger.kernel.org # 5.4+
    Reviewed-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: Anand Jain <anand.jain@oracle.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 020d8ceab3412776ff4b921bfe5e630019bbbf18
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Wed Jul 21 19:10:08 2021 -0400

    tracing: Synthetic event field_pos is an index not a boolean
    
    commit 3b13911a2fd0dd0146c9777a254840c5466cf120 upstream.
    
    Performing the following:
    
     ># echo 'wakeup_lat s32 pid; u64 delta; char wake_comm[]' > synthetic_events
     ># echo 'hist:keys=pid:__arg__1=common_timestamp.usecs' > events/sched/sched_waking/trigger
     ># echo 'hist:keys=next_pid:pid=next_pid,delta=common_timestamp.usecs-$__arg__1:onmatch(sched.sched_waking).trace(wakeup_lat,$pid,$delta,prev_comm)'\
          > events/sched/sched_switch/trigger
     ># echo 1 > events/synthetic/enable
    
    Crashed the kernel:
    
     BUG: kernel NULL pointer dereference, address: 000000000000001b
     #PF: supervisor read access in kernel mode
     #PF: error_code(0x0000) - not-present page
     PGD 0 P4D 0
     Oops: 0000 [#1] PREEMPT SMP
     CPU: 7 PID: 0 Comm: swapper/7 Not tainted 5.13.0-rc5-test+ #104
     Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 07/14/2016
     RIP: 0010:strlen+0x0/0x20
     Code: f6 82 80 2b 0b bc 20 74 11 0f b6 50 01 48 83 c0 01 f6 82 80 2b 0b bc
      20 75 ef c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 <80> 3f 00 74 10
      48 89 f8 48 83 c0 01 80 38 9 f8 c3 31
     RSP: 0018:ffffaa75000d79d0 EFLAGS: 00010046
     RAX: 0000000000000002 RBX: ffff9cdb55575270 RCX: 0000000000000000
     RDX: ffff9cdb58c7a320 RSI: ffffaa75000d7b40 RDI: 000000000000001b
     RBP: ffffaa75000d7b40 R08: ffff9cdb40a4f010 R09: ffffaa75000d7ab8
     R10: ffff9cdb4398c700 R11: 0000000000000008 R12: ffff9cdb58c7a320
     R13: ffff9cdb55575270 R14: ffff9cdb58c7a000 R15: 0000000000000018
     FS:  0000000000000000(0000) GS:ffff9cdb5aa00000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 000000000000001b CR3: 00000000c0612006 CR4: 00000000001706e0
     Call Trace:
      trace_event_raw_event_synth+0x90/0x1d0
      action_trace+0x5b/0x70
      event_hist_trigger+0x4bd/0x4e0
      ? cpumask_next_and+0x20/0x30
      ? update_sd_lb_stats.constprop.0+0xf6/0x840
      ? __lock_acquire.constprop.0+0x125/0x550
      ? find_held_lock+0x32/0x90
      ? sched_clock_cpu+0xe/0xd0
      ? lock_release+0x155/0x440
      ? update_load_avg+0x8c/0x6f0
      ? enqueue_entity+0x18a/0x920
      ? __rb_reserve_next+0xe5/0x460
      ? ring_buffer_lock_reserve+0x12a/0x3f0
      event_triggers_call+0x52/0xe0
      trace_event_buffer_commit+0x1ae/0x240
      trace_event_raw_event_sched_switch+0x114/0x170
      __traceiter_sched_switch+0x39/0x50
      __schedule+0x431/0xb00
      schedule_idle+0x28/0x40
      do_idle+0x198/0x2e0
      cpu_startup_entry+0x19/0x20
      secondary_startup_64_no_verify+0xc2/0xcb
    
    The reason is that the dynamic events array keeps track of the field
    position of the fields array, via the field_pos variable in the
    synth_field structure. Unfortunately, that field is a boolean for some
    reason, which means any field_pos greater than 1 will be a bug (in this
    case it was 2).
    
    Link: https://lkml.kernel.org/r/20210721191008.638bce34@oasis.local.home
    
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: stable@vger.kernel.org
    Fixes: bd82631d7ccdc ("tracing: Add support for dynamic strings to synthetic events")
    Reviewed-by: Tom Zanussi <zanussi@kernel.org>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 917a5bdd114a27c159796928cb3c09723a51d1c7
Author: Haoran Luo <www@aegistudio.net>
Date:   Wed Jul 21 14:12:07 2021 +0000

    tracing: Fix bug in rb_per_cpu_empty() that might cause deadloop.
    
    commit 67f0d6d9883c13174669f88adac4f0ee656cc16a upstream.
    
    The "rb_per_cpu_empty()" misinterpret the condition (as not-empty) when
    "head_page" and "commit_page" of "struct ring_buffer_per_cpu" points to
    the same buffer page, whose "buffer_data_page" is empty and "read" field
    is non-zero.
    
    An error scenario could be constructed as followed (kernel perspective):
    
    1. All pages in the buffer has been accessed by reader(s) so that all of
    them will have non-zero "read" field.
    
    2. Read and clear all buffer pages so that "rb_num_of_entries()" will
    return 0 rendering there's no more data to read. It is also required
    that the "read_page", "commit_page" and "tail_page" points to the same
    page, while "head_page" is the next page of them.
    
    3. Invoke "ring_buffer_lock_reserve()" with large enough "length"
    so that it shot pass the end of current tail buffer page. Now the
    "head_page", "commit_page" and "tail_page" points to the same page.
    
    4. Discard current event with "ring_buffer_discard_commit()", so that
    "head_page", "commit_page" and "tail_page" points to a page whose buffer
    data page is now empty.
    
    When the error scenario has been constructed, "tracing_read_pipe" will
    be trapped inside a deadloop: "trace_empty()" returns 0 since
    "rb_per_cpu_empty()" returns 0 when it hits the CPU containing such
    constructed ring buffer. Then "trace_find_next_entry_inc()" always
    return NULL since "rb_num_of_entries()" reports there's no more entry
    to read. Finally "trace_seq_to_user()" returns "-EBUSY" spanking
    "tracing_read_pipe" back to the start of the "waitagain" loop.
    
    I've also written a proof-of-concept script to construct the scenario
    and trigger the bug automatically, you can use it to trace and validate
    my reasoning above:
    
      https://github.com/aegistudio/RingBufferDetonator.git
    
    Tests has been carried out on linux kernel 5.14-rc2
    (2734d6c1b1a089fb593ef6a23d4b70903526fe0c), my fixed version
    of kernel (for testing whether my update fixes the bug) and
    some older kernels (for range of affected kernels). Test result is
    also attached to the proof-of-concept repository.
    
    Link: https://lore.kernel.org/linux-trace-devel/YPaNxsIlb2yjSi5Y@aegistudio/
    Link: https://lore.kernel.org/linux-trace-devel/YPgrN85WL9VyrZ55@aegistudio
    
    Cc: stable@vger.kernel.org
    Fixes: bf41a158cacba ("ring-buffer: make reentrant")
    Suggested-by: Linus Torvalds <torvalds@linuxfoundation.org>
    Signed-off-by: Haoran Luo <www@aegistudio.net>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 29ecaddb8655537d298aef5d88b4380c80c72058
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Wed Jul 21 11:00:53 2021 -0400

    tracing/histogram: Rename "cpu" to "common_cpu"
    
    commit 1e3bac71c5053c99d438771fc9fa5082ae5d90aa upstream.
    
    Currently the histogram logic allows the user to write "cpu" in as an
    event field, and it will record the CPU that the event happened on.
    
    The problem with this is that there's a lot of events that have "cpu"
    as a real field, and using "cpu" as the CPU it ran on, makes it
    impossible to run histograms on the "cpu" field of events.
    
    For example, if I want to have a histogram on the count of the
    workqueue_queue_work event on its cpu field, running:
    
     ># echo 'hist:keys=cpu' > events/workqueue/workqueue_queue_work/trigger
    
    Gives a misleading and wrong result.
    
    Change the command to "common_cpu" as no event should have "common_*"
    fields as that's a reserved name for fields used by all events. And
    this makes sense here as common_cpu would be a field used by all events.
    
    Now we can even do:
    
     ># echo 'hist:keys=common_cpu,cpu if cpu < 100' > events/workqueue/workqueue_queue_work/trigger
     ># cat events/workqueue/workqueue_queue_work/hist
     # event histogram
     #
     # trigger info: hist:keys=common_cpu,cpu:vals=hitcount:sort=hitcount:size=2048 if cpu < 100 [active]
     #
    
     { common_cpu:          0, cpu:          2 } hitcount:          1
     { common_cpu:          0, cpu:          4 } hitcount:          1
     { common_cpu:          7, cpu:          7 } hitcount:          1
     { common_cpu:          0, cpu:          7 } hitcount:          1
     { common_cpu:          0, cpu:          1 } hitcount:          1
     { common_cpu:          0, cpu:          6 } hitcount:          2
     { common_cpu:          0, cpu:          5 } hitcount:          2
     { common_cpu:          1, cpu:          1 } hitcount:          4
     { common_cpu:          6, cpu:          6 } hitcount:          4
     { common_cpu:          5, cpu:          5 } hitcount:         14
     { common_cpu:          4, cpu:          4 } hitcount:         26
     { common_cpu:          0, cpu:          0 } hitcount:         39
     { common_cpu:          2, cpu:          2 } hitcount:        184
    
    Now for backward compatibility, I added a trick. If "cpu" is used, and
    the field is not found, it will fall back to "common_cpu" and work as
    it did before. This way, it will still work for old programs that use
    "cpu" to get the actual CPU, but if the event has a "cpu" as a field, it
    will get that event's "cpu" field, which is probably what it wants
    anyway.
    
    I updated the tracefs/README to include documentation about both the
    common_timestamp and the common_cpu. This way, if that text is present in
    the README, then an application can know that common_cpu is supported over
    just plain "cpu".
    
    Link: https://lkml.kernel.org/r/20210721110053.26b4f641@oasis.local.home
    
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: stable@vger.kernel.org
    Fixes: 8b7622bf94a44 ("tracing: Add cpu field for hist triggers")
    Reviewed-by: Tom Zanussi <zanussi@kernel.org>
    Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 58f47cfe5210daf71b3e6cb34570f80fee667611
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Thu Jul 22 21:52:18 2021 -0400

    tracepoints: Update static_call before tp_funcs when adding a tracepoint
    
    commit 352384d5c84ebe40fa77098cc234fe173247d8ef upstream.
    
    Because of the significant overhead that retpolines pose on indirect
    calls, the tracepoint code was updated to use the new "static_calls" that
    can modify the running code to directly call a function instead of using
    an indirect caller, and this function can be changed at runtime.
    
    In the tracepoint code that calls all the registered callbacks that are
    attached to a tracepoint, the following is done:
    
            it_func_ptr = rcu_dereference_raw((&__tracepoint_##name)->funcs);
            if (it_func_ptr) {
                    __data = (it_func_ptr)->data;
                    static_call(tp_func_##name)(__data, args);
            }
    
    If there's just a single callback, the static_call is updated to just call
    that callback directly. Once another handler is added, then the static
    caller is updated to call the iterator, that simply loops over all the
    funcs in the array and calls each of the callbacks like the old method
    using indirect calling.
    
    The issue was discovered with a race between updating the funcs array and
    updating the static_call. The funcs array was updated first and then the
    static_call was updated. This is not an issue as long as the first element
    in the old array is the same as the first element in the new array. But
    that assumption is incorrect, because callbacks also have a priority
    field, and if there's a callback added that has a higher priority than the
    callback on the old array, then it will become the first callback in the
    new array. This means that it is possible to call the old callback with
    the new callback data element, which can cause a kernel panic.
    
            static_call = callback1()
            funcs[] = {callback1,data1};
            callback2 has higher priority than callback1
    
            CPU 1                           CPU 2
            -----                           -----
    
       new_funcs = {callback2,data2},
                   {callback1,data1}
    
       rcu_assign_pointer(tp->funcs, new_funcs);
    
      /*
       * Now tp->funcs has the new array
       * but the static_call still calls callback1
       */
    
                                    it_func_ptr = tp->funcs [ new_funcs ]
                                    data = it_func_ptr->data [ data2 ]
                                    static_call(callback1, data);
    
                                    /* Now callback1 is called with
                                     * callback2's data */
    
                                    [ KERNEL PANIC ]
    
       update_static_call(iterator);
    
    To prevent this from happening, always switch the static_call to the
    iterator before assigning the tp->funcs to the new array. The iterator will
    always properly match the callback with its data.
    
    To trigger this bug:
    
      In one terminal:
    
        while :; do hackbench 50; done
    
      In another terminal
    
        echo 1 > /sys/kernel/tracing/events/sched/sched_waking/enable
        while :; do
            echo 1 > /sys/kernel/tracing/set_event_pid;
            sleep 0.5
            echo 0 > /sys/kernel/tracing/set_event_pid;
            sleep 0.5
       done
    
    And it doesn't take long to crash. This is because the set_event_pid adds
    a callback to the sched_waking tracepoint with a high priority, which will
    be called before the sched_waking trace event callback is called.
    
    Note, the removal to a single callback updates the array first, before
    changing the static_call to single callback, which is the proper order as
    the first element in the array is the same as what the static_call is
    being changed to.
    
    Link: https://lore.kernel.org/io-uring/4ebea8f0-58c9-e571-fd30-0ce4f6f09c70@samba.org/
    
    Cc: stable@vger.kernel.org
    Fixes: d25e37d89dd2f ("tracepoint: Optimize using static_call()")
    Reported-by: Stefan Metzmacher <metze@samba.org>
    tested-by: Stefan Metzmacher <metze@samba.org>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0ea2fd39f1192941bd49e9c0d93ce61cbba5f6f3
Author: Marc Zyngier <maz@kernel.org>
Date:   Tue Jul 13 19:43:26 2021 +0100

    firmware/efi: Tell memblock about EFI iomem reservations
    
    commit 2bab693a608bdf614b9fcd44083c5100f34b9f77 upstream.
    
    kexec_load_file() relies on the memblock infrastructure to avoid
    stamping over regions of memory that are essential to the survival
    of the system.
    
    However, nobody seems to agree how to flag these regions as reserved,
    and (for example) EFI only publishes its reservations in /proc/iomem
    for the benefit of the traditional, userspace based kexec tool.
    
    On arm64 platforms with GICv3, this can result in the payload being
    placed at the location of the LPI tables. Shock, horror!
    
    Let's augment the EFI reservation code with a memblock_reserve() call,
    protecting our dear tables from the secondary kernel invasion.
    
    Reported-by: Moritz Fischer <mdf@kernel.org>
    Tested-by: Moritz Fischer <mdf@kernel.org>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Cc: stable@vger.kernel.org
    Cc: Ard Biesheuvel <ardb@kernel.org>
    Cc: James Morse <james.morse@arm.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Will Deacon <will@kernel.org>
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 68a4037d5dd0e75f9b74e65c838fc1dbfddb03f1
Author: Amelie Delaunay <amelie.delaunay@foss.st.com>
Date:   Fri Jul 16 14:07:18 2021 +0200

    usb: typec: stusb160x: Don't block probing of consumer of "connector" nodes
    
    commit 6b63376722d9e1b915a2948e9b30f4ba2712e3f5 upstream.
    
    Similar as with tcpm this patch lets fw_devlink know not to wait on the
    fwnode to be populated as a struct device.
    
    Without this patch, USB functionality can be broken on some previously
    supported boards.
    
    Fixes: 28ec344bb891 ("usb: typec: tcpm: Don't block probing of consumers of "connector" nodes")
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
    Link: https://lore.kernel.org/r/20210716120718.20398-3-amelie.delaunay@foss.st.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eeb18490e8f492e85bdd6134e61c4a918c72454c
Author: Amelie Delaunay <amelie.delaunay@foss.st.com>
Date:   Fri Jul 16 14:07:17 2021 +0200

    usb: typec: stusb160x: register role switch before interrupt registration
    
    commit 86762ad4abcc549deb7a155c8e5e961b9755bcf0 upstream.
    
    During interrupt registration, attach state is checked. If attached,
    then the Type-C state is updated with typec_set_xxx functions and role
    switch is set with usb_role_switch_set_role().
    
    If the usb_role_switch parameter is error or null, the function simply
    returns 0.
    
    So, to update usb_role_switch role if a device is attached before the
    irq is registered, usb_role_switch must be registered before irq
    registration.
    
    Fixes: da0cb6310094 ("usb: typec: add support for STUSB160x Type-C controller family")
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
    Link: https://lore.kernel.org/r/20210716120718.20398-2-amelie.delaunay@foss.st.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 703527bf83917c567c2f3022ccf7564d410c97ca
Author: Martin Kepplinger <martink@posteo.de>
Date:   Wed Jul 14 08:18:07 2021 +0200

    usb: typec: tipd: Don't block probing of consumer of "connector" nodes
    
    commit 57560ee95cb7f91cf0bc31d4ae8276e0dcfe17aa upstream.
    
    Similar as with tcpm this patch lets fw_devlink know not to wait on the
    fwnode to be populated as a struct device.
    
    Without this patch, USB functionality can be broken on some previously
    supported boards.
    
    Fixes: 28ec344bb891 ("usb: typec: tcpm: Don't block probing of consumers of "connector" nodes")
    Cc: stable <stable@vger.kernel.org>
    Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Martin Kepplinger <martin.kepplinger@puri.sm>
    Link: https://lore.kernel.org/r/20210714061807.5737-1-martin.kepplinger@puri.sm
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 61c129211a3d95599a619a9fb5cb90399c7abbc9
Author: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com>
Date:   Tue Jul 20 05:41:24 2021 -0700

    usb: dwc2: gadget: Fix sending zero length packet in DDMA mode.
    
    commit d53dc38857f6dbefabd9eecfcbf67b6eac9a1ef4 upstream.
    
    Sending zero length packet in DDMA mode perform by DMA descriptor
    by setting SP (short packet) flag.
    
    For DDMA in function dwc2_hsotg_complete_in() does not need to send
    zlp.
    
    Tested by USBCV MSC tests.
    
    Fixes: f71b5e2533de ("usb: dwc2: gadget: fix zero length packet transfers")
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com>
    Link: https://lore.kernel.org/r/967bad78c55dd2db1c19714eee3d0a17cf99d74a.1626777738.git.Minas.Harutyunyan@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bd062872040bae54878ed2207c548925ab64f097
Author: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com>
Date:   Tue Jul 13 09:32:55 2021 +0400

    usb: dwc2: gadget: Fix GOUTNAK flow for Slave mode.
    
    commit fecb3a171db425e5068b27231f8efe154bf72637 upstream.
    
    Because of dwc2_hsotg_ep_stop_xfr() function uses poll
    mode, first need to mask GINTSTS_GOUTNAKEFF interrupt.
    In Slave mode GINTSTS_GOUTNAKEFF interrupt will be
    aserted only after pop OUT NAK status packet from RxFIFO.
    
    In dwc2_hsotg_ep_sethalt() function before setting
    DCTL_SGOUTNAK need to unmask GOUTNAKEFF interrupt.
    
    Tested by USBCV CH9 and MSC tests set in Slave, BDMA and DDMA.
    All tests are passed.
    
    Fixes: a4f827714539a ("usb: dwc2: gadget: Disable enabled HW endpoint in dwc2_hsotg_ep_disable")
    Fixes: 6070636c4918c ("usb: dwc2: Fix Stalling a Non-Isochronous OUT EP")
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com>
    Link: https://lore.kernel.org/r/e17fad802bbcaf879e1ed6745030993abb93baf8.1626152924.git.Minas.Harutyunyan@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 36b53430c97f9e5e7298896fb017bc4f141eca47
Author: Marek Szyprowski <m.szyprowski@samsung.com>
Date:   Fri Jul 16 07:01:27 2021 +0200

    usb: dwc2: Skip clock gating on Samsung SoCs
    
    commit c4a0f7a6ab5417eb6105b0e1d7e6e67f6ef7d4e5 upstream.
    
    Commit 0112b7ce68ea ("usb: dwc2: Update dwc2_handle_usb_suspend_intr
    function.") changed the way the driver handles power down modes in a such
    way that it uses clock gating when no other power down mode is available.
    
    This however doesn't work well on the DWC2 implementation used on the
    Samsung SoCs. When a clock gating is enabled, system hangs. It looks that
    the proper clock gating requires some additional glue code in the shared
    USB2 PHY and/or Samsung glue code for the DWC2. To restore driver
    operation on the Samsung SoCs simply skip enabling clock gating mode
    until one finds what is really needed to make it working reliably.
    
    Fixes: 0112b7ce68ea ("usb: dwc2: Update dwc2_handle_usb_suspend_intr function.")
    Cc: stable <stable@vger.kernel.org>
    Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
    Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Link: https://lore.kernel.org/r/20210716050127.4406-1-m.szyprowski@samsung.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b85e8638ba15b43dc7ed7d5242249ad520e00b45
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Fri Jun 18 22:14:41 2021 +0800

    usb: gadget: Fix Unbalanced pm_runtime_enable in tegra_xudc_probe
    
    commit 5b01248156bd75303e66985c351dee648c149979 upstream.
    
    Add missing pm_runtime_disable() when probe error out. It could
    avoid pm_runtime implementation complains when removing and probing
    again the driver.
    
    Fixes: 49db427232fe ("usb: gadget: Add UDC driver for tegra XUSB device mode controller")
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Link: https://lore.kernel.org/r/20210618141441.107817-1-zhangqilong3@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7138b108ecdbbe7e96a5157db2874af69013f159
Author: John Keeping <john@metanate.com>
Date:   Wed Jul 21 17:17:45 2021 +0100

    USB: serial: cp210x: add ID for CEL EM3588 USB ZigBee stick
    
    commit d6a206e60124a9759dd7f6dfb86b0e1d3b1df82e upstream.
    
    Add the USB serial device ID for the CEL ZigBee EM3588 radio stick.
    
    Signed-off-by: John Keeping <john@metanate.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f1a01c2b462835f7b8ef7654d5902d477e2c304d
Author: Ian Ray <ian.ray@ge.com>
Date:   Mon Jul 19 18:43:49 2021 +0200

    USB: serial: cp210x: fix comments for GE CS1000
    
    commit e9db418d4b828dd049caaf5ed65dc86f93bb1a0c upstream.
    
    Fix comments for GE CS1000 CP210x USB ID assignments.
    
    Fixes: 42213a0190b5 ("USB: serial: cp210x: add some more GE USB IDs")
    Signed-off-by: Ian Ray <ian.ray@ge.com>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8a55cb17e401851a0f49cc9792c05a5af82b1bab
Author: Marco De Marco <marco.demarco@posteo.net>
Date:   Mon Jul 5 19:44:21 2021 +0000

    USB: serial: option: add support for u-blox LARA-R6 family
    
    commit 94b619a07655805a1622484967754f5848640456 upstream.
    
    The patch is meant to support LARA-R6 Cat 1 module family.
    
    Module USB ID:
    Vendor  ID: 0x05c6
    Product ID: 0x90fA
    
    Interface layout:
    If 0: Diagnostic
    If 1: AT parser
    If 2: AT parser
    If 3: QMI wwan (not available in all versions)
    
    Signed-off-by: Marco De Marco <marco.demarco@posteo.net>
    Link: https://lore.kernel.org/r/49260184.kfMIbaSn9k@mars
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c9d143a3d8aa7faecacd34d1c5ca903311b92996
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date:   Thu Jun 24 21:20:39 2021 +0900

    usb: renesas_usbhs: Fix superfluous irqs happen after usb_pkt_pop()
    
    commit 5719df243e118fb343725e8b2afb1637e1af1373 upstream.
    
    This driver has a potential issue which this driver is possible to
    cause superfluous irqs after usb_pkt_pop() is called. So, after
    the commit 3af32605289e ("usb: renesas_usbhs: fix error return
    code of usbhsf_pkt_handler()") had been applied, we could observe
    the following error happened when we used g_audio.
    
        renesas_usbhs e6590000.usb: irq_ready run_error 1 : -22
    
    To fix the issue, disable the tx or rx interrupt in usb_pkt_pop().
    
    Fixes: 2743e7f90dc0 ("usb: renesas_usbhs: fix the usb_pkt_pop()")
    Cc: <stable@vger.kernel.org> # v4.4+
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Link: https://lore.kernel.org/r/20210624122039.596528-1-yoshihiro.shimoda.uh@renesas.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d4179cdb769a651f2ae89c325612a69bf6fbdf70
Author: Mark Tomlinson <mark.tomlinson@alliedtelesis.co.nz>
Date:   Fri Jun 25 15:14:56 2021 +1200

    usb: max-3421: Prevent corruption of freed memory
    
    commit b5fdf5c6e6bee35837e160c00ac89327bdad031b upstream.
    
    The MAX-3421 USB driver remembers the state of the USB toggles for a
    device/endpoint. To save SPI writes, this was only done when a new
    device/endpoint was being used. Unfortunately, if the old device was
    removed, this would cause writes to freed memory.
    
    To fix this, a simpler scheme is used. The toggles are read from
    hardware when a URB is completed, and the toggles are always written to
    hardware when any URB transaction is started. This will cause a few more
    SPI transactions, but no causes kernel panics.
    
    Fixes: 2d53139f3162 ("Add support for using a MAX3421E chip as a host driver.")
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Mark Tomlinson <mark.tomlinson@alliedtelesis.co.nz>
    Link: https://lore.kernel.org/r/20210625031456.8632-1-mark.tomlinson@alliedtelesis.co.nz
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3b5d8c72ffd5f5d347a90013d7b508a12b9d0b9c
Author: Julian Sikorski <belegdol@gmail.com>
Date:   Tue Jul 20 19:19:10 2021 +0200

    USB: usb-storage: Add LaCie Rugged USB3-FW to IGNORE_UAS
    
    commit 6abf2fe6b4bf6e5256b80c5817908151d2d33e9f upstream.
    
    LaCie Rugged USB3-FW appears to be incompatible with UAS. It generates
    errors like:
    [ 1151.582598] sd 14:0:0:0: tag#16 uas_eh_abort_handler 0 uas-tag 1 inflight: IN
    [ 1151.582602] sd 14:0:0:0: tag#16 CDB: Report supported operation codes a3 0c 01 12 00 00 00 00 02 00 00 00
    [ 1151.588594] scsi host14: uas_eh_device_reset_handler start
    [ 1151.710482] usb 2-4: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
    [ 1151.741398] scsi host14: uas_eh_device_reset_handler success
    [ 1181.785534] scsi host14: uas_eh_device_reset_handler start
    
    Signed-off-by: Julian Sikorski <belegdol+github@gmail.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20210720171910.36497-1-belegdol+github@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9499b2d2cc601745eb9b57ecd983931a17f66eae
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Thu Jul 15 18:01:21 2021 +0300

    usb: hub: Fix link power management max exit latency (MEL) calculations
    
    commit 1bf2761c837571a66ec290fb66c90413821ffda2 upstream.
    
    Maximum Exit Latency (MEL) value is used by host to know how much in
    advance it needs to start waking up a U1/U2 suspended link in order to
    service a periodic transfer in time.
    
    Current MEL calculation only includes the time to wake up the path from
    U1/U2 to U0. This is called tMEL1 in USB 3.1 section C 1.5.2
    
    Total MEL = tMEL1 + tMEL2 +tMEL3 + tMEL4 which should additinally include:
    - tMEL2 which is the time it takes for PING message to reach device
    - tMEL3 time for device to process the PING and submit a PING_RESPONSE
    - tMEL4 time for PING_RESPONSE to traverse back upstream to host.
    
    Add the missing tMEL2, tMEL3 and tMEL4 to MEL calculation.
    
    Cc: <stable@kernel.org> # v3.5
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20210715150122.1995966-1-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c7affd5b02265fc8cdb06453f701cd78f531171e
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Thu Jul 15 18:01:22 2021 +0300

    usb: hub: Disable USB 3 device initiated lpm if exit latency is too high
    
    commit 1b7f56fbc7a1b66967b6114d1b5f5a257c3abae6 upstream.
    
    The device initiated link power management U1/U2 states should not be
    enabled in case the system exit latency plus one bus interval (125us) is
    greater than the shortest service interval of any periodic endpoint.
    
    This is the case for both U1 and U2 sytstem exit latencies and link states.
    
    See USB 3.2 section 9.4.9 "Set Feature" for more details
    
    Note, before this patch the host and device initiated U1/U2 lpm states
    were both enabled with lpm. After this patch it's possible to end up with
    only host inititated U1/U2 lpm in case the exit latencies won't allow
    device initiated lpm.
    
    If this case we still want to set the udev->usb3_lpm_ux_enabled flag so
    that sysfs users can see the link may go to U1/U2.
    
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20210715150122.1995966-2-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1408e47ab233d78b43af735a6bbf64f503260f51
Author: Nicholas Piggin <npiggin@gmail.com>
Date:   Thu Jul 8 21:26:22 2021 +1000

    KVM: PPC: Book3S HV Nested: Sanitise H_ENTER_NESTED TM state
    
    commit d9c57d3ed52a92536f5fa59dc5ccdd58b4875076 upstream.
    
    The H_ENTER_NESTED hypercall is handled by the L0, and it is a request
    by the L1 to switch the context of the vCPU over to that of its L2
    guest, and return with an interrupt indication. The L1 is responsible
    for switching some registers to guest context, and the L0 switches
    others (including all the hypervisor privileged state).
    
    If the L2 MSR has TM active, then the L1 is responsible for
    recheckpointing the L2 TM state. Then the L1 exits to L0 via the
    H_ENTER_NESTED hcall, and the L0 saves the TM state as part of the exit,
    and then it recheckpoints the TM state as part of the nested entry and
    finally HRFIDs into the L2 with TM active MSR. Not efficient, but about
    the simplest approach for something that's horrendously complicated.
    
    Problems arise if the L1 exits to the L0 with a TM state which does not
    match the L2 TM state being requested. For example if the L1 is
    transactional but the L2 MSR is non-transactional, or vice versa. The
    L0's HRFID can take a TM Bad Thing interrupt and crash.
    
    Fix this by disallowing H_ENTER_NESTED in TM[T] state entirely, and then
    ensuring that if the L1 is suspended then the L2 must have TM active,
    and if the L1 is not suspended then the L2 must not have TM active.
    
    Fixes: 360cae313702 ("KVM: PPC: Book3S HV: Nested guest entry via hypercall")
    Cc: stable@vger.kernel.org # v4.20+
    Reported-by: Alexey Kardashevskiy <aik@ozlabs.ru>
    Acked-by: Michael Neuling <mikey@neuling.org>
    Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 35e114e6f84ab559eb35a5ac73590d23a43f22ba
Author: Nicholas Piggin <npiggin@gmail.com>
Date:   Tue Jul 20 20:43:09 2021 +1000

    KVM: PPC: Book3S: Fix H_RTAS rets buffer overflow
    
    commit f62f3c20647ebd5fb6ecb8f0b477b9281c44c10a upstream.
    
    The kvmppc_rtas_hcall() sets the host rtas_args.rets pointer based on
    the rtas_args.nargs that was provided by the guest. That guest nargs
    value is not range checked, so the guest can cause the host rets pointer
    to be pointed outside the args array. The individual rtas function
    handlers check the nargs and nrets values to ensure they are correct,
    but if they are not, the handlers store a -3 (0xfffffffd) failure
    indication in rets[0] which corrupts host memory.
    
    Fix this by testing up front whether the guest supplied nargs and nret
    would exceed the array size, and fail the hcall directly without storing
    a failure indication to rets[0].
    
    Also expand on a comment about why we kill the guest and try not to
    return errors directly if we have a valid rets[0] pointer.
    
    Fixes: 8e591cb72047 ("KVM: PPC: Book3S: Add infrastructure to implement kernel-side RTAS calls")
    Cc: stable@vger.kernel.org # v3.10+
    Reported-by: Alexey Kardashevskiy <aik@ozlabs.ru>
    Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d98808e2414bdb06a7e392260ea17fa7929a5ee
Author: David Jeffery <djeffery@redhat.com>
Date:   Thu Jul 15 17:37:44 2021 -0400

    usb: ehci: Prevent missed ehci interrupts with edge-triggered MSI
    
    commit 0b60557230adfdeb8164e0b342ac9cd469a75759 upstream.
    
    When MSI is used by the ehci-hcd driver, it can cause lost interrupts which
    results in EHCI only continuing to work due to a polling fallback. But the
    reliance of polling drastically reduces performance of any I/O through EHCI.
    
    Interrupts are lost as the EHCI interrupt handler does not safely handle
    edge-triggered interrupts. It fails to ensure all interrupt status bits are
    cleared, which works with level-triggered interrupts but not the
    edge-triggered interrupts typical from using MSI.
    
    To fix this problem, check if the driver may have raced with the hardware
    setting additional interrupt status bits and clear status until it is in a
    stable state.
    
    Fixes: 306c54d0edb6 ("usb: hcd: Try MSI interrupts on PCI devices")
    Tested-by: Laurence Oberman <loberman@redhat.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: David Jeffery <djeffery@redhat.com>
    Link: https://lore.kernel.org/r/20210715213744.GA44506@redhat
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2c476bab281843c1f2eb8bc37622f27580b506ef
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Thu Jul 15 18:06:51 2021 +0300

    xhci: Fix lost USB 2 remote wake
    
    commit 72f68bf5c756f5ce1139b31daae2684501383ad5 upstream.
    
    There's a small window where a USB 2 remote wake may be left unhandled
    due to a race between hub thread and xhci port event interrupt handler.
    
    When the resume event is detected in the xhci interrupt handler it kicks
    the hub timer, which should move the port from resume to U0 once resume
    has been signalled for long enough.
    
    To keep the hub "thread" running we set a bus_state->resuming_ports flag.
    This flag makes sure hub timer function kicks itself.
    
    checking this flag was not properly protected by the spinlock. Flag was
    copied to a local variable before lock was taken. The local variable was
    then checked later with spinlock held.
    
    If interrupt is handled right after copying the flag to the local variable
    we end up stopping the hub thread before it can handle the USB 2 resume.
    
    CPU0                                    CPU1
    (hub thread)                            (xhci event handler)
    
    xhci_hub_status_data()
    status = bus_state->resuming_ports;
                                            <Interrupt>
                                            handle_port_status()
                                            spin_lock()
                                            bus_state->resuming_ports = 1
                                            set_flag(HCD_FLAG_POLL_RH)
                                            spin_unlock()
    spin_lock()
    if (!status)
      clear_flag(HCD_FLAG_POLL_RH)
    spin_unlock()
    
    Fix this by taking the lock a bit earlier so that it covers
    the resuming_ports flag copy in the hub thread
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20210715150651.1996099-2-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c15cef90a456b265e1a39d7c42339ee2204f824
Author: Greg Thelen <gthelen@google.com>
Date:   Fri Jul 2 00:12:24 2021 -0700

    usb: xhci: avoid renesas_usb_fw.mem when it's unusable
    
    commit 0665e387318607d8269bfdea60723c627c8bae43 upstream.
    
    Commit a66d21d7dba8 ("usb: xhci: Add support for Renesas controller with
    memory") added renesas_usb_fw.mem firmware reference to xhci-pci.  Thus
    modinfo indicates xhci-pci.ko has "firmware: renesas_usb_fw.mem".  But
    the firmware is only actually used with CONFIG_USB_XHCI_PCI_RENESAS.  An
    unusable firmware reference can trigger safety checkers which look for
    drivers with unmet firmware dependencies.
    
    Avoid referring to renesas_usb_fw.mem in circumstances when it cannot be
    loaded (when CONFIG_USB_XHCI_PCI_RENESAS isn't set).
    
    Fixes: a66d21d7dba8 ("usb: xhci: Add support for Renesas controller with memory")
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Thelen <gthelen@google.com>
    Link: https://lore.kernel.org/r/20210702071224.3673568-1-gthelen@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 62b022edb1874e5527223623312c18db5d268d4e
Author: Moritz Fischer <mdf@kernel.org>
Date:   Mon Jul 19 00:05:19 2021 -0700

    Revert "usb: renesas-xhci: Fix handling of unknown ROM state"
    
    commit 44cf53602f5a0db80d53c8fff6cdbcae59650a42 upstream.
    
    This reverts commit d143825baf15f204dac60acdf95e428182aa3374.
    
    Justin reports some of his systems now fail as result of this commit:
    
     xhci_hcd 0000:04:00.0: Direct firmware load for renesas_usb_fw.mem failed with error -2
     xhci_hcd 0000:04:00.0: request_firmware failed: -2
     xhci_hcd: probe of 0000:04:00.0 failed with error -2
    
    The revert brings back the original issue the commit tried to solve but
    at least unbreaks existing systems relying on previous behavior.
    
    Cc: stable@vger.kernel.org
    Cc: Mathias Nyman <mathias.nyman@intel.com>
    Cc: Vinod Koul <vkoul@kernel.org>
    Cc: Justin Forbes <jmforbes@linuxtx.org>
    Reported-by: Justin Forbes <jmforbes@linuxtx.org>
    Signed-off-by: Moritz Fischer <mdf@kernel.org>
    Fixes: d143825baf15 ("usb: renesas-xhci: Fix handling of unknown ROM state")
    Link: https://lore.kernel.org/r/20210719070519.41114-1-mdf@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0def8cf06098d630b904be51045088345403c986
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Jul 20 11:26:40 2021 +0200

    ALSA: pcm: Fix mmap capability check
    
    commit c4824ae7db418aee6f50f308a20b832e58e997fd upstream.
    
    The hw_support_mmap() doesn't cover all memory allocation types and
    might use a wrong device pointer for checking the capability.
    Check the all memory allocation types more completely.
    
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20210720092640.12338-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7ca1bb5bace3a750d14ed7bb1dfc59df94339fe2
Author: Alan Young <consult.awy@gmail.com>
Date:   Fri Jul 9 09:48:54 2021 +0100

    ALSA: pcm: Call substream ack() method upon compat mmap commit
    
    commit 2e2832562c877e6530b8480982d99a4ff90c6777 upstream.
    
    If a 32-bit application is being used with a 64-bit kernel and is using
    the mmap mechanism to write data, then the SNDRV_PCM_IOCTL_SYNC_PTR
    ioctl results in calling snd_pcm_ioctl_sync_ptr_compat(). Make this use
    pcm_lib_apply_appl_ptr() so that the substream's ack() method, if
    defined, is called.
    
    The snd_pcm_sync_ptr() function, used in the 64-bit ioctl case, already
    uses snd_pcm_ioctl_sync_ptr_compat().
    
    Fixes: 9027c4639ef1 ("ALSA: pcm: Call ack() whenever appl_ptr is updated")
    Signed-off-by: Alan Young <consult.awy@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/c441f18c-eb2a-3bdd-299a-696ccca2de9c@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7810cd82b1ad3c9422242933ad6dd435e1ebc3a9
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Jul 16 15:56:00 2021 +0200

    ALSA: hdmi: Expose all pins on MSI MS-7C94 board
    
    commit 33f735f137c6539e3ceceb515cd1e2a644005b49 upstream.
    
    The BIOS on MSI Mortar B550m WiFi (MS-7C94) board with AMDGPU seems
    disabling the other pins than HDMI although it has more outputs
    including DP.
    
    This patch adds the board to the allow list for enabling all pins.
    
    Reported-by: Damjan Georgievski <gdamjan@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/CAEk1YH4Jd0a8vfZxORVu7qg+Zsc-K+pR187ezNq8QhJBPW4gpw@mail.gmail.com
    Link: https://lore.kernel.org/r/20210716135600.24176-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7b75c0f0a668d8bb037427a1bfa2d5944ae2c7a5
Author: Hui Wang <hui.wang@canonical.com>
Date:   Mon Jul 19 11:02:31 2021 +0800

    ALSA: hda/realtek: Fix pop noise and 2 Front Mic issues on a machine
    
    commit e4efa82660e6d80338c554e45e903714e1b2c27b upstream.
    
    This is a Lenovo ThinkStation machine which uses the codec alc623.
    There are 2 issues on this machine, the 1st one is the pop noise in
    the lineout, the 2nd one is there are 2 Front Mics and pulseaudio
    can't handle them, After applying the fixup of
    ALC623_FIXUP_LENOVO_THINKSTATION_P340 to this machine, the 2 issues
    are fixed.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Hui Wang <hui.wang@canonical.com>
    Link: https://lore.kernel.org/r/20210719030231.6870-1-hui.wang@canonical.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ac8ea355df6de4d5bb30f52eba38bb6a74d526b9
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Jul 16 15:27:23 2021 +0200

    ALSA: sb: Fix potential ABBA deadlock in CSP driver
    
    commit 1c2b9519159b470ef24b2638f4794e86e2952ab7 upstream.
    
    SB16 CSP driver may hit potentially a typical ABBA deadlock in two
    code paths:
    
     In snd_sb_csp_stop():
         spin_lock_irqsave(&p->chip->mixer_lock, flags);
         spin_lock(&p->chip->reg_lock);
    
     In snd_sb_csp_load():
         spin_lock_irqsave(&p->chip->reg_lock, flags);
         spin_lock(&p->chip->mixer_lock);
    
    Also the similar pattern is seen in snd_sb_csp_start().
    
    Although the practical impact is very small (those states aren't
    triggered in the same running state and this happens only on a real
    hardware, decades old ISA sound boards -- which must be very difficult
    to find nowadays), it's a real scenario and has to be fixed.
    
    This patch addresses those deadlocks by splitting the locks in
    snd_sb_csp_start() and snd_sb_csp_stop() for avoiding the nested
    locks.
    
    Reported-by: Jia-Ju Bai <baijiaju1990@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/7b0fcdaf-cd4f-4728-2eae-48c151a92e10@gmail.com
    Link: https://lore.kernel.org/r/20210716132723.13216-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ecdaa97166666e825c1c8128d0598d577d437174
Author: Alexander Tsoy <alexander@tsoy.me>
Date:   Thu Jul 22 02:56:05 2021 +0300

    ALSA: usb-audio: Add registration quirk for JBL Quantum headsets
    
    commit b0084afde27fe8a504377dee65f55bc6aa776937 upstream.
    
    These devices has two interfaces, but only the second interface
    contains the capture endpoint, thus quirk is required to delay the
    registration until the second interface appears.
    
    Tested-by: Jakub Fišer <jakub@ufiseru.cz>
    Signed-off-by: Alexander Tsoy <alexander@tsoy.me>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20210721235605.53741-1-alexander@tsoy.me
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 498129dedee00af52408e4ad0f9ef91b4ba9e821
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Jul 14 10:48:36 2021 +0200

    ALSA: usb-audio: Add missing proc text entry for BESPOKEN type
    
    commit 64752a95b702817602d72f109ceaf5ec0780e283 upstream.
    
    Recently we've added a new usb_mixer element type, USB_MIXER_BESPOKEN,
    but it wasn't added in the table in snd_usb_mixer_dump_cval().  This
    is no big problem since each bespoken type should have its own dump
    method, but it still isn't disallowed to use the standard one, so we
    should cover it as well.  Along with it, define the table with the
    explicit array initializer for avoiding other pitfalls.
    
    Fixes: 785b6f29a795 ("ALSA: usb-audio: scarlett2: Fix wrong resume call")
    Reported-by: Pavel Machek <pavel@denx.de>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20210714084836.1977-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ca4c5e5c7bebe30de6048c1f65fb22a659393cce
Author: Alexander Egorenkov <egorenar@linux.ibm.com>
Date:   Fri Jul 16 22:00:22 2021 +0200

    s390/boot: fix use of expolines in the DMA code
    
    commit 463f36c76fa4ec015c640ff63ccf52e7527abee0 upstream.
    
    The DMA code section of the decompressor must be compiled with expolines
    if Spectre V2 mitigation has been enabled for the decompressed kernel.
    This is required because although the decompressor's image contains
    the DMA code section, it is handed over to the decompressed kernel for use.
    
    Because the DMA code is already slow w/o expolines, use expolines always
    regardless whether the decompressed kernel is using them or not. This
    simplifies the DMA code by dropping the conditional compilation of
    expolines.
    
    Fixes: bf72630130c2 ("s390: use proper expoline sections for .dma code")
    Cc: <stable@vger.kernel.org> # 5.2
    Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
    Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fde6627ce6dc6864f2b17b6408dc36d012524fb5
Author: Vasily Gorbik <gor@linux.ibm.com>
Date:   Fri Jun 25 23:50:07 2021 +0200

    s390/ftrace: fix ftrace_update_ftrace_func implementation
    
    commit f8c2602733c953ed7a16e060640b8e96f9d94b9b upstream.
    
    s390 enforces DYNAMIC_FTRACE if FUNCTION_TRACER is selected.
    At the same time implementation of ftrace_caller is not compliant with
    HAVE_DYNAMIC_FTRACE since it doesn't provide implementation of
    ftrace_update_ftrace_func() and calls ftrace_trace_function() directly.
    
    The subtle difference is that during ftrace code patching ftrace
    replaces function tracer via ftrace_update_ftrace_func() and activates
    it back afterwards. Unexpected direct calls to ftrace_trace_function()
    during ftrace code patching leads to nullptr-dereferences when tracing
    is activated for one of functions which are used during code patching.
    Those function currently are:
    copy_from_kernel_nofault()
    copy_from_kernel_nofault_allowed()
    preempt_count_sub() [with debug_defconfig]
    preempt_count_add() [with debug_defconfig]
    
    Corresponding KASAN report:
     BUG: KASAN: nullptr-dereference in function_trace_call+0x316/0x3b0
     Read of size 4 at addr 0000000000001e08 by task migration/0/15
    
     CPU: 0 PID: 15 Comm: migration/0 Tainted: G B 5.13.0-41423-g08316af3644d
     Hardware name: IBM 3906 M04 704 (LPAR)
     Stopper: multi_cpu_stop+0x0/0x3e0 <- stop_machine_cpuslocked+0x1e4/0x218
     Call Trace:
      [<0000000001f77caa>] show_stack+0x16a/0x1d0
      [<0000000001f8de42>] dump_stack+0x15a/0x1b0
      [<0000000001f81d56>] print_address_description.constprop.0+0x66/0x2e0
      [<000000000082b0ca>] kasan_report+0x152/0x1c0
      [<00000000004cfd8e>] function_trace_call+0x316/0x3b0
      [<0000000001fb7082>] ftrace_caller+0x7a/0x7e
      [<00000000006bb3e6>] copy_from_kernel_nofault_allowed+0x6/0x10
      [<00000000006bb42e>] copy_from_kernel_nofault+0x3e/0xd0
      [<000000000014605c>] ftrace_make_call+0xb4/0x1f8
      [<000000000047a1b4>] ftrace_replace_code+0x134/0x1d8
      [<000000000047a6e0>] ftrace_modify_all_code+0x120/0x1d0
      [<000000000047a7ec>] __ftrace_modify_code+0x5c/0x78
      [<000000000042395c>] multi_cpu_stop+0x224/0x3e0
      [<0000000000423212>] cpu_stopper_thread+0x33a/0x5a0
      [<0000000000243ff2>] smpboot_thread_fn+0x302/0x708
      [<00000000002329ea>] kthread+0x342/0x408
      [<00000000001066b2>] __ret_from_fork+0x92/0xf0
      [<0000000001fb57fa>] ret_from_fork+0xa/0x30
    
     The buggy address belongs to the page:
     page:(____ptrval____) refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1
     flags: 0x1ffff00000001000(reserved|node=0|zone=0|lastcpupid=0x1ffff)
     raw: 1ffff00000001000 0000040000000048 0000040000000048 0000000000000000
     raw: 0000000000000000 0000000000000000 ffffffff00000001 0000000000000000
     page dumped because: kasan: bad access detected
    
     Memory state around the buggy address:
      0000000000001d00: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
      0000000000001d80: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
     >0000000000001e00: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
                           ^
      0000000000001e80: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
      0000000000001f00: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
     ==================================================================
    
    To fix that introduce ftrace_func callback to be called from
    ftrace_caller and update it in ftrace_update_ftrace_func().
    
    Fixes: 4cc9bed034d1 ("[S390] cleanup ftrace backend functions")
    Cc: stable@vger.kernel.org
    Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 93af4d65538c3e36802f3b45720a5ae6f8076f0a
Author: Stephen Boyd <swboyd@chromium.org>
Date:   Wed Jun 23 00:50:02 2021 -0700

    mmc: core: Don't allocate IDA for OF aliases
    
    commit 10252bae863d09b9648bed2e035572d207200ca1 upstream.
    
    There's a chance that the IDA allocated in mmc_alloc_host() is not freed
    for some time because it's freed as part of a class' release function
    (see mmc_host_classdev_release() where the IDA is freed). If another
    thread is holding a reference to the class, then only once all balancing
    device_put() calls (in turn calling kobject_put()) have been made will
    the IDA be released and usable again.
    
    Normally this isn't a problem because the kobject is released before
    anything else that may want to use the same number tries to again, but
    with CONFIG_DEBUG_KOBJECT_RELEASE=y and OF aliases it becomes pretty
    easy to try to allocate an alias from the IDA twice while the first time
    it was allocated is still pending a call to ida_simple_remove(). It's
    also possible to trigger it by using CONFIG_DEBUG_KOBJECT_RELEASE and
    probe defering a driver at boot that calls mmc_alloc_host() before
    trying to get resources that may defer likes clks or regulators.
    
    Instead of allocating from the IDA in this scenario, let's just skip it
    if we know this is an OF alias. The number is already "claimed" and
    devices that aren't using OF aliases won't try to use the claimed
    numbers anyway (see mmc_first_nonreserved_index()). This should avoid
    any issues with mmc_alloc_host() returning failures from the
    ida_simple_get() in the case that we're using an OF alias.
    
    Cc: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
    Cc: Sujit Kautkar <sujitka@chromium.org>
    Reported-by: Zubin Mithra <zsm@chromium.org>
    Fixes: fa2d0aa96941 ("mmc: core: Allow setting slot index via device tree alias")
    Signed-off-by: Stephen Boyd <swboyd@chromium.org>
    Link: https://lore.kernel.org/r/20210623075002.1746924-3-swboyd@chromium.org
    Cc: stable@vger.kernel.org
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 025b6262dc963796992ca32c812f2794e02b6a4f
Author: Olivier Langlois <olivier@trillion01.com>
Date:   Wed Jun 23 11:50:11 2021 -0700

    io_uring: Fix race condition when sqp thread goes to sleep
    
    commit 997135017716c33f3405e86cca5da9567b40a08e upstream.
    
    If an asynchronous completion happens before the task is preparing
    itself to wait and set its state to TASK_INTERRUPTIBLE, the completion
    will not wake up the sqp thread.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Olivier Langlois <olivier@trillion01.com>
    Reviewed-by: Pavel Begunkov <asml.silence@gmail.com>
    Link: https://lore.kernel.org/r/d1419dc32ec6a97b453bee34dc03fa6a02797142.1624473200.git.olivier@trillion01.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ccf23a0888077a25a0793a746c3941db2a7562e4
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat Jul 24 15:25:54 2021 -0700

    ACPI: fix NULL pointer dereference
    
    commit fc68f42aa737dc15e7665a4101d4168aadb8e4c4 upstream.
    
    Commit 71f642833284 ("ACPI: utils: Fix reference counting in
    for_each_acpi_dev_match()") started doing "acpi_dev_put()" on a pointer
    that was possibly NULL.  That fails miserably, because that helper
    inline function is not set up to handle that case.
    
    Just make acpi_dev_put() silently accept a NULL pointer, rather than
    calling down to put_device() with an invalid offset off that NULL
    pointer.
    
    Link: https://lore.kernel.org/lkml/a607c149-6bf6-0fd0-0e31-100378504da2@kernel.dk/
    Reported-and-tested-by: Jens Axboe <axboe@kernel.dk>
    Tested-by: Daniel Scally <djrscally@gmail.com>
    Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 343b467acb55ccafdbb5ad7a3df397040758bff7
Author: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
Date:   Wed Jun 30 18:54:38 2021 -0700

    proc: Avoid mixing integer types in mem_rw()
    
    [ Upstream commit d238692b4b9f2c36e35af4c6e6f6da36184aeb3e ]
    
    Use size_t when capping the count argument received by mem_rw(). Since
    count is size_t, using min_t(int, ...) can lead to a negative value
    that will later be passed to access_remote_vm(), which can cause
    unexpected behavior.
    
    Since we are capping the value to at maximum PAGE_SIZE, the conversion
    from size_t to int when passing it to access_remote_vm() as "len"
    shouldn't be a problem.
    
    Link: https://lkml.kernel.org/r/20210512125215.3348316-1-marcelo.cerri@canonical.com
    Reviewed-by: David Disseldorp <ddiss@suse.de>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
    Signed-off-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
    Cc: Alexey Dobriyan <adobriyan@gmail.com>
    Cc: Souza Cascardo <cascardo@canonical.com>
    Cc: Christian Brauner <christian.brauner@ubuntu.com>
    Cc: Michel Lespinasse <walken@google.com>
    Cc: Helge Deller <deller@gmx.de>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Lorenzo Stoakes <lstoakes@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 11b40c8a67fe12d9ce449c130be9567a9663ad72
Author: Ronnie Sahlberg <lsahlber@redhat.com>
Date:   Fri Jul 23 11:21:24 2021 +1000

    cifs: fix fallocate when trying to allocate a hole.
    
    [ Upstream commit 488968a8945c119859d91bb6a8dc13bf50002f15 ]
    
    Remove the conditional checking for out_data_len and skipping the fallocate
    if it is 0. This is wrong will actually change any legitimate the fallocate
    where the entire region is unallocated into a no-op.
    
    Additionally, before allocating the range, if FALLOC_FL_KEEP_SIZE is set then
    we need to clamp the length of the fallocate region as to not extend the size of the file.
    
    Fixes: 966a3cb7c7db ("cifs: improve fallocate emulation")
    Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a803678bd60e7a767138fda0b9f3ec05ec8b9534
Author: Ronnie Sahlberg <lsahlber@redhat.com>
Date:   Thu Jul 22 14:53:32 2021 +1000

    cifs: only write 64kb at a time when fallocating a small region of a file
    
    [ Upstream commit 2485bd7557a7edb4520b4072af464f0a08c8efe0 ]
    
    We only allow sending single credit writes through the SMB2_write() synchronous
    api so split this into smaller chunks.
    
    Fixes: 966a3cb7c7db ("cifs: improve fallocate emulation")
    
    Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com>
    Reported-by: Namjae Jeon <namjae.jeon@samsung.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ea826bd778f53507ab810b0380d0823761bdbce8
Author: Ioana Ciornei <ioana.ciornei@nxp.com>
Date:   Thu Jul 22 15:15:51 2021 +0300

    dpaa2-switch: seed the buffer pool after allocating the swp
    
    [ Upstream commit 7aaa0f311e2df2704fa8ddb8ed681a3b5841d0bf ]
    
    Any interraction with the buffer pool (seeding a buffer, acquire one) is
    made through a software portal (SWP, a DPIO object).
    There are circumstances where the dpaa2-switch driver probes on a DPSW
    before any DPIO devices have been probed. In this case, seeding of the
    buffer pool will lead to a panic since no SWPs are initialized.
    
    To fix this, seed the buffer pool after making sure that the software
    portals have been probed and are ready to be used.
    
    Fixes: 0b1b71370458 ("staging: dpaa2-switch: handle Rx path on control interface")
    Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a0f2f2bf424dec6f2d299d4e1a8035883434e17a
Author: Maxime Ripard <maxime@cerno.tech>
Date:   Tue Jul 20 15:45:23 2021 +0200

    drm/panel: raspberrypi-touchscreen: Prevent double-free
    
    [ Upstream commit 7bbcb919e32d776ca8ddce08abb391ab92eef6a9 ]
    
    The mipi_dsi_device allocated by mipi_dsi_device_register_full() is
    already free'd on release.
    
    Fixes: 2f733d6194bd ("drm/panel: Add support for the Raspberry Pi 7" Touchscreen.")
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210720134525.563936-9-maxime@cerno.tech
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6cd7bb123703048bef66aebfc63e8c8152cc8fdf
Author: Yajun Deng <yajun.deng@linux.dev>
Date:   Thu Jul 22 11:23:43 2021 +0800

    net: sched: cls_api: Fix the the wrong parameter
    
    [ Upstream commit 9d85a6f44bd5585761947f40f7821c9cd78a1bbe ]
    
    The 4th parameter in tc_chain_notify() should be flags rather than seq.
    Let's change it back correctly.
    
    Fixes: 32a4f5ecd738 ("net: sched: introduce chain object to uapi")
    Signed-off-by: Yajun Deng <yajun.deng@linux.dev>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c95f925b0c7ef9383591c0ed233cb1e06831b07b
Author: Heinrich Schuchardt <xypron.glpk@gmx.de>
Date:   Tue Jun 29 15:40:18 2021 +0200

    RISC-V: load initrd wherever it fits into memory
    
    [ Upstream commit c79e89ecaa246c880292ba68cbe08c9c30db77e3 ]
    
    Requiring that initrd is loaded below RAM start + 256 MiB led to failure
    to boot SUSE Linux with GRUB on QEMU, cf.
    https://lists.gnu.org/archive/html/grub-devel/2021-06/msg00037.html
    
    Remove the constraint.
    
    Reported-by: Andreas Schwab <schwab@linux-m68k.org>
    Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
    Reviewed-by: Atish Patra <atish.patra@wdc.com>
    Acked-by: Ard Biesheuvel <ardb@kernel.org>
    Fixes: d7071743db31 ("RISC-V: Add EFI stub support.")
    Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0bc325702d70d1e9dfcd4dced086ebf3f6420a7c
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date:   Wed Jul 21 15:37:59 2021 +0300

    net: dsa: sja1105: make VID 4095 a bridge VLAN too
    
    [ Upstream commit e40cba9490bab1414d45c2d62defc0ad4f6e4136 ]
    
    This simple series of commands:
    
    ip link add br0 type bridge vlan_filtering 1
    ip link set swp0 master br0
    
    fails on sja1105 with the following error:
    [   33.439103] sja1105 spi0.1: vlan-lookup-table needs to have at least the default untagged VLAN
    [   33.447710] sja1105 spi0.1: Invalid config, cannot upload
    Warning: sja1105: Failed to change VLAN Ethertype.
    
    For context, sja1105 has 3 operating modes:
    - SJA1105_VLAN_UNAWARE: the dsa_8021q_vlans are committed to hardware
    - SJA1105_VLAN_FILTERING_FULL: the bridge_vlans are committed to hardware
    - SJA1105_VLAN_FILTERING_BEST_EFFORT: both the dsa_8021q_vlans and the
      bridge_vlans are committed to hardware
    
    Swapping out a VLAN list and another in happens in
    sja1105_build_vlan_table(), which performs a delta update procedure.
    That function is called from a few places, notably from
    sja1105_vlan_filtering() which is called from the
    SWITCHDEV_ATTR_ID_BRIDGE_VLAN_FILTERING handler.
    
    The above set of 2 commands fails when run on a kernel pre-commit
    8841f6e63f2c ("net: dsa: sja1105: make devlink property
    best_effort_vlan_filtering true by default"). So the priv->vlan_state
    transition that takes place is between VLAN-unaware and full VLAN
    filtering. So the dsa_8021q_vlans are swapped out and the bridge_vlans
    are swapped in.
    
    So why does it fail?
    
    Well, the bridge driver, through nbp_vlan_init(), first sets up the
    SWITCHDEV_ATTR_ID_BRIDGE_VLAN_FILTERING attribute, and only then
    proceeds to call nbp_vlan_add for the default_pvid.
    
    So when we swap out the dsa_8021q_vlans and swap in the bridge_vlans in
    the SWITCHDEV_ATTR_ID_BRIDGE_VLAN_FILTERING handler, there are no bridge
    VLANs (yet). So we have wiped the VLAN table clean, and the low-level
    static config checker complains of an invalid configuration. We _will_
    add the bridge VLANs using the dynamic config interface, albeit later,
    when nbp_vlan_add() calls us. So it is natural that it fails.
    
    So why did it ever work?
    
    Surprisingly, it looks like I only tested this configuration with 2
    things set up in a particular way:
    - a network manager that brings all ports up
    - a kernel with CONFIG_VLAN_8021Q=y
    
    It is widely known that commit ad1afb003939 ("vlan_dev: VLAN 0 should be
    treated as "no vlan tag" (802.1p packet)") installs VID 0 to every net
    device that comes up. DSA treats these VLANs as bridge VLANs, and
    therefore, in my testing, the list of bridge_vlans was never empty.
    
    However, if CONFIG_VLAN_8021Q is not enabled, or the port is not up when
    it joins a VLAN-aware bridge, the bridge_vlans list will be temporarily
    empty, and the sja1105_static_config_reload() call from
    sja1105_vlan_filtering() will fail.
    
    To fix this, the simplest thing is to keep VID 4095, the one used for
    CPU-injected control packets since commit ed040abca4c1 ("net: dsa:
    sja1105: use 4095 as the private VLAN for untagged traffic"), in the
    list of bridge VLANs too, not just the list of tag_8021q VLANs. This
    ensures that the list of bridge VLANs will never be empty.
    
    Fixes: ec5ae61076d0 ("net: dsa: sja1105: save/restore VLANs using a delta commit method")
    Reported-by: Radu Pirea (NXP OSS) <radu-nicolae.pirea@oss.nxp.com>
    Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ec7be4fdd8e14c1033a602a273f4ba255f4ee6fd
Author: Wei Wang <weiwan@google.com>
Date:   Wed Jul 21 10:27:38 2021 -0700

    tcp: disable TFO blackhole logic by default
    
    [ Upstream commit 213ad73d06073b197a02476db3a4998e219ddb06 ]
    
    Multiple complaints have been raised from the TFO users on the internet
    stating that the TFO blackhole logic is too aggressive and gets falsely
    triggered too often.
    (e.g. https://blog.apnic.net/2021/07/05/tcp-fast-open-not-so-fast/)
    Considering that most middleboxes no longer drop TFO packets, we decide
    to disable the blackhole logic by setting
    /proc/sys/net/ipv4/tcp_fastopen_blackhole_timeout_set to 0 by default.
    
    Fixes: cf1ef3f0719b4 ("net/tcp_fastopen: Disable active side TFO in certain scenarios")
    Signed-off-by: Wei Wang <weiwan@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
    Acked-by: Yuchung Cheng <ycheng@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ad9bfbe97bdef94dc27b5407929eb7356c1a5284
Author: Bin Meng <bmeng.cn@gmail.com>
Date:   Sun Jun 27 21:51:17 2021 +0800

    riscv: Fix 32-bit RISC-V boot failure
    
    [ Upstream commit d0e4dae74470fb709fc0ab61862c317938f4cc4d ]
    
    Commit dd2d082b5760 ("riscv: Cleanup setup_bootmem()") adjusted
    the calling sequence in setup_bootmem(), which invalidates the fix
    commit de043da0b9e7 ("RISC-V: Fix usage of memblock_enforce_memory_limit")
    did for 32-bit RISC-V unfortunately.
    
    So now 32-bit RISC-V does not boot again when testing booting kernel
    on QEMU 'virt' with '-m 2G', which was exactly what the original
    commit de043da0b9e7 ("RISC-V: Fix usage of memblock_enforce_memory_limit")
    tried to fix.
    
    Fixes: dd2d082b5760 ("riscv: Cleanup setup_bootmem()")
    Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
    Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fecd81c2e62f2de91273117b07362308b398e0d0
Author: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
Date:   Tue Jul 20 19:34:39 2021 -0700

    ibmvnic: Remove the proper scrq flush
    
    [ Upstream commit bb55362bd6976631b662ca712779b6532d8de0a6 ]
    
    Commit 65d6470d139a ("ibmvnic: clean pending indirect buffs during reset")
    intended to remove the call to ibmvnic_tx_scrq_flush() when the
    ->resetting flag is true and was tested that way. But during the final
    rebase to net-next, the hunk got applied to a block few lines below
    (which happened to have the same diff context) and the wrong call to
    ibmvnic_tx_scrq_flush() got removed.
    
    Fix that by removing the correct ibmvnic_tx_scrq_flush() and restoring
    the one that was incorrectly removed.
    
    Fixes: 65d6470d139a ("ibmvnic: clean pending indirect buffs during reset")
    Reported-by: Dany Madden <drt@linux.ibm.com>
    Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fee8c811ab344cb996ce98978ca1fdbd2a7e463e
Author: Vadim Fedorenko <vfedorenko@novek.ru>
Date:   Tue Jul 20 23:35:28 2021 +0300

    udp: check encap socket in __udp_lib_err
    
    [ Upstream commit 9bfce73c8921c92a9565562e6e7d458d37b7ce80 ]
    
    Commit d26796ae5894 ("udp: check udp sock encap_type in __udp_lib_err")
    added checks for encapsulated sockets but it broke cases when there is
    no implementation of encap_err_lookup for encapsulation, i.e. ESP in
    UDP encapsulation. Fix it by calling encap_err_lookup only if socket
    implements this method otherwise treat it as legal socket.
    
    Fixes: d26796ae5894 ("udp: check udp sock encap_type in __udp_lib_err")
    Signed-off-by: Vadim Fedorenko <vfedorenko@novek.ru>
    Reviewed-by: Xin Long <lucien.xin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c1de376423a7759bf4fa25d6a038a4c1e035c9e1
Author: Xin Long <lucien.xin@gmail.com>
Date:   Tue Jul 20 16:07:01 2021 -0400

    sctp: update active_key for asoc when old key is being replaced
    
    [ Upstream commit 58acd10092268831e49de279446c314727101292 ]
    
    syzbot reported a call trace:
    
      BUG: KASAN: use-after-free in sctp_auth_shkey_hold+0x22/0xa0 net/sctp/auth.c:112
      Call Trace:
       sctp_auth_shkey_hold+0x22/0xa0 net/sctp/auth.c:112
       sctp_set_owner_w net/sctp/socket.c:131 [inline]
       sctp_sendmsg_to_asoc+0x152e/0x2180 net/sctp/socket.c:1865
       sctp_sendmsg+0x103b/0x1d30 net/sctp/socket.c:2027
       inet_sendmsg+0x99/0xe0 net/ipv4/af_inet.c:821
       sock_sendmsg_nosec net/socket.c:703 [inline]
       sock_sendmsg+0xcf/0x120 net/socket.c:723
    
    This is an use-after-free issue caused by not updating asoc->shkey after
    it was replaced in the key list asoc->endpoint_shared_keys, and the old
    key was freed.
    
    This patch is to fix by also updating active_key for asoc when old key is
    being replaced with a new one. Note that this issue doesn't exist in
    sctp_auth_del_key_id(), as it's not allowed to delete the active_key
    from the asoc.
    
    Fixes: 1b1e0bc99474 ("sctp: add refcnt support for sh_key")
    Reported-by: syzbot+b774577370208727d12b@syzkaller.appspotmail.com
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 65bd5af10d020589d22010c26d800dc8fdafae9c
Author: Christoph Hellwig <hch@lst.de>
Date:   Wed Jul 21 10:00:11 2021 +0200

    nvme: set the PRACT bit when using Write Zeroes with T10 PI
    
    [ Upstream commit aaeb7bb061be545251606f4d9c82d710ca2a7c8e ]
    
    When using Write Zeroes on a namespace that has protection
    information enabled they behavior without the PRACT bit
    counter-intuitive and will generally lead to validation failures
    when reading the written blocks.  Fix this by always setting the
    PRACT bit that generates matching PI data on the fly.
    
    Fixes: 6e02318eaea5 ("nvme: add support for the Write Zeroes command")
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Keith Busch <kbusch@kernel.org>
    Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bc08be0ed085f832f882cb60f89a3b7f467b7fde
Author: Sayanta Pattanayak <sayanta.pattanayak@arm.com>
Date:   Tue Jul 20 17:17:40 2021 +0100

    r8169: Avoid duplicate sysfs entry creation error
    
    [ Upstream commit e9a72f874d5b95cef0765bafc56005a50f72c5fe ]
    
    When registering the MDIO bus for a r8169 device, we use the PCI
    bus/device specifier as a (seemingly) unique device identifier.
    However the very same BDF number can be used on another PCI segment,
    which makes the driver fail probing:
    
    [ 27.544136] r8169 0002:07:00.0: enabling device (0000 -> 0003)
    [ 27.559734] sysfs: cannot create duplicate filename '/class/mdio_bus/r8169-700'
    ....
    [ 27.684858] libphy: mii_bus r8169-700 failed to register
    [ 27.695602] r8169: probe of 0002:07:00.0 failed with error -22
    
    Add the segment number to the device name to make it more unique.
    
    This fixes operation on ARM N1SDP boards, with two boards connected
    together to form an SMP system, and all on-board devices showing up
    twice, just on different PCI segments. A similar issue would occur on
    large systems with many PCI slots and multiple RTL8169 NICs.
    
    Fixes: f1e911d5d0dfd ("r8169: add basic phylib support")
    Signed-off-by: Sayanta Pattanayak <sayanta.pattanayak@arm.com>
    [Andre: expand commit message, use pci_domain_nr()]
    Signed-off-by: Andre Przywara <andre.przywara@arm.com>
    Acked-by: Heiner Kallweit <hkallweit1@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2131ea6126924e733c7bd718034927078d037d39
Author: David Howells <dhowells@redhat.com>
Date:   Mon Jul 12 17:04:47 2021 +0100

    afs: Fix setting of writeback_index
    
    [ Upstream commit 5a972474cf685bf99ca430979657095bda3a15c8 ]
    
    Fix afs_writepages() to always set mapping->writeback_index to a page index
    and not a byte position[1].
    
    Fixes: 31143d5d515e ("AFS: implement basic file write support")
    Reported-by: Marc Dionne <marc.dionne@auristor.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Reviewed-by: Marc Dionne <marc.dionne@auristor.com>
    cc: linux-afs@lists.infradead.org
    Link: https://lore.kernel.org/r/CAB9dFdvHsLsw7CMnB+4cgciWDSqVjuij4mH3TaXnHQB8sz5rHw@mail.gmail.com/ [1]
    Link: https://lore.kernel.org/r/162610728339.3408253.4604750166391496546.stgit@warthog.procyon.org.uk/ # v2 (no v1)
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8dda575c891255cff73d8fbdb0f18e0469b61f49
Author: Tom Rix <trix@redhat.com>
Date:   Fri Apr 30 08:50:31 2021 -0700

    afs: check function return
    
    [ Upstream commit afe6949862f77bcc14fa16ad7938a04e84586d6a ]
    
    Static analysis reports this problem
    
    write.c:773:29: warning: Assigned value is garbage or undefined
      mapping->writeback_index = next;
                               ^ ~~~~
    The call to afs_writepages_region() can return without setting
    next.  So check the function return before using next.
    
    Changes:
     ver #2:
       - Need to fix the range_cyclic case also[1].
    
    Fixes: e87b03f5830e ("afs: Prepare for use of THPs")
    Signed-off-by: Tom Rix <trix@redhat.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Reviewed-by: Marc Dionne <marc.dionne@auristor.com>
    cc: linux-afs@lists.infradead.org
    Link: https://lore.kernel.org/r/20210430155031.3287870-1-trix@redhat.com
    Link: https://lore.kernel.org/r/CAB9dFdvHsLsw7CMnB+4cgciWDSqVjuij4mH3TaXnHQB8sz5rHw@mail.gmail.com/ [1]
    Link: https://lore.kernel.org/r/162609464716.3133237.10354897554363093252.stgit@warthog.procyon.org.uk/ # v1
    Link: https://lore.kernel.org/r/162610727640.3408253.8687445613469681311.stgit@warthog.procyon.org.uk/ # v2
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3d888afffcf389c3f6a109056a3621229266d327
Author: David Howells <dhowells@redhat.com>
Date:   Tue Jun 15 11:57:26 2021 +0100

    afs: Fix tracepoint string placement with built-in AFS
    
    [ Upstream commit 6c881ca0b3040f3e724eae513117ba4ddef86057 ]
    
    To quote Alexey[1]:
    
        I was adding custom tracepoint to the kernel, grabbed full F34 kernel
        .config, disabled modules and booted whole shebang as VM kernel.
    
        Then did
    
            perf record -a -e ...
    
        It crashed:
    
            general protection fault, probably for non-canonical address 0x435f5346592e4243: 0000 [#1] SMP PTI
            CPU: 1 PID: 842 Comm: cat Not tainted 5.12.6+ #26
            Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014
            RIP: 0010:t_show+0x22/0xd0
    
        Then reproducer was narrowed to
    
            # cat /sys/kernel/tracing/printk_formats
    
        Original F34 kernel with modules didn't crash.
    
        So I started to disable options and after disabling AFS everything
        started working again.
    
        The root cause is that AFS was placing char arrays content into a
        section full of _pointers_ to strings with predictable consequences.
    
        Non canonical address 435f5346592e4243 is "CB.YFS_" which came from
        CM_NAME macro.
    
        Steps to reproduce:
    
            CONFIG_AFS=y
            CONFIG_TRACING=y
    
            # cat /sys/kernel/tracing/printk_formats
    
    Fix this by the following means:
    
     (1) Add enum->string translation tables in the event header with the AFS
         and YFS cache/callback manager operations listed by RPC operation ID.
    
     (2) Modify the afs_cb_call tracepoint to print the string from the
         translation table rather than using the string at the afs_call name
         pointer.
    
     (3) Switch translation table depending on the service we're being accessed
         as (AFS or YFS) in the tracepoint print clause.  Will this cause
         problems to userspace utilities?
    
         Note that the symbolic representation of the YFS service ID isn't
         available to this header, so I've put it in as a number.  I'm not sure
         if this is the best way to do this.
    
     (4) Remove the name wrangling (CM_NAME) macro and put the names directly
         into the afs_call_type structs in cmservice.c.
    
    Fixes: 8e8d7f13b6d5a9 ("afs: Add some tracepoints")
    Reported-by: Alexey Dobriyan (SK hynix) <adobriyan@gmail.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Reviewed-by: Marc Dionne <marc.dionne@auristor.com>
    cc: Andrew Morton <akpm@linux-foundation.org>
    cc: linux-afs@lists.infradead.org
    Link: https://lore.kernel.org/r/YLAXfvZ+rObEOdc%2F@localhost.localdomain/ [1]
    Link: https://lore.kernel.org/r/643721.1623754699@warthog.procyon.org.uk/
    Link: https://lore.kernel.org/r/162430903582.2896199.6098150063997983353.stgit@warthog.procyon.org.uk/ # v1
    Link: https://lore.kernel.org/r/162609463957.3133237.15916579353149746363.stgit@warthog.procyon.org.uk/ # v1 (repost)
    Link: https://lore.kernel.org/r/162610726860.3408253.445207609466288531.stgit@warthog.procyon.org.uk/ # v2
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6bd6db23b44d9e13a0688c0fd167a9344dae6865
Author: Vincent Palatin <vpalatin@chromium.org>
Date:   Wed Jul 21 11:25:16 2021 +0200

    Revert "USB: quirks: ignore remote wake-up on Fibocom L850-GL LTE modem"
    
    [ Upstream commit f3a1a937f7b240be623d989c8553a6d01465d04f ]
    
    This reverts commit 0bd860493f81eb2a46173f6f5e44cc38331c8dbd.
    
    While the patch was working as stated,ie preventing the L850-GL LTE modem
    from crashing on some U3 wake-ups due to a race condition between the
    host wake-up and the modem-side wake-up, when using the MBIM interface,
    this would force disabling the USB runtime PM on the device.
    
    The increased power consumption is significant for LTE laptops,
    and given that with decently recent modem firmwares, when the modem hits
    the bug, it automatically recovers (ie it drops from the bus, but
    automatically re-enumerates after less than half a second, rather than being
    stuck until a power cycle as it was doing with ancient firmware), for
    most people, the trade-off now seems in favor of re-enabling it by
    default.
    
    For people with access to the platform code, the bug can also be worked-around
    successfully by changing the USB3 LFPM polling off-time for the XHCI
    controller in the BIOS code.
    
    Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
    Link: https://lore.kernel.org/r/20210721092516.2775971-1-vpalatin@chromium.org
    Fixes: 0bd860493f81 ("USB: quirks: ignore remote wake-up on Fibocom L850-GL LTE modem")
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit de3a841649ae4b463088d4aaaf3c32399f134e67
Author: Zhihao Cheng <chengzhihao1@huawei.com>
Date:   Mon Jul 5 21:38:29 2021 +0800

    nvme-pci: don't WARN_ON in nvme_reset_work if ctrl.state is not RESETTING
    
    [ Upstream commit 7764656b108cd308c39e9a8554353b8f9ca232a3 ]
    
    Followling process:
    nvme_probe
      nvme_reset_ctrl
        nvme_change_ctrl_state(ctrl, NVME_CTRL_RESETTING)
        queue_work(nvme_reset_wq, &ctrl->reset_work)
    
    --------------> nvme_remove
                      nvme_change_ctrl_state(&dev->ctrl, NVME_CTRL_DELETING)
    worker_thread
      process_one_work
        nvme_reset_work
        WARN_ON(dev->ctrl.state != NVME_CTRL_RESETTING)
    
    , which will trigger WARN_ON in nvme_reset_work():
    [  127.534298] WARNING: CPU: 0 PID: 139 at drivers/nvme/host/pci.c:2594
    [  127.536161] CPU: 0 PID: 139 Comm: kworker/u8:7 Not tainted 5.13.0
    [  127.552518] Call Trace:
    [  127.552840]  ? kvm_sched_clock_read+0x25/0x40
    [  127.553936]  ? native_send_call_func_single_ipi+0x1c/0x30
    [  127.555117]  ? send_call_function_single_ipi+0x9b/0x130
    [  127.556263]  ? __smp_call_single_queue+0x48/0x60
    [  127.557278]  ? ttwu_queue_wakelist+0xfa/0x1c0
    [  127.558231]  ? try_to_wake_up+0x265/0x9d0
    [  127.559120]  ? ext4_end_io_rsv_work+0x160/0x290
    [  127.560118]  process_one_work+0x28c/0x640
    [  127.561002]  worker_thread+0x39a/0x700
    [  127.561833]  ? rescuer_thread+0x580/0x580
    [  127.562714]  kthread+0x18c/0x1e0
    [  127.563444]  ? set_kthread_struct+0x70/0x70
    [  127.564347]  ret_from_fork+0x1f/0x30
    
    The preceding problem can be easily reproduced by executing following
    script (based on blktests suite):
    test() {
      pdev="$(_get_pci_dev_from_blkdev)"
      sysfs="/sys/bus/pci/devices/${pdev}"
      for ((i = 0; i < 10; i++)); do
        echo 1 > "$sysfs/remove"
        echo 1 > /sys/bus/pci/rescan
      done
    }
    
    Since the device ctrl could be updated as an non-RESETTING state by
    repeating probe/remove in userspace (which is a normal situation), we
    can replace stack dumping WARN_ON with a warnning message.
    
    Fixes: 82b057caefaff ("nvme-pci: fix multiple ctrl removal schedulin")
    Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a521c15683c1d604a85c3829d1a8428040807f35
Author: Jason Ekstrand <jason@jlekstrand.net>
Date:   Tue Jul 20 13:13:55 2021 -0500

    drm/ttm: Force re-init if ttm_global_init() fails
    
    [ Upstream commit 235c3610d5f02ee91244239b43cd9ae8b4859dff ]
    
    If we have a failure, decrement the reference count so that the next
    call to ttm_global_init() will actually do something instead of assume
    everything is all set up.
    
    Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
    Fixes: 62b53b37e4b1 ("drm/ttm: use a static ttm_bo_global instance")
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210720181357.2760720-5-jason@jlekstrand.net
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e7732c5a19a15a62b0b23fd683a639b0483e1f40
Author: David Disseldorp <ddiss@suse.de>
Date:   Wed Jul 21 00:55:22 2021 +0200

    scsi: target: Fix NULL dereference on XCOPY completion
    
    [ Upstream commit a47fa41381a09e5997afd762664db4f5f6657e03 ]
    
    CPU affinity control added with commit 39ae3edda325 ("scsi: target: core:
    Make completion affinity configurable") makes target_complete_cmd() queue
    work on a CPU based on se_tpg->se_tpg_wwn->cmd_compl_affinity state.
    
    LIO's EXTENDED COPY worker is a special case in that read/write cmds are
    dispatched using the global xcopy_pt_tpg, which carries a NULL se_tpg_wwn
    pointer following initialization in target_xcopy_setup_pt().
    
    The NULL xcopy_pt_tpg->se_tpg_wwn pointer is dereferenced on completion of
    any EXTENDED COPY initiated read/write cmds. E.g using the libiscsi
    SCSI.ExtendedCopy.Simple test:
    
      BUG: kernel NULL pointer dereference, address: 00000000000001a8
      RIP: 0010:target_complete_cmd+0x9d/0x130 [target_core_mod]
      Call Trace:
       fd_execute_rw+0x148/0x42a [target_core_file]
       ? __dynamic_pr_debug+0xa7/0xe0
       ? target_check_reservation+0x5b/0x940 [target_core_mod]
       __target_execute_cmd+0x1e/0x90 [target_core_mod]
       transport_generic_new_cmd+0x17c/0x330 [target_core_mod]
       target_xcopy_issue_pt_cmd+0x9/0x60 [target_core_mod]
       target_xcopy_read_source.isra.7+0x10b/0x1b0 [target_core_mod]
       ? target_check_fua+0x40/0x40 [target_core_mod]
       ? transport_complete_task_attr+0x130/0x130 [target_core_mod]
       target_xcopy_do_work+0x61f/0xc00 [target_core_mod]
    
    This fix makes target_complete_cmd() queue work on se_cmd->cpuid if
    se_tpg_wwn is NULL.
    
    Link: https://lore.kernel.org/r/20210720225522.26291-1-ddiss@suse.de
    Fixes: 39ae3edda325 ("scsi: target: core: Make completion affinity configurable")
    Cc: Lee Duncan <lduncan@suse.com>
    Cc: Mike Christie <michael.christie@oracle.com>
    Reviewed-by: Mike Christie <michael.christie@oracle.com>
    Signed-off-by: David Disseldorp <ddiss@suse.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2ed13e8f7829dc9011a3d02f25c63b9ce14e9c94
Author: Chris Packham <chris.packham@alliedtelesis.co.nz>
Date:   Fri Jul 16 08:58:32 2021 +1200

    i2c: mpc: Poll for MCF
    
    [ Upstream commit 4a8ac5e45cdaa88884b4ce05303e304cbabeb367 ]
    
    During some transfers the bus can still be busy when an interrupt is
    received. Commit 763778cd7926 ("i2c: mpc: Restore reread of I2C status
    register") attempted to address this by re-reading MPC_I2C_SR once but
    that just made it less likely to happen without actually preventing it.
    Instead of a single re-read, poll with a timeout so that the bus is given
    enough time to settle but a genuine stuck SCL is still noticed.
    
    Fixes: 1538d82f4647 ("i2c: mpc: Interrupt driven transfer")
    Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a706c12da916ef6fd7b31664d1caffe0b1d4a1d3
Author: Luis Henriques <lhenriques@suse.de>
Date:   Thu Jul 15 14:40:39 2021 +0100

    ceph: don't WARN if we're still opening a session to an MDS
    
    [ Upstream commit cdb330f4b41ab55feb35487729e883c9e08b8a54 ]
    
    If MDSs aren't available while mounting a filesystem, the session state
    will transition from SESSION_OPENING to SESSION_CLOSING.  And in that
    scenario check_session_state() will be called from delayed_work() and
    trigger this WARN.
    
    Avoid this by only WARNing after a session has already been established
    (i.e., the s_ttl will be different from 0).
    
    Fixes: 62575e270f66 ("ceph: check session state after bumping session->s_seq")
    Signed-off-by: Luis Henriques <lhenriques@suse.de>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 115784bcccf135c3a3548098153413d76f16aae0
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Tue Jul 20 15:08:40 2021 +0200

    ipv6: fix another slab-out-of-bounds in fib6_nh_flush_exceptions
    
    [ Upstream commit 8fb4792f091e608a0a1d353dfdf07ef55a719db5 ]
    
    While running the self-tests on a KASAN enabled kernel, I observed a
    slab-out-of-bounds splat very similar to the one reported in
    commit 821bbf79fe46 ("ipv6: Fix KASAN: slab-out-of-bounds Read in
     fib6_nh_flush_exceptions").
    
    We additionally need to take care of fib6_metrics initialization
    failure when the caller provides an nh.
    
    The fix is similar, explicitly free the route instead of calling
    fib6_info_release on a half-initialized object.
    
    Fixes: f88d8ea67fbdb ("ipv6: Plumb support for nexthop object in a fib6_info")
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 34f1e1f657fae2891b485a3b2b95fe4d2aef9f0d
Author: Peilin Ye <peilin.ye@bytedance.com>
Date:   Mon Jul 19 16:41:24 2021 -0700

    net/sched: act_skbmod: Skip non-Ethernet packets
    
    [ Upstream commit 727d6a8b7ef3d25080fad228b2c4a1d4da5999c6 ]
    
    Currently tcf_skbmod_act() assumes that packets use Ethernet as their L2
    protocol, which is not always the case.  As an example, for CAN devices:
    
            $ ip link add dev vcan0 type vcan
            $ ip link set up vcan0
            $ tc qdisc add dev vcan0 root handle 1: htb
            $ tc filter add dev vcan0 parent 1: protocol ip prio 10 \
                    matchall action skbmod swap mac
    
    Doing the above silently corrupts all the packets.  Do not perform skbmod
    actions for non-Ethernet packets.
    
    Fixes: 86da71b57383 ("net_sched: Introduce skbmod action")
    Reviewed-by: Cong Wang <cong.wang@bytedance.com>
    Signed-off-by: Peilin Ye <peilin.ye@bytedance.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 502731a03f27cba1513fbbff77e508185ffce5bb
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Tue Jul 20 16:38:05 2021 +0800

    io_uring: fix memleak in io_init_wq_offload()
    
    [ Upstream commit 362a9e65289284f36403058eea2462d0330c1f24 ]
    
    I got memory leak report when doing fuzz test:
    
    BUG: memory leak
    unreferenced object 0xffff888107310a80 (size 96):
    comm "syz-executor.6", pid 4610, jiffies 4295140240 (age 20.135s)
    hex dump (first 32 bytes):
    01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
    00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........
    backtrace:
    [<000000001974933b>] kmalloc include/linux/slab.h:591 [inline]
    [<000000001974933b>] kzalloc include/linux/slab.h:721 [inline]
    [<000000001974933b>] io_init_wq_offload fs/io_uring.c:7920 [inline]
    [<000000001974933b>] io_uring_alloc_task_context+0x466/0x640 fs/io_uring.c:7955
    [<0000000039d0800d>] __io_uring_add_tctx_node+0x256/0x360 fs/io_uring.c:9016
    [<000000008482e78c>] io_uring_add_tctx_node fs/io_uring.c:9052 [inline]
    [<000000008482e78c>] __do_sys_io_uring_enter fs/io_uring.c:9354 [inline]
    [<000000008482e78c>] __se_sys_io_uring_enter fs/io_uring.c:9301 [inline]
    [<000000008482e78c>] __x64_sys_io_uring_enter+0xabc/0xc20 fs/io_uring.c:9301
    [<00000000b875f18f>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    [<00000000b875f18f>] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80
    [<000000006b0a8484>] entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    CPU0                          CPU1
    io_uring_enter                io_uring_enter
    io_uring_add_tctx_node        io_uring_add_tctx_node
    __io_uring_add_tctx_node      __io_uring_add_tctx_node
    io_uring_alloc_task_context   io_uring_alloc_task_context
    io_init_wq_offload            io_init_wq_offload
    hash = kzalloc                hash = kzalloc
    ctx->hash_map = hash          ctx->hash_map = hash <- one of the hash is leaked
    
    When calling io_uring_enter() in parallel, the 'hash_map' will be leaked,
    add uring_lock to protect 'hash_map'.
    
    Fixes: e941894eae31 ("io-wq: make buffered file write hashed work map per-ctx")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Reviewed-by: Pavel Begunkov <asml.silence@gmail.com>
    Link: https://lore.kernel.org/r/20210720083805.3030730-1-yangyingliang@huawei.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 23c492a5041896ba62e5e9c4aad1ca5d4853d92d
Author: Alexandru Tachici <alexandru.tachici@analog.com>
Date:   Sat Jul 17 00:02:45 2021 +0300

    spi: spi-bcm2835: Fix deadlock
    
    [ Upstream commit c45c1e82bba130db4f19d9dbc1deefcf4ea994ed ]
    
    The bcm2835_spi_transfer_one function can create a deadlock
    if it is called while another thread already has the
    CCF lock.
    
    Signed-off-by: Alexandru Tachici <alexandru.tachici@analog.com>
    Fixes: f8043872e796 ("spi: add driver for BCM2835")
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Link: https://lore.kernel.org/r/20210716210245.13240-2-alexandru.tachici@analog.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 140e0dbad4cf04da50d8acc09e33de760c3c554b
Author: Jian Shen <shenjian15@huawei.com>
Date:   Mon Jul 19 17:13:08 2021 +0800

    net: hns3: fix rx VLAN offload state inconsistent issue
    
    [ Upstream commit bbfd4506f962e7e6fff8f37f017154a3c3791264 ]
    
    Currently, VF doesn't enable rx VLAN offload when initializating,
    and PF does it for VFs. If user disable the rx VLAN offload for
    VF with ethtool -K, and reload the VF driver, it may cause the
    rx VLAN offload state being inconsistent between hardware and
    software.
    
    Fixes it by enabling rx VLAN offload when VF initializing.
    
    Fixes: e2cb1dec9779 ("net: hns3: Add HNS3 VF HCL(Hardware Compatibility Layer) Support")
    Signed-off-by: Jian Shen <shenjian15@huawei.com>
    Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1e3b38761394c699e898674fd3237f2cf3c0d990
Author: Chengwen Feng <fengchengwen@huawei.com>
Date:   Mon Jul 19 17:13:05 2021 +0800

    net: hns3: fix possible mismatches resp of mailbox
    
    [ Upstream commit 1b713d14dc3c077ec45e65dab4ea01a8bc41b8c1 ]
    
    Currently, the mailbox synchronous communication between VF and PF use
    the following fields to maintain communication:
    1. Origin_mbx_msg which was combined by message code and subcode, used
    to match request and response.
    2. Received_resp which means whether received response.
    
    There may possible mismatches of the following situation:
    1. VF sends message A with code=1 subcode=1.
    2. PF was blocked about 500ms when processing the message A.
    3. VF will detect message A timeout because it can't get the response
    within 500ms.
    4. VF sends message B with code=1 subcode=1 which equal message A.
    5. PF processes the first message A and send the response message to
    VF.
    6. VF will identify the response matched the message B because the
    code/subcode is the same. This will lead to mismatch of request and
    response.
    
    To fix the above bug, we use the following scheme:
    1. The message sent from VF was labelled with match_id which was a
    unique 16-bit non-zero value.
    2. The response sent from PF will label with match_id which got from
    the request.
    3. The VF uses the match_id to match request and response message.
    
    As for PF driver, it only needs to copy the match_id from request to
    response.
    
    Fixes: dde1a86e93ca ("net: hns3: Add mailbox support to PF driver")
    Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
    Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e52445629c2e4306f3169397f8c06d3798592217
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Mon Jul 19 18:17:46 2021 -0500

    ALSA: hda: intel-dsp-cfg: add missing ElkhartLake PCI ID
    
    [ Upstream commit 114613f62f42e7cbc1242c4e82076a0153043761 ]
    
    We missed the fact that ElkhartLake platforms have two different PCI
    IDs. We only added one so the SOF driver is never selected by the
    autodetection logic for the missing configuration.
    
    BugLink: https://github.com/thesofproject/linux/issues/2990
    Fixes: cc8f81c7e625 ('ALSA: hda: fix intel DSP config')
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Link: https://lore.kernel.org/r/20210719231746.557325-1-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ce9f267d9e8a612e34d581bd29b04ec45f9c8ea5
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Jul 19 02:12:18 2021 -0700

    net/tcp_fastopen: fix data races around tfo_active_disable_stamp
    
    [ Upstream commit 6f20c8adb1813467ea52c1296d52c4e95978cb2f ]
    
    tfo_active_disable_stamp is read and written locklessly.
    We need to annotate these accesses appropriately.
    
    Then, we need to perform the atomic_inc(tfo_active_disable_times)
    after the timestamp has been updated, and thus add barriers
    to make sure tcp_fastopen_active_should_disable() wont read
    a stale timestamp.
    
    Fixes: cf1ef3f0719b ("net/tcp_fastopen: Disable active side TFO in certain scenarios")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Wei Wang <weiwan@google.com>
    Cc: Yuchung Cheng <ycheng@google.com>
    Cc: Neal Cardwell <ncardwell@google.com>
    Acked-by: Wei Wang <weiwan@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b9d21b9b46bda14fe74a97a593c5bee258d064d3
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Sun Jul 18 13:38:34 2021 -0700

    net: hisilicon: rename CACHE_LINE_MASK to avoid redefinition
    
    [ Upstream commit b16f3299ae1aa3c327e1fb742d0379ae4d6e86f2 ]
    
    Building on ARCH=arc causes a "redefined" warning, so rename this
    driver's CACHE_LINE_MASK to avoid the warning.
    
    ../drivers/net/ethernet/hisilicon/hip04_eth.c:134: warning: "CACHE_LINE_MASK" redefined
      134 | #define CACHE_LINE_MASK   0x3F
    In file included from ../include/linux/cache.h:6,
                     from ../include/linux/printk.h:9,
                     from ../include/linux/kernel.h:19,
                     from ../include/linux/list.h:9,
                     from ../include/linux/module.h:12,
                     from ../drivers/net/ethernet/hisilicon/hip04_eth.c:7:
    ../arch/arc/include/asm/cache.h:17: note: this is the location of the previous definition
       17 | #define CACHE_LINE_MASK  (~(L1_CACHE_BYTES - 1))
    
    Fixes: d413779cdd93 ("net: hisilicon: Add an tx_desc to adapt HI13X1_GMAC")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: Vineet Gupta <vgupta@synopsys.com>
    Cc: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a24886feddbae495a7ea3ee266c59b0fd5820e6a
Author: Somnath Kotur <somnath.kotur@broadcom.com>
Date:   Sun Jul 18 15:36:31 2021 -0400

    bnxt_en: Check abort error state in bnxt_half_open_nic()
    
    [ Upstream commit 11a39259ff79b74bc99f8b7c44075a2d6d5e7ab1 ]
    
    bnxt_half_open_nic() is called during during ethtool self test and is
    protected by rtnl_lock.  Firmware reset can be happening at the same
    time.  Only critical portions of the entire firmware reset sequence
    are protected by the rtnl_lock.  It is possible that bnxt_half_open_nic()
    can be called when the firmware reset sequence is aborting.  In that
    case, bnxt_half_open_nic() needs to check if the ABORT_ERR flag is set
    and abort if it is.  The ethtool self test will fail but the NIC will be
    brought to a consistent IF_DOWN state.
    
    Without this patch, if bnxt_half_open_nic() were to continue in this
    error state, it may crash like this:
    
      bnxt_en 0000:82:00.1 enp130s0f1np1: FW reset in progress during close, FW reset will be aborted
      Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
      ...
      Process ethtool (pid: 333327, stack limit = 0x0000000046476577)
      Call trace:
      bnxt_alloc_mem+0x444/0xef0 [bnxt_en]
      bnxt_half_open_nic+0x24/0xb8 [bnxt_en]
      bnxt_self_test+0x2dc/0x390 [bnxt_en]
      ethtool_self_test+0xe0/0x1f8
      dev_ethtool+0x1744/0x22d0
      dev_ioctl+0x190/0x3e0
      sock_ioctl+0x238/0x480
      do_vfs_ioctl+0xc4/0x758
      ksys_ioctl+0x84/0xb8
      __arm64_sys_ioctl+0x28/0x38
      el0_svc_handler+0xb0/0x180
      el0_svc+0x8/0xc
    
    Fixes: a1301f08c5ac ("bnxt_en: Check abort error state in bnxt_open_nic().")
    Signed-off-by: Somnath Kotur <somnath.kotur@broadcom.com>
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c2ed50ff29f829d246679a067b17d6e9969186e5
Author: Michael Chan <michael.chan@broadcom.com>
Date:   Sun Jul 18 15:36:30 2021 -0400

    bnxt_en: Validate vlan protocol ID on RX packets
    
    [ Upstream commit 96bdd4b9ea7ef9a12db8fdd0ce90e37dffbd3703 ]
    
    Only pass supported VLAN protocol IDs for stripped VLAN tags to the
    stack.  The stack will hit WARN() if the protocol ID is unsupported.
    
    Existing firmware sets up the chip to strip 0x8100, 0x88a8, 0x9100.
    Only the 1st two protocols are supported by the kernel.
    
    Fixes: a196e96bb68f ("bnxt_en: clean up VLAN feature bit handling")
    Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com>
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a1a54e07e63c8537ee511de7788e3274accd0340
Author: Somnath Kotur <somnath.kotur@broadcom.com>
Date:   Sun Jul 18 15:36:29 2021 -0400

    bnxt_en: fix error path of FW reset
    
    [ Upstream commit 3958b1da725a477b4a222183d16a14d85445d4b6 ]
    
    When bnxt_open() fails in the firmware reset path, the driver needs to
    gracefully abort, but it is executing code that should be invoked only
    in the success path.  Define a function to abort FW reset and
    consolidate all error paths to call this new function.
    
    Fixes: dab62e7c2de7 ("bnxt_en: Implement faster recovery for firmware fatal error.")
    Signed-off-by: Somnath Kotur <somnath.kotur@broadcom.com>
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c8c2eed44e41518003d95af987f6dbe9cb530e77
Author: Michael Chan <michael.chan@broadcom.com>
Date:   Sun Jul 18 15:36:28 2021 -0400

    bnxt_en: Add missing check for BNXT_STATE_ABORT_ERR in bnxt_fw_rset_task()
    
    [ Upstream commit 6cd657cb3ee6f4de57e635b126ffbe0e51d00f1a ]
    
    In the BNXT_FW_RESET_STATE_POLL_VF state in bnxt_fw_reset_task() after all
    VFs have unregistered, we need to check for BNXT_STATE_ABORT_ERR after
    we acquire the rtnl_lock.  If the flag is set, we need to abort.
    
    Fixes: 230d1f0de754 ("bnxt_en: Handle firmware reset.")
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4564b85633b2df1f737565c164a0477c798b156b
Author: Michael Chan <michael.chan@broadcom.com>
Date:   Sun Jul 18 15:36:27 2021 -0400

    bnxt_en: Refresh RoCE capabilities in bnxt_ulp_probe()
    
    [ Upstream commit 2c9f046bc377efd1f5e26e74817d5f96e9506c86 ]
    
    The capabilities can change after firmware upgrade/downgrade, so we
    should get the up-to-date RoCE capabilities everytime bnxt_ulp_probe()
    is called.
    
    Fixes: 2151fe0830fd ("bnxt_en: Handle RESET_NOTIFY async event from firmware.")
    Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com>
    Reviewed-by: Edwin Peer <edwin.peer@broadcom.com>
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 52b6ad30a026c675f0a9be8c51b0bb9116339b14
Author: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
Date:   Sun Jul 18 15:36:25 2021 -0400

    bnxt_en: don't disable an already disabled PCI device
    
    [ Upstream commit c81cfb6256d90ea5ba4a6fb280ea3b171be4e05c ]
    
    If device is already disabled in reset path and PCI io error is
    detected before the device could be enabled, driver could
    call pci_disable_device() for already disabled device. Fix this
    problem by calling pci_disable_device() only if the device is already
    enabled.
    
    Fixes: 6316ea6db93d ("bnxt_en: Enable AER support.")
    Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8ac2e2d69b353ba013e2cd4c2355ede98b542bbe
Author: Andy Shevchenko <andy.shevchenko@gmail.com>
Date:   Mon Jul 12 21:21:21 2021 +0300

    ACPI: utils: Fix reference counting in for_each_acpi_dev_match()
    
    [ Upstream commit 71f6428332844f38c7cb10461d9f29e9c9b983a0 ]
    
    Currently it's possible to iterate over the dangling pointer in case the device
    suddenly disappears. This may happen becase callers put it at the end of a loop.
    
    Instead, let's move that call inside acpi_dev_get_next_match_dev().
    
    Fixes: 803abec64ef9 ("media: ipu3-cio2: Add cio2-bridge to ipu3-cio2 driver")
    Fixes: bf263f64e804 ("media: ACPI / bus: Add acpi_dev_get_next_match_dev() and helper macro")
    Fixes: edbd1bc4951e ("efi/dev-path-parser: Switch to use for_each_acpi_dev_match()")
    Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Reviewed-by: Daniel Scally <djrscally@gmail.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 587c2751068a8a78197f6b2d80357d42c828205a
Author: Andy Shevchenko <andy.shevchenko@gmail.com>
Date:   Sun Apr 4 21:12:16 2021 +0300

    efi/dev-path-parser: Switch to use for_each_acpi_dev_match()
    
    [ Upstream commit edbd1bc4951eff8da65732dbe0d381e555054428 ]
    
    Switch to use for_each_acpi_dev_match() instead of home grown analogue.
    No functional change intended.
    
    Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4657af6770c0bfc0b60751cf5fbb8e562d72150a
Author: Robert Richter <rrichter@amd.com>
Date:   Thu Jul 15 11:26:01 2021 +0200

    ACPI: Kconfig: Fix table override from built-in initrd
    
    [ Upstream commit d2cbbf1fe503c07e466c62f83aa1926d74d15821 ]
    
    During a rework of initramfs code the INITRAMFS_COMPRESSION config
    option was removed in commit 65e00e04e5ae. A leftover as a dependency
    broke the config option ACPI_TABLE_OVERRIDE_VIA_ BUILTIN_INITRD that
    is used to enable the overriding of ACPI tables from built-in initrd.
    Fixing the dependency.
    
    Fixes: 65e00e04e5ae ("initramfs: refactor the initramfs build rules")
    Signed-off-by: Robert Richter <rrichter@amd.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 24376facf2fd3d4df77a5f61a711615ed037ca04
Author: Marek Vasut <marex@denx.de>
Date:   Fri Jul 16 20:21:33 2021 +0200

    spi: cadence: Correct initialisation of runtime PM again
    
    [ Upstream commit 56912da7a68c8356df6a6740476237441b0b792a ]
    
    The original implementation of RPM handling in probe() was mostly
    correct, except it failed to call pm_runtime_get_*() to activate the
    hardware. The subsequent fix, 734882a8bf98 ("spi: cadence: Correct
    initialisation of runtime PM"), breaks the implementation further,
    to the point where the system using this hard IP on ZynqMP hangs on
    boot, because it accesses hardware which is gated off.
    
    Undo 734882a8bf98 ("spi: cadence: Correct initialisation of runtime
    PM") and instead add missing pm_runtime_get_noresume() and move the
    RPM disabling all the way to the end of probe(). That makes ZynqMP
    not hang on boot yet again.
    
    Fixes: 734882a8bf98 ("spi: cadence: Correct initialisation of runtime PM")
    Signed-off-by: Marek Vasut <marex@denx.de>
    Cc: Charles Keepax <ckeepax@opensource.cirrus.com>
    Cc: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20210716182133.218640-1-marex@denx.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6128d746d705d3cd74f84f81119fc8850cc96c92
Author: Dmitry Bogdanov <d.bogdanov@yadro.com>
Date:   Fri Jul 2 12:16:55 2021 +0300

    scsi: target: Fix protect handling in WRITE SAME(32)
    
    [ Upstream commit 6d8e7e7c932162bccd06872362751b0e1d76f5af ]
    
    WRITE SAME(32) command handling reads WRPROTECT at the wrong offset in 1st
    byte instead of 10th byte.
    
    Link: https://lore.kernel.org/r/20210702091655.22818-1-d.bogdanov@yadro.com
    Fixes: afd73f1b60fc ("target: Perform PROTECT sanity checks for WRITE_SAME")
    Signed-off-by: Dmitry Bogdanov <d.bogdanov@yadro.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 868ffb5f290f4582238854e1ff96b1506102e9e9
Author: Mike Christie <michael.christie@oracle.com>
Date:   Wed Jun 30 19:25:59 2021 -0500

    scsi: iscsi: Fix iface sysfs attr detection
    
    [ Upstream commit e746f3451ec7f91dcc9fd67a631239c715850a34 ]
    
    A ISCSI_IFACE_PARAM can have the same value as a ISCSI_NET_PARAM so when
    iscsi_iface_attr_is_visible tries to figure out the type by just checking
    the value, we can collide and return the wrong type. When we call into the
    driver we might not match and return that we don't want attr visible in
    sysfs. The patch fixes this by setting the type when we figure out what the
    param is.
    
    Link: https://lore.kernel.org/r/20210701002559.89533-1-michael.christie@oracle.com
    Fixes: 3e0f65b34cc9 ("[SCSI] iscsi_transport: Additional parameters for network settings")
    Signed-off-by: Mike Christie <michael.christie@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bc1660206c3723c37ed4d622ad81781f1e987250
Author: Nguyen Dinh Phi <phind.uet@gmail.com>
Date:   Sun Jul 18 22:40:13 2021 +0800

    netrom: Decrease sock refcount when sock timers expire
    
    [ Upstream commit 517a16b1a88bdb6b530f48d5d153478b2552d9a8 ]
    
    Commit 63346650c1a9 ("netrom: switch to sock timer API") switched to use
    sock timer API. It replaces mod_timer() by sk_reset_timer(), and
    del_timer() by sk_stop_timer().
    
    Function sk_reset_timer() will increase the refcount of sock if it is
    called on an inactive timer, hence, in case the timer expires, we need to
    decrease the refcount ourselves in the handler, otherwise, the sock
    refcount will be unbalanced and the sock will never be freed.
    
    Signed-off-by: Nguyen Dinh Phi <phind.uet@gmail.com>
    Reported-by: syzbot+10f1194569953b72f1ae@syzkaller.appspotmail.com
    Fixes: 63346650c1a9 ("netrom: switch to sock timer API")
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c9437655302c503caa2a7ecf7a3167ee6a02cbef
Author: Xin Long <lucien.xin@gmail.com>
Date:   Sat Jul 17 17:19:19 2021 -0400

    sctp: trim optlen when it's a huge value in sctp_setsockopt
    
    [ Upstream commit 2f3fdd8d4805015fa964807e1c7f3d88f31bd389 ]
    
    After commit ca84bd058dae ("sctp: copy the optval from user space in
    sctp_setsockopt"), it does memory allocation in sctp_setsockopt with
    the optlen, and it would fail the allocation and return error if the
    optlen from user space is a huge value.
    
    This breaks some sockopts, like SCTP_HMAC_IDENT, SCTP_RESET_STREAMS and
    SCTP_AUTH_KEY, as when processing these sockopts before, optlen would
    be trimmed to a biggest value it needs when optlen is a huge value,
    instead of failing the allocation and returning error.
    
    This patch is to fix the allocation failure when it's a huge optlen from
    user space by trimming it to the biggest size sctp sockopt may need when
    necessary, and this biggest size is from sctp_setsockopt_reset_streams()
    for SCTP_RESET_STREAMS, which is bigger than those for SCTP_HMAC_IDENT
    and SCTP_AUTH_KEY.
    
    Fixes: ca84bd058dae ("sctp: copy the optval from user space in sctp_setsockopt")
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cac71d27745f92ee13f0ecc668ffe151a4a9c9b1
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Sat Jul 17 14:29:33 2021 +0300

    net: sched: fix memory leak in tcindex_partial_destroy_work
    
    [ Upstream commit f5051bcece50140abd1a11a2d36dc3ec5484fc32 ]
    
    Syzbot reported memory leak in tcindex_set_parms(). The problem was in
    non-freed perfect hash in tcindex_partial_destroy_work().
    
    In tcindex_set_parms() new tcindex_data is allocated and some fields from
    old one are copied to new one, but not the perfect hash. Since
    tcindex_partial_destroy_work() is the destroy function for old
    tcindex_data, we need to free perfect hash to avoid memory leak.
    
    Reported-and-tested-by: syzbot+f0bbb2287b8993d4fa74@syzkaller.appspotmail.com
    Fixes: 331b72922c5f ("net: sched: RCU cls_tcindex")
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a4a488915feaad38345cc01b80d52e8200ff5209
Author: Nicholas Piggin <npiggin@gmail.com>
Date:   Fri Jul 16 12:43:10 2021 +1000

    KVM: PPC: Fix kvm_arch_vcpu_ioctl vcpu_load leak
    
    [ Upstream commit bc4188a2f56e821ea057aca6bf444e138d06c252 ]
    
    vcpu_put is not called if the user copy fails. This can result in preempt
    notifier corruption and crashes, among other issues.
    
    Fixes: b3cebfe8c1ca ("KVM: PPC: Move vcpu_load/vcpu_put down to each ioctl case in kvm_arch_vcpu_ioctl")
    Reported-by: Alexey Kardashevskiy <aik@ozlabs.ru>
    Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20210716024310.164448-2-npiggin@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cdf4a0589eafbf9bc94af61b9ecf72220f00523f
Author: Nicholas Piggin <npiggin@gmail.com>
Date:   Fri Jul 16 12:43:09 2021 +1000

    KVM: PPC: Book3S: Fix CONFIG_TRANSACTIONAL_MEM=n crash
    
    [ Upstream commit bd31ecf44b8e18ccb1e5f6b50f85de6922a60de3 ]
    
    When running CPU_FTR_P9_TM_HV_ASSIST, HFSCR[TM] is set for the guest
    even if the host has CONFIG_TRANSACTIONAL_MEM=n, which causes it to be
    unprepared to handle guest exits while transactional.
    
    Normal guests don't have a problem because the HTM capability will not
    be advertised, but a rogue or buggy one could crash the host.
    
    Fixes: 4bb3c7a0208f ("KVM: PPC: Book3S HV: Work around transactional memory bugs in POWER9")
    Reported-by: Alexey Kardashevskiy <aik@ozlabs.ru>
    Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20210716024310.164448-1-npiggin@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 69f253c44401b7bd2ca42a943b43c0f784f4bafb
Author: Yajun Deng <yajun.deng@linux.dev>
Date:   Wed Jul 14 17:13:20 2021 +0800

    net: decnet: Fix sleeping inside in af_decnet
    
    [ Upstream commit 5f119ba1d5771bbf46d57cff7417dcd84d3084ba ]
    
    The release_sock() is blocking function, it would change the state
    after sleeping. use wait_woken() instead.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Yajun Deng <yajun.deng@linux.dev>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 626cb6d84ba227e9b1b2f578522bf59361611656
Author: Michal Suchanek <msuchanek@suse.de>
Date:   Thu Jul 8 11:46:54 2021 +0200

    efi/tpm: Differentiate missing and invalid final event log table.
    
    [ Upstream commit 674a9f1f6815849bfb5bf385e7da8fc198aaaba9 ]
    
    Missing TPM final event log table is not a firmware bug.
    
    Clearly if providing event log in the old format makes the final event
    log invalid it should not be provided at least in that case.
    
    Fixes: b4f1874c6216 ("tpm: check event log version before reading final events")
    Signed-off-by: Michal Suchanek <msuchanek@suse.de>
    Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f6eeb0829e1a29050d52b60f3f99650c248b3986
Author: Vijendar Mukunda <vijendar.mukunda@amd.com>
Date:   Fri Jul 16 18:00:12 2021 +0530

    ASoC: soc-pcm: add a flag to reverse the stop sequence
    
    [ Upstream commit 59dd33f82dc0975c55d3d46801e7ca45532d7673 ]
    
    On stream stop, currently CPU DAI stop sequence invoked first
    followed by DMA. For Few platforms, it is required to stop the
    DMA first before stopping CPU DAI.
    
    Introduced new flag in dai_link structure for reordering stop sequence.
    Based on flag check, ASoC core will re-order the stop sequence.
    
    Fixes: 4378f1fbe92405 ("ASoC: soc-pcm: Use different sequence for start/stop trigger")
    Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
    Link: https://lore.kernel.org/r/20210716123015.15697-1-vijendar.mukunda@amd.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 57df79dd0b47e89f149027af77b6727440d38443
Author: Roman Skakun <Roman_Skakun@epam.com>
Date:   Fri Jul 16 11:39:34 2021 +0300

    dma-mapping: handle vmalloc addresses in dma_common_{mmap,get_sgtable}
    
    [ Upstream commit 40ac971eab89330d6153e7721e88acd2d98833f9 ]
    
    xen-swiotlb can use vmalloc backed addresses for dma coherent allocations
    and uses the common helpers.  Properly handle them to unbreak Xen on
    ARM platforms.
    
    Fixes: 1b65c4e5a9af ("swiotlb-xen: use xen_alloc/free_coherent_pages")
    Signed-off-by: Roman Skakun <roman_skakun@epam.com>
    Reviewed-by: Andrii Anisov <andrii_anisov@epam.com>
    [hch: split the patch, renamed the helpers]
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eeaa4b8d1e2e6f10362673d283a97dccc7275afa
Author: Dongliang Mu <mudongliangabcd@gmail.com>
Date:   Wed Jul 14 17:13:22 2021 +0800

    usb: hso: fix error handling code of hso_create_net_device
    
    [ Upstream commit a6ecfb39ba9d7316057cea823b196b734f6b18ca ]
    
    The current error handling code of hso_create_net_device is
    hso_free_net_device, no matter which errors lead to. For example,
    WARNING in hso_free_net_device [1].
    
    Fix this by refactoring the error handling code of
    hso_create_net_device by handling different errors by different code.
    
    [1] https://syzkaller.appspot.com/bug?id=66eff8d49af1b28370ad342787413e35bbe76efe
    
    Reported-by: syzbot+44d53c7255bb1aea22d2@syzkaller.appspotmail.com
    Fixes: 5fcfb6d0bfcd ("hso: fix bailout in error case of probe")
    Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d20ce763c6904fc66405b177c1d0153282a43237
Author: Yoshitaka Ikeda <ikeda@nskint.co.jp>
Date:   Thu Jul 15 16:21:32 2021 +0000

    spi: spi-cadence-quadspi: Fix division by zero warning
    
    [ Upstream commit 55cef88bbf12f3bfbe5c2379a8868a034707e755 ]
    
    Fix below division by zero warning:
    - Added an if statement because buswidth can be zero, resulting in division by zero.
    - The modified code was based on another driver (atmel-quadspi).
    
    [    0.795337] Division by zero in kernel.
       :
    [    0.834051] [<807fd40c>] (__div0) from [<804e1acc>] (Ldiv0+0x8/0x10)
    [    0.839097] [<805f0710>] (cqspi_exec_mem_op) from [<805edb4c>] (spi_mem_exec_op+0x3b0/0x3f8)
    
    Fixes: 7512eaf54190 ("spi: cadence-quadspi: Fix dummy cycle calculation when buswidth > 1")
    Signed-off-by: Yoshitaka Ikeda <ikeda@nskint.co.jp>
    Link: https://lore.kernel.org/r/ed989af6-da88-4e0b-9ed8-126db6cad2e4@nskint.co.jp
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d4c7797ab1517515f0d08b3bc1c6b48883889c54
Author: Ziyang Xuan <william.xuanziyang@huawei.com>
Date:   Thu Jul 15 20:22:04 2021 +0800

    net: fix uninit-value in caif_seqpkt_sendmsg
    
    [ Upstream commit 991e634360f2622a683b48dfe44fe6d9cb765a09 ]
    
    When nr_segs equal to zero in iovec_from_user, the object
    msg->msg_iter.iov is uninit stack memory in caif_seqpkt_sendmsg
    which is defined in ___sys_sendmsg. So we cann't just judge
    msg->msg_iter.iov->base directlly. We can use nr_segs to judge
    msg in caif_seqpkt_sendmsg whether has data buffers.
    
    =====================================================
    BUG: KMSAN: uninit-value in caif_seqpkt_sendmsg+0x693/0xf60 net/caif/caif_socket.c:542
    Call Trace:
     __dump_stack lib/dump_stack.c:77 [inline]
     dump_stack+0x1c9/0x220 lib/dump_stack.c:118
     kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118
     __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215
     caif_seqpkt_sendmsg+0x693/0xf60 net/caif/caif_socket.c:542
     sock_sendmsg_nosec net/socket.c:652 [inline]
     sock_sendmsg net/socket.c:672 [inline]
     ____sys_sendmsg+0x12b6/0x1350 net/socket.c:2343
     ___sys_sendmsg net/socket.c:2397 [inline]
     __sys_sendmmsg+0x808/0xc90 net/socket.c:2480
     __compat_sys_sendmmsg net/compat.c:656 [inline]
    
    Reported-by: syzbot+09a5d591c1f98cf5efcb@syzkaller.appspotmail.com
    Link: https://syzkaller.appspot.com/bug?id=1ace85e8fc9b0d5a45c08c2656c3e91762daa9b8
    Fixes: bece7b2398d0 ("caif: Rewritten socket implementation")
    Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3d6f06fb19fb1763c7dd77f6b13e077f3e639f16
Author: Tobias Klauser <tklauser@distanz.ch>
Date:   Thu Jul 15 13:06:09 2021 +0200

    bpftool: Check malloc return value in mount_bpffs_for_pin
    
    [ Upstream commit d444b06e40855219ef38b5e9286db16d435f06dc ]
    
    Fix and add a missing NULL check for the prior malloc() call.
    
    Fixes: 49a086c201a9 ("bpftool: implement prog load command")
    Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Reviewed-by: Quentin Monnet <quentin@isovalent.com>
    Acked-by: Roman Gushchin <guro@fb.com>
    Link: https://lore.kernel.org/bpf/20210715110609.29364-1-tklauser@distanz.ch
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 464c306367cb649360a9143e469682a8dcc0a38d
Author: Jakub Sitnicki <jakub@cloudflare.com>
Date:   Wed Jul 14 17:47:50 2021 +0200

    bpf, sockmap, udp: sk_prot needs inuse_idx set for proc stats
    
    [ Upstream commit 54ea2f49fd9400dd698c25450be3352b5613b3b4 ]
    
    The proc socket stats use sk_prot->inuse_idx value to record inuse sock
    stats. We currently do not set this correctly from sockmap side. The
    result is reading sock stats '/proc/net/sockstat' gives incorrect values.
    The socket counter is incremented correctly, but because we don't set the
    counter correctly when we replace sk_prot we may omit the decrement.
    
    To get the correct inuse_idx value move the core_initcall that initializes
    the UDP proto handlers to late_initcall. This way it is initialized after
    UDP has the chance to assign the inuse_idx value from the register protocol
    handler.
    
    Fixes: edc6741cc660 ("bpf: Add sockmap hooks for UDP sockets")
    Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Reviewed-by: Cong Wang <cong.wang@bytedance.com>
    Acked-by: John Fastabend <john.fastabend@gmail.com>
    Link: https://lore.kernel.org/bpf/20210714154750.528206-1-jakub@cloudflare.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 600b122a690b613bb15eb98a6758d3926e06714e
Author: John Fastabend <john.fastabend@gmail.com>
Date:   Mon Jul 12 12:55:46 2021 -0700

    bpf, sockmap, tcp: sk_prot needs inuse_idx set for proc stats
    
    [ Upstream commit 228a4a7ba8e99bb9ef980b62f71e3be33f4aae69 ]
    
    The proc socket stats use sk_prot->inuse_idx value to record inuse sock
    stats. We currently do not set this correctly from sockmap side. The
    result is reading sock stats '/proc/net/sockstat' gives incorrect values.
    The socket counter is incremented correctly, but because we don't set the
    counter correctly when we replace sk_prot we may omit the decrement.
    
    To get the correct inuse_idx value move the core_initcall that initializes
    the TCP proto handlers to late_initcall. This way it is initialized after
    TCP has the chance to assign the inuse_idx value from the register protocol
    handler.
    
    Fixes: 604326b41a6fb ("bpf, sockmap: convert to generic sk_msg interface")
    Suggested-by: Jakub Sitnicki <jakub@cloudflare.com>
    Signed-off-by: John Fastabend <john.fastabend@gmail.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Reviewed-by: Cong Wang <cong.wang@bytedance.com>
    Link: https://lore.kernel.org/bpf/20210712195546.423990-3-john.fastabend@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6c508a1c6c62793dc6e6872cad4b200097bab7c9
Author: John Fastabend <john.fastabend@gmail.com>
Date:   Mon Jul 12 12:55:45 2021 -0700

    bpf, sockmap: Fix potential memory leak on unlikely error case
    
    [ Upstream commit 7e6b27a69167f97c56b5437871d29e9722c3e470 ]
    
    If skb_linearize is needed and fails we could leak a msg on the error
    handling. To fix ensure we kfree the msg block before returning error.
    Found during code review.
    
    Fixes: 4363023d2668e ("bpf, sockmap: Avoid failures from skb_to_sgvec when skb has frag_list")
    Signed-off-by: John Fastabend <john.fastabend@gmail.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Reviewed-by: Cong Wang <cong.wang@bytedance.com>
    Link: https://lore.kernel.org/bpf/20210712195546.423990-2-john.fastabend@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6be4502a80e3e17d96ac0033887dfbfec4480043
Author: Colin Ian King <colin.king@canonical.com>
Date:   Thu Jul 15 13:57:12 2021 +0100

    s390/bpf: Perform r1 range checking before accessing jit->seen_reg[r1]
    
    [ Upstream commit 91091656252f5d6d8c476e0c92776ce9fae7b445 ]
    
    Currently array jit->seen_reg[r1] is being accessed before the range
    checking of index r1. The range changing on r1 should be performed
    first since it will avoid any potential out-of-range accesses on the
    array seen_reg[] and also it is more optimal to perform checks on r1
    before fetching data from the array. Fix this by swapping the order
    of the checks before the array access.
    
    Fixes: 054623105728 ("s390/bpf: Add s390x eBPF JIT compiler backend")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Tested-by: Ilya Leoshkevich <iii@linux.ibm.com>
    Acked-by: Ilya Leoshkevich <iii@linux.ibm.com>
    Link: https://lore.kernel.org/bpf/20210715125712.24690-1-colin.king@canonical.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7006eabb4044ef46fe0ba15eefeb8f8aea172bf0
Author: Colin Ian King <colin.king@canonical.com>
Date:   Wed Jul 14 16:23:43 2021 +0100

    liquidio: Fix unintentional sign extension issue on left shift of u16
    
    [ Upstream commit e7efc2ce3d0789cd7c21b70ff00cd7838d382639 ]
    
    Shifting the u16 integer oct->pcie_port by CN23XX_PKT_INPUT_CTL_MAC_NUM_POS
    (29) bits will be promoted to a 32 bit signed int and then sign-extended
    to a u64. In the cases where oct->pcie_port where bit 2 is set (e.g. 3..7)
    the shifted value will be sign extended and the top 32 bits of the result
    will be set.
    
    Fix this by casting the u16 values to a u64 before the 29 bit left shift.
    
    Addresses-Coverity: ("Unintended sign extension")
    
    Fixes: 3451b97cce2d ("liquidio: CN23XX register setup")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1dd68ece22bab3f715c2cbfbeebf614c5441ba02
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Wed Jul 14 11:58:12 2021 +0200

    net: dsa: mv88e6xxx: NET_DSA_MV88E6XXX_PTP should depend on NET_DSA_MV88E6XXX
    
    [ Upstream commit 99bb2ebab953435852340cdb198c5abbf0bb5dd3 ]
    
    Making global2 support mandatory removed the Kconfig symbol
    NET_DSA_MV88E6XXX_GLOBAL2.  This symbol also served as an intermediate
    symbol to make NET_DSA_MV88E6XXX_PTP depend on NET_DSA_MV88E6XXX.  With
    the symbol removed, the user is always asked about PTP support for
    Marvell 88E6xxx switches, even if the latter support is not enabled.
    
    Fix this by reinstating the dependency.
    
    Fixes: 63368a7416df144b ("net: dsa: mv88e6xxx: Make global2 support mandatory")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5bd05b57e901066299fc675d120e0676255c2e9f
Author: Maxime Ripard <maxime@cerno.tech>
Date:   Wed Jul 7 11:51:10 2021 +0200

    drm/vc4: hdmi: Drop devm interrupt handler for CEC interrupts
    
    [ Upstream commit 32a19de21ae40f0601f48575b610dde4f518ccc6 ]
    
    The CEC interrupt handlers are registered through the
    devm_request_threaded_irq function. However, while free_irq is indeed
    called properly when the device is unbound or bind fails, it's called
    after unbind or bind is done.
    
    In our particular case, it means that on failure it creates a window
    where our interrupt handler can be called, but we're freeing every
    resource (CEC adapter, DRM objects, etc.) it might need.
    
    In order to address this, let's switch to the non-devm variant to
    control better when the handler will be unregistered and allow us to
    make it safe.
    
    Fixes: 15b4511a4af6 ("drm/vc4: add HDMI CEC support")
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210707095112.1469670-2-maxime@cerno.tech
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3ba73cb983023c833043c5f70325a77fabff6361
Author: Nicolas Saenz Julienne <nsaenzju@redhat.com>
Date:   Fri Jul 9 16:13:25 2021 +0200

    timers: Fix get_next_timer_interrupt() with no timers pending
    
    [ Upstream commit aebacb7f6ca1926918734faae14d1f0b6fae5cb7 ]
    
    31cd0e119d50 ("timers: Recalculate next timer interrupt only when
    necessary") subtly altered get_next_timer_interrupt()'s behaviour. The
    function no longer consistently returns KTIME_MAX with no timers
    pending.
    
    In order to decide if there are any timers pending we check whether the
    next expiry will happen NEXT_TIMER_MAX_DELTA jiffies from now.
    Unfortunately, the next expiry time and the timer base clock are no
    longer updated in unison. The former changes upon certain timer
    operations (enqueue, expire, detach), whereas the latter keeps track of
    jiffies as they move forward. Ultimately breaking the logic above.
    
    A simplified example:
    
    - Upon entering get_next_timer_interrupt() with:
    
            jiffies = 1
            base->clk = 0;
            base->next_expiry = NEXT_TIMER_MAX_DELTA;
    
      'base->next_expiry == base->clk + NEXT_TIMER_MAX_DELTA', the function
      returns KTIME_MAX.
    
    - 'base->clk' is updated to the jiffies value.
    
    - The next time we enter get_next_timer_interrupt(), taking into account
      no timer operations happened:
    
            base->clk = 1;
            base->next_expiry = NEXT_TIMER_MAX_DELTA;
    
      'base->next_expiry != base->clk + NEXT_TIMER_MAX_DELTA', the function
      returns a valid expire time, which is incorrect.
    
    This ultimately might unnecessarily rearm sched's timer on nohz_full
    setups, and add latency to the system[1].
    
    So, introduce 'base->timers_pending'[2], update it every time
    'base->next_expiry' changes, and use it in get_next_timer_interrupt().
    
    [1] See tick_nohz_stop_tick().
    [2] A quick pahole check on x86_64 and arm64 shows it doesn't make
        'struct timer_base' any bigger.
    
    Fixes: 31cd0e119d50 ("timers: Recalculate next timer interrupt only when necessary")
    Signed-off-by: Nicolas Saenz Julienne <nsaenzju@redhat.com>
    Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 364ec7249d01013e331b597089a1e04a8761d9d8
Author: Sathya Prakash M R <sathya.prakash.m.r@intel.com>
Date:   Mon Jul 12 15:16:20 2021 -0500

    ASoC: SOF: Intel: Update ADL descriptor to use ACPI power states
    
    [ Upstream commit aa21548e34c19c12e924c736f3fd9e6a4d0f5419 ]
    
    The ADL descriptor was missing an ACPI power setting, causing the DSP
    to enter D3 even with a D0i1-compatible wake-on-voice/hotwording
    capture stream.
    
    Fixes: 4ad03f894b3c ('ASoC: SOF: Intel: Update ADL P to use its own descriptor')
    Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
    Signed-off-by: Sathya Prakash M R <sathya.prakash.m.r@intel.com>
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Link: https://lore.kernel.org/r/20210712201620.44311-1-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a7537dc73e69ad9c0b67ad24ad3ebee954ed0af6
Author: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Date:   Sat Jul 10 11:16:35 2021 +0800

    xdp, net: Fix use-after-free in bpf_xdp_link_release
    
    [ Upstream commit 5acc7d3e8d342858405fbbc671221f676b547ce7 ]
    
    The problem occurs between dev_get_by_index() and dev_xdp_attach_link().
    At this point, dev_xdp_uninstall() is called. Then xdp link will not be
    detached automatically when dev is released. But link->dev already
    points to dev, when xdp link is released, dev will still be accessed,
    but dev has been released.
    
    dev_get_by_index()        |
    link->dev = dev           |
                              |      rtnl_lock()
                              |      unregister_netdevice_many()
                              |          dev_xdp_uninstall()
                              |      rtnl_unlock()
    rtnl_lock();              |
    dev_xdp_attach_link()     |
    rtnl_unlock();            |
                              |      netdev_run_todo() // dev released
    bpf_xdp_link_release()    |
        /* access dev.        |
           use-after-free */  |
    
    [   45.966867] BUG: KASAN: use-after-free in bpf_xdp_link_release+0x3b8/0x3d0
    [   45.967619] Read of size 8 at addr ffff00000f9980c8 by task a.out/732
    [   45.968297]
    [   45.968502] CPU: 1 PID: 732 Comm: a.out Not tainted 5.13.0+ #22
    [   45.969222] Hardware name: linux,dummy-virt (DT)
    [   45.969795] Call trace:
    [   45.970106]  dump_backtrace+0x0/0x4c8
    [   45.970564]  show_stack+0x30/0x40
    [   45.970981]  dump_stack_lvl+0x120/0x18c
    [   45.971470]  print_address_description.constprop.0+0x74/0x30c
    [   45.972182]  kasan_report+0x1e8/0x200
    [   45.972659]  __asan_report_load8_noabort+0x2c/0x50
    [   45.973273]  bpf_xdp_link_release+0x3b8/0x3d0
    [   45.973834]  bpf_link_free+0xd0/0x188
    [   45.974315]  bpf_link_put+0x1d0/0x218
    [   45.974790]  bpf_link_release+0x3c/0x58
    [   45.975291]  __fput+0x20c/0x7e8
    [   45.975706]  ____fput+0x24/0x30
    [   45.976117]  task_work_run+0x104/0x258
    [   45.976609]  do_notify_resume+0x894/0xaf8
    [   45.977121]  work_pending+0xc/0x328
    [   45.977575]
    [   45.977775] The buggy address belongs to the page:
    [   45.978369] page:fffffc00003e6600 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4f998
    [   45.979522] flags: 0x7fffe0000000000(node=0|zone=0|lastcpupid=0x3ffff)
    [   45.980349] raw: 07fffe0000000000 fffffc00003e6708 ffff0000dac3c010 0000000000000000
    [   45.981309] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
    [   45.982259] page dumped because: kasan: bad access detected
    [   45.982948]
    [   45.983153] Memory state around the buggy address:
    [   45.983753]  ffff00000f997f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    [   45.984645]  ffff00000f998000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    [   45.985533] >ffff00000f998080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    [   45.986419]                                               ^
    [   45.987112]  ffff00000f998100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    [   45.988006]  ffff00000f998180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    [   45.988895] ==================================================================
    [   45.989773] Disabling lock debugging due to kernel taint
    [   45.990552] Kernel panic - not syncing: panic_on_warn set ...
    [   45.991166] CPU: 1 PID: 732 Comm: a.out Tainted: G    B             5.13.0+ #22
    [   45.991929] Hardware name: linux,dummy-virt (DT)
    [   45.992448] Call trace:
    [   45.992753]  dump_backtrace+0x0/0x4c8
    [   45.993208]  show_stack+0x30/0x40
    [   45.993627]  dump_stack_lvl+0x120/0x18c
    [   45.994113]  dump_stack+0x1c/0x34
    [   45.994530]  panic+0x3a4/0x7d8
    [   45.994930]  end_report+0x194/0x198
    [   45.995380]  kasan_report+0x134/0x200
    [   45.995850]  __asan_report_load8_noabort+0x2c/0x50
    [   45.996453]  bpf_xdp_link_release+0x3b8/0x3d0
    [   45.997007]  bpf_link_free+0xd0/0x188
    [   45.997474]  bpf_link_put+0x1d0/0x218
    [   45.997942]  bpf_link_release+0x3c/0x58
    [   45.998429]  __fput+0x20c/0x7e8
    [   45.998833]  ____fput+0x24/0x30
    [   45.999247]  task_work_run+0x104/0x258
    [   45.999731]  do_notify_resume+0x894/0xaf8
    [   46.000236]  work_pending+0xc/0x328
    [   46.000697] SMP: stopping secondary CPUs
    [   46.001226] Dumping ftrace buffer:
    [   46.001663]    (ftrace buffer empty)
    [   46.002110] Kernel Offset: disabled
    [   46.002545] CPU features: 0x00000001,23202c00
    [   46.003080] Memory Limit: none
    
    Fixes: aa8d3a716b59db6c ("bpf, xdp: Add bpf_link-based XDP attachment API")
    Reported-by: Abaci <abaci@linux.alibaba.com>
    Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Reviewed-by: Dust Li <dust.li@linux.alibaba.com>
    Acked-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/20210710031635.41649-1-xuanzhuo@linux.alibaba.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cbb086074dab631ac43f8645cbac1d7b148e05c4
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Mon Jul 12 22:57:35 2021 +0200

    bpf: Fix tail_call_reachable rejection for interpreter when jit failed
    
    [ Upstream commit 5dd0a6b8582ffbfa88351949d50eccd5b6694ade ]
    
    During testing of f263a81451c1 ("bpf: Track subprog poke descriptors correctly
    and fix use-after-free") under various failure conditions, for example, when
    jit_subprogs() fails and tries to clean up the program to be run under the
    interpreter, we ran into the following freeze:
    
      [...]
      #127/8 tailcall_bpf2bpf_3:FAIL
      [...]
      [   92.041251] BUG: KASAN: slab-out-of-bounds in ___bpf_prog_run+0x1b9d/0x2e20
      [   92.042408] Read of size 8 at addr ffff88800da67f68 by task test_progs/682
      [   92.043707]
      [   92.044030] CPU: 1 PID: 682 Comm: test_progs Tainted: G   O   5.13.0-53301-ge6c08cb33a30-dirty #87
      [   92.045542] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 04/01/2014
      [   92.046785] Call Trace:
      [   92.047171]  ? __bpf_prog_run_args64+0xc0/0xc0
      [   92.047773]  ? __bpf_prog_run_args32+0x8b/0xb0
      [   92.048389]  ? __bpf_prog_run_args64+0xc0/0xc0
      [   92.049019]  ? ktime_get+0x117/0x130
      [...] // few hundred [similar] lines more
      [   92.659025]  ? ktime_get+0x117/0x130
      [   92.659845]  ? __bpf_prog_run_args64+0xc0/0xc0
      [   92.660738]  ? __bpf_prog_run_args32+0x8b/0xb0
      [   92.661528]  ? __bpf_prog_run_args64+0xc0/0xc0
      [   92.662378]  ? print_usage_bug+0x50/0x50
      [   92.663221]  ? print_usage_bug+0x50/0x50
      [   92.664077]  ? bpf_ksym_find+0x9c/0xe0
      [   92.664887]  ? ktime_get+0x117/0x130
      [   92.665624]  ? kernel_text_address+0xf5/0x100
      [   92.666529]  ? __kernel_text_address+0xe/0x30
      [   92.667725]  ? unwind_get_return_address+0x2f/0x50
      [   92.668854]  ? ___bpf_prog_run+0x15d4/0x2e20
      [   92.670185]  ? ktime_get+0x117/0x130
      [   92.671130]  ? __bpf_prog_run_args64+0xc0/0xc0
      [   92.672020]  ? __bpf_prog_run_args32+0x8b/0xb0
      [   92.672860]  ? __bpf_prog_run_args64+0xc0/0xc0
      [   92.675159]  ? ktime_get+0x117/0x130
      [   92.677074]  ? lock_is_held_type+0xd5/0x130
      [   92.678662]  ? ___bpf_prog_run+0x15d4/0x2e20
      [   92.680046]  ? ktime_get+0x117/0x130
      [   92.681285]  ? __bpf_prog_run32+0x6b/0x90
      [   92.682601]  ? __bpf_prog_run64+0x90/0x90
      [   92.683636]  ? lock_downgrade+0x370/0x370
      [   92.684647]  ? mark_held_locks+0x44/0x90
      [   92.685652]  ? ktime_get+0x117/0x130
      [   92.686752]  ? lockdep_hardirqs_on+0x79/0x100
      [   92.688004]  ? ktime_get+0x117/0x130
      [   92.688573]  ? __cant_migrate+0x2b/0x80
      [   92.689192]  ? bpf_test_run+0x2f4/0x510
      [   92.689869]  ? bpf_test_timer_continue+0x1c0/0x1c0
      [   92.690856]  ? rcu_read_lock_bh_held+0x90/0x90
      [   92.691506]  ? __kasan_slab_alloc+0x61/0x80
      [   92.692128]  ? eth_type_trans+0x128/0x240
      [   92.692737]  ? __build_skb+0x46/0x50
      [   92.693252]  ? bpf_prog_test_run_skb+0x65e/0xc50
      [   92.693954]  ? bpf_prog_test_run_raw_tp+0x2d0/0x2d0
      [   92.694639]  ? __fget_light+0xa1/0x100
      [   92.695162]  ? bpf_prog_inc+0x23/0x30
      [   92.695685]  ? __sys_bpf+0xb40/0x2c80
      [   92.696324]  ? bpf_link_get_from_fd+0x90/0x90
      [   92.697150]  ? mark_held_locks+0x24/0x90
      [   92.698007]  ? lockdep_hardirqs_on_prepare+0x124/0x220
      [   92.699045]  ? finish_task_switch+0xe6/0x370
      [   92.700072]  ? lockdep_hardirqs_on+0x79/0x100
      [   92.701233]  ? finish_task_switch+0x11d/0x370
      [   92.702264]  ? __switch_to+0x2c0/0x740
      [   92.703148]  ? mark_held_locks+0x24/0x90
      [   92.704155]  ? __x64_sys_bpf+0x45/0x50
      [   92.705146]  ? do_syscall_64+0x35/0x80
      [   92.706953]  ? entry_SYSCALL_64_after_hwframe+0x44/0xae
      [...]
    
    Turns out that the program rejection from e411901c0b77 ("bpf: allow for tailcalls
    in BPF subprograms for x64 JIT") is buggy since env->prog->aux->tail_call_reachable
    is never true. Commit ebf7d1f508a7 ("bpf, x64: rework pro/epilogue and tailcall
    handling in JIT") added a tracker into check_max_stack_depth() which propagates
    the tail_call_reachable condition throughout the subprograms. This info is then
    assigned to the subprogram's func[i]->aux->tail_call_reachable. However, in the
    case of the rejection check upon JIT failure, env->prog->aux->tail_call_reachable
    is used. func[0]->aux->tail_call_reachable which represents the main program's
    information did not propagate this to the outer env->prog->aux, though. Add this
    propagation into check_max_stack_depth() where it needs to belong so that the
    check can be done reliably.
    
    Fixes: ebf7d1f508a7 ("bpf, x64: rework pro/epilogue and tailcall handling in JIT")
    Fixes: e411901c0b77 ("bpf: allow for tailcalls in BPF subprograms for x64 JIT")
    Co-developed-by: John Fastabend <john.fastabend@gmail.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: John Fastabend <john.fastabend@gmail.com>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Acked-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
    Link: https://lore.kernel.org/bpf/618c34e3163ad1a36b1e82377576a6081e182f25.1626123173.git.daniel@iogearbox.net
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cd12f874ae1003cf391a8b08dab5ef6c46e08d21
Author: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Date:   Thu Jul 8 16:04:09 2021 +0800

    bpf, test: fix NULL pointer dereference on invalid expected_attach_type
    
    [ Upstream commit 5e21bb4e812566aef86fbb77c96a4ec0782286e4 ]
    
    These two types of XDP progs (BPF_XDP_DEVMAP, BPF_XDP_CPUMAP) will not be
    executed directly in the driver, therefore we should also not directly
    run them from here. To run in these two situations, there must be further
    preparations done, otherwise these may cause a kernel panic.
    
    For more details, see also dev_xdp_attach().
    
      [   46.982479] BUG: kernel NULL pointer dereference, address: 0000000000000000
      [   46.984295] #PF: supervisor read access in kernel mode
      [   46.985777] #PF: error_code(0x0000) - not-present page
      [   46.987227] PGD 800000010dca4067 P4D 800000010dca4067 PUD 10dca6067 PMD 0
      [   46.989201] Oops: 0000 [#1] SMP PTI
      [   46.990304] CPU: 7 PID: 562 Comm: a.out Not tainted 5.13.0+ #44
      [   46.992001] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/24
      [   46.995113] RIP: 0010:___bpf_prog_run+0x17b/0x1710
      [   46.996586] Code: 49 03 14 cc e8 76 f6 fe ff e9 ad fe ff ff 0f b6 43 01 48 0f bf 4b 02 48 83 c3 08 89 c2 83 e0 0f c0 ea 04 02
      [   47.001562] RSP: 0018:ffffc900005afc58 EFLAGS: 00010246
      [   47.003115] RAX: 0000000000000000 RBX: ffffc9000023f068 RCX: 0000000000000000
      [   47.005163] RDX: 0000000000000000 RSI: 0000000000000079 RDI: ffffc900005afc98
      [   47.007135] RBP: 0000000000000000 R08: ffffc9000023f048 R09: c0000000ffffdfff
      [   47.009171] R10: 0000000000000001 R11: ffffc900005afb40 R12: ffffc900005afc98
      [   47.011172] R13: 0000000000000001 R14: 0000000000000001 R15: ffffffff825258a8
      [   47.013244] FS:  00007f04a5207580(0000) GS:ffff88842fdc0000(0000) knlGS:0000000000000000
      [   47.015705] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   47.017475] CR2: 0000000000000000 CR3: 0000000100182005 CR4: 0000000000770ee0
      [   47.019558] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [   47.021595] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [   47.023574] PKRU: 55555554
      [   47.024571] Call Trace:
      [   47.025424]  __bpf_prog_run32+0x32/0x50
      [   47.026296]  ? printk+0x53/0x6a
      [   47.027066]  ? ktime_get+0x39/0x90
      [   47.027895]  bpf_test_run.cold.28+0x23/0x123
      [   47.028866]  ? printk+0x53/0x6a
      [   47.029630]  bpf_prog_test_run_xdp+0x149/0x1d0
      [   47.030649]  __sys_bpf+0x1305/0x23d0
      [   47.031482]  __x64_sys_bpf+0x17/0x20
      [   47.032316]  do_syscall_64+0x3a/0x80
      [   47.033165]  entry_SYSCALL_64_after_hwframe+0x44/0xae
      [   47.034254] RIP: 0033:0x7f04a51364dd
      [   47.035133] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 48
      [   47.038768] RSP: 002b:00007fff8f9fc518 EFLAGS: 00000213 ORIG_RAX: 0000000000000141
      [   47.040344] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f04a51364dd
      [   47.041749] RDX: 0000000000000048 RSI: 0000000020002a80 RDI: 000000000000000a
      [   47.043171] RBP: 00007fff8f9fc530 R08: 0000000002049300 R09: 0000000020000100
      [   47.044626] R10: 0000000000000004 R11: 0000000000000213 R12: 0000000000401070
      [   47.046088] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
      [   47.047579] Modules linked in:
      [   47.048318] CR2: 0000000000000000
      [   47.049120] ---[ end trace 7ad34443d5be719a ]---
      [   47.050273] RIP: 0010:___bpf_prog_run+0x17b/0x1710
      [   47.051343] Code: 49 03 14 cc e8 76 f6 fe ff e9 ad fe ff ff 0f b6 43 01 48 0f bf 4b 02 48 83 c3 08 89 c2 83 e0 0f c0 ea 04 02
      [   47.054943] RSP: 0018:ffffc900005afc58 EFLAGS: 00010246
      [   47.056068] RAX: 0000000000000000 RBX: ffffc9000023f068 RCX: 0000000000000000
      [   47.057522] RDX: 0000000000000000 RSI: 0000000000000079 RDI: ffffc900005afc98
      [   47.058961] RBP: 0000000000000000 R08: ffffc9000023f048 R09: c0000000ffffdfff
      [   47.060390] R10: 0000000000000001 R11: ffffc900005afb40 R12: ffffc900005afc98
      [   47.061803] R13: 0000000000000001 R14: 0000000000000001 R15: ffffffff825258a8
      [   47.063249] FS:  00007f04a5207580(0000) GS:ffff88842fdc0000(0000) knlGS:0000000000000000
      [   47.065070] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   47.066307] CR2: 0000000000000000 CR3: 0000000100182005 CR4: 0000000000770ee0
      [   47.067747] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [   47.069217] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [   47.070652] PKRU: 55555554
      [   47.071318] Kernel panic - not syncing: Fatal exception
      [   47.072854] Kernel Offset: disabled
      [   47.073683] ---[ end Kernel panic - not syncing: Fatal exception ]---
    
    Fixes: 9216477449f3 ("bpf: cpumap: Add the possibility to attach an eBPF program to cpumap")
    Fixes: fbee97feed9b ("bpf: Add support to attach bpf program to a devmap entry")
    Reported-by: Abaci <abaci@linux.alibaba.com>
    Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Reviewed-by: Dust Li <dust.li@linux.alibaba.com>
    Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
    Acked-by: David Ahern <dsahern@kernel.org>
    Acked-by: Song Liu <songliubraving@fb.com>
    Link: https://lore.kernel.org/bpf/20210708080409.73525-1-xuanzhuo@linux.alibaba.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bc813a1ae95c0a260d2213ba5656ed119cc559a1
Author: Maxim Schwalm <maxim.schwalm@gmail.com>
Date:   Mon Jul 12 03:50:11 2021 +0300

    ASoC: rt5631: Fix regcache sync errors on resume
    
    [ Upstream commit c71f78a662611fe2c67f3155da19b0eff0f29762 ]
    
    The ALC5631 does not like multi-write accesses, avoid them. This fixes:
    
    rt5631 4-001a: Unable to sync registers 0x3a-0x3c. -121
    
    errors on resume from suspend (and all registers after the registers in
    the error not being synced).
    
    Inspired by commit 2d30e9494f1e ("ASoC: rt5651: Fix regcache sync errors
    on resume") from Hans de Geode, which fixed the same errors on ALC5651.
    
    Signed-off-by: Maxim Schwalm <maxim.schwalm@gmail.com>
    Link: https://lore.kernel.org/r/20210712005011.28536-1-digetx@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 09b8cc7810587257e5f82080884001301e1a1ba9
Author: Peter Hess <peter.hess@ph-home.de>
Date:   Tue Jul 6 14:16:09 2021 +0200

    spi: mediatek: fix fifo rx mode
    
    [ Upstream commit 3a70dd2d050331ee4cf5ad9d5c0a32d83ead9a43 ]
    
    In FIFO mode were two problems:
    - RX mode was never handled and
    - in this case the tx_buf pointer was NULL and caused an exception
    
    fix this by handling RX mode in mtk_spi_fifo_transfer
    
    Fixes: a568231f4632 ("spi: mediatek: Add spi bus for Mediatek MT8173")
    Signed-off-by: Peter Hess <peter.hess@ph-home.de>
    Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
    Link: https://lore.kernel.org/r/20210706121609.680534-1-linux@fw-web.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit edd1b2b19214d90df76af88cebbe619222c344e2
Author: Axel Lin <axel.lin@ingics.com>
Date:   Wed Jun 30 17:59:59 2021 +0800

    regulator: hi6421: Fix getting wrong drvdata
    
    [ Upstream commit 1c73daee4bf30ccdff5e86dc400daa6f74735da5 ]
    
    Since config.dev = pdev->dev.parent in current code, so
    dev_get_drvdata(rdev->dev.parent) call in hi6421_regulator_enable
    returns the drvdata of the mfd device rather than the regulator. Fix it.
    
    This was broken while converting to use simplified DT parsing because the
    config.dev changed from pdev->dev to pdev->dev.parent for parsing the
    parent's of_node.
    
    Fixes: 29dc269a85ef ("regulator: hi6421: Convert to use simplified DT parsing")
    Signed-off-by: Axel Lin <axel.lin@ingics.com>
    Link: https://lore.kernel.org/r/20210630095959.2411543-1-axel.lin@ingics.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ae58c13a6b24b02dcadcd1380b49782808f43cee
Author: Axel Lin <axel.lin@ingics.com>
Date:   Sat Jun 19 20:41:33 2021 +0800

    regulator: hi6421: Use correct variable type for regmap api val argument
    
    [ Upstream commit ae60e6a9d24e89a74e2512204ad04de94921bdd2 ]
    
    Use unsigned int instead of u32 for regmap_read/regmap_update_bits val
    argument.
    
    Signed-off-by: Axel Lin <axel.lin@ingics.com>
    Link: https://lore.kernel.org/r/20210619124133.4096683-1-axel.lin@ingics.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ffb6e766e200f33b9a3df70e1e3f5eb3c26881f1
Author: Alain Volmat <alain.volmat@foss.st.com>
Date:   Wed Jul 7 10:27:00 2021 +0200

    spi: stm32: fixes pm_runtime calls in probe/remove
    
    [ Upstream commit 7999d2555c9f879d006ea8469d74db9cdb038af0 ]
    
    Add pm_runtime calls in probe/probe error path and remove
    in order to be consistent in all places in ordering and
    ensure that pm_runtime is disabled prior to resources used
    by the SPI controller.
    
    This patch also fixes the 2 following warnings on driver remove:
    WARNING: CPU: 0 PID: 743 at drivers/clk/clk.c:594 clk_core_disable_lock+0x18/0x24
    WARNING: CPU: 0 PID: 743 at drivers/clk/clk.c:476 clk_unprepare+0x24/0x2c
    
    Fixes: 038ac869c9d2 ("spi: stm32: add runtime PM support")
    
    Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
    Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
    Link: https://lore.kernel.org/r/1625646426-5826-2-git-send-email-alain.volmat@foss.st.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5b64a59c2c6e52fb17b6a9692ad9062749e9e5ec
Author: Charles Keepax <ckeepax@opensource.cirrus.com>
Date:   Sat Jun 26 16:59:39 2021 +0100

    ASoC: wm_adsp: Correct wm_coeff_tlv_get handling
    
    [ Upstream commit dd6fb8ff2210f74b056bf9234d0605e8c26a8ac0 ]
    
    When wm_coeff_tlv_get was updated it was accidentally switch to the _raw
    version of the helper causing it to ignore the current DSP state it
    should be checking. Switch the code back to the correct helper so that
    users can't read the controls when they arn't available.
    
    Fixes: 73ecf1a673d3 ("ASoC: wm_adsp: Correct cache handling of new kernel control API")
    Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20210626155941.12251-1-ckeepax@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 14e7330ad1064fe453c3c144b42a3aab931ff80a
Author: Lecopzer Chen <lecopzer.chen@mediatek.com>
Date:   Thu Jul 15 15:37:16 2021 +0800

    Kbuild: lto: fix module versionings mismatch in GNU make 3.X
    
    [ Upstream commit 1d11053dc63094075bf9e4809fffd3bb5e72f9a6 ]
    
    When building modules(CONFIG_...=m), I found some of module versions
    are incorrect and set to 0.
    This can be found in build log for first clean build which shows
    
    WARNING: EXPORT symbol "XXXX" [drivers/XXX/XXX.ko] version generation failed,
    symbol will not be versioned.
    
    But in second build(incremental build), the WARNING disappeared and the
    module version becomes valid CRC and make someone who want to change
    modules without updating kernel image can't insert their modules.
    
    The problematic code is
    +       $(foreach n, $(filter-out FORCE,$^),                            \
    +               $(if $(wildcard $(n).symversions),                      \
    +                       ; cat $(n).symversions >> $@.symversions))
    
    For example:
      rm -f fs/notify/built-in.a.symversions    ; rm -f fs/notify/built-in.a; \
    llvm-ar cDPrST fs/notify/built-in.a fs/notify/fsnotify.o \
    fs/notify/notification.o fs/notify/group.o ...
    
    `foreach n` shows nothing to `cat` into $(n).symversions because
    `if $(wildcard $(n).symversions)` return nothing, but actually
    they do exist during this line was executed.
    
    -rw-r--r-- 1 root root 168580 Jun 13 19:10 fs/notify/fsnotify.o
    -rw-r--r-- 1 root root    111 Jun 13 19:10 fs/notify/fsnotify.o.symversions
    
    The reason is the $(n).symversions are generated at runtime, but
    Makefile wildcard function expends and checks the file exist or not
    during parsing the Makefile.
    
    Thus fix this by use `test` shell command to check the file
    existence in runtime.
    
    Rebase from both:
    1. [https://lore.kernel.org/lkml/20210616080252.32046-1-lecopzer.chen@mediatek.com/]
    2. [https://lore.kernel.org/lkml/20210702032943.7865-1-lecopzer.chen@mediatek.com/]
    
    Fixes: 38e891849003 ("kbuild: lto: fix module versioning")
    Co-developed-by: Sami Tolvanen <samitolvanen@google.com>
    Signed-off-by: Lecopzer Chen <lecopzer.chen@mediatek.com>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4fc85eb660864c4b7a3d1d46c13157fcefeed7e2
Author: Yang Jihong <yangjihong1@huawei.com>
Date:   Tue Jul 13 19:23:58 2021 +0800

    perf sched: Fix record failure when CONFIG_SCHEDSTATS is not set
    
    [ Upstream commit b0f008551f0bf4d5f6db9b5f0e071b02790d6a2e ]
    
    The tracepoints trace_sched_stat_{wait, sleep, iowait} are not exposed to user
    if CONFIG_SCHEDSTATS is not set, "perf sched record" records the three events.
    As a result, the command fails.
    
    Before:
    
      #perf sched record sleep 1
      event syntax error: 'sched:sched_stat_wait'
                           \___ unknown tracepoint
    
      Error:  File /sys/kernel/tracing/events/sched/sched_stat_wait not found.
      Hint:   Perhaps this kernel misses some CONFIG_ setting to enable this feature?.
    
      Run 'perf list' for a list of valid events
    
       Usage: perf record [<options>] [<command>]
          or: perf record [<options>] -- <command> [<options>]
    
          -e, --event <event>   event selector. use 'perf list' to list available events
    
    Solution:
      Check whether schedstat tracepoints are exposed. If no, these events are not recorded.
    
    After:
      # perf sched record sleep 1
      [ perf record: Woken up 1 times to write data ]
      [ perf record: Captured and wrote 0.163 MB perf.data (1091 samples) ]
      # perf sched report
      run measurement overhead: 4736 nsecs
      sleep measurement overhead: 9059979 nsecs
      the run test took 999854 nsecs
      the sleep test took 8945271 nsecs
      nr_run_events:        716
      nr_sleep_events:      785
      nr_wakeup_events:     0
      ...
      ------------------------------------------------------------
    
    Fixes: 2a09b5de235a6 ("sched/fair: do not expose some tracepoints to user if CONFIG_SCHEDSTATS is not set")
    Signed-off-by: Yang Jihong <yangjihong1@huawei.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Cc: Yafang Shao <laoar.shao@gmail.com>
    Link: http://lore.kernel.org/lkml/20210713112358.194693-1-yangjihong1@huawei.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a83d04c140e37dcbcc5a25f19aad0973c12b64fb
Author: Riccardo Mancini <rickyman7@gmail.com>
Date:   Fri Jul 16 16:11:20 2021 +0200

    perf data: Close all files in close_dir()
    
    [ Upstream commit d4b3eedce151e63932ce4a00f1d0baa340a8b907 ]
    
    When using 'perf report' in directory mode, the first file is not closed
    on exit, causing a memory leak.
    
    The problem is caused by the iterating variable never reaching 0.
    
    Fixes: 145520631130bd64 ("perf data: Add perf_data__(create_dir|close_dir) functions")
    Signed-off-by: Riccardo Mancini <rickyman7@gmail.com>
    Acked-by: Namhyung Kim <namhyung@kernel.org>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Zhen Lei <thunder.leizhen@huawei.com>
    Link: http://lore.kernel.org/lkml/20210716141122.858082-1-rickyman7@gmail.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ed0bdfef4ba5e294815769ef2ca50bc99e0a820f
Author: Riccardo Mancini <rickyman7@gmail.com>
Date:   Thu Jul 15 18:07:25 2021 +0200

    perf probe-file: Delete namelist in del_events() on the error path
    
    [ Upstream commit e0fa7ab42232e742dcb3de9f3c1f6127b5adc019 ]
    
    ASan reports some memory leaks when running:
    
      # perf test "42: BPF filter"
    
    This second leak is caused by a strlist not being dellocated on error
    inside probe_file__del_events.
    
    This patch adds a goto label before the deallocation and makes the error
    path jump to it.
    
    Signed-off-by: Riccardo Mancini <rickyman7@gmail.com>
    Fixes: e7895e422e4da63d ("perf probe: Split del_perf_probe_events()")
    Cc: Ian Rogers <irogers@google.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lore.kernel.org/lkml/174963c587ae77fa108af794669998e4ae558338.1626343282.git.rickyman7@gmail.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 871c7043aa52382d62f1c0bff8691a052030843a
Author: Riccardo Mancini <rickyman7@gmail.com>
Date:   Thu Jul 15 18:07:19 2021 +0200

    perf lzma: Close lzma stream on exit
    
    [ Upstream commit f8cbb0f926ae1e1fb5f9e51614e5437560ed4039 ]
    
    ASan reports memory leaks when running:
    
      # perf test "88: Check open filename arg using perf trace + vfs_getname"
    
    One of these is caused by the lzma stream never being closed inside
    lzma_decompress_to_file().
    
    This patch adds the missing lzma_end().
    
    Signed-off-by: Riccardo Mancini <rickyman7@gmail.com>
    Fixes: 80a32e5b498a7547 ("perf tools: Add lzma decompression support for kernel module")
    Cc: Ian Rogers <irogers@google.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lore.kernel.org/lkml/aaf50bdce7afe996cfc06e1bbb36e4a2a9b9db93.1626343282.git.rickyman7@gmail.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e4518a4141f260ed0fec6bcca24906250ff441c6
Author: Riccardo Mancini <rickyman7@gmail.com>
Date:   Thu Jul 15 18:07:18 2021 +0200

    perf script: Fix memory 'threads' and 'cpus' leaks on exit
    
    [ Upstream commit faf3ac305d61341c74e5cdd9e41daecce7f67bfe ]
    
    ASan reports several memory leaks while running:
    
      # perf test "82: Use vfs_getname probe to get syscall args filenames"
    
    Two of these are caused by some refcounts not being decreased on
    perf-script exit, namely script.threads and script.cpus.
    
    This patch adds the missing __put calls in a new perf_script__exit
    function, which is called at the end of cmd_script.
    
    This patch concludes the fixes of all remaining memory leaks in perf
    test "82: Use vfs_getname probe to get syscall args filenames".
    
    Signed-off-by: Riccardo Mancini <rickyman7@gmail.com>
    Fixes: cfc8874a48599249 ("perf script: Process cpu/threads maps")
    Cc: Ian Rogers <irogers@google.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lore.kernel.org/lkml/5ee73b19791c6fa9d24c4d57f4ac1a23609400d7.1626343282.git.rickyman7@gmail.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a412ae547ed514efefd4d980e8511ec32021777c
Author: Riccardo Mancini <rickyman7@gmail.com>
Date:   Thu Jul 15 18:07:17 2021 +0200

    perf script: Release zstd data
    
    [ Upstream commit 1b1f57cf9e4c8eb16c8f6b2ce12cc5dd3517fc61 ]
    
    ASan reports several memory leak while running:
    
      # perf test "82: Use vfs_getname probe to get syscall args filenames"
    
    One of the leaks is caused by zstd data not being released on exit in
    perf-script.
    
    This patch adds the missing zstd_fini().
    
    Signed-off-by: Riccardo Mancini <rickyman7@gmail.com>
    Fixes: b13b04d9382113f7 ("perf script: Initialize zstd_data")
    Cc: Ian Rogers <irogers@google.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Milian Wolff <milian.wolff@kdab.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lore.kernel.org/lkml/39388e8cc2f85ca219ea18697a17b7bd8f74b693.1626343282.git.rickyman7@gmail.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f50f139670f942a7885225f3b930261eff249a79
Author: Riccardo Mancini <rickyman7@gmail.com>
Date:   Thu Jul 15 18:07:14 2021 +0200

    perf report: Free generated help strings for sort option
    
    [ Upstream commit a37338aad8c4d8676173ead14e881d2ec308155c ]
    
    ASan reports the memory leak of the strings allocated by sort_help() when
    running perf report.
    
    This patch changes the returned pointer to char* (instead of const
    char*), saves it in a temporary variable, and finally deallocates it at
    function exit.
    
    Signed-off-by: Riccardo Mancini <rickyman7@gmail.com>
    Fixes: 702fb9b415e7c99b ("perf report: Show all sort keys in help output")
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lore.kernel.org/lkml/a38b13f02812a8a6759200b9063c6191337f44d4.1626343282.git.rickyman7@gmail.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 97bb58171315dbe7b5295fd68cfc65348d4c071c
Author: Riccardo Mancini <rickyman7@gmail.com>
Date:   Thu Jul 15 18:07:13 2021 +0200

    perf env: Fix memory leak of cpu_pmu_caps
    
    [ Upstream commit da6b7c6c0626901428245f65712385805e42eba6 ]
    
    ASan reports memory leaks while running:
    
     # perf test "83: Zstd perf.data compression/decompression"
    
    The first of the leaks is caused by env->cpu_pmu_caps not being freed.
    
    This patch adds the missing (z)free inside perf_env__exit.
    
    Signed-off-by: Riccardo Mancini <rickyman7@gmail.com>
    Fixes: 6f91ea283a1ed23e ("perf header: Support CPU PMU capabilities")
    Cc: Ian Rogers <irogers@google.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lore.kernel.org/lkml/6ba036a8220156ec1f3d6be3e5d25920f6145028.1626343282.git.rickyman7@gmail.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9f29d864b4adf41015965dec115532692654373f
Author: Riccardo Mancini <rickyman7@gmail.com>
Date:   Thu Jul 15 18:07:12 2021 +0200

    perf test maps__merge_in: Fix memory leak of maps
    
    [ Upstream commit 244d1797c8c8e850b8de7992af713aa5c70d5650 ]
    
    ASan reports a memory leak when running:
    
      # perf test "65: maps__merge_in"
    
    This is the second and final patch addressing these memory leaks.
    
    This time, the problem is simply that the maps object is never
    destructed.
    
    This patch adds the missing maps__exit call.
    
    Signed-off-by: Riccardo Mancini <rickyman7@gmail.com>
    Fixes: 79b6bb73f888933c ("perf maps: Merge 'struct maps' with 'struct map_groups'")
    Cc: Ian Rogers <irogers@google.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lore.kernel.org/lkml/a1a29b97a58738987d150e94d4ebfad0282fb038.1626343282.git.rickyman7@gmail.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 976804a726c7cb90a940668ddd70f1e781fabb39
Author: Riccardo Mancini <rickyman7@gmail.com>
Date:   Thu Jul 15 18:07:11 2021 +0200

    perf dso: Fix memory leak in dso__new_map()
    
    [ Upstream commit 581e295a0f6b5c2931d280259fbbfff56959faa9 ]
    
    ASan reports a memory leak when running:
    
      # perf test "65: maps__merge_in".
    
    The causes of the leaks are two, this patch addresses only the first
    one, which is related to dso__new_map().
    
    The bug is that dso__new_map() creates a new dso but never decreases the
    refcount it gets from creating it.
    
    This patch adds the missing dso__put().
    
    Signed-off-by: Riccardo Mancini <rickyman7@gmail.com>
    Fixes: d3a7c489c7fd2463 ("perf tools: Reference count struct dso")
    Cc: Ian Rogers <irogers@google.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lore.kernel.org/lkml/60bfe0cd06e89e2ca33646eb8468d7f5de2ee597.1626343282.git.rickyman7@gmail.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e39103cfa102b390a5aa1c1f5b372115bc6b31dd
Author: Riccardo Mancini <rickyman7@gmail.com>
Date:   Thu Jul 15 18:07:10 2021 +0200

    perf test event_update: Fix memory leak of unit
    
    [ Upstream commit dccfca926c351ba0893af4c8b481477bdb2881a4 ]
    
    ASan reports a memory leak while running:
    
      # perf test "49: Synthesize attr update"
    
    Caused by a string being duplicated but never freed.
    
    This patch adds the missing free().
    
    Note that evsel->unit is not deallocated together with evsel since it is
    supposed to be a constant string.
    
    Signed-off-by: Riccardo Mancini <rickyman7@gmail.com>
    Fixes: a6e5281780d1da65 ("perf tools: Add event_update event unit type")
    Cc: Ian Rogers <irogers@google.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lore.kernel.org/lkml/1fbc8158663fb0d4d5392e36bae564f6ad60be3c.1626343282.git.rickyman7@gmail.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4db1e70516a4cc10ab8c861e903b5f3d7afa50c8
Author: Riccardo Mancini <rickyman7@gmail.com>
Date:   Thu Jul 15 18:07:09 2021 +0200

    perf test event_update: Fix memory leak of evlist
    
    [ Upstream commit fc56f54f6fcd5337634f4545af6459613129b432 ]
    
    ASan reports a memory leak when running:
    
      # perf test "49: Synthesize attr update"
    
    Caused by evlist not being deleted.
    
    This patch adds the missing evlist__delete and removes the
    perf_cpu_map__put since it's already being deleted by evlist__delete.
    
    Signed-off-by: Riccardo Mancini <rickyman7@gmail.com>
    Fixes: a6e5281780d1da65 ("perf tools: Add event_update event unit type")
    Cc: Ian Rogers <irogers@google.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lore.kernel.org/lkml/f7994ad63d248f7645f901132d208fadf9f2b7e4.1626343282.git.rickyman7@gmail.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 19239ff4c98da41d223daa3806b8cef0f43ed13a
Author: Riccardo Mancini <rickyman7@gmail.com>
Date:   Thu Jul 15 18:07:08 2021 +0200

    perf test session_topology: Delete session->evlist
    
    [ Upstream commit 233f2dc1c284337286f9a64c0152236779a42f6c ]
    
    ASan reports a memory leak related to session->evlist while running:
    
      # perf test "41: Session topology".
    
    When perf_data is in write mode, session->evlist is owned by the caller,
    which should also take care of deleting it.
    
    This patch adds the missing evlist__delete().
    
    Signed-off-by: Riccardo Mancini <rickyman7@gmail.com>
    Fixes: c84974ed9fb67293 ("perf test: Add entry to test cpu topology")
    Cc: Ian Rogers <irogers@google.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Kan Liang <kan.liang@intel.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lore.kernel.org/lkml/822f741f06eb25250fb60686cf30a35f447e9e91.1626343282.git.rickyman7@gmail.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 76b70b7987e76f420a5039b17d7498f9e8b3feae
Author: Riccardo Mancini <rickyman7@gmail.com>
Date:   Thu Jul 15 18:07:07 2021 +0200

    perf env: Fix sibling_dies memory leak
    
    [ Upstream commit 42db3d9ded555f7148b5695109a7dc8d66f0dde4 ]
    
    ASan reports a memory leak in perf_env while running:
    
      # perf test "41: Session topology"
    
    Caused by sibling_dies not being freed.
    
    This patch adds the required free.
    
    Fixes: acae8b36cded0ee6 ("perf header: Add die information in CPU topology")
    Signed-off-by: Riccardo Mancini <rickyman7@gmail.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lore.kernel.org/lkml/2140d0b57656e4eb9021ca9772250c24c032924b.1626343282.git.rickyman7@gmail.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1e338fb1f779dcec3eb508a99a580f0e6334ae07
Author: Riccardo Mancini <rickyman7@gmail.com>
Date:   Thu Jul 15 18:07:06 2021 +0200

    perf probe: Fix dso->nsinfo refcounting
    
    [ Upstream commit dedeb4be203b382ba7245d13079bc3b0f6d40c65 ]
    
    ASan reports a memory leak of nsinfo during the execution of:
    
     # perf test "31: Lookup mmap thread".
    
    The leak is caused by a refcounted variable being replaced without
    dropping the refcount.
    
    This patch makes sure that the refcnt of nsinfo is decreased whenever
    a refcounted variable is replaced with a new value.
    
    Signed-off-by: Riccardo Mancini <rickyman7@gmail.com>
    Fixes: 544abd44c7064c8a ("perf probe: Allow placing uprobes in alternate namespaces.")
    Cc: Ian Rogers <irogers@google.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Krister Johansen <kjlx@templeofstupid.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lore.kernel.org/lkml/55223bc8821b34ccb01f92ef1401c02b6a32e61f.1626343282.git.rickyman7@gmail.com
    [ Split from a larger patch ]
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7ec2746ef5c6dbb6f1df9d4c18e81e13b85ddcaa
Author: Riccardo Mancini <rickyman7@gmail.com>
Date:   Thu Jul 15 18:07:06 2021 +0200

    perf map: Fix dso->nsinfo refcounting
    
    [ Upstream commit 2d6b74baa7147251c30a46c4996e8cc224aa2dc5 ]
    
    ASan reports a memory leak of nsinfo during the execution of
    
      # perf test "31: Lookup mmap thread"
    
    The leak is caused by a refcounted variable being replaced without
    dropping the refcount.
    
    This patch makes sure that the refcnt of nsinfo is decreased whenever a
    refcounted variable is replaced with a new value.
    
    Signed-off-by: Riccardo Mancini <rickyman7@gmail.com>
    Fixes: bf2e710b3cb8445c ("perf maps: Lookup maps in both intitial mountns and inner mountns.")
    Cc: Ian Rogers <irogers@google.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Krister Johansen <kjlx@templeofstupid.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lore.kernel.org/lkml/55223bc8821b34ccb01f92ef1401c02b6a32e61f.1626343282.git.rickyman7@gmail.com
    [ Split from a larger patch ]
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 54dc8a81b785fee27cfc032f0683b2aba9d7479a
Author: Riccardo Mancini <rickyman7@gmail.com>
Date:   Thu Jul 15 18:07:06 2021 +0200

    perf inject: Fix dso->nsinfo refcounting
    
    [ Upstream commit 0967ebffe098157180a0bbd180ac90348c6e07d7 ]
    
    ASan reports a memory leak of nsinfo during the execution of:
    
      # perf test "31: Lookup mmap thread"
    
    The leak is caused by a refcounted variable being replaced without
    dropping the refcount.
    
    This patch makes sure that the refcnt of nsinfo is decreased when a
    refcounted variable is replaced with a new value.
    
    Signed-off-by: Riccardo Mancini <rickyman7@gmail.com>
    Fixes: 27c9c3424fc217da ("perf inject: Add --buildid-all option")
    Cc: Ian Rogers <irogers@google.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lore.kernel.org/lkml/55223bc8821b34ccb01f92ef1401c02b6a32e61f.1626343282.git.rickyman7@gmail.com
    [ Split from a larger patch ]
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ebeae33405576af47cfae09b2d5720cdc4fb06d0
Author: Sudeep Holla <sudeep.holla@arm.com>
Date:   Thu Jun 24 10:50:59 2021 +0100

    firmware: arm_scmi: Ensure drivers provide a probe function
    
    [ Upstream commit 5e469dac326555d2038d199a6329458cc82a34e5 ]
    
    The bus probe callback calls the driver callback without further
    checking. Better be safe than sorry and refuse registration of a driver
    without a probe function to prevent a NULL pointer exception.
    
    Link: https://lore.kernel.org/r/20210624095059.4010157-2-sudeep.holla@arm.com
    Fixes: 933c504424a2 ("firmware: arm_scmi: add scmi protocol bus to enumerate protocol devices")
    Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Tested-by: Cristian Marussi <cristian.marussi@arm.com>
    Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
    Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1824f2a7d4a7cf9bc7ab19172ccf8f33de21d37c
Author: Zev Weiss <zev@bewilderbeest.net>
Date:   Fri Apr 16 02:51:13 2021 -0500

    ARM: dts: aspeed: Update e3c246d4i vuart properties
    
    [ Upstream commit 812bae32e5d50914f75a6e036d3bde39ca86b0c3 ]
    
    This device-tree was merged with a provisional vuart IRQ-polarity
    property that was still under review and ended up taking a somewhat
    different form.  This patch updates it to match the final form of the
    new vuart properties, which additionally allow specifying the SIRQ
    number and LPC address.
    
    Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
    Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
    Fixes: ca03042f0f12 ("serial: 8250_aspeed_vuart: add aspeed, lpc-io-reg and aspeed, lpc-interrupts DT properties")
    Reviewed-by: Joel Stanley <joel@jms.id.au>
    Link: https://lore.kernel.org/r/20210416075113.18047-1-zev@bewilderbeest.net
    Signed-off-by: Joel Stanley <joel@jms.id.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9fe5024f5738fe1bcf5cf39a5654b4fdd07e7ff2
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Wed Jul 14 15:38:41 2021 +0100

    arm64: mte: fix restoration of GCR_EL1 from suspend
    
    [ Upstream commit 59f44069e0527523f27948da7b77599a73dab157 ]
    
    Since commit:
    
      bad1e1c663e0a72f ("arm64: mte: switch GCR_EL1 in kernel entry and exit")
    
    we saved/restored the user GCR_EL1 value at exception boundaries, and
    update_gcr_el1_excl() is no longer used for this. However it is used to
    restore the kernel's GCR_EL1 value when returning from a suspend state.
    Thus, the comment is misleading (and an ISB is necessary).
    
    When restoring the kernel's GCR value, we need an ISB to ensure this is
    used by subsequent instructions. We don't necessarily get an ISB by
    other means (e.g. if the kernel is built without support for pointer
    authentication). As __cpu_setup() initialised GCR_EL1.Exclude to 0xffff,
    until a context synchronization event, allocation tag 0 may be used
    rather than the desired set of tags.
    
    This patch drops the misleading comment, adds the missing ISB, and for
    clarity folds update_gcr_el1_excl() into its only user.
    
    Fixes: bad1e1c663e0 ("arm64: mte: switch GCR_EL1 in kernel entry and exit")
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Cc: Andrey Konovalov <andreyknvl@gmail.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
    Cc: Will Deacon <will@kernel.org>
    Link: https://lore.kernel.org/r/20210714143843.56537-2-mark.rutland@arm.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3a2c492e752814ad0567dd1a4ec37398ae003842
Author: Sean Christopherson <seanjc@google.com>
Date:   Thu May 6 10:58:26 2021 -0700

    KVM: SVM: Fix sev_pin_memory() error checks in SEV migration utilities
    
    [ Upstream commit c7a1b2b678c54ac19320daf525038d0e2e43ca7c ]
    
    Use IS_ERR() instead of checking for a NULL pointer when querying for
    sev_pin_memory() failures.  sev_pin_memory() always returns an error code
    cast to a pointer, or a valid pointer; it never returns NULL.
    
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Cc: Steve Rutherford <srutherford@google.com>
    Cc: Brijesh Singh <brijesh.singh@amd.com>
    Cc: Ashish Kalra <ashish.kalra@amd.com>
    Fixes: d3d1af85e2c7 ("KVM: SVM: Add KVM_SEND_UPDATE_DATA command")
    Fixes: 15fb7de1a7f5 ("KVM: SVM: Add KVM_SEV_RECEIVE_UPDATE_DATA command")
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20210506175826.2166383-3-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9d85689380b6a5ebf0c4fe2047d84043b3c70a46
Author: Sean Christopherson <seanjc@google.com>
Date:   Thu May 6 10:58:25 2021 -0700

    KVM: SVM: Return -EFAULT if copy_to_user() for SEV mig packet header fails
    
    [ Upstream commit b4a693924aab93f3747465b2261add46c82c3220 ]
    
    Return -EFAULT if copy_to_user() fails; if accessing user memory faults,
    copy_to_user() returns the number of bytes remaining, not an error code.
    
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Cc: Steve Rutherford <srutherford@google.com>
    Cc: Brijesh Singh <brijesh.singh@amd.com>
    Cc: Ashish Kalra <ashish.kalra@amd.com>
    Fixes: d3d1af85e2c7 ("KVM: SVM: Add KVM_SEND_UPDATE_DATA command")
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20210506175826.2166383-2-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 319b79706f63dcee469dc4cc01c52a533b62622d
Author: Like Xu <like.xu.linux@gmail.com>
Date:   Mon Jun 28 15:43:54 2021 +0800

    KVM: x86/pmu: Clear anythread deprecated bit when 0xa leaf is unsupported on the SVM
    
    [ Upstream commit 7234c362ccb3c2228f06f19f93b132de9cfa7ae4 ]
    
    The AMD platform does not support the functions Ah CPUID leaf. The returned
    results for this entry should all remain zero just like the native does:
    
    AMD host:
       0x0000000a 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000
    (uncanny) AMD guest:
       0x0000000a 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00008000
    
    Fixes: cadbaa039b99 ("perf/x86/intel: Make anythread filter support conditional")
    Signed-off-by: Like Xu <likexu@tencent.com>
    Message-Id: <20210628074354.33848-1-likexu@tencent.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 916450b2101ba9a1245efd8b1f9139d24dcb8ab1
Author: Íñigo Huguet <ihuguet@redhat.com>
Date:   Tue Jul 13 16:21:27 2021 +0200

    sfc: fix lack of XDP TX queues - error XDP TX failed (-22)
    
    [ Upstream commit f28100cb9c9645c07cbd22431278ac9492f6a01c ]
    
    Fixes: e26ca4b53582 sfc: reduce the number of requested xdp ev queues
    
    The buggy commit intended to allocate less channels for XDP in order to
    be more unlikely to reach the limit of 32 channels of the driver.
    
    The idea was to use each IRQ/eventqeue for more XDP TX queues than
    before, calculating which is the maximum number of TX queues that one
    event queue can handle. For example, in EF10 each event queue could
    handle up to 8 queues, better than the 4 they were handling before the
    change. This way, it would have to allocate half of channels than before
    for XDP TX.
    
    The problem is that the TX queues are also contained inside the channel
    structs, and there are only 4 queues per channel. Reducing the number of
    channels means also reducing the number of queues, resulting in not
    having the desired number of 1 queue per CPU.
    
    This leads to getting errors on XDP_TX and XDP_REDIRECT if they're
    executed from a high numbered CPU, because there only exist queues for
    the low half of CPUs, actually. If XDP_TX/REDIRECT is executed in a low
    numbered CPU, the error doesn't happen. This is the error in the logs
    (repeated many times, even rate limited):
    sfc 0000:5e:00.0 ens3f0np0: XDP TX failed (-22)
    
    This errors happens in function efx_xdp_tx_buffers, where it expects to
    have a dedicated XDP TX queue per CPU.
    
    Reverting the change makes again more likely to reach the limit of 32
    channels in machines with many CPUs. If this happen, no XDP_TX/REDIRECT
    will be possible at all, and we will have this log error messages:
    
    At interface probe:
    sfc 0000:5e:00.0: Insufficient resources for 12 XDP event queues (24 other channels, max 32)
    
    At every subsequent XDP_TX/REDIRECT failure, rate limited:
    sfc 0000:5e:00.0 ens3f0np0: XDP TX failed (-22)
    
    However, without reverting the change, it makes the user to think that
    everything is OK at probe time, but later it fails in an unpredictable
    way, depending on the CPU that handles the packet.
    
    It is better to restore the predictable behaviour. If the user sees the
    error message at probe time, he/she can try to configure the best way it
    fits his/her needs. At least, he/she will have 2 options:
    - Accept that XDP_TX/REDIRECT is not available (he/she may not need it)
    - Load sfc module with modparam 'rss_cpus' with a lower number, thus
      creating less normal RX queues/channels, letting more free resources
      for XDP, with some performance penalty.
    
    Anyway, let the calculation of maximum TX queues that can be handled by
    a single event queue, and use it only if it's less than the number of TX
    queues per channel. This doesn't happen in practice, but could happen if
    some constant values are tweaked in the future, such us
    EFX_MAX_TXQ_PER_CHANNEL, EFX_MAX_EVQ_SIZE or EFX_MAX_DMAQ_SIZE.
    
    Related mailing list thread:
    https://lore.kernel.org/bpf/20201215104327.2be76156@carbon/
    
    Signed-off-by: Íñigo Huguet <ihuguet@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 14a3ed8ef86850bbacaf316e962f4ae38b212cd7
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date:   Tue Jul 13 12:33:50 2021 +0300

    net: ocelot: fix switchdev objects synced for wrong netdev with LAG offload
    
    [ Upstream commit e56c6bbd98dc1cefb6f9c5d795fd29016e4f2fe7 ]
    
    The point with a *dev and a *brport_dev is that when we have a LAG net
    device that is a bridge port, *dev is an ocelot net device and
    *brport_dev is the bonding/team net device. The ocelot net device
    beneath the LAG does not exist from the bridge's perspective, so we need
    to sync the switchdev objects belonging to the brport_dev and not to the
    dev.
    
    Fixes: e4bd44e89dcf ("net: ocelot: replay switchdev events when joining bridge")
    Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d1f7e509dc3a6cc74beb72f2f4a46b41861a5a5e
Author: Casey Chen <cachen@purestorage.com>
Date:   Wed Jul 7 14:14:32 2021 -0700

    nvme-pci: do not call nvme_dev_remove_admin from nvme_remove
    
    [ Upstream commit 251ef6f71be2adfd09546a26643426fe62585173 ]
    
    nvme_dev_remove_admin could free dev->admin_q and the admin_tagset
    while they are being accessed by nvme_dev_disable(), which can be called
    by nvme_reset_work via nvme_remove_dead_ctrl.
    
    Commit cb4bfda62afa ("nvme-pci: fix hot removal during error handling")
    intended to avoid requests being stuck on a removed controller by killing
    the admin queue. But the later fix c8e9e9b7646e ("nvme-pci: unquiesce
    admin queue on shutdown"), together with nvme_dev_disable(dev, true)
    right before nvme_dev_remove_admin() could help dispatch requests and
    fail them early, so we don't need nvme_dev_remove_admin() any more.
    
    Fixes: cb4bfda62afa ("nvme-pci: fix hot removal during error handling")
    Signed-off-by: Casey Chen <cachen@purestorage.com>
    Reviewed-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b093e56f137c739b9e99ddf6c1e05fff70097800
Author: Marek Behún <kabel@kernel.org>
Date:   Sun Jul 11 18:38:15 2021 +0200

    net: phy: marvell10g: fix differentiation of 88X3310 from 88X3340
    
    [ Upstream commit a5de4be0aaaa66a2fa98e8a33bdbed3bd0682804 ]
    
    It seems that we cannot differentiate 88X3310 from 88X3340 by simply
    looking at bit 3 of revision ID. This only works on revisions A0 and A1.
    On revision B0, this bit is always 1.
    
    Instead use the 3.d00d register for differentiation, since this register
    contains information about number of ports on the device.
    
    Fixes: 9885d016ffa9 ("net: phy: marvell10g: add separate structure for 88X3340")
    Signed-off-by: Marek Behún <kabel@kernel.org>
    Reported-by: Matteo Croce <mcroce@linux.microsoft.com>
    Tested-by: Matteo Croce <mcroce@microsoft.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b2fe6fc671eaef878fbe00712d5ab32ac2dd9bec
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Fri Jul 9 17:20:51 2021 -0700

    mptcp: properly account bulk freed memory
    
    [ Upstream commit ce599c516386f09ca30848a1a4eb93d3fffbe187 ]
    
    After commit 879526030c8b ("mptcp: protect the rx path with
    the msk socket spinlock") the rmem currently used by a given
    msk is really sk_rmem_alloc - rmem_released.
    
    The safety check in mptcp_data_ready() does not take the above
    in due account, as a result legit incoming data is kept in
    subflow receive queue with no reason, delaying or blocking
    MPTCP-level ack generation.
    
    This change addresses the issue introducing a new helper to fetch
    the rmem memory and using it as needed. Additionally add a MIB
    counter for the exceptional event described above - the peer is
    misbehaving.
    
    Finally, introduce the required annotation when rmem_released is
    updated.
    
    Fixes: 879526030c8b ("mptcp: protect the rx path with the msk socket spinlock")
    Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/211
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cd7f1414f17072e9c267ee37013ba38446ee0ab7
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Tue Jun 22 12:25:23 2021 -0700

    mptcp: refine mptcp_cleanup_rbuf
    
    [ Upstream commit fde56eea01f96b664eb63033990be0fd2a945da5 ]
    
    The current cleanup rbuf tries a bit too hard to avoid acquiring
    the subflow socket lock. We may end-up delaying the needed ack,
    or skip acking a blocked subflow.
    
    Address the above extending the conditions used to trigger the cleanup
    to reflect more closely what TCP does and invoking tcp_cleanup_rbuf()
    on all the active subflows.
    
    Note that we can't replicate the exact tests implemented in
    tcp_cleanup_rbuf(), as MPTCP lacks some of the required info - e.g.
    ping-pong mode.
    
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b24550868ff63d859b47a04dc218a397b56cf9ea
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Mon Jun 21 15:54:34 2021 -0700

    mptcp: use fast lock for subflows when possible
    
    [ Upstream commit 75e908c33615999abe1f3a8429d25dea30d28e4e ]
    
    There are a bunch of callsite where the ssk socket
    lock is acquired using the full-blown version eligible for
    the fast variant. Let's move to the latter.
    
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c888aa8632185b5e03f09921c4c79ea0225d7cda
Author: Jianguo Wu <wujianguo@chinatelecom.cn>
Date:   Fri Jul 9 17:20:50 2021 -0700

    selftests: mptcp: fix case multiple subflows limited by server
    
    [ Upstream commit a7da441621c7945fbfd43ed239c93b8073cda502 ]
    
    After patch "mptcp: fix syncookie process if mptcp can not_accept new
    subflow", if subflow is limited, MP_JOIN SYN is dropped, and no SYN/ACK
    will be replied.
    
    So in case "multiple subflows limited by server", the expected SYN/ACK
    number should be 1.
    
    Fixes: 00587187ad30 ("selftests: mptcp: add test cases for mptcp join tests with syn cookies")
    Reported-by: kernel test robot <oliver.sang@intel.com>
    Signed-off-by: Jianguo Wu <wujianguo@chinatelecom.cn>
    Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fe2350115a5f406ec900ed6fbb07b9f27c4e8add
Author: Jianguo Wu <wujianguo@chinatelecom.cn>
Date:   Fri Jul 9 17:20:49 2021 -0700

    mptcp: avoid processing packet if a subflow reset
    
    [ Upstream commit 6787b7e350d3552651a3422d3d8980fbc8d65368 ]
    
    If check_fully_established() causes a subflow reset, it should not
    continue to process the packet in tcp_data_queue().
    Add a return value to mptcp_incoming_options(), and return false if a
    subflow has been reset, else return true. Then drop the packet in
    tcp_data_queue()/tcp_rcv_state_process() if mptcp_incoming_options()
    return false.
    
    Fixes: d582484726c4 ("mptcp: fix fallback for MP_JOIN subflows")
    Signed-off-by: Jianguo Wu <wujianguo@chinatelecom.cn>
    Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1dabd873933f4ae3c4d33dd9434450e2fa1d04dd
Author: Geliang Tang <geliangtang@gmail.com>
Date:   Thu Jun 17 16:46:12 2021 -0700

    mptcp: add sk parameter for mptcp_get_options
    
    [ Upstream commit c863225b79426459feca2ef5b0cc2f07e8e68771 ]
    
    This patch added a new parameter name sk in mptcp_get_options().
    
    Acked-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Geliang Tang <geliangtang@gmail.com>
    Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 89aa6912f2cfe50639420099874e60b325cc4f5f
Author: Jianguo Wu <wujianguo@chinatelecom.cn>
Date:   Fri Jul 9 17:20:48 2021 -0700

    mptcp: fix syncookie process if mptcp can not_accept new subflow
    
    [ Upstream commit 8547ea5f52dd8ef19b69c25c41b1415481b3503b ]
    
    Lots of "TCP: tcp_fin: Impossible, sk->sk_state=7" in client side
    when doing stress testing using wrk and webfsd.
    
    There are at least two cases may trigger this warning:
    1.mptcp is in syncookie, and server recv MP_JOIN SYN request,
      in subflow_check_req(), the mptcp_can_accept_new_subflow()
      return false, so subflow_init_req_cookie_join_save() isn't
      called, i.e. not store the data present in the MP_JOIN syn
      request and the random nonce in hash table - join_entries[],
      but still send synack. When recv 3rd-ack,
      mptcp_token_join_cookie_init_state() will return false, and
      3rd-ack is dropped, then if mptcp conn is closed by client,
      client will send a DATA_FIN and a MPTCP FIN, the DATA_FIN
      doesn't have MP_CAPABLE or MP_JOIN,
      so mptcp_subflow_init_cookie_req() will return 0, and pass
      the cookie check, MP_JOIN request is fallback to normal TCP.
      Server will send a TCP FIN if closed, in client side,
      when process TCP FIN, it will do reset, the code path is:
        tcp_data_queue()->mptcp_incoming_options()
          ->check_fully_established()->mptcp_subflow_reset().
      mptcp_subflow_reset() will set sock state to TCP_CLOSE,
      so tcp_fin will hit TCP_CLOSE, and print the warning.
    
    2.mptcp is in syncookie, and server recv 3rd-ack, in
      mptcp_subflow_init_cookie_req(), mptcp_can_accept_new_subflow()
      return false, and subflow_req->mp_join is not set to 1,
      so in subflow_syn_recv_sock() will not reset the MP_JOIN
      subflow, but fallback to normal TCP, and then the same thing
      happens when server will send a TCP FIN if closed.
    
    For case1, subflow_check_req() return -EPERM,
    then tcp_conn_request() will drop MP_JOIN SYN.
    
    For case2, let subflow_syn_recv_sock() call
    mptcp_can_accept_new_subflow(), and do fatal fallback, send reset.
    
    Fixes: 9466a1ccebbe ("mptcp: enable JOIN requests even if cookies are in use")
    Signed-off-by: Jianguo Wu <wujianguo@chinatelecom.cn>
    Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1aa3ffb95fdc2090395a5733fc950859777a037f
Author: Jianguo Wu <wujianguo@chinatelecom.cn>
Date:   Fri Jul 9 17:20:47 2021 -0700

    mptcp: remove redundant req destruct in subflow_check_req()
    
    [ Upstream commit 030d37bd1cd2443a1f21db47eb301899bfa45a2a ]
    
    In subflow_check_req(), if subflow sport is mismatch, will put msk,
    destroy token, and destruct req, then return -EPERM, which can be
    done by subflow_req_destructor() via:
    
      tcp_conn_request()
        |--__reqsk_free()
          |--subflow_req_destructor()
    
    So we should remove these redundant code, otherwise will call
    tcp_v4_reqsk_destructor() twice, and may double free
    inet_rsk(req)->ireq_opt.
    
    Fixes: 5bc56388c74f ("mptcp: add port number check for MP_JOIN")
    Signed-off-by: Jianguo Wu <wujianguo@chinatelecom.cn>
    Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 688984fc1af16c094f52516de0f0155d2043d5cc
Author: Jianguo Wu <wujianguo@chinatelecom.cn>
Date:   Fri Jul 9 17:20:46 2021 -0700

    mptcp: fix warning in __skb_flow_dissect() when do syn cookie for subflow join
    
    [ Upstream commit 0c71929b5893e410e0efbe1bbeca6f19a5f19956 ]
    
    I did stress test with wrk[1] and webfsd[2] with the assistance of
    mptcp-tools[3]:
    
      Server side:
          ./use_mptcp.sh webfsd -4 -R /tmp/ -p 8099
      Client side:
          ./use_mptcp.sh wrk -c 200 -d 30 -t 4 http://192.168.174.129:8099/
    
    and got the following warning message:
    
    [   55.552626] TCP: request_sock_subflow: Possible SYN flooding on port 8099. Sending cookies.  Check SNMP counters.
    [   55.553024] ------------[ cut here ]------------
    [   55.553027] WARNING: CPU: 0 PID: 10 at net/core/flow_dissector.c:984 __skb_flow_dissect+0x280/0x1650
    ...
    [   55.553117] CPU: 0 PID: 10 Comm: ksoftirqd/0 Not tainted 5.12.0+ #18
    [   55.553121] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 02/27/2020
    [   55.553124] RIP: 0010:__skb_flow_dissect+0x280/0x1650
    ...
    [   55.553133] RSP: 0018:ffffb79580087770 EFLAGS: 00010246
    [   55.553137] RAX: 0000000000000000 RBX: ffffffff8ddb58e0 RCX: ffffb79580087888
    [   55.553139] RDX: ffffffff8ddb58e0 RSI: ffff8f7e4652b600 RDI: 0000000000000000
    [   55.553141] RBP: ffffb79580087858 R08: 0000000000000000 R09: 0000000000000008
    [   55.553143] R10: 000000008c622965 R11: 00000000d3313a5b R12: ffff8f7e4652b600
    [   55.553146] R13: ffff8f7e465c9062 R14: 0000000000000000 R15: ffffb79580087888
    [   55.553149] FS:  0000000000000000(0000) GS:ffff8f7f75e00000(0000) knlGS:0000000000000000
    [   55.553152] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   55.553154] CR2: 00007f73d1d19000 CR3: 0000000135e10004 CR4: 00000000003706f0
    [   55.553160] Call Trace:
    [   55.553166]  ? __sha256_final+0x67/0xd0
    [   55.553173]  ? sha256+0x7e/0xa0
    [   55.553177]  __skb_get_hash+0x57/0x210
    [   55.553182]  subflow_init_req_cookie_join_save+0xac/0xc0
    [   55.553189]  subflow_check_req+0x474/0x550
    [   55.553195]  ? ip_route_output_key_hash+0x67/0x90
    [   55.553200]  ? xfrm_lookup_route+0x1d/0xa0
    [   55.553207]  subflow_v4_route_req+0x8e/0xd0
    [   55.553212]  tcp_conn_request+0x31e/0xab0
    [   55.553218]  ? selinux_socket_sock_rcv_skb+0x116/0x210
    [   55.553224]  ? tcp_rcv_state_process+0x179/0x6d0
    [   55.553229]  tcp_rcv_state_process+0x179/0x6d0
    [   55.553235]  tcp_v4_do_rcv+0xaf/0x220
    [   55.553239]  tcp_v4_rcv+0xce4/0xd80
    [   55.553243]  ? ip_route_input_rcu+0x246/0x260
    [   55.553248]  ip_protocol_deliver_rcu+0x35/0x1b0
    [   55.553253]  ip_local_deliver_finish+0x44/0x50
    [   55.553258]  ip_local_deliver+0x6c/0x110
    [   55.553262]  ? ip_rcv_finish_core.isra.19+0x5a/0x400
    [   55.553267]  ip_rcv+0xd1/0xe0
    ...
    
    After debugging, I found in __skb_flow_dissect(), skb->dev and skb->sk
    are both NULL, then net is NULL, and trigger WARN_ON_ONCE(!net),
    actually net is always NULL in this code path, as skb->dev is set to
    NULL in tcp_v4_rcv(), and skb->sk is never set.
    
    Code snippet in __skb_flow_dissect() that trigger warning:
      975         if (skb) {
      976                 if (!net) {
      977                         if (skb->dev)
      978                                 net = dev_net(skb->dev);
      979                         else if (skb->sk)
      980                                 net = sock_net(skb->sk);
      981                 }
      982         }
      983
      984         WARN_ON_ONCE(!net);
    
    So, using seq and transport header derived hash.
    
    [1] https://github.com/wg/wrk
    [2] https://github.com/ourway/webfsd
    [3] https://github.com/pabeni/mptcp-tools
    
    Fixes: 9466a1ccebbe ("mptcp: enable JOIN requests even if cookies are in use")
    Suggested-by: Paolo Abeni <pabeni@redhat.com>
    Suggested-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Jianguo Wu <wujianguo@chinatelecom.cn>
    Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5a870ea6e8b7beb767f2158aea59736e9326e073
Author: Zack Rusin <zackr@vmware.com>
Date:   Tue Jun 15 14:23:35 2021 -0400

    drm/vmwgfx: Fix a bad merge in otable batch takedown
    
    [ Upstream commit 34bd46bcf3de72cbffcdc42d3fa67e543d1c869b ]
    
    Change
    2ef4fb92363c ("drm/vmwgfx: Make sure bo's are unpinned before putting them back")
    caused a conflict in one of the drm trees and the merge commit
    68a32ba14177 ("Merge tag 'drm-next-2021-04-28' of git://anongit.freedesktop.org/drm/drm")
    accidently re-added code that the original change was removing.
    Fixed by removing the incorrect buffer unpin - it has already been unpinned
    two lines above.
    
    Fixes: 68a32ba14177 ("Merge tag 'drm-next-2021-04-28' of git://anongit.freedesktop.org/drm/drm")
    Signed-off-by: Zack Rusin <zackr@vmware.com>
    Reviewed-by: Martin Krastev <krastevm@vmware.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210615182336.995192-4-zackr@vmware.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 441b2f191e9f3a28baf5f5142838dd844cbfa11d
Author: Shahjada Abul Husain <shahjada@chelsio.com>
Date:   Thu Jul 8 21:51:56 2021 +0530

    cxgb4: fix IRQ free race during driver unload
    
    [ Upstream commit 015fe6fd29c4b9ac0f61b8c4455ef88e6018b9cc ]
    
    IRQs are requested during driver's ndo_open() and then later
    freed up in disable_interrupts() during driver unload.
    A race exists where driver can set the CXGB4_FULL_INIT_DONE
    flag in ndo_open() after the disable_interrupts() in driver
    unload path checks it, and hence misses calling free_irq().
    
    Fix by unregistering netdevice first and sync with driver's
    ndo_open(). This ensures disable_interrupts() checks the flag
    correctly and frees up the IRQs properly.
    
    Fixes: b37987e8db5f ("cxgb4: Disable interrupts and napi before unregistering netdev")
    Signed-off-by: Shahjada Abul Husain <shahjada@chelsio.com>
    Signed-off-by: Raju Rangoju <rajur@chelsio.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit efdf9d46bc15786b35a07284dbfb8573cb1addd4
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Thu Jul 1 10:27:51 2021 +0200

    pwm: sprd: Ensure configuring period and duty_cycle isn't wrongly skipped
    
    [ Upstream commit 65e2e6c1c20104ed19060a38f4edbf14e9f9a9a5 ]
    
    As the last call to sprd_pwm_apply() might have exited early if
    state->enabled was false, the values for period and duty_cycle stored in
    pwm->state might not have been written to hardware and it must be
    ensured that they are configured before enabling the PWM.
    
    Fixes: 8aae4b02e8a6 ("pwm: sprd: Add Spreadtrum PWM support")
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6c75b21b2aab0eb604c827d3fc846f2ddb3890fb
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Wed Jul 7 16:15:30 2021 +0800

    selftests: icmp_redirect: IPv6 PMTU info should be cleared after redirect
    
    [ Upstream commit 0e02bf5de46ae30074a2e1a8194a422a84482a1a ]
    
    After redirecting, it's already a new path. So the old PMTU info should
    be cleared. The IPv6 test "mtu exception plus redirect" should only
    has redirect info without old PMTU.
    
    The IPv4 test can not be changed because of legacy.
    
    Fixes: ec8105352869 ("selftests: Add redirect tests")
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 84d37878814b0a4ab4faf7fc1f3394cf37e2a5ba
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Wed Jul 7 16:15:29 2021 +0800

    selftests: icmp_redirect: remove from checking for IPv6 route get
    
    [ Upstream commit 24b671aad4eae423e1abf5b7f08d9a5235458b8d ]
    
    If the kernel doesn't enable option CONFIG_IPV6_SUBTREES, the RTA_SRC
    info will not be exported to userspace in rt6_fill_node(). And ip cmd will
    not print "from ::" to the route output. So remove this check.
    
    Fixes: ec8105352869 ("selftests: Add redirect tests")
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b11b6ecda552cc0bf59fd7cdd0d59b0c2a1491ee
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Wed Jul 7 15:53:35 2021 +0800

    stmmac: platform: Fix signedness bug in stmmac_probe_config_dt()
    
    [ Upstream commit eca81f09145d765c21dd8fb1ba5d874ca255c32c ]
    
    The "plat->phy_interface" variable is an enum and in this context GCC
    will treat it as an unsigned int so the error handling is never
    triggered.
    
    Fixes: b9f0b2f634c0 ("net: stmmac: platform: fix probe for ACPI devices")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 350e10d217337480158b604bbf6601c50ed161c6
Author: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date:   Tue Jul 6 11:13:35 2021 +0200

    ipv6: fix 'disable_policy' for fwd packets
    
    [ Upstream commit ccd27f05ae7b8ebc40af5b004e94517a919aa862 ]
    
    The goal of commit df789fe75206 ("ipv6: Provide ipv6 version of
    "disable_policy" sysctl") was to have the disable_policy from ipv4
    available on ipv6.
    However, it's not exactly the same mechanism. On IPv4, all packets coming
    from an interface, which has disable_policy set, bypass the policy check.
    For ipv6, this is done only for local packets, ie for packets destinated to
    an address configured on the incoming interface.
    
    Let's align ipv6 with ipv4 so that the 'disable_policy' sysctl has the same
    effect for both protocols.
    
    My first approach was to create a new kind of route cache entries, to be
    able to set DST_NOPOLICY without modifying routes. This would have added a
    lot of code. Because the local delivery path is already handled, I choose
    to focus on the forwarding path to minimize code churn.
    
    Fixes: df789fe75206 ("ipv6: Provide ipv6 version of "disable_policy" sysctl")
    Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8994e395fc39a15351ea39ca89d746abd55da017
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Mon Jul 5 15:38:14 2021 +0000

    bonding: fix incorrect return value of bond_ipsec_offload_ok()
    
    [ Upstream commit 168e696a36792a4a3b2525a06249e7472ef90186 ]
    
    bond_ipsec_offload_ok() is called to check whether the interface supports
    ipsec offload or not.
    bonding interface support ipsec offload only in active-backup mode.
    So, if a bond interface is not in active-backup mode, it should return
    false but it returns true.
    
    Fixes: a3b658cfb664 ("bonding: allow xfrm offload setup post-module-load")
    Signed-off-by: Taehee Yoo <ap420073@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4ac748c4b2240cd3b4086166c3fdd8e01621728e
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Mon Jul 5 15:38:13 2021 +0000

    bonding: fix suspicious RCU usage in bond_ipsec_offload_ok()
    
    [ Upstream commit 955b785ec6b3b2f9b91914d6eeac8ee66ee29239 ]
    
    To dereference bond->curr_active_slave, it uses rcu_dereference().
    But it and the caller doesn't acquire RCU so a warning occurs.
    So add rcu_read_lock().
    
    Splat looks like:
    WARNING: suspicious RCU usage
    5.13.0-rc6+ #1179 Not tainted
    drivers/net/bonding/bond_main.c:571 suspicious
    rcu_dereference_check() usage!
    
    other info that might help us debug this:
    
    rcu_scheduler_active = 2, debug_locks = 1
    1 lock held by ping/974:
     #0: ffff888109e7db70 (sk_lock-AF_INET){+.+.}-{0:0},
    at: raw_sendmsg+0x1303/0x2cb0
    
    stack backtrace:
    CPU: 2 PID: 974 Comm: ping Not tainted 5.13.0-rc6+ #1179
    Call Trace:
     dump_stack+0xa4/0xe5
     bond_ipsec_offload_ok+0x1f4/0x260 [bonding]
     xfrm_output+0x179/0x890
     xfrm4_output+0xfa/0x410
     ? __xfrm4_output+0x4b0/0x4b0
     ? __ip_make_skb+0xecc/0x2030
     ? xfrm4_udp_encap_rcv+0x800/0x800
     ? ip_local_out+0x21/0x3a0
     ip_send_skb+0x37/0xa0
     raw_sendmsg+0x1bfd/0x2cb0
    
    Fixes: 18cb261afd7b ("bonding: support hardware encryption offload to slaves")
    Signed-off-by: Taehee Yoo <ap420073@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 42ec69b9cd7d1f9a8b7420807f3a5d899ca99d28
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Mon Jul 5 15:38:12 2021 +0000

    bonding: Add struct bond_ipesc to manage SA
    
    [ Upstream commit 9a5605505d9c7dbfdb89cc29a8f5fc5cf9fd2334 ]
    
    bonding has been supporting ipsec offload.
    When SA is added, bonding just passes SA to its own active real interface.
    But it doesn't manage SA.
    So, when events(add/del real interface, active real interface change, etc)
    occur, bonding can't handle that well because It doesn't manage SA.
    So some problems(panic, UAF, refcnt leak)occur.
    
    In order to make it stable, it should manage SA.
    That's the reason why struct bond_ipsec is added.
    When a new SA is added to bonding interface, it is stored in the
    bond_ipsec list. And the SA is passed to a current active real interface.
    If events occur, it uses bond_ipsec data to handle these events.
    bond->ipsec_list is protected by bond->ipsec_lock.
    
    If a current active real interface is changed, the following logic works.
    1. delete all SAs from old active real interface
    2. Add all SAs to the new active real interface.
    3. If a new active real interface doesn't support ipsec offload or SA's
    option, it sets real_dev to NULL.
    
    Fixes: 18cb261afd7b ("bonding: support hardware encryption offload to slaves")
    Signed-off-by: Taehee Yoo <ap420073@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d5e9ed0855a4aef14a4506a0caee9464308c4069
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Mon Jul 5 15:38:11 2021 +0000

    bonding: disallow setting nested bonding + ipsec offload
    
    [ Upstream commit b121693381b112b78c076dea171ee113e237c0e4 ]
    
    bonding interface can be nested and it supports ipsec offload.
    So, it allows setting the nested bonding + ipsec scenario.
    But code does not support this scenario.
    So, it should be disallowed.
    
    interface graph:
    bond2
       |
    bond1
       |
    eth0
    
    The nested bonding + ipsec offload may not a real usecase.
    So, disallowing this scenario is fine.
    
    Fixes: 18cb261afd7b ("bonding: support hardware encryption offload to slaves")
    Signed-off-by: Taehee Yoo <ap420073@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c24d04866549619d6d6fdee6fe9d3eadd6c7f578
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Mon Jul 5 15:38:10 2021 +0000

    bonding: fix suspicious RCU usage in bond_ipsec_del_sa()
    
    [ Upstream commit a22c39b831a081da9b2c488bd970a4412d926f30 ]
    
    To dereference bond->curr_active_slave, it uses rcu_dereference().
    But it and the caller doesn't acquire RCU so a warning occurs.
    So add rcu_read_lock().
    
    Test commands:
        ip netns add A
        ip netns exec A bash
        modprobe netdevsim
        echo "1 1" > /sys/bus/netdevsim/new_device
        ip link add bond0 type bond
        ip link set eth0 master bond0
        ip link set eth0 up
        ip link set bond0 up
        ip x s add proto esp dst 14.1.1.1 src 15.1.1.1 spi 0x07 mode \
    transport reqid 0x07 replay-window 32 aead 'rfc4106(gcm(aes))' \
    0x44434241343332312423222114131211f4f3f2f1 128 sel src 14.0.0.52/24 \
    dst 14.0.0.70/24 proto tcp offload dev bond0 dir in
        ip x s f
    
    Splat looks like:
    =============================
    WARNING: suspicious RCU usage
    5.13.0-rc3+ #1168 Not tainted
    -----------------------------
    drivers/net/bonding/bond_main.c:448 suspicious rcu_dereference_check()
    usage!
    
    other info that might help us debug this:
    
    rcu_scheduler_active = 2, debug_locks = 1
    2 locks held by ip/705:
     #0: ffff888106701780 (&net->xfrm.xfrm_cfg_mutex){+.+.}-{3:3},
    at: xfrm_netlink_rcv+0x59/0x80 [xfrm_user]
     #1: ffff8880075b0098 (&x->lock){+.-.}-{2:2},
    at: xfrm_state_delete+0x16/0x30
    
    stack backtrace:
    CPU: 6 PID: 705 Comm: ip Not tainted 5.13.0-rc3+ #1168
    Call Trace:
     dump_stack+0xa4/0xe5
     bond_ipsec_del_sa+0x16a/0x1c0 [bonding]
     __xfrm_state_delete+0x51f/0x730
     xfrm_state_delete+0x1e/0x30
     xfrm_state_flush+0x22f/0x390
     xfrm_flush_sa+0xd8/0x260 [xfrm_user]
     ? xfrm_flush_policy+0x290/0x290 [xfrm_user]
     xfrm_user_rcv_msg+0x331/0x660 [xfrm_user]
     ? rcu_read_lock_sched_held+0x91/0xc0
     ? xfrm_user_state_lookup.constprop.39+0x320/0x320 [xfrm_user]
     ? find_held_lock+0x3a/0x1c0
     ? mutex_lock_io_nested+0x1210/0x1210
     ? sched_clock_cpu+0x18/0x170
     netlink_rcv_skb+0x121/0x350
    [ ... ]
    
    Fixes: 18cb261afd7b ("bonding: support hardware encryption offload to slaves")
    Signed-off-by: Taehee Yoo <ap420073@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a1f01d2ddb55f62bd70d3c1391f5c652d5dbc139
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Mon Jul 5 15:38:09 2021 +0000

    ixgbevf: use xso.real_dev instead of xso.dev in callback functions of struct xfrmdev_ops
    
    [ Upstream commit 2de7e4f67599affc97132bd07e30e3bd59d0b777 ]
    
    There are two pointers in struct xfrm_state_offload, *dev, *real_dev.
    These are used in callback functions of struct xfrmdev_ops.
    The *dev points whether bonding interface or real interface.
    If bonding ipsec offload is used, it points bonding interface If not,
    it points real interface.
    And real_dev always points real interface.
    So, ixgbevf should always use real_dev instead of dev.
    Of course, real_dev always not be null.
    
    Test commands:
        ip link add bond0 type bond
        #eth0 is ixgbevf interface
        ip link set eth0 master bond0
        ip link set bond0 up
        ip x s add proto esp dst 14.1.1.1 src 15.1.1.1 spi 0x07 mode \
    transport reqid 0x07 replay-window 32 aead 'rfc4106(gcm(aes))' \
    0x44434241343332312423222114131211f4f3f2f1 128 sel src 14.0.0.52/24 \
    dst 14.0.0.70/24 proto tcp offload dev bond0 dir in
    
    Splat looks like:
    KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
    CPU: 6 PID: 688 Comm: ip Not tainted 5.13.0-rc3+ #1168
    RIP: 0010:ixgbevf_ipsec_find_empty_idx+0x28/0x1b0 [ixgbevf]
    Code: 00 00 0f 1f 44 00 00 55 53 48 89 fb 48 83 ec 08 40 84 f6 0f 84 9c
    00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02
    84 c0 74 08 3c 01 0f 8e 4c 01 00 00 66 81 3b 00 04 0f
    RSP: 0018:ffff8880089af390 EFLAGS: 00010246
    RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000001
    RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
    RBP: ffff8880089af4f8 R08: 0000000000000003 R09: fffffbfff4287e11
    R10: 0000000000000001 R11: ffff888005de8908 R12: 0000000000000000
    R13: ffff88810936a000 R14: ffff88810936a000 R15: ffff888004d78040
    FS:  00007fdf9883a680(0000) GS:ffff88811a400000(0000)
    knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 000055bc14adbf40 CR3: 000000000b87c005 CR4: 00000000003706e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     ixgbevf_ipsec_add_sa+0x1bf/0x9c0 [ixgbevf]
     ? rcu_read_lock_sched_held+0x91/0xc0
     ? ixgbevf_ipsec_parse_proto_keys.isra.9+0x280/0x280 [ixgbevf]
     ? lock_acquire+0x191/0x720
     ? bond_ipsec_add_sa+0x48/0x350 [bonding]
     ? lockdep_hardirqs_on_prepare+0x3e0/0x3e0
     ? rcu_read_lock_held+0x91/0xa0
     ? rcu_read_lock_sched_held+0xc0/0xc0
     bond_ipsec_add_sa+0x193/0x350 [bonding]
     xfrm_dev_state_add+0x2a9/0x770
     ? memcpy+0x38/0x60
     xfrm_add_sa+0x2278/0x3b10 [xfrm_user]
     ? xfrm_get_policy+0xaa0/0xaa0 [xfrm_user]
     ? register_lock_class+0x1750/0x1750
     xfrm_user_rcv_msg+0x331/0x660 [xfrm_user]
     ? rcu_read_lock_sched_held+0x91/0xc0
     ? xfrm_user_state_lookup.constprop.39+0x320/0x320 [xfrm_user]
     ? find_held_lock+0x3a/0x1c0
     ? mutex_lock_io_nested+0x1210/0x1210
     ? sched_clock_cpu+0x18/0x170
     netlink_rcv_skb+0x121/0x350
    [ ... ]
    
    Fixes: 272c2330adc9 ("xfrm: bail early on slave pass over skb")
    Signed-off-by: Taehee Yoo <ap420073@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9863701fa0ecd2abfadb27b0e7a9b0fe1c9d02b6
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Mon Jul 5 15:38:07 2021 +0000

    bonding: fix null dereference in bond_ipsec_add_sa()
    
    [ Upstream commit 105cd17a866017b45f3c45901b394c711c97bf40 ]
    
    If bond doesn't have real device, bond->curr_active_slave is null.
    But bond_ipsec_add_sa() dereferences bond->curr_active_slave without
    null checking.
    So, null-ptr-deref would occur.
    
    Test commands:
        ip link add bond0 type bond
        ip link set bond0 up
        ip x s add proto esp dst 14.1.1.1 src 15.1.1.1 spi \
    0x07 mode transport reqid 0x07 replay-window 32 aead 'rfc4106(gcm(aes))' \
    0x44434241343332312423222114131211f4f3f2f1 128 sel src 14.0.0.52/24 \
    dst 14.0.0.70/24 proto tcp offload dev bond0 dir in
    
    Splat looks like:
    KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
    CPU: 4 PID: 680 Comm: ip Not tainted 5.13.0-rc3+ #1168
    RIP: 0010:bond_ipsec_add_sa+0xc4/0x2e0 [bonding]
    Code: 85 21 02 00 00 4d 8b a6 48 0c 00 00 e8 75 58 44 ce 85 c0 0f 85 14
    01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 e2 48 c1 ea 03 <80> 3c 02
    00 0f 85 fc 01 00 00 48 8d bb e0 02 00 00 4d 8b 2c 24 48
    RSP: 0018:ffff88810946f508 EFLAGS: 00010246
    RAX: dffffc0000000000 RBX: ffff88810b4e8040 RCX: 0000000000000001
    RDX: 0000000000000000 RSI: ffffffff8fe34280 RDI: ffff888115abe100
    RBP: ffff88810946f528 R08: 0000000000000003 R09: fffffbfff2287e11
    R10: 0000000000000001 R11: ffff888115abe0c8 R12: 0000000000000000
    R13: ffffffffc0aea9a0 R14: ffff88800d7d2000 R15: ffff88810b4e8330
    FS:  00007efc5552e680(0000) GS:ffff888119c00000(0000)
    knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 000055c2530dbf40 CR3: 0000000103056004 CR4: 00000000003706e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     xfrm_dev_state_add+0x2a9/0x770
     ? memcpy+0x38/0x60
     xfrm_add_sa+0x2278/0x3b10 [xfrm_user]
     ? xfrm_get_policy+0xaa0/0xaa0 [xfrm_user]
     ? register_lock_class+0x1750/0x1750
     xfrm_user_rcv_msg+0x331/0x660 [xfrm_user]
     ? rcu_read_lock_sched_held+0x91/0xc0
     ? xfrm_user_state_lookup.constprop.39+0x320/0x320 [xfrm_user]
     ? find_held_lock+0x3a/0x1c0
     ? mutex_lock_io_nested+0x1210/0x1210
     ? sched_clock_cpu+0x18/0x170
     netlink_rcv_skb+0x121/0x350
     ? xfrm_user_state_lookup.constprop.39+0x320/0x320 [xfrm_user]
     ? netlink_ack+0x9d0/0x9d0
     ? netlink_deliver_tap+0x17c/0xa50
     xfrm_netlink_rcv+0x68/0x80 [xfrm_user]
     netlink_unicast+0x41c/0x610
     ? netlink_attachskb+0x710/0x710
     netlink_sendmsg+0x6b9/0xb70
    [ ...]
    
    Fixes: 18cb261afd7b ("bonding: support hardware encryption offload to slaves")
    Signed-off-by: Taehee Yoo <ap420073@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9ae2584fdd67b0c793935fa0d2fcedeb3d9a438b
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Mon Jul 5 15:38:06 2021 +0000

    bonding: fix suspicious RCU usage in bond_ipsec_add_sa()
    
    [ Upstream commit b648eba4c69e5819880b4907e7fcb2bb576069ab ]
    
    To dereference bond->curr_active_slave, it uses rcu_dereference().
    But it and the caller doesn't acquire RCU so a warning occurs.
    So add rcu_read_lock().
    
    Test commands:
        ip link add dummy0 type dummy
        ip link add bond0 type bond
        ip link set dummy0 master bond0
        ip link set dummy0 up
        ip link set bond0 up
        ip x s add proto esp dst 14.1.1.1 src 15.1.1.1 spi 0x07 \
                mode transport \
                reqid 0x07 replay-window 32 aead 'rfc4106(gcm(aes))' \
                0x44434241343332312423222114131211f4f3f2f1 128 sel \
                src 14.0.0.52/24 dst 14.0.0.70/24 proto tcp offload \
                dev bond0 dir in
    
    Splat looks like:
    =============================
    WARNING: suspicious RCU usage
    5.13.0-rc3+ #1168 Not tainted
    -----------------------------
    drivers/net/bonding/bond_main.c:411 suspicious rcu_dereference_check() usage!
    
    other info that might help us debug this:
    
    rcu_scheduler_active = 2, debug_locks = 1
    1 lock held by ip/684:
     #0: ffffffff9a2757c0 (&net->xfrm.xfrm_cfg_mutex){+.+.}-{3:3},
    at: xfrm_netlink_rcv+0x59/0x80 [xfrm_user]
       55.191733][  T684] stack backtrace:
    CPU: 0 PID: 684 Comm: ip Not tainted 5.13.0-rc3+ #1168
    Call Trace:
     dump_stack+0xa4/0xe5
     bond_ipsec_add_sa+0x18c/0x1f0 [bonding]
     xfrm_dev_state_add+0x2a9/0x770
     ? memcpy+0x38/0x60
     xfrm_add_sa+0x2278/0x3b10 [xfrm_user]
     ? xfrm_get_policy+0xaa0/0xaa0 [xfrm_user]
     ? register_lock_class+0x1750/0x1750
     xfrm_user_rcv_msg+0x331/0x660 [xfrm_user]
     ? rcu_read_lock_sched_held+0x91/0xc0
     ? xfrm_user_state_lookup.constprop.39+0x320/0x320 [xfrm_user]
     ? find_held_lock+0x3a/0x1c0
     ? mutex_lock_io_nested+0x1210/0x1210
     ? sched_clock_cpu+0x18/0x170
     netlink_rcv_skb+0x121/0x350
     ? xfrm_user_state_lookup.constprop.39+0x320/0x320 [xfrm_user]
     ? netlink_ack+0x9d0/0x9d0
     ? netlink_deliver_tap+0x17c/0xa50
     xfrm_netlink_rcv+0x68/0x80 [xfrm_user]
     netlink_unicast+0x41c/0x610
     ? netlink_attachskb+0x710/0x710
     netlink_sendmsg+0x6b9/0xb70
    [ ... ]
    
    Fixes: 18cb261afd7b ("bonding: support hardware encryption offload to slaves")
    Signed-off-by: Taehee Yoo <ap420073@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 08d21fa872ec8ceb0054f224e1bf8cd764622928
Author: Wang Hai <wanghai38@huawei.com>
Date:   Mon Jun 28 17:18:15 2021 +0800

    bpf, samples: Fix xdpsock with '-M' parameter missing unload process
    
    [ Upstream commit 2620e92ae6ed83260eb46d214554cd308ee35d92 ]
    
    Execute the following command and exit, then execute it again, the following
    error will be reported:
    
      $ sudo ./samples/bpf/xdpsock -i ens4f2 -M
      ^C
      $ sudo ./samples/bpf/xdpsock -i ens4f2 -M
      libbpf: elf: skipping unrecognized data section(16) .eh_frame
      libbpf: elf: skipping relo section(17) .rel.eh_frame for section(16) .eh_frame
      libbpf: Kernel error message: XDP program already attached
      ERROR: link set xdp fd failed
    
    Commit c9d27c9e8dc7 ("samples: bpf: Do not unload prog within xdpsock") removed
    the unloading prog code because of the presence of bpf_link. This is fine if
    XDP_SHARED_UMEM is disabled, but if it is enabled, unloading the prog is still
    needed.
    
    Fixes: c9d27c9e8dc7 ("samples: bpf: Do not unload prog within xdpsock")
    Signed-off-by: Wang Hai <wanghai38@huawei.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Magnus Karlsson <magnus.karlsson@intel.com>
    Cc: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
    Link: https://lore.kernel.org/bpf/20210628091815.2373487-1-wanghai38@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b2a6c45d44e9e72259f52d9db92e060e655158df
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Thu Jul 1 22:18:24 2021 +0200

    gve: Fix an error handling path in 'gve_probe()'
    
    [ Upstream commit 2342ae10d1272d411a468a85a67647dd115b344f ]
    
    If the 'register_netdev() call fails, we must release the resources
    allocated by the previous 'gve_init_priv()' call, as already done in the
    remove function.
    
    Add a new label and the missing 'gve_teardown_priv_resources()' in the
    error handling path.
    
    Fixes: 893ce44df565 ("gve: Add basic driver framework for Compute Engine Virtual NIC")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Reviewed-by: Catherine Sullivan <csully@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2f2b3b953b43d7653310fd0d4e51607d920ef9f3
Author: Mohammad Athari Bin Ismail <mohammad.athari.ismail@intel.com>
Date:   Wed Jun 30 17:59:35 2021 +0800

    net: stmmac: Terminate FPE workqueue in suspend
    
    [ Upstream commit 6b28a86d6c0bb02119f386ec2f56efde909e9bcb ]
    
    Add stmmac_fpe_stop_wq() in stmmac_suspend() to terminate FPE workqueue
    during suspend. So, in suspend mode, there will be no FPE workqueue
    available. Without this fix, new additional FPE workqueue will be created
    in every suspend->resume cycle.
    
    Fixes: 5a5586112b92 ("net: stmmac: support FPE link partner hand-shaking procedure")
    Signed-off-by: Mohammad Athari Bin Ismail <mohammad.athari.ismail@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 317de567c11203b18cc28c0fb75c3ad2d6d1ff8c
Author: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
Date:   Fri Jun 11 22:42:17 2021 +0000

    igb: Fix position of assignment to *ring
    
    [ Upstream commit 382a7c20d9253bcd5715789b8179528d0f3de72c ]
    
    Assignment to *ring should be done after correctness check of the
    argument queue.
    
    Fixes: 91db364236c8 ("igb: Refactor igb_configure_cbs()")
    Signed-off-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
    Acked-by: Vinicius Costa Gomes <vinicius.gomes@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 6c82171aa35b3a3ccc2f46aa41a946b63e6b9169
Author: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Date:   Thu Apr 22 10:19:23 2021 +0000

    igb: Check if num of q_vectors is smaller than max before array access
    
    [ Upstream commit 6c19d772618fea40d9681f259368f284a330fd90 ]
    
    Ensure that the adapter->q_vector[MAX_Q_VECTORS] array isn't accessed
    beyond its size. It was fixed by using a local variable num_q_vectors
    as a limit for loop index, and ensure that num_q_vectors is not bigger
    than MAX_Q_VECTORS.
    
    Fixes: 047e0030f1e6 ("igb: add new data structure for handling interrupts and NAPI")
    Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
    Reviewed-by: Grzegorz Siwik <grzegorz.siwik@intel.com>
    Reviewed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
    Reviewed-by: Slawomir Laba <slawomirx.laba@intel.com>
    Reviewed-by: Sylwester Dziedziuch <sylwesterx.dziedziuch@intel.com>
    Reviewed-by: Mateusz Palczewski <mateusz.placzewski@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 e2b71652a5e396486445c6bc2149af2d03a5eeaa
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Wed Jun 16 07:53:02 2021 +0200

    iavf: Fix an error handling path in 'iavf_probe()'
    
    [ Upstream commit af30cbd2f4d6d66a9b6094e0aa32420bc8b20e08 ]
    
    If an error occurs after a 'pci_enable_pcie_error_reporting()' call, it
    must be undone by a corresponding 'pci_disable_pcie_error_reporting()'
    call, as already done in the remove function.
    
    Fixes: 5eae00c57f5e ("i40evf: main driver core")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2f5343365d179e9d8d872f1006697d206d63a72e
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Wed Jun 16 07:05:53 2021 +0200

    e1000e: Fix an error handling path in 'e1000_probe()'
    
    [ Upstream commit 4589075608420bc49fcef6e98279324bf2bb91ae ]
    
    If an error occurs after a 'pci_enable_pcie_error_reporting()' call, it
    must be undone by a corresponding 'pci_disable_pcie_error_reporting()'
    call, as already done in the remove function.
    
    Fixes: 111b9dc5c981 ("e1000e: add aer support")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Acked-by: Sasha Neftin <sasha.neftin@intel.com>
    Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b928fdcafad9927db7a994f2f299eb9150c3ebbf
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Wed Jun 16 07:00:36 2021 +0200

    fm10k: Fix an error handling path in 'fm10k_probe()'
    
    [ Upstream commit e85e14d68f517ef12a5fb8123fff65526b35b6cd ]
    
    If an error occurs after a 'pci_enable_pcie_error_reporting()' call, it
    must be undone by a corresponding 'pci_disable_pcie_error_reporting()'
    call, as already done in the remove function.
    
    Fixes: 19ae1b3fb99c ("fm10k: Add support for PCI power management and error handling")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a0169ebdb140bff6c43a7389adf2e4ea3da675fa
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Jun 12 22:08:33 2021 +0200

    igb: Fix an error handling path in 'igb_probe()'
    
    [ Upstream commit fea03b1cebd653cd095f2e9a58cfe1c85661c363 ]
    
    If an error occurs after a 'pci_enable_pcie_error_reporting()' call, it
    must be undone by a corresponding 'pci_disable_pcie_error_reporting()'
    call, as already done in the remove function.
    
    Fixes: 40a914fa72ab ("igb: Add support for pci-e Advanced Error Reporting")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    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 67ad974445802c2f4d083c60902296d35070f9c2
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Jun 12 22:00:05 2021 +0200

    igc: Fix an error handling path in 'igc_probe()'
    
    [ Upstream commit c6bc9e5ce5d37cb3e6b552f41b92a193db1806ab ]
    
    If an error occurs after a 'pci_enable_pcie_error_reporting()' call, it
    must be undone by a corresponding 'pci_disable_pcie_error_reporting()'
    call, as already done in the remove function.
    
    Fixes: c9a11c23ceb6 ("igc: Add netdev")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
    Acked-by: Sasha Neftin <sasha.neftin@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 67a846441f8ef62347533255df72e743298f9d94
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Jun 12 15:46:09 2021 +0200

    ixgbe: Fix an error handling path in 'ixgbe_probe()'
    
    [ Upstream commit dd2aefcd5e37989ae5f90afdae44bbbf3a2990da ]
    
    If an error occurs after a 'pci_enable_pcie_error_reporting()' call, it
    must be undone by a corresponding 'pci_disable_pcie_error_reporting()'
    call, as already done in the remove function.
    
    Fixes: 6fabd715e6d8 ("ixgbe: Implement PCIe AER support")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    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 9d81d1be9f31afff9447a480473274192d6ef947
Author: Tom Rix <trix@redhat.com>
Date:   Fri May 21 12:50:19 2021 -0700

    igc: change default return of igc_read_phy_reg()
    
    [ Upstream commit 05682a0a61b6cbecd97a0f37f743b2cbfd516977 ]
    
    Static analysis reports this problem
    
    igc_main.c:4944:20: warning: The left operand of '&'
      is a garbage value
        if (!(phy_data & SR_1000T_REMOTE_RX_STATUS) &&
              ~~~~~~~~ ^
    
    phy_data is set by the call to igc_read_phy_reg() only if
    there is a read_reg() op, else it is unset and a 0 is
    returned.  Change the return to -EOPNOTSUPP.
    
    Fixes: 208983f099d9 ("igc: Add watchdog")
    Signed-off-by: Tom Rix <trix@redhat.com>
    Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8e24c12f2ff6d32fd9f057382f08e748ec97194c
Author: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Date:   Thu May 13 17:31:04 2021 -0700

    igb: Fix use-after-free error during reset
    
    [ Upstream commit 7b292608db23ccbbfbfa50cdb155d01725d7a52e ]
    
    Cleans the next descriptor to watch (next_to_watch) when cleaning the
    TX ring.
    
    Failure to do so can cause invalid memory accesses. If igb_poll() runs
    while the controller is reset this can lead to the driver try to free
    a skb that was already freed.
    
    (The crash is harder to reproduce with the igb driver, but the same
    potential problem exists as the code is identical to igc)
    
    Fixes: 7cc6fd4c60f2 ("igb: Don't bother clearing Tx buffer_info in igb_clean_tx_ring")
    Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
    Reported-by: Erez Geva <erez.geva.ext@siemens.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 ea5e36b7367ea0a36ef73a163768f16d2977bd83
Author: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Date:   Thu May 13 17:31:03 2021 -0700

    igc: Fix use-after-free error during reset
    
    [ Upstream commit 56ea7ed103b46970e171eb1c95916f393d64eeff ]
    
    Cleans the next descriptor to watch (next_to_watch) when cleaning the
    TX ring.
    
    Failure to do so can cause invalid memory accesses. If igc_poll() runs
    while the controller is being reset this can lead to the driver try to
    free a skb that was already freed.
    
    Log message:
    
     [  101.525242] refcount_t: underflow; use-after-free.
     [  101.525251] WARNING: CPU: 1 PID: 646 at lib/refcount.c:28 refcount_warn_saturate+0xab/0xf0
     [  101.525259] Modules linked in: sch_etf(E) sch_mqprio(E) rfkill(E) intel_rapl_msr(E) intel_rapl_common(E)
     x86_pkg_temp_thermal(E) intel_powerclamp(E) coretemp(E) binfmt_misc(E) kvm_intel(E) kvm(E) irqbypass(E) crc32_pclmul(E)
     ghash_clmulni_intel(E) aesni_intel(E) mei_wdt(E) libaes(E) crypto_simd(E) cryptd(E) glue_helper(E) snd_hda_codec_hdmi(E)
     rapl(E) intel_cstate(E) snd_hda_intel(E) snd_intel_dspcfg(E) sg(E) soundwire_intel(E) intel_uncore(E) at24(E)
     soundwire_generic_allocation(E) iTCO_wdt(E) soundwire_cadence(E) intel_pmc_bxt(E) serio_raw(E) snd_hda_codec(E)
     iTCO_vendor_support(E) watchdog(E) snd_hda_core(E) snd_hwdep(E) snd_soc_core(E) snd_compress(E) snd_pcsp(E)
     soundwire_bus(E) snd_pcm(E) evdev(E) snd_timer(E) mei_me(E) snd(E) soundcore(E) mei(E) configfs(E) ip_tables(E) x_tables(E)
     autofs4(E) ext4(E) crc32c_generic(E) crc16(E) mbcache(E) jbd2(E) sd_mod(E) t10_pi(E) crc_t10dif(E) crct10dif_generic(E)
     i915(E) ahci(E) libahci(E) ehci_pci(E) igb(E) xhci_pci(E) ehci_hcd(E)
     [  101.525303]  drm_kms_helper(E) dca(E) xhci_hcd(E) libata(E) crct10dif_pclmul(E) cec(E) crct10dif_common(E) tsn(E) igc(E)
     e1000e(E) ptp(E) i2c_i801(E) crc32c_intel(E) psmouse(E) i2c_algo_bit(E) i2c_smbus(E) scsi_mod(E) lpc_ich(E) pps_core(E)
     usbcore(E) drm(E) button(E) video(E)
     [  101.525318] CPU: 1 PID: 646 Comm: irq/37-enp7s0-T Tainted: G            E     5.10.30-rt37-tsn1-rt-ipipe #ipipe
     [  101.525320] Hardware name: SIEMENS AG SIMATIC IPC427D/A5E31233588, BIOS V17.02.09 03/31/2017
     [  101.525322] RIP: 0010:refcount_warn_saturate+0xab/0xf0
     [  101.525325] Code: 05 31 48 44 01 01 e8 f0 c6 42 00 0f 0b c3 80 3d 1f 48 44 01 00 75 90 48 c7 c7 78 a8 f3 a6 c6 05 0f 48
     44 01 01 e8 d1 c6 42 00 <0f> 0b c3 80 3d fe 47 44 01 00 0f 85 6d ff ff ff 48 c7 c7 d0 a8 f3
     [  101.525327] RSP: 0018:ffffbdedc0917cb8 EFLAGS: 00010286
     [  101.525329] RAX: 0000000000000000 RBX: ffff98fd6becbf40 RCX: 0000000000000001
     [  101.525330] RDX: 0000000000000001 RSI: ffffffffa6f2700c RDI: 00000000ffffffff
     [  101.525332] RBP: ffff98fd6becc14c R08: ffffffffa7463d00 R09: ffffbdedc0917c50
     [  101.525333] R10: ffffffffa74c3578 R11: 0000000000000034 R12: 00000000ffffff00
     [  101.525335] R13: ffff98fd6b0b1000 R14: 0000000000000039 R15: ffff98fd6be35c40
     [  101.525337] FS:  0000000000000000(0000) GS:ffff98fd6e240000(0000) knlGS:0000000000000000
     [  101.525339] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     [  101.525341] CR2: 00007f34135a3a70 CR3: 0000000150210003 CR4: 00000000001706e0
     [  101.525343] Call Trace:
     [  101.525346]  sock_wfree+0x9c/0xa0
     [  101.525353]  unix_destruct_scm+0x7b/0xa0
     [  101.525358]  skb_release_head_state+0x40/0x90
     [  101.525362]  skb_release_all+0xe/0x30
     [  101.525364]  napi_consume_skb+0x57/0x160
     [  101.525367]  igc_poll+0xb7/0xc80 [igc]
     [  101.525376]  ? sched_clock+0x5/0x10
     [  101.525381]  ? sched_clock_cpu+0xe/0x100
     [  101.525385]  net_rx_action+0x14c/0x410
     [  101.525388]  __do_softirq+0xe9/0x2f4
     [  101.525391]  __local_bh_enable_ip+0xe3/0x110
     [  101.525395]  ? irq_finalize_oneshot.part.47+0xe0/0xe0
     [  101.525398]  irq_forced_thread_fn+0x6a/0x80
     [  101.525401]  irq_thread+0xe8/0x180
     [  101.525403]  ? wake_threads_waitq+0x30/0x30
     [  101.525406]  ? irq_thread_check_affinity+0xd0/0xd0
     [  101.525408]  kthread+0x183/0x1a0
     [  101.525412]  ? kthread_park+0x80/0x80
     [  101.525415]  ret_from_fork+0x22/0x30
    
    Fixes: 13b5b7fd6a4a ("igc: Add support for Tx/Rx rings")
    Reported-by: Erez Geva <erez.geva.ext@siemens.com>
    Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
    Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>