Changelog in Linux kernel 6.6.52

 
arm64: dts: rockchip: fix eMMC/SPI corruption when audio has been used on RK3399 Puma [+ + +]
Author: Quentin Schulz <quentin.schulz@cherry.de>
Date:   Wed Jul 31 13:05:28 2024 +0200

    arm64: dts: rockchip: fix eMMC/SPI corruption when audio has been used on RK3399 Puma
    
    commit bb94a157b37ec23f53906a279320f6ed64300eba upstream.
    
    In commit 91419ae0420f ("arm64: dts: rockchip: use BCLK to GPIO switch
    on rk3399"), an additional pinctrl state was added whose default pinmux
    is for 8ch i2s0. However, Puma only has 2ch i2s0. It's been overriding
    the pinctrl-0 property but the second property override was missed in
    the aforementioned commit.
    
    On Puma, a hardware slider called "BIOS Disable/Normal Boot" can disable
    eMMC and SPI to force booting from SD card. Another software-controlled
    GPIO is then configured to override this behavior to make eMMC and SPI
    available without human intervention. This is currently done in U-Boot
    and it was enough until the aforementioned commit.
    
    Indeed, because of this additional not-yet-overridden property, this
    software-controlled GPIO is now muxed in a state that does not override
    this hardware slider anymore, rendering SPI and eMMC flashes unusable.
    
    Let's override the property with the 2ch pinmux to fix this.
    
    Fixes: 91419ae0420f ("arm64: dts: rockchip: use BCLK to GPIO switch on rk3399")
    Cc: stable@vger.kernel.org
    Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
    Link: https://lore.kernel.org/r/20240731-puma-emmc-6-v1-1-4e28eadf32d0@cherry.de
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: rockchip: fix PMIC interrupt pin in pinctrl for ROCK Pi E [+ + +]
Author: FUKAUMI Naoki <naoki@radxa.com>
Date:   Mon Jul 22 18:52:16 2024 +0900

    arm64: dts: rockchip: fix PMIC interrupt pin in pinctrl for ROCK Pi E
    
    [ Upstream commit c623e9daf60a0275d623ce054601550e54987f5b ]
    
    use GPIO0_A2 as PMIC interrupt pin in pinctrl.
    (I forgot to fix this part in previous commit.)
    
    Fixes: 02afd3d5b9fa ("arm64: dts: rockchip: fix PMIC interrupt pin on ROCK Pi E")
    Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
    Link: https://lore.kernel.org/r/20240722095216.1656081-1-naoki@radxa.com
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: rockchip: override BIOS_DISABLE signal via GPIO hog on RK3399 Puma [+ + +]
Author: Quentin Schulz <quentin.schulz@cherry.de>
Date:   Wed Jul 31 13:05:29 2024 +0200

    arm64: dts: rockchip: override BIOS_DISABLE signal via GPIO hog on RK3399 Puma
    
    commit 741f5ba7ccba5d7ae796dd11c320e28045524771 upstream.
    
    The Qseven BIOS_DISABLE signal on the RK3399-Q7 keeps the on-module eMMC
    and SPI flash powered-down initially (in fact it keeps the reset signal
    asserted). BIOS_DISABLE_OVERRIDE pin allows to override that signal so
    that eMMC and SPI can be used regardless of the state of the signal.
    
    Let's make this GPIO a hog so that it's reserved and locked in the
    proper state.
    
    At the same time, make sure the pin is reserved for the hog and cannot
    be requested by another node.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
    Link: https://lore.kernel.org/r/20240731-puma-emmc-6-v1-2-4e28eadf32d0@cherry.de
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ASoC: codecs: avoid possible garbage value in peb2466_reg_read() [+ + +]
Author: Su Hui <suhui@nfschina.com>
Date:   Wed Sep 11 19:54:50 2024 +0800

    ASoC: codecs: avoid possible garbage value in peb2466_reg_read()
    
    [ Upstream commit 38cc0334baabc5baf08a1db753de521e016c0432 ]
    
    Clang static checker (scan-build) warning:
    sound/soc/codecs/peb2466.c:232:8:
    Assigned value is garbage or undefined [core.uninitialized.Assign]
      232 |                 *val = tmp;
          |                      ^ ~~~
    
    When peb2466_read_byte() fails, 'tmp' will have a garbage value.
    Add a judgemnet to avoid this problem.
    
    Fixes: 227f609c7c0e ("ASoC: codecs: Add support for the Infineon PEB2466 codec")
    Signed-off-by: Su Hui <suhui@nfschina.com>
    Link: https://patch.msgid.link/20240911115448.277828-1-suhui@nfschina.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: meson: axg-card: fix 'use-after-free' [+ + +]
Author: Arseniy Krasnov <avkrasnov@salutedevices.com>
Date:   Wed Sep 11 17:24:25 2024 +0300

    ASoC: meson: axg-card: fix 'use-after-free'
    
    commit 4f9a71435953f941969a4f017e2357db62d85a86 upstream.
    
    Buffer 'card->dai_link' is reallocated in 'meson_card_reallocate_links()',
    so move 'pad' pointer initialization after this function when memory is
    already reallocated.
    
    Kasan bug report:
    
    ==================================================================
    BUG: KASAN: slab-use-after-free in axg_card_add_link+0x76c/0x9bc
    Read of size 8 at addr ffff000000e8b260 by task modprobe/356
    
    CPU: 0 PID: 356 Comm: modprobe Tainted: G O 6.9.12-sdkernel #1
    Call trace:
     dump_backtrace+0x94/0xec
     show_stack+0x18/0x24
     dump_stack_lvl+0x78/0x90
     print_report+0xfc/0x5c0
     kasan_report+0xb8/0xfc
     __asan_load8+0x9c/0xb8
     axg_card_add_link+0x76c/0x9bc [snd_soc_meson_axg_sound_card]
     meson_card_probe+0x344/0x3b8 [snd_soc_meson_card_utils]
     platform_probe+0x8c/0xf4
     really_probe+0x110/0x39c
     __driver_probe_device+0xb8/0x18c
     driver_probe_device+0x108/0x1d8
     __driver_attach+0xd0/0x25c
     bus_for_each_dev+0xe0/0x154
     driver_attach+0x34/0x44
     bus_add_driver+0x134/0x294
     driver_register+0xa8/0x1e8
     __platform_driver_register+0x44/0x54
     axg_card_pdrv_init+0x20/0x1000 [snd_soc_meson_axg_sound_card]
     do_one_initcall+0xdc/0x25c
     do_init_module+0x10c/0x334
     load_module+0x24c4/0x26cc
     init_module_from_file+0xd4/0x128
     __arm64_sys_finit_module+0x1f4/0x41c
     invoke_syscall+0x60/0x188
     el0_svc_common.constprop.0+0x78/0x13c
     do_el0_svc+0x30/0x40
     el0_svc+0x38/0x78
     el0t_64_sync_handler+0x100/0x12c
     el0t_64_sync+0x190/0x194
    
    Fixes: 7864a79f37b5 ("ASoC: meson: add axg sound card support")
    Cc: Stable@vger.kernel.org
    Signed-off-by: Arseniy Krasnov <avkrasnov@salutedevices.com>
    Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
    Link: https://patch.msgid.link/20240911142425.598631-1-avkrasnov@salutedevices.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
btrfs: update target inode's ctime on unlink [+ + +]
Author: Jeff Layton <jlayton@kernel.org>
Date:   Mon Aug 12 12:30:52 2024 -0400

    btrfs: update target inode's ctime on unlink
    
    [ Upstream commit 3bc2ac2f8f0b78a13140fc72022771efe0c9b778 ]
    
    Unlink changes the link count on the target inode. POSIX mandates that
    the ctime must also change when this occurs.
    
    According to https://pubs.opengroup.org/onlinepubs/9699919799/functions/unlink.html:
    
    "Upon successful completion, unlink() shall mark for update the last data
     modification and last file status change timestamps of the parent
     directory. Also, if the file's link count is not 0, the last file status
     change timestamp of the file shall be marked for update."
    
    Signed-off-by: Jeff Layton <jlayton@kernel.org>
    Reviewed-by: David Sterba <dsterba@suse.com>
    [ add link to the opengroup docs ]
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cifs: Fix signature miscalculation [+ + +]
Author: David Howells <dhowells@redhat.com>
Date:   Thu Sep 12 16:58:48 2024 +0100

    cifs: Fix signature miscalculation
    
    [ Upstream commit 5a20b7cb0d8d3ee490a8e088dc2584aa782e3355 ]
    
    Fix the calculation of packet signatures by adding the offset into a page
    in the read or write data payload when hashing the pages from it.
    
    Fixes: 39bc58203f04 ("cifs: Add a function to Hash the contents of an iterator")
    Signed-off-by: David Howells <dhowells@redhat.com>
    Reviewed-by: Tom Talpey <tom@talpey.com>
    Reviewed-by: Paulo Alcantara (Red Hat) <pc@manguebit.com>
    cc: Shyam Prasad N <nspmangalore@gmail.com>
    cc: Rohith Surabattula <rohiths.msft@gmail.com>
    cc: Jeff Layton <jlayton@kernel.org>
    cc: linux-cifs@vger.kernel.org
    cc: linux-fsdevel@vger.kernel.org
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cxl/core: Fix incorrect vendor debug UUID define [+ + +]
Author: peng guo <engguopeng@buaa.edu.cn>
Date:   Wed Jul 10 10:31:12 2024 +0800

    cxl/core: Fix incorrect vendor debug UUID define
    
    [ Upstream commit 8ecef8e01a08c7e3e4ffc8f08d9f9663984f334b ]
    
    When user send a mbox command whose opcode is CXL_MBOX_OP_CLEAR_LOG and
    the in_payload is normal vendor debug log UUID according to
    the CXL specification cxl_payload_from_user_allowed() will return
    false unexpectedly, Sending mbox cmd operation fails and the kernel
    log will print:
    Clear Log: input payload not allowed.
    
    All CXL devices that support a debug log shall support the Vendor Debug
    Log to allow the log to be accessed through a common host driver, for any
    device, all versions of the CXL specification define the same value with
    Log Identifier of: 5e1819d9-11a9-400c-811f-d60719403d86
    
    Refer to CXL spec r3.1 Table 8-71
    
    Fix the definition value of DEFINE_CXL_VENDOR_DEBUG_UUID to match the
    CXL specification.
    
    Fixes: 472b1ce6e9d6 ("cxl/mem: Enable commands via CEL")
    Signed-off-by: peng guo <engguopeng@buaa.edu.cn>
    Reviewed-by: Alison Schofield <alison.schofield@intel.com>
    Link: https://patch.msgid.link/20240710023112.8063-1-engguopeng@buaa.edu.cn
    Signed-off-by: Dave Jiang <dave.jiang@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
device property: Add cleanup.h based fwnode_handle_put() scope based cleanup. [+ + +]
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Sat Feb 17 16:42:36 2024 +0000

    device property: Add cleanup.h based fwnode_handle_put() scope based cleanup.
    
    [ Upstream commit 59ed5e2d505bf5f9b4af64d0021cd0c96aec1f7c ]
    
    Useful where the fwnode_handle was obtained from a call such as
    fwnode_find_reference() as it will safely do nothing if IS_ERR() is true
    and will automatically release the reference on the variable leaving
    scope.
    
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Link: https://lore.kernel.org/r/20240217164249.921878-3-jic23@kernel.org
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Stable-dep-of: 61cbfb5368dd ("iio: adc: ad7124: fix DT configuration parsing")
    Signed-off-by: Sasha Levin <sashal@kernel.org>
device property: Introduce device_for_each_child_node_scoped() [+ + +]
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Sat Feb 17 16:42:38 2024 +0000

    device property: Introduce device_for_each_child_node_scoped()
    
    [ Upstream commit 365130fd47af6d4317aa16a407874b699ab8d8cb ]
    
    Similar to recently propose for_each_child_of_node_scoped() this
    new version of the loop macro instantiates a new local
    struct fwnode_handle * that uses the __free(fwnode_handle) auto
    cleanup handling so that if a reference to a node is held on early
    exit from the loop the reference will be released. If the loop
    runs to completion, the child pointer will be NULL and no action will
    be taken.
    
    The reason this is useful is that it removes the need for
    fwnode_handle_put() on early loop exits.  If there is a need
    to retain the reference, then return_ptr(child) or no_free_ptr(child)
    may be used to safely disable the auto cleanup.
    
    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Link: https://lore.kernel.org/r/20240217164249.921878-5-jic23@kernel.org
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Stable-dep-of: 61cbfb5368dd ("iio: adc: ad7124: fix DT configuration parsing")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dm-integrity: fix a race condition when accessing recalc_sector [+ + +]
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Thu Sep 5 20:27:25 2024 +0200

    dm-integrity: fix a race condition when accessing recalc_sector
    
    commit f8e1ca92e35e9041cc0a1bc226ef07a853a22de4 upstream.
    
    There's a race condition when accessing the variable
    ic->sb->recalc_sector. The function integrity_recalc writes to this
    variable when it makes some progress and the function
    dm_integrity_map_continue may read this variable concurrently.
    
    One problem is that on 32-bit architectures the 64-bit variable is not
    read and written atomically - it may be possible to read garbage if read
    races with write.
    
    Another problem is that memory accesses to this variable are not guarded
    with memory barriers.
    
    This commit fixes the race - it moves reading ic->sb->recalc_sector to an
    earlier place where we hold &ic->endio_wait.lock.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
dma-buf: heaps: Fix off-by-one in CMA heap fault handler [+ + +]
Author: T.J. Mercier <tjmercier@google.com>
Date:   Fri Aug 30 19:26:26 2024 +0000

    dma-buf: heaps: Fix off-by-one in CMA heap fault handler
    
    commit ea5ff5d351b520524019f7ff7f9ce418de2dad87 upstream.
    
    Until VM_DONTEXPAND was added in commit 1c1914d6e8c6 ("dma-buf: heaps:
    Don't track CMA dma-buf pages under RssFile") it was possible to obtain
    a mapping larger than the buffer size via mremap and bypass the overflow
    check in dma_buf_mmap_internal. When using such a mapping to attempt to
    fault past the end of the buffer, the CMA heap fault handler also checks
    the fault offset against the buffer size, but gets the boundary wrong by
    1. Fix the boundary check so that we don't read off the end of the pages
    array and insert an arbitrary page in the mapping.
    
    Reported-by: Xingyu Jin <xingyuj@google.com>
    Fixes: a5d2d29e24be ("dma-buf: heaps: Move heap-helper logic into the cma_heap implementation")
    Cc: stable@vger.kernel.org # Applicable >= 5.10. Needs adjustments only for 5.10.
    Signed-off-by: T.J. Mercier <tjmercier@google.com>
    Acked-by: John Stultz <jstultz@google.com>
    Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240830192627.2546033-1-tjmercier@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amd/amdgpu: apply command submission parser for JPEG v1 [+ + +]
Author: David (Ming Qiang) Wu <David.Wu3@amd.com>
Date:   Thu Sep 5 16:57:28 2024 -0400

    drm/amd/amdgpu: apply command submission parser for JPEG v1
    
    commit 8409fb50ce48d66cf9dc5391f03f05c56c430605 upstream.
    
    Similar to jpeg_v2_dec_ring_parse_cs() but it has different
    register ranges and a few other registers access.
    
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: David (Ming Qiang) Wu <David.Wu3@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    (cherry picked from commit 3d5adbdf1d01708777f2eda375227cbf7a98b9fe)
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amd/display: Disable error correction if it's not supported [+ + +]
Author: Cruise <cruise.hung@amd.com>
Date:   Fri Apr 12 09:51:29 2024 +0800

    drm/amd/display: Disable error correction if it's not supported
    
    [ Upstream commit a8ac994cf0693a1ce59410995594e56124a1c79f ]
    
    [Why]
    Error correction was enabled in a monitor which doesn't support.
    
    [How]
    Disable error correction if it's not supported
    
    Reviewed-by: Wenjing Liu <wenjing.liu@amd.com>
    Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
    Signed-off-by: Cruise <cruise.hung@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Stable-dep-of: a8baec4623ae ("drm/amd/display: Fix FEC_READY write on DP LT")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: Fix FEC_READY write on DP LT [+ + +]
Author: Ilya Bakoulin <ilya.bakoulin@amd.com>
Date:   Wed Apr 17 14:21:28 2024 -0400

    drm/amd/display: Fix FEC_READY write on DP LT
    
    [ Upstream commit a8baec4623aedf36d50767627f6eae5ebf07c6fb ]
    
    [Why/How]
    We can miss writing FEC_READY in some cases before LT start, which
    violates DP spec. Remove the condition guarding the DPCD write so that
    the write happens unconditionally.
    
    Cc: Mario Limonciello <mario.limonciello@amd.com>
    Cc: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Wenjing Liu <wenjing.liu@amd.com>
    Acked-by: Wayne Lin <wayne.lin@amd.com>
    Signed-off-by: Ilya Bakoulin <ilya.bakoulin@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amdgpu/atomfirmware: Silence UBSAN warning [+ + +]
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Fri Sep 6 10:42:45 2024 -0400

    drm/amdgpu/atomfirmware: Silence UBSAN warning
    
    commit 17ea4383649fdeaff3181ddcf1ff03350d42e591 upstream.
    
    Per the comments, these are variable sized arrays.
    
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3613
    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    (cherry picked from commit 81f7804ba84ee617ed594de934ed87bcc4f83531)
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/i915/guc: prevent a possible int overflow in wq offsets [+ + +]
Author: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
Date:   Thu Jul 25 08:59:25 2024 -0700

    drm/i915/guc: prevent a possible int overflow in wq offsets
    
    [ Upstream commit d3d37f74683e2f16f2635ee265884f7ca69350ae ]
    
    It may be possible for the sum of the values derived from
    i915_ggtt_offset() and __get_parent_scratch_offset()/
    i915_ggtt_offset() to go over the u32 limit before being assigned
    to wq offsets of u64 type.
    
    Mitigate these issues by expanding one of the right operands
    to u64 to avoid any overflow issues just in case.
    
    Found by Linux Verification Center (linuxtesting.org) with static
    analysis tool SVACE.
    
    Fixes: c2aa552ff09d ("drm/i915/guc: Add multi-lrc context registration")
    Cc: Matthew Brost <matthew.brost@intel.com>
    Cc: John Harrison <John.C.Harrison@Intel.com>
    Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240725155925.14707-1-n.zhandarovich@fintech.ru
    Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    (cherry picked from commit 1f1c1bd56620b80ae407c5790743e17caad69cec)
    Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/msm/adreno: Fix error return if missing firmware-name [+ + +]
Author: Rob Clark <robdclark@chromium.org>
Date:   Tue Jul 16 09:06:30 2024 -0700

    drm/msm/adreno: Fix error return if missing firmware-name
    
    [ Upstream commit 624ab9cde26a9f150b4fd268b0f3dae3184dc40c ]
    
    -ENODEV is used to signify that there is no zap shader for the platform,
    and the CPU can directly take the GPU out of secure mode.  We want to
    use this return code when there is no zap-shader node.  But not when
    there is, but without a firmware-name property.  This case we want to
    treat as-if the needed fw is not found.
    
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Akhil P Oommen <quic_akhilpo@quicinc.com>
    Patchwork: https://patchwork.freedesktop.org/patch/604564/
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/nouveau/fb: restore init() for ramgp102 [+ + +]
Author: Ben Skeggs <bskeggs@nvidia.com>
Date:   Thu Sep 5 09:24:18 2024 +1000

    drm/nouveau/fb: restore init() for ramgp102
    
    commit 6db9df4f7055eb4ea339e7b83ca676edd9ec1277 upstream.
    
    init() was removed from ramgp102 when reworking the memory detection, as
    it was thought that the code was only necessary when the driver performs
    mclk changes, which nouveau doesn't support on pascal.
    
    However, it turns out that we still need to execute this on some GPUs to
    restore settings after DEVINIT, so revert to the original behaviour.
    
    v2: fix tags in commit message, cc stable
    
    Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/319
    Fixes: 2c0c15a22fa0 ("drm/nouveau/fb/gp102-ga100: switch to simpler vram size detection method")
    Cc: stable@vger.kernel.org # 6.6+
    Signed-off-by: Ben Skeggs <bskeggs@nvidia.com>
    Signed-off-by: Danilo Krummrich <dakr@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240904232418.8590-1-bskeggs@nvidia.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/syncobj: Fix syncobj leak in drm_syncobj_eventfd_ioctl [+ + +]
Author: T.J. Mercier <tjmercier@google.com>
Date:   Mon Sep 9 20:53:59 2024 +0000

    drm/syncobj: Fix syncobj leak in drm_syncobj_eventfd_ioctl
    
    commit 8c7c44be57672e1474bf15a451011c291e85fda4 upstream.
    
    A syncobj reference is taken in drm_syncobj_find, but not released if
    eventfd_ctx_fdget or kzalloc fails. Put the reference in these error
    paths.
    
    Reported-by: Xingyu Jin <xingyuj@google.com>
    Fixes: c7a472297169 ("drm/syncobj: add IOCTL to register an eventfd")
    Signed-off-by: T.J. Mercier <tjmercier@google.com>
    Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
    Reviewed-by. Christian König <christian.koenig@amd.com>
    CC: stable@vger.kernel.org # 6.6+
    Link: https://patchwork.freedesktop.org/patch/msgid/20240909205400.3498337-1-tjmercier@google.com
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm: panel-orientation-quirks: Add quirk for Ayn Loki Max [+ + +]
Author: Bouke Sybren Haarsma <boukehaarsma23@gmail.com>
Date:   Sun Jul 28 14:47:31 2024 +0200

    drm: panel-orientation-quirks: Add quirk for Ayn Loki Max
    
    [ Upstream commit 2c71c8459c8ca66bd8f597effaac892ee8448a9f ]
    
    Add quirk orientation for Ayn Loki Max model.
    
    This has been tested by JELOS team that uses their
    own patched kernel for a while now and confirmed by
    users in the ChimeraOS discord servers.
    
    Signed-off-by: Bouke Sybren Haarsma <boukehaarsma23@gmail.com>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240728124731.168452-3-boukehaarsma23@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm: panel-orientation-quirks: Add quirk for Ayn Loki Zero [+ + +]
Author: Bouke Sybren Haarsma <boukehaarsma23@gmail.com>
Date:   Sun Jul 28 14:47:30 2024 +0200

    drm: panel-orientation-quirks: Add quirk for Ayn Loki Zero
    
    [ Upstream commit b86aa4140f6a8f01f35bfb05af60e01a55b48803 ]
    
    Add quirk orientation for the Ayn Loki Zero.
    
    This also has been tested/used by the JELOS team.
    
    Signed-off-by: Bouke Sybren Haarsma <boukehaarsma23@gmail.com>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240728124731.168452-2-boukehaarsma23@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
eeprom: digsy_mtc: Fix 93xx46 driver probe failure [+ + +]
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Wed May 8 21:46:55 2024 +0300

    eeprom: digsy_mtc: Fix 93xx46 driver probe failure
    
    [ Upstream commit 2b82641ad0620b2d71dc05024b20f82db7e1c0b6 ]
    
    The update to support other (bigger) types of EEPROMs broke
    the driver loading due to removal of the default size.
    
    Fix this by adding the respective (new) flag to the platform data.
    
    Fixes: 14374fbb3f06 ("misc: eeprom_93xx46: Add new 93c56 and 93c66 compatible strings")
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Link: https://lore.kernel.org/r/20240508184905.2102633-3-andriy.shevchenko@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fou: fix initialization of grc [+ + +]
Author: Muhammad Usama Anjum <usama.anjum@collabora.com>
Date:   Fri Sep 6 15:28:39 2024 +0500

    fou: fix initialization of grc
    
    [ Upstream commit 4c8002277167125078e6b9b90137bdf443ebaa08 ]
    
    The grc must be initialize first. There can be a condition where if
    fou is NULL, goto out will be executed and grc would be used
    uninitialized.
    
    Fixes: 7e4196935069 ("fou: Fix null-ptr-deref in GRO.")
    Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
    Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Link: https://patch.msgid.link/20240906102839.202798-1-usama.anjum@collabora.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
HID: multitouch: Add support for GT7868Q [+ + +]
Author: Dmitry Savin <envelsavinds@gmail.com>
Date:   Tue Jul 16 23:27:57 2024 +0100

    HID: multitouch: Add support for GT7868Q
    
    [ Upstream commit c8000deb68365b461b324d68c7ea89d730f0bb85 ]
    
    GT7868Q has incorrect data in the report and needs a fixup.
    The change enables haptic touchpad on Lenovo ThinkBook 13x Gen 4
    and has been tested on the device.
    
    Signed-off-by: Dmitry Savin <envelsavinds@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
hwmon: (pmbus) Conditionally clear individual status bits for pmbus rev >= 1.2 [+ + +]
Author: Patryk Biel <pbiel7@gmail.com>
Date:   Mon Sep 9 11:30:28 2024 +0200

    hwmon: (pmbus) Conditionally clear individual status bits for pmbus rev >= 1.2
    
    [ Upstream commit 20471071f198c8626dbe3951ac9834055b387844 ]
    
    The current implementation of pmbus_show_boolean assumes that all devices
    support write-back operation of status register to clear pending warnings
    or faults. Since clearing individual bits in the status registers was only
    introduced in PMBus specification 1.2, this operation may not be supported
    by some older devices. This can result in an error while reading boolean
    attributes such as temp1_max_alarm.
    
    Fetch PMBus revision supported by the device and modify pmbus_show_boolean
    so that it only tries to clear individual status bits if the device is
    compliant with PMBus specs >= 1.2. Otherwise clear all fault indicators
    on the current page after a fault status was reported.
    
    Fixes: 35f165f08950a ("hwmon: (pmbus) Clear pmbus fault/warning bits after read")
    Signed-off-by: Patryk Biel <pbiel7@gmail.com>
    Message-ID: <20240909-pmbus-status-reg-clearing-v1-1-f1c0d68c6408@gmail.com>
    [groeck:
     Rewrote description
     Moved revision detection code ahead of clear faults command
     Assigned revision if return value from PMBUS_REVISION command is 0
     Improved return value check from calling _pmbus_write_byte_data()]
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
IB/mlx5: Rename 400G_8X speed to comply to naming convention [+ + +]
Author: Patrisious Haddad <phaddad@nvidia.com>
Date:   Wed Sep 20 13:07:43 2023 +0300

    IB/mlx5: Rename 400G_8X speed to comply to naming convention
    
    [ Upstream commit b28ad32442bec2f0d9cb660d7d698a1a53c13d08 ]
    
    Rename 400G_8X speed to comply to naming convention.
    
    Signed-off-by: Patrisious Haddad <phaddad@nvidia.com>
    Reviewed-by: Mark Zhang <markzhang@nvidia.com>
    Link: https://lore.kernel.org/r/ac98447cac8379a43fbdb36d56e5fb2b741a97ff.1695204156.git.leon@kernel.org
    Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Stable-dep-of: 80bf474242b2 ("net/mlx5e: Add missing link mode to ptys2ext_ethtool_map")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ice: fix accounting for filters shared by multiple VSIs [+ + +]
Author: Jacob Keller <jacob.e.keller@intel.com>
Date:   Wed Jul 31 09:55:55 2024 -0700

    ice: fix accounting for filters shared by multiple VSIs
    
    [ Upstream commit e843cf7b34fe2e0c1afc55e1f3057375c9b77a14 ]
    
    When adding a switch filter (such as a MAC or VLAN filter), it is expected
    that the driver will detect the case where the filter already exists, and
    return -EEXIST. This is used by calling code such as ice_vc_add_mac_addr,
    and ice_vsi_add_vlan to avoid incrementing the accounting fields such as
    vsi->num_vlan or vf->num_mac.
    
    This logic works correctly for the case where only a single VSI has added a
    given switch filter.
    
    When a second VSI adds the same switch filter, the driver converts the
    existing filter from an ICE_FWD_TO_VSI filter into an ICE_FWD_TO_VSI_LIST
    filter. This saves switch resources, by ensuring that multiple VSIs can
    re-use the same filter.
    
    The ice_add_update_vsi_list() function is responsible for doing this
    conversion. When first converting a filter from the FWD_TO_VSI into
    FWD_TO_VSI_LIST, it checks if the VSI being added is the same as the
    existing rule's VSI. In such a case it returns -EEXIST.
    
    However, when the switch rule has already been converted to a
    FWD_TO_VSI_LIST, the logic is different. Adding a new VSI in this case just
    requires extending the VSI list entry. The logic for checking if the rule
    already exists in this case returns 0 instead of -EEXIST.
    
    This breaks the accounting logic mentioned above, so the counters for how
    many MAC and VLAN filters exist for a given VF or VSI no longer accurately
    reflect the actual count. This breaks other code which relies on these
    counts.
    
    In typical usage this primarily affects such filters generally shared by
    multiple VSIs such as VLAN 0, or broadcast and multicast MAC addresses.
    
    Fix this by correctly reporting -EEXIST in the case of adding the same VSI
    to a switch rule already converted to ICE_FWD_TO_VSI_LIST.
    
    Fixes: 9daf8208dd4d ("ice: Add support for switch filter programming")
    Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
    Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ice: Fix lldp packets dropping after changing the number of channels [+ + +]
Author: Martyna Szapar-Mudlaw <martyna.szapar-mudlaw@linux.intel.com>
Date:   Wed Jun 26 11:43:42 2024 +0200

    ice: Fix lldp packets dropping after changing the number of channels
    
    [ Upstream commit 9debb703e14939dfafa5d403f27c4feb2e9f6501 ]
    
    After vsi setup refactor commit 6624e780a577 ("ice: split ice_vsi_setup
    into smaller functions") ice_cfg_sw_lldp function which removes rx rule
    directing LLDP packets to vsi is moved from ice_vsi_release to
    ice_vsi_decfg function. ice_vsi_decfg is used in more cases than just in
    vsi_release resulting in unnecessary removal of rx lldp packets handling
    switch rule. This leads to lldp packets being dropped after a change number
    of channels via ethtool.
    This patch moves ice_cfg_sw_lldp function that removes rx lldp sw rule back
    to ice_vsi_release function.
    
    Fixes: 6624e780a577 ("ice: split ice_vsi_setup into smaller functions")
    Reported-by: Matěj Grégr <mgregr@netx.as>
    Closes: https://lore.kernel.org/intel-wired-lan/1be45a76-90af-4813-824f-8398b69745a9@netx.as/T/#u
    Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
    Signed-off-by: Martyna Szapar-Mudlaw <martyna.szapar-mudlaw@linux.intel.com>
    Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ice: fix VSI lists confusion when adding VLANs [+ + +]
Author: Michal Schmidt <mschmidt@redhat.com>
Date:   Wed Sep 4 11:39:22 2024 +0200

    ice: fix VSI lists confusion when adding VLANs
    
    [ Upstream commit d2940002b0aa42898de815a1453b29d440292386 ]
    
    The description of function ice_find_vsi_list_entry says:
      Search VSI list map with VSI count 1
    
    However, since the blamed commit (see Fixes below), the function no
    longer checks vsi_count. This causes a problem in ice_add_vlan_internal,
    where the decision to share VSI lists between filter rules relies on the
    vsi_count of the found existing VSI list being 1.
    
    The reproducing steps:
    1. Have a PF and two VFs.
       There will be a filter rule for VLAN 0, referring to a VSI list
       containing VSIs: 0 (PF), 2 (VF#0), 3 (VF#1).
    2. Add VLAN 1234 to VF#0.
       ice will make the wrong decision to share the VSI list with the new
       rule. The wrong behavior may not be immediately apparent, but it can
       be observed with debug prints.
    3. Add VLAN 1234 to VF#1.
       ice will unshare the VSI list for the VLAN 1234 rule. Due to the
       earlier bad decision, the newly created VSI list will contain
       VSIs 0 (PF) and 3 (VF#1), instead of expected 2 (VF#0) and 3 (VF#1).
    4. Try pinging a network peer over the VLAN interface on VF#0.
       This fails.
    
    Reproducer script at:
    https://gitlab.com/mschmidt2/repro/-/blob/master/RHEL-46814/test-vlan-vsi-list-confusion.sh
    Commented debug trace:
    https://gitlab.com/mschmidt2/repro/-/blob/master/RHEL-46814/ice-vlan-vsi-lists-debug.txt
    Patch adding the debug prints:
    https://gitlab.com/mschmidt2/linux/-/commit/f8a8814623944a45091a77c6094c40bfe726bfdb
    (Unsafe, by the way. Lacks rule_lock when dumping in ice_remove_vlan.)
    
    Michal Swiatkowski added to the explanation that the bug is caused by
    reusing a VSI list created for VLAN 0. All created VFs' VSIs are added
    to VLAN 0 filter. When a non-zero VLAN is created on a VF which is already
    in VLAN 0 (normal case), the VSI list from VLAN 0 is reused.
    It leads to a problem because all VFs (VSIs to be specific) that are
    subscribed to VLAN 0 will now receive a new VLAN tag traffic. This is
    one bug, another is the bug described above. Removing filters from
    one VF will remove VLAN filter from the previous VF. It happens a VF is
    reset. Example:
    - creation of 3 VFs
    - we have VSI list (used for VLAN 0) [0 (pf), 2 (vf1), 3 (vf2), 4 (vf3)]
    - we are adding VLAN 100 on VF1, we are reusing the previous list
      because 2 is there
    - VLAN traffic works fine, but VLAN 100 tagged traffic can be received
      on all VSIs from the list (for example broadcast or unicast)
    - trust is turning on VF2, VF2 is resetting, all filters from VF2 are
      removed; the VLAN 100 filter is also removed because 3 is on the list
    - VLAN traffic to VF1 isn't working anymore, there is a need to recreate
      VLAN interface to readd VLAN filter
    
    One thing I'm not certain about is the implications for the LAG feature,
    which is another caller of ice_find_vsi_list_entry. I don't have a
    LAG-capable card at hand to test.
    
    Fixes: 23ccae5ce15f ("ice: changes to the interface with the HW and FW for SRIOV_VF+LAG")
    Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
    Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
    Reviewed-by: Dave Ertman <David.m.ertman@intel.com>
    Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
igb: Always call igb_xdp_ring_update_tail() under Tx lock [+ + +]
Author: Sriram Yagnaraman <sriram.yagnaraman@ericsson.com>
Date:   Thu Aug 22 09:42:07 2024 +0200

    igb: Always call igb_xdp_ring_update_tail() under Tx lock
    
    [ Upstream commit 27717f8b17c098c4373ddb8fe89e1a1899c7779d ]
    
    Always call igb_xdp_ring_update_tail() under __netif_tx_lock, add a comment
    and lockdep assert to indicate that. This is needed to share the same TX
    ring between XDP, XSK and slow paths. Furthermore, the current XDP
    implementation is racy on tail updates.
    
    Fixes: 9cbc948b5a20 ("igb: add XDP support")
    Signed-off-by: Sriram Yagnaraman <sriram.yagnaraman@est.tech>
    [Kurt: Add lockdep assert and fixes tag]
    Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de>
    Acked-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
    Tested-by: George Kuruvinakunnel <george.kuruvinakunnel@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iio: adc: ad7124: fix DT configuration parsing [+ + +]
Author: Dumitru Ceclan <mitrutzceclan@gmail.com>
Date:   Tue Aug 6 11:51:33 2024 +0300

    iio: adc: ad7124: fix DT configuration parsing
    
    [ Upstream commit 61cbfb5368dd50ed0d65ce21d305aa923581db2b ]
    
    The cfg pointer is set before reading the channel number that the
    configuration should point to. This causes configurations to be shifted
    by one channel.
    For example setting bipolar to the first channel defined in the DT will
    cause bipolar mode to be active on the second defined channel.
    
    Fix by moving the cfg pointer setting after reading the channel number.
    
    Fixes: 7b8d045e497a ("iio: adc: ad7124: allow more than 8 channels")
    Signed-off-by: Dumitru Ceclan <dumitru.ceclan@analog.com>
    Reviewed-by: Nuno Sa <nuno.sa@analog.com>
    Link: https://patch.msgid.link/20240806085133.114547-1-dumitru.ceclan@analog.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iio: adc: ad7124: Switch from of specific to fwnode based property handling [+ + +]
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Sun Feb 18 17:27:26 2024 +0000

    iio: adc: ad7124: Switch from of specific to fwnode based property handling
    
    [ Upstream commit a6eaf02b82744b424b9b2c74847282deb2c6f77b ]
    
    Using the generic firmware data access functions from property.h
    provides a number of advantages:
     1) Works with different firmware types.
     2) Doesn't provide a 'bad' example for new IIO drivers.
     3) Lets us use the new _scoped() loops with automatic reference count
        cleanup for fwnode_handle
    
    Cc: Lars-Peter Clausen <lars@metafoo.de>
    Cc: Michael Hennerich <Michael.Hennerich@analog.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Link: https://lore.kernel.org/r/20240218172731.1023367-4-jic23@kernel.org
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Stable-dep-of: 61cbfb5368dd ("iio: adc: ad7124: fix DT configuration parsing")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Input: ads7846 - ratelimit the spi_sync error message [+ + +]
Author: Marek Vasut <marex@denx.de>
Date:   Mon Jul 8 23:18:57 2024 +0200

    Input: ads7846 - ratelimit the spi_sync error message
    
    [ Upstream commit ccbfea78adf75d3d9e87aa739dab83254f5333fa ]
    
    In case the touch controller is not connected, this message keeps scrolling
    on the console indefinitelly. Ratelimit it to avoid filling kernel logs.
    
    "
    ads7846 spi2.1: spi_sync --> -22
    "
    
    Signed-off-by: Marek Vasut <marex@denx.de>
    Link: https://lore.kernel.org/r/20240708211913.171243-1-marex@denx.de
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Input: i8042 - add Fujitsu Lifebook E756 to i8042 quirk table [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Aug 14 12:06:19 2024 +0200

    Input: i8042 - add Fujitsu Lifebook E756 to i8042 quirk table
    
    [ Upstream commit 7ce7c2283fa6843ab3c2adfeb83dcc504a107858 ]
    
    Yet another quirk entry for Fujitsu laptop.  Lifebook E756 requires
    i8041.nomux for keeping the touchpad working after suspend/resume.
    
    Link: https://bugzilla.suse.com/show_bug.cgi?id=1229056
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Link: https://lore.kernel.org/r/20240814100630.2048-1-tiwai@suse.de
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Input: synaptics - enable SMBus for HP Elitebook 840 G2 [+ + +]
Author: Jonathan Denose <jdenose@google.com>
Date:   Tue Jul 23 21:33:30 2024 -0700

    Input: synaptics - enable SMBus for HP Elitebook 840 G2
    
    [ Upstream commit da897484557b34a54fabb81f6c223c19a69e546d ]
    
    The kernel reports that the touchpad for this device can support a
    different bus.
    
    With SMBus enabled the touchpad movement is smoother and three-finger
    gestures are recognized.
    
    Signed-off-by: Jonathan Denose <jdenose@google.com>
    Link: https://lore.kernel.org/r/20240719180612.1.Ib652dd808c274076f32cd7fc6c1160d2cf71753b@changeid
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ksmbd: override fsids for share path check [+ + +]
Author: Namjae Jeon <linkinjeon@kernel.org>
Date:   Mon Aug 5 08:56:18 2024 +0900

    ksmbd: override fsids for share path check
    
    [ Upstream commit a018c1b636e79b60149b41151ded7c2606d8606e ]
    
    Sangsoo reported that a DAC denial error occurred when accessing
    files through the ksmbd thread. This patch override fsids for share
    path check.
    
    Reported-by: Sangsoo Lee <constant.lee@samsung.com>
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ksmbd: override fsids for smb2_query_info() [+ + +]
Author: Namjae Jeon <linkinjeon@kernel.org>
Date:   Mon Aug 5 08:57:03 2024 +0900

    ksmbd: override fsids for smb2_query_info()
    
    [ Upstream commit f6bd41280a44dcc2e0a25ed72617d25f586974a7 ]
    
    Sangsoo reported that a DAC denial error occurred when accessing
    files through the ksmbd thread. This patch override fsids for
    smb2_query_info().
    
    Reported-by: Sangsoo Lee <constant.lee@samsung.com>
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: Linux 6.6.52 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Sep 18 19:24:10 2024 +0200

    Linux 6.6.52
    
    Link: https://lore.kernel.org/r/20240916114224.509743970@linuxfoundation.org
    Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com>
    Tested-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Tested-by: Peter Schneider <pschneider1968@googlemail.com>
    Tested-by: Mark Brown <broonie@kernel.org>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Kexy Biscuit <kexybiscuit@aosc.io>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
minmax: reduce min/max macro expansion in atomisp driver [+ + +]
Author: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Date:   Wed Sep 11 18:51:11 2024 +0100

    minmax: reduce min/max macro expansion in atomisp driver
    
    commit 7c6a3a65ace70f12b27b1a27c9a69cb791dc6e91 upstream.
    
    Avoid unnecessary nested min()/max() which results in egregious macro
    expansion.
    
    Use clamp_t() as this introduces the least possible expansion, and turn
    the {s,u}DIGIT_FITTING() macros into inline functions to avoid the
    nested expansion.
    
    This resolves an issue with slackware 15.0 32-bit compilation as
    reported by Richard Narron.
    
    Presumably the min/max fixups would be difficult to backport, this patch
    should be easier and fix's Richard's problem in 5.15.
    
    Reported-by: Richard Narron <richard@aaazen.com>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Closes: https://lore.kernel.org/all/4a5321bd-b1f-1832-f0c-cea8694dc5aa@aaazen.com/
    Fixes: 867046cc7027 ("minmax: relax check to allow comparison between unsigned arguments and signed constants")
    Cc: stable@vger.kernel.org
    Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mm: avoid leaving partial pfn mappings around in error case [+ + +]
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed Sep 11 17:11:23 2024 -0700

    mm: avoid leaving partial pfn mappings around in error case
    
    commit 79a61cc3fc0466ad2b7b89618a6157785f0293b3 upstream.
    
    As Jann points out, PFN mappings are special, because unlike normal
    memory mappings, there is no lifetime information associated with the
    mapping - it is just a raw mapping of PFNs with no reference counting of
    a 'struct page'.
    
    That's all very much intentional, but it does mean that it's easy to
    mess up the cleanup in case of errors.  Yes, a failed mmap() will always
    eventually clean up any partial mappings, but without any explicit
    lifetime in the page table mapping itself, it's very easy to do the
    error handling in the wrong order.
    
    In particular, it's easy to mistakenly free the physical backing store
    before the page tables are actually cleaned up and (temporarily) have
    stale dangling PTE entries.
    
    To make this situation less error-prone, just make sure that any partial
    pfn mapping is torn down early, before any other error handling.
    
    Reported-and-tested-by: Jann Horn <jannh@google.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Jason Gunthorpe <jgg@ziepe.ca>
    Cc: Simona Vetter <simona.vetter@ffwll.ch>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mptcp: pm: Fix uaf in __timer_delete_sync [+ + +]
Author: Edward Adam Davis <eadavis@qq.com>
Date:   Tue Sep 10 17:58:56 2024 +0800

    mptcp: pm: Fix uaf in __timer_delete_sync
    
    commit b4cd80b0338945a94972ac3ed54f8338d2da2076 upstream.
    
    There are two paths to access mptcp_pm_del_add_timer, result in a race
    condition:
    
         CPU1                               CPU2
         ====                               ====
         net_rx_action
         napi_poll                          netlink_sendmsg
         __napi_poll                        netlink_unicast
         process_backlog                    netlink_unicast_kernel
         __netif_receive_skb                genl_rcv
         __netif_receive_skb_one_core       netlink_rcv_skb
         NF_HOOK                            genl_rcv_msg
         ip_local_deliver_finish            genl_family_rcv_msg
         ip_protocol_deliver_rcu            genl_family_rcv_msg_doit
         tcp_v4_rcv                         mptcp_pm_nl_flush_addrs_doit
         tcp_v4_do_rcv                      mptcp_nl_remove_addrs_list
         tcp_rcv_established                mptcp_pm_remove_addrs_and_subflows
         tcp_data_queue                     remove_anno_list_by_saddr
         mptcp_incoming_options             mptcp_pm_del_add_timer
         mptcp_pm_del_add_timer             kfree(entry)
    
    In remove_anno_list_by_saddr(running on CPU2), after leaving the critical
    zone protected by "pm.lock", the entry will be released, which leads to the
    occurrence of uaf in the mptcp_pm_del_add_timer(running on CPU1).
    
    Keeping a reference to add_timer inside the lock, and calling
    sk_stop_timer_sync() with this reference, instead of "entry->add_timer".
    
    Move list_del(&entry->list) to mptcp_pm_del_add_timer and inside the pm lock,
    do not directly access any members of the entry outside the pm lock, which
    can avoid similar "entry->x" uaf.
    
    Fixes: 00cfd77b9063 ("mptcp: retransmit ADD_ADDR when timeout")
    Cc: stable@vger.kernel.org
    Reported-and-tested-by: syzbot+f3a31fb909db9b2a5c4d@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=f3a31fb909db9b2a5c4d
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Edward Adam Davis <eadavis@qq.com>
    Acked-by: Paolo Abeni <pabeni@redhat.com>
    Link: https://patch.msgid.link/tencent_7142963A37944B4A74EF76CD66EA3C253609@qq.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net/mlx5: Add missing masks and QoS bit masks for scheduling elements [+ + +]
Author: Carolina Jubran <cjubran@nvidia.com>
Date:   Mon Aug 5 10:03:20 2024 +0300

    net/mlx5: Add missing masks and QoS bit masks for scheduling elements
    
    [ Upstream commit 452ef7f86036392005940de54228d42ca0044192 ]
    
    Add the missing masks for supported element types and Transmit
    Scheduling Arbiter (TSAR) types in scheduling elements.
    
    Also, add the corresponding bit masks for these types in the QoS
    capabilities of a NIC scheduler.
    
    Fixes: 214baf22870c ("net/mlx5e: Support HTB offload")
    Signed-off-by: Carolina Jubran <cjubran@nvidia.com>
    Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5: Correct TASR typo into TSAR [+ + +]
Author: Cosmin Ratiu <cratiu@nvidia.com>
Date:   Fri Jun 14 00:00:31 2024 +0300

    net/mlx5: Correct TASR typo into TSAR
    
    [ Upstream commit e575d3a6dd22123888defb622b1742aa2d45b942 ]
    
    TSAR is the correct spelling (Transmit Scheduling ARbiter).
    
    Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
    Reviewed-by: Gal Pressman <gal@nvidia.com>
    Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
    Link: https://lore.kernel.org/r/20240613210036.1125203-2-tariqt@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: 861cd9b9cb62 ("net/mlx5: Verify support for scheduling element and TSAR type")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5: Explicitly set scheduling element and TSAR type [+ + +]
Author: Carolina Jubran <cjubran@nvidia.com>
Date:   Mon Sep 2 11:46:14 2024 +0300

    net/mlx5: Explicitly set scheduling element and TSAR type
    
    [ Upstream commit c88146abe4d0f8cf659b2b8883fdc33936d2e3b8 ]
    
    Ensure the scheduling element type and TSAR type are explicitly
    initialized in the QoS rate group creation.
    
    This prevents potential issues due to default values.
    
    Fixes: 1ae258f8b343 ("net/mlx5: E-switch, Introduce rate limiting groups API")
    Signed-off-by: Carolina Jubran <cjubran@nvidia.com>
    Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5: Fix bridge mode operations when there are no VFs [+ + +]
Author: Benjamin Poirier <bpoirier@nvidia.com>
Date:   Fri Aug 30 08:39:27 2024 -0400

    net/mlx5: Fix bridge mode operations when there are no VFs
    
    [ Upstream commit b1d305abef4640af1b4f1b4774d513cd81b10cfc ]
    
    Currently, trying to set the bridge mode attribute when numvfs=0 leads to a
    crash:
    
    bridge link set dev eth2 hwmode vepa
    
    [  168.967392] BUG: kernel NULL pointer dereference, address: 0000000000000030
    [...]
    [  168.969989] RIP: 0010:mlx5_add_flow_rules+0x1f/0x300 [mlx5_core]
    [...]
    [  168.976037] Call Trace:
    [  168.976188]  <TASK>
    [  168.978620]  _mlx5_eswitch_set_vepa_locked+0x113/0x230 [mlx5_core]
    [  168.979074]  mlx5_eswitch_set_vepa+0x7f/0xa0 [mlx5_core]
    [  168.979471]  rtnl_bridge_setlink+0xe9/0x1f0
    [  168.979714]  rtnetlink_rcv_msg+0x159/0x400
    [  168.980451]  netlink_rcv_skb+0x54/0x100
    [  168.980675]  netlink_unicast+0x241/0x360
    [  168.980918]  netlink_sendmsg+0x1f6/0x430
    [  168.981162]  ____sys_sendmsg+0x3bb/0x3f0
    [  168.982155]  ___sys_sendmsg+0x88/0xd0
    [  168.985036]  __sys_sendmsg+0x59/0xa0
    [  168.985477]  do_syscall_64+0x79/0x150
    [  168.987273]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
    [  168.987773] RIP: 0033:0x7f8f7950f917
    
    (esw->fdb_table.legacy.vepa_fdb is null)
    
    The bridge mode is only relevant when there are multiple functions per
    port. Therefore, prevent setting and getting this setting when there are no
    VFs.
    
    Note that after this change, there are no settings to change on the PF
    interface using `bridge link` when there are no VFs, so the interface no
    longer appears in the `bridge link` output.
    
    Fixes: 4b89251de024 ("net/mlx5: Support ndo bridge_setlink and getlink")
    Signed-off-by: Benjamin Poirier <bpoirier@nvidia.com>
    Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5: Update the list of the PCI supported devices [+ + +]
Author: Maher Sanalla <msanalla@nvidia.com>
Date:   Thu Aug 15 11:02:34 2024 +0300

    net/mlx5: Update the list of the PCI supported devices
    
    [ Upstream commit 7472d157cb8014103105433bcc0705af2e6f7184 ]
    
    Add the upcoming ConnectX-9 device ID to the table of supported
    PCI device IDs.
    
    Fixes: f908a35b2218 ("net/mlx5: Update the list of the PCI supported devices")
    Signed-off-by: Maher Sanalla <msanalla@nvidia.com>
    Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5: Verify support for scheduling element and TSAR type [+ + +]
Author: Carolina Jubran <cjubran@nvidia.com>
Date:   Mon Aug 5 13:13:03 2024 +0300

    net/mlx5: Verify support for scheduling element and TSAR type
    
    [ Upstream commit 861cd9b9cb62feb244b8d77e68fd6ddedbbf66e9 ]
    
    Before creating a scheduling element in a NIC or E-Switch scheduler,
    ensure that the requested element type is supported. If the element is
    of type Transmit Scheduling Arbiter (TSAR), also verify that the
    specific TSAR type is supported.
    
    Fixes: 214baf22870c ("net/mlx5e: Support HTB offload")
    Fixes: 85c5f7c9200e ("net/mlx5: E-switch, Create QoS on demand")
    Fixes: 0fe132eac38c ("net/mlx5: E-switch, Allow to add vports to rate groups")
    Signed-off-by: Carolina Jubran <cjubran@nvidia.com>
    Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/mlx5e: Add missing link mode to ptys2ext_ethtool_map [+ + +]
Author: Shahar Shitrit <shshitrit@nvidia.com>
Date:   Sun Aug 11 13:58:04 2024 +0300

    net/mlx5e: Add missing link mode to ptys2ext_ethtool_map
    
    [ Upstream commit 80bf474242b21d64a514fd2bb65faa7a17ca8d8d ]
    
    Add MLX5E_400GAUI_8_400GBASE_CR8 to the extended modes
    in ptys2ext_ethtool_table, since it was missing.
    
    Fixes: 6a897372417e ("net/mlx5: ethtool, Add ethtool support for 50Gbps per lane link modes")
    Signed-off-by: Shahar Shitrit <shshitrit@nvidia.com>
    Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
    Reviewed-by: Carolina Jubran <cjubran@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5e: Add missing link modes to ptys2ethtool_map [+ + +]
Author: Shahar Shitrit <shshitrit@nvidia.com>
Date:   Sun Aug 11 13:56:13 2024 +0300

    net/mlx5e: Add missing link modes to ptys2ethtool_map
    
    [ Upstream commit 7617d62cba4a8a3ff3ed3fda0171c43f135c142e ]
    
    Add MLX5E_1000BASE_T and MLX5E_100BASE_TX to the legacy
    modes in ptys2legacy_ethtool_table, since they were missing.
    
    Fixes: 665bc53969d7 ("net/mlx5e: Use new ethtool get/set link ksettings API")
    Signed-off-by: Shahar Shitrit <shshitrit@nvidia.com>
    Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
    Reviewed-by: Carolina Jubran <cjubran@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net: dpaa: Pad packets to ETH_ZLEN [+ + +]
Author: Sean Anderson <sean.anderson@linux.dev>
Date:   Tue Sep 10 10:31:44 2024 -0400

    net: dpaa: Pad packets to ETH_ZLEN
    
    [ Upstream commit cbd7ec083413c6a2e0c326d49e24ec7d12c7a9e0 ]
    
    When sending packets under 60 bytes, up to three bytes of the buffer
    following the data may be leaked. Avoid this by extending all packets to
    ETH_ZLEN, ensuring nothing is leaked in the padding. This bug can be
    reproduced by running
    
            $ ping -s 11 destination
    
    Fixes: 9ad1a3749333 ("dpaa_eth: add support for DPAA Ethernet")
    Suggested-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://patch.msgid.link/20240910143144.1439910-1-sean.anderson@linux.dev
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: dsa: felix: ignore pending status of TAS module when it's disabled [+ + +]
Author: Xiaoliang Yang <xiaoliang.yang_1@nxp.com>
Date:   Fri Sep 6 17:35:50 2024 +0800

    net: dsa: felix: ignore pending status of TAS module when it's disabled
    
    [ Upstream commit 70654f4c212e83898feced125d91ebb3695950d8 ]
    
    The TAS module could not be configured when it's running in pending
    status. We need disable the module and configure it again. However, the
    pending status is not cleared after the module disabled. TC taprio set
    will always return busy even it's disabled.
    
    For example, a user uses tc-taprio to configure Qbv and a future
    basetime. The TAS module will run in a pending status. There is no way
    to reconfigure Qbv, it always returns busy.
    
    Actually the TAS module can be reconfigured when it's disabled. So it
    doesn't need to check the pending status if the TAS module is disabled.
    
    After the patch, user can delete the tc taprio configuration to disable
    Qbv and reconfigure it again.
    
    Fixes: de143c0e274b ("net: dsa: felix: Configure Time-Aware Scheduler via taprio offload")
    Signed-off-by: Xiaoliang Yang <xiaoliang.yang_1@nxp.com>
    Link: https://patch.msgid.link/20240906093550.29985-1-xiaoliang.yang_1@nxp.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ethernet: use ip_hdrlen() instead of bit shift [+ + +]
Author: Moon Yeounsu <yyyynoom@gmail.com>
Date:   Wed Aug 7 19:07:21 2024 +0900

    net: ethernet: use ip_hdrlen() instead of bit shift
    
    [ Upstream commit 9a039eeb71a42c8b13408a1976e300f3898e1be0 ]
    
    `ip_hdr(skb)->ihl << 2` is the same as `ip_hdrlen(skb)`
    Therefore, we should use a well-defined function not a bit shift
    to find the header length.
    
    It also compresses two lines to a single line.
    
    Signed-off-by: Moon Yeounsu <yyyynoom@gmail.com>
    Reviewed-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ftgmac100: Enable TX interrupt to avoid TX timeout [+ + +]
Author: Jacky Chou <jacky_chou@aspeedtech.com>
Date:   Fri Sep 6 14:28:31 2024 +0800

    net: ftgmac100: Enable TX interrupt to avoid TX timeout
    
    [ Upstream commit fef2843bb49f414d1523ca007d088071dee0e055 ]
    
    Currently, the driver only enables RX interrupt to handle RX
    packets and TX resources. Sometimes there is not RX traffic,
    so the TX resource needs to wait for RX interrupt to free.
    This situation will toggle the TX timeout watchdog when the MAC
    TX ring has no more resources to transmit packets.
    Therefore, enable TX interrupt to release TX resources at any time.
    
    When I am verifying iperf3 over UDP, the network hangs.
    Like the log below.
    
    root# iperf3 -c 192.168.100.100 -i1 -t10 -u -b0
    Connecting to host 192.168.100.100, port 5201
    [  4] local 192.168.100.101 port 35773 connected to 192.168.100.100 port 5201
    [ ID] Interval           Transfer     Bandwidth       Total Datagrams
    [  4]   0.00-20.42  sec   160 KBytes  64.2 Kbits/sec  20
    [  4]  20.42-20.42  sec  0.00 Bytes  0.00 bits/sec  0
    [  4]  20.42-20.42  sec  0.00 Bytes  0.00 bits/sec  0
    [  4]  20.42-20.42  sec  0.00 Bytes  0.00 bits/sec  0
    [  4]  20.42-20.42  sec  0.00 Bytes  0.00 bits/sec  0
    [  4]  20.42-20.42  sec  0.00 Bytes  0.00 bits/sec  0
    [  4]  20.42-20.42  sec  0.00 Bytes  0.00 bits/sec  0
    [  4]  20.42-20.42  sec  0.00 Bytes  0.00 bits/sec  0
    [  4]  20.42-20.42  sec  0.00 Bytes  0.00 bits/sec  0
    [  4]  20.42-20.42  sec  0.00 Bytes  0.00 bits/sec  0
    - - - - - - - - - - - - - - - - - - - - - - - - -
    [ ID] Interval          Transfer    Bandwidth      Jitter   Lost/Total Datagrams
    [  4]   0.00-20.42  sec  160 KBytes 64.2 Kbits/sec 0.000 ms 0/20 (0%)
    [  4] Sent 20 datagrams
    iperf3: error - the server has terminated
    
    The network topology is FTGMAC connects directly to a PC.
    UDP does not need to wait for ACK, unlike TCP.
    Therefore, FTGMAC needs to enable TX interrupt to release TX resources instead
    of waiting for the RX interrupt.
    
    Fixes: 10cbd6407609 ("ftgmac100: Rework NAPI & interrupts handling")
    Signed-off-by: Jacky Chou <jacky_chou@aspeedtech.com>
    Link: https://patch.msgid.link/20240906062831.2243399-1-jacky_chou@aspeedtech.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: hns3: use correct release function during uninitialization [+ + +]
Author: Peiyang Wang <wangpeiyang1@huawei.com>
Date:   Tue Aug 13 22:10:24 2024 +0800

    net: hns3: use correct release function during uninitialization
    
    [ Upstream commit 7660833d217528c8f2385528951ab820a031e4e3 ]
    
    pci_request_regions is called to apply for PCI I/O and memory resources
    when the driver is initialized, Therefore, when the driver is uninstalled,
    pci_release_regions should be used to release PCI I/O and memory resources
    instead of pci_release_mem_regions is used to release memory reasouces
    only.
    
    Signed-off-by: Peiyang Wang <wangpeiyang1@huawei.com>
    Signed-off-by: Jijie Shao <shaojijie@huawei.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: phy: vitesse: repair vsc73xx autonegotiation [+ + +]
Author: Pawel Dembicki <paweldembicki@gmail.com>
Date:   Fri Aug 9 21:38:06 2024 +0200

    net: phy: vitesse: repair vsc73xx autonegotiation
    
    [ Upstream commit de7a670f8defe4ed2115552ad23dea0f432f7be4 ]
    
    When the vsc73xx mdio bus work properly, the generic autonegotiation
    configuration works well.
    
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: tighten bad gso csum offset check in virtio_net_hdr [+ + +]
Author: Willem de Bruijn <willemb@google.com>
Date:   Tue Sep 10 17:35:35 2024 -0400

    net: tighten bad gso csum offset check in virtio_net_hdr
    
    commit 6513eb3d3191574b58859ef2d6dc26c0277c6f81 upstream.
    
    The referenced commit drops bad input, but has false positives.
    Tighten the check to avoid these.
    
    The check detects illegal checksum offload requests, which produce
    csum_start/csum_off beyond end of packet after segmentation.
    
    But it is based on two incorrect assumptions:
    
    1. virtio_net_hdr_to_skb with VIRTIO_NET_HDR_GSO_TCP[46] implies GSO.
    True in callers that inject into the tx path, such as tap.
    But false in callers that inject into rx, like virtio-net.
    Here, the flags indicate GRO, and CHECKSUM_UNNECESSARY or
    CHECKSUM_NONE without VIRTIO_NET_HDR_F_NEEDS_CSUM is normal.
    
    2. TSO requires checksum offload, i.e., ip_summed == CHECKSUM_PARTIAL.
    False, as tcp[46]_gso_segment will fix up csum_start and offset for
    all other ip_summed by calling __tcp_v4_send_check.
    
    Because of 2, we can limit the scope of the fix to virtio_net_hdr
    that do try to set these fields, with a bogus value.
    
    Link: https://lore.kernel.org/netdev/20240909094527.GA3048202@port70.net/
    Fixes: 89add40066f9 ("net: drop bad gso csum_start and offset in virtio_net_hdr")
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Cc: stable@vger.kernel.org
    Link: https://patch.msgid.link/20240910213553.839926-1-willemdebruijn.kernel@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: xilinx: axienet: Fix race in axienet_stop [+ + +]
Author: Sean Anderson <sean.anderson@linux.dev>
Date:   Tue Sep 3 13:51:41 2024 -0400

    net: xilinx: axienet: Fix race in axienet_stop
    
    commit 858430db28a5f5a11f8faa3a6fa805438e6f0851 upstream.
    
    axienet_dma_err_handler can race with axienet_stop in the following
    manner:
    
    CPU 1                       CPU 2
    ======================      ==================
    axienet_stop()
        napi_disable()
        axienet_dma_stop()
                                axienet_dma_err_handler()
                                    napi_disable()
                                    axienet_dma_stop()
                                    axienet_dma_start()
                                    napi_enable()
        cancel_work_sync()
        free_irq()
    
    Fix this by setting a flag in axienet_stop telling
    axienet_dma_err_handler not to bother doing anything. I chose not to use
    disable_work_sync to allow for easier backporting.
    
    Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
    Fixes: 8a3b7a252dca ("drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver")
    Link: https://patch.msgid.link/20240903175141.4132898-1-sean.anderson@linux.dev
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    [ Adjusted to apply before dmaengine support ]
    Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
netfilter: nft_socket: fix sk refcount leaks [+ + +]
Author: Florian Westphal <fw@strlen.de>
Date:   Thu Sep 5 12:54:46 2024 +0200

    netfilter: nft_socket: fix sk refcount leaks
    
    [ Upstream commit 8b26ff7af8c32cb4148b3e147c52f9e4c695209c ]
    
    We must put 'sk' reference before returning.
    
    Fixes: 039b1f4f24ec ("netfilter: nft_socket: fix erroneous socket assignment")
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
NFS: Avoid unnecessary rescanning of the per-server delegation list [+ + +]
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Wed Aug 21 14:05:02 2024 -0400

    NFS: Avoid unnecessary rescanning of the per-server delegation list
    
    [ Upstream commit f92214e4c312f6ea9d78650cc6291d200f17abb6 ]
    
    If the call to nfs_delegation_grab_inode() fails, we will not have
    dropped any locks that require us to rescan the list.
    
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
NFSv4: Fix clearing of layout segments in layoutreturn [+ + +]
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Wed Aug 21 14:05:01 2024 -0400

    NFSv4: Fix clearing of layout segments in layoutreturn
    
    [ Upstream commit d72b7963115bea971a28eaa2cb76722c023f9fdf ]
    
    Make sure that we clear the layout segments in cases where we see a
    fatal error, and also in the case where the layout is invalid.
    
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nvmem: core: add nvmem_dev_size() helper [+ + +]
Author: Rafał Miłecki <rafal@milecki.pl>
Date:   Thu Dec 21 18:34:17 2023 +0100

    nvmem: core: add nvmem_dev_size() helper
    
    [ Upstream commit 33cf42e68efc8ff529a7eee08a4f0ba8c8d0a207 ]
    
    This is required by layouts that need to read whole NVMEM content. It's
    especially useful for NVMEM devices without hardcoded layout (like
    U-Boot environment data block).
    
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/r/20231221173421.13737-2-zajec5@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: 8679e8b4a1eb ("nvmem: u-boot-env: error if NVMEM device is too small")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nvmem: u-boot-env: error if NVMEM device is too small [+ + +]
Author: John Thomson <git@johnthomson.fastmail.com.au>
Date:   Mon Sep 2 15:25:08 2024 +0100

    nvmem: u-boot-env: error if NVMEM device is too small
    
    [ Upstream commit 8679e8b4a1ebdb40c4429e49368d29353e07b601 ]
    
    Verify data size before trying to parse it to avoid reading out of
    buffer. This could happen in case of problems at MTD level or invalid DT
    bindings.
    
    Signed-off-by: John Thomson <git@johnthomson.fastmail.com.au>
    Cc: stable <stable@kernel.org>
    Fixes: d5542923f200 ("nvmem: add driver handling U-Boot environment variables")
    [rmilecki: simplify commit description & rebase]
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20240902142510.71096-2-srinivas.kandagatla@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nvmem: u-boot-env: improve coding style [+ + +]
Author: Rafał Miłecki <rafal@milecki.pl>
Date:   Thu Dec 21 18:34:20 2023 +0100

    nvmem: u-boot-env: improve coding style
    
    [ Upstream commit 6bafe07c930676d6430be471310958070816a595 ]
    
    1. Prefer kzalloc() over kcalloc()
       See memory-allocation.rst which says: "to be on the safe side it's
       best to use routines that set memory to zero, like kzalloc()"
    2. Drop dev_err() for u_boot_env_add_cells() fail
       It can fail only on -ENOMEM. We don't want to print error then.
    3. Add extra "crc32_addr" variable
       It makes code reading header's crc32 easier to understand / review.
    
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/r/20231221173421.13737-5-zajec5@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: 8679e8b4a1eb ("nvmem: u-boot-env: error if NVMEM device is too small")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nvmem: u-boot-env: use nvmem device helpers [+ + +]
Author: Rafał Miłecki <rafal@milecki.pl>
Date:   Thu Dec 21 18:34:19 2023 +0100

    nvmem: u-boot-env: use nvmem device helpers
    
    [ Upstream commit a832556d23c5a11115f300011a5874d6107a0d62 ]
    
    Use nvmem_dev_size() and nvmem_device_read() to make this driver less
    mtd dependent.
    
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/r/20231221173421.13737-4-zajec5@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: 8679e8b4a1eb ("nvmem: u-boot-env: error if NVMEM device is too small")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nvmem: u-boot-env: use nvmem_add_one_cell() nvmem subsystem helper [+ + +]
Author: Rafał Miłecki <rafal@milecki.pl>
Date:   Thu Dec 21 18:34:18 2023 +0100

    nvmem: u-boot-env: use nvmem_add_one_cell() nvmem subsystem helper
    
    [ Upstream commit 7c8979b42b1a9c5604f431ba804928e55919263c ]
    
    Simplify adding NVMEM cells.
    
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/r/20231221173421.13737-3-zajec5@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: 8679e8b4a1eb ("nvmem: u-boot-env: error if NVMEM device is too small")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
octeontx2-af: Modify SMQ flush sequence to drop packets [+ + +]
Author: Naveen Mamindlapalli <naveenm@marvell.com>
Date:   Fri Sep 6 10:28:38 2024 +0530

    octeontx2-af: Modify SMQ flush sequence to drop packets
    
    [ Upstream commit 019aba04f08c2102b35ce7fee9d4628d349f56c0 ]
    
    The current implementation of SMQ flush sequence waits for the packets
    in the TM pipeline to be transmitted out of the link. This sequence
    doesn't succeed in HW when there is any issue with link such as lack of
    link credits, link down or any other traffic that is fully occupying the
    link bandwidth (QoS). This patch modifies the SMQ flush sequence to
    drop the packets after TL1 level (SQM) instead of polling for the packets
    to be sent out of RPM/CGX link.
    
    Fixes: 5d9b976d4480 ("octeontx2-af: Support fixed transmit scheduler topology")
    Signed-off-by: Naveen Mamindlapalli <naveenm@marvell.com>
    Reviewed-by: Sunil Kovvuri Goutham <sgoutham@marvell.com>
    Link: https://patch.msgid.link/20240906045838.1620308-1-naveenm@marvell.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pinctrl: meteorlake: Add Arrow Lake-H/U ACPI ID [+ + +]
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date:   Mon Jun 24 12:55:42 2024 +0300

    pinctrl: meteorlake: Add Arrow Lake-H/U ACPI ID
    
    commit a366e46da10d7bfa1a52c3bd31f342a3d0e8e7fe upstream.
    
    Intel Arrow Lake-H/U has the same GPIO hardware than Meteor Lake-P but
    the ACPI ID is different. Add this new ACPI ID to the list of supported
    devices.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
platform/surface: aggregator_registry: Add support for Surface Laptop Go 3 [+ + +]
Author: Maximilian Luz <luzmaximilian@gmail.com>
Date:   Sun Aug 11 15:19:45 2024 +0200

    platform/surface: aggregator_registry: Add support for Surface Laptop Go 3
    
    [ Upstream commit ed235163c3f02329d5e37ed4485bbc39ed2568d4 ]
    
    Add SAM client device nodes for the Surface Laptop Go 3. It seems to use
    the same SAM client devices as the Surface Laptop Go 1 and 2, so re-use
    their node group.
    
    Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
    Link: https://lore.kernel.org/r/20240811131948.261806-3-luzmaximilian@gmail.com
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

platform/surface: aggregator_registry: Add Support for Surface Pro 10 [+ + +]
Author: Maximilian Luz <luzmaximilian@gmail.com>
Date:   Sun Aug 11 15:19:44 2024 +0200

    platform/surface: aggregator_registry: Add Support for Surface Pro 10
    
    [ Upstream commit 9c8e022567bbec53bee8ae75c44b3d6cd2080d42 ]
    
    Add SAM client device nodes for the Surface Pro 10. It seems to use the
    same SAM client devices as the Surface Pro 9, so re-use its node group.
    
    Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
    Link: https://lore.kernel.org/r/20240811131948.261806-2-luzmaximilian@gmail.com
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
platform/x86: panasonic-laptop: Allocate 1 entry extra in the sinf array [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Sep 9 13:32:26 2024 +0200

    platform/x86: panasonic-laptop: Allocate 1 entry extra in the sinf array
    
    commit 33297cef3101d950cec0033a0dce0a2d2bd59999 upstream.
    
    Some DSDT-s have an off-by-one bug where the SINF package count is
    one higher than the SQTY reported value, allocate 1 entry extra.
    
    Also make the SQTY <-> SINF package count mismatch error more verbose
    to help debugging similar issues in the future.
    
    This fixes the panasonic-laptop driver failing to probe() on some
    devices with the following errors:
    
    [    3.958887] SQTY reports bad SINF length SQTY: 37 SINF-pkg-count: 38
    [    3.958892] Couldn't retrieve BIOS data
    [    3.983685] Panasonic Laptop Support - With Macros: probe of MAT0019:00 failed with error -5
    
    Fixes: 709ee531c153 ("panasonic-laptop: add Panasonic Let's Note laptop extras driver v0.94")
    Cc: stable@vger.kernel.org
    Tested-by: James Harmison <jharmison@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20240909113227.254470-2-hdegoede@redhat.com
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

platform/x86: panasonic-laptop: Fix SINF array out of bounds accesses [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Sep 9 13:32:25 2024 +0200

    platform/x86: panasonic-laptop: Fix SINF array out of bounds accesses
    
    commit f52e98d16e9bd7dd2b3aef8e38db5cbc9899d6a4 upstream.
    
    The panasonic laptop code in various places uses the SINF array with index
    values of 0 - SINF_CUR_BRIGHT(0x0d) without checking that the SINF array
    is big enough.
    
    Not all panasonic laptops have this many SINF array entries, for example
    the Toughbook CF-18 model only has 10 SINF array entries. So it only
    supports the AC+DC brightness entries and mute.
    
    Check that the SINF array has a minimum size which covers all AC+DC
    brightness entries and refuse to load if the SINF array is smaller.
    
    For higher SINF indexes hide the sysfs attributes when the SINF array
    does not contain an entry for that attribute, avoiding show()/store()
    accessing the array out of bounds and add bounds checking to the probe()
    and resume() code accessing these.
    
    Fixes: e424fb8cc4e6 ("panasonic-laptop: avoid overflow in acpi_pcc_hotkey_add()")
    Cc: stable@vger.kernel.org
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20240909113227.254470-1-hdegoede@redhat.com
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
powerpc/mm: Fix boot warning with hugepages and CONFIG_DEBUG_VIRTUAL [+ + +]
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Thu Aug 8 09:05:08 2024 +0200

    powerpc/mm: Fix boot warning with hugepages and CONFIG_DEBUG_VIRTUAL
    
    [ Upstream commit e7e846dc6c73fbc94ae8b4ec20d05627646416f2 ]
    
    Booting with CONFIG_DEBUG_VIRTUAL leads to following warning when
    passing hugepage reservation on command line:
    
      Kernel command line: hugepagesz=1g hugepages=1 hugepagesz=64m hugepages=1 hugepagesz=256m hugepages=1 noreboot
      HugeTLB: allocating 1 of page size 1.00 GiB failed.  Only allocated 0 hugepages.
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 0 at arch/powerpc/include/asm/io.h:948 __alloc_bootmem_huge_page+0xd4/0x284
      Modules linked in:
      CPU: 0 PID: 0 Comm: swapper Not tainted 6.10.0-rc6-00396-g6b0e82791bd0-dirty #936
      Hardware name: MPC8544DS e500v2 0x80210030 MPC8544 DS
      NIP:  c1020240 LR: c10201d0 CTR: 00000000
      REGS: c13fdd30 TRAP: 0700   Not tainted  (6.10.0-rc6-00396-g6b0e82791bd0-dirty)
      MSR:  00021000 <CE,ME>  CR: 44084288  XER: 20000000
    
      GPR00: c10201d0 c13fde20 c130b560 e8000000 e8001000 00000000 00000000 c1420000
      GPR08: 00000000 00028001 00000000 00000004 44084282 01066ac0 c0eb7c9c efffe149
      GPR16: c0fc4228 0000005f ffffffff c0eb7d0c c0eb7cc0 c0eb7ce0 ffffffff 00000000
      GPR24: c1441cec efffe153 e8001000 c14240c0 00000000 c1441d64 00000000 e8000000
      NIP [c1020240] __alloc_bootmem_huge_page+0xd4/0x284
      LR [c10201d0] __alloc_bootmem_huge_page+0x64/0x284
      Call Trace:
      [c13fde20] [c10201d0] __alloc_bootmem_huge_page+0x64/0x284 (unreliable)
      [c13fde50] [c10207b8] hugetlb_hstate_alloc_pages+0x8c/0x3e8
      [c13fdeb0] [c1021384] hugepages_setup+0x240/0x2cc
      [c13fdef0] [c1000574] unknown_bootoption+0xfc/0x280
      [c13fdf30] [c0078904] parse_args+0x200/0x4c4
      [c13fdfa0] [c1000d9c] start_kernel+0x238/0x7d0
      [c13fdff0] [c0000434] set_ivor+0x12c/0x168
      Code: 554aa33e 7c042840 3ce0c142 80a7427c 5109a016 50caa016 7c9a2378 7fdcf378 4180000c 7c052040 41810160 7c095040 <0fe00000> 38c00000 40800108 3c60c0eb
      ---[ end trace 0000000000000000 ]---
    
    This is due to virt_addr_valid() using high_memory before it is set.
    
    high_memory is set in mem_init() using max_low_pfn, but max_low_pfn
    is available long before, it is set in mem_topology_setup(). So just
    like commit daa9ada2093e ("powerpc/mm: Fix boot crash with FLATMEM")
    moved the setting of max_mapnr immediately after the call to
    mem_topology_setup(), the same can be done for high_memory.
    
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/62b69c4baad067093f39e7e60df0fe27a86b8d2a.1723100702.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
riscv: dts: starfive: add assigned-clock* to limit frquency [+ + +]
Author: William Qiu <william.qiu@starfivetech.com>
Date:   Fri Sep 22 14:28:34 2023 +0800

    riscv: dts: starfive: add assigned-clock* to limit frquency
    
    commit af571133f7ae028ec9b5fdab78f483af13bf28d3 upstream.
    
    In JH7110 SoC, we need to go by-pass mode, so we need add the
    assigned-clock* properties to limit clock frquency.
    
    Signed-off-by: William Qiu <william.qiu@starfivetech.com>
    Reviewed-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
    Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
    Signed-off-by: WangYuli <wangyuli@uniontech.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
scripts: kconfig: merge_config: config files: add a trailing newline [+ + +]
Author: Anders Roxell <anders.roxell@linaro.org>
Date:   Mon Aug 5 11:22:34 2024 +0200

    scripts: kconfig: merge_config: config files: add a trailing newline
    
    [ Upstream commit 33330bcf031818e60a816db0cfd3add9eecc3b28 ]
    
    When merging files without trailing newlines at the end of the file, two
    config fragments end up at the same row if file1.config doens't have a
    trailing newline at the end of the file.
    
    file1.config "CONFIG_1=y"
    file2.config "CONFIG_2=y"
    ./scripts/kconfig/merge_config.sh -m .config file1.config file2.config
    
    This will generate a .config looking like this.
    cat .config
    ...
    CONFIG_1=yCONFIG_2=y"
    
    Making sure so we add a newline at the end of every config file that is
    passed into the script.
    
    Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests/bpf: Support SOCK_STREAM in unix_inet_redir_to_connected() [+ + +]
Author: Michal Luczaj <mhal@rbox.co>
Date:   Sat Jul 13 21:41:39 2024 +0200

    selftests/bpf: Support SOCK_STREAM in unix_inet_redir_to_connected()
    
    [ Upstream commit 1b0ad43177c097d38b967b99c2b71d8be28b0223 ]
    
    Function ignores the AF_UNIX socket type argument, SOCK_DGRAM is hardcoded.
    Fix to respect the argument provided.
    
    Fixes: 75e0e27db6cf ("selftest/bpf: Change udp to inet in some function names")
    Suggested-by: Jakub Sitnicki <jakub@cloudflare.com>
    Signed-off-by: Michal Luczaj <mhal@rbox.co>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Tested-by: Jakub Sitnicki <jakub@cloudflare.com>
    Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com>
    Link: https://lore.kernel.org/bpf/20240713200218.2140950-3-mhal@rbox.co
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests: mptcp: join: restrict fullmesh endp on 1st sf [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Tue Sep 10 21:06:36 2024 +0200

    selftests: mptcp: join: restrict fullmesh endp on 1st sf
    
    commit 49ac6f05ace5bb0070c68a0193aa05d3c25d4c83 upstream.
    
    A new endpoint using the IP of the initial subflow has been recently
    added to increase the code coverage. But it breaks the test when using
    old kernels not having commit 86e39e04482b ("mptcp: keep track of local
    endpoint still available for each msk"), e.g. on v5.15.
    
    Similar to commit d4c81bbb8600 ("selftests: mptcp: join: support local
    endpoint being tracked or not"), it is possible to add the new endpoint
    conditionally, by checking if "mptcp_pm_subflow_check_next" is present
    in kallsyms: this is not directly linked to the commit introducing this
    symbol but for the parent one which is linked anyway. So we can know in
    advance what will be the expected behaviour, and add the new endpoint
    only when it makes sense to do so.
    
    Fixes: 4878f9f8421f ("selftests: mptcp: join: validate fullmesh endp on 1st sf")
    Cc: stable@vger.kernel.org
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://patch.msgid.link/20240910-net-selftests-mptcp-fix-install-v1-1-8f124aa9156d@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

selftests: net: csum: Fix checksums for packets with non-zero padding [+ + +]
Author: Sean Anderson <sean.anderson@linux.dev>
Date:   Fri Sep 6 17:07:43 2024 -0400

    selftests: net: csum: Fix checksums for packets with non-zero padding
    
    [ Upstream commit e8a63d473b49011a68a748aea1c8aefa046ebacf ]
    
    Padding is not included in UDP and TCP checksums. Therefore, reduce the
    length of the checksummed data to include only the data in the IP
    payload. This fixes spurious reported checksum failures like
    
    rx: pkt: sport=33000 len=26 csum=0xc850 verify=0xf9fe
    pkt: bad csum
    
    Technically it is possible for there to be trailing bytes after the UDP
    data but before the Ethernet padding (e.g. if sizeof(ip) + sizeof(udp) +
    udp.len < ip.len). However, we don't generate such packets.
    
    Fixes: 91a7de85600d ("selftests/net: add csum offload test")
    Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Link: https://patch.msgid.link/20240906210743.627413-1-sean.anderson@linux.dev
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
smb/server: fix return value of smb2_open() [+ + +]
Author: ChenXiaoSong <chenxiaosong@kylinos.cn>
Date:   Thu Aug 22 08:20:50 2024 +0000

    smb/server: fix return value of smb2_open()
    
    [ Upstream commit 2186a116538a715b20e15f84fdd3545e5fe0a39b ]
    
    In most error cases, error code is not returned in smb2_open(),
    __process_request() will not print error message.
    
    Fix this by returning the correct value at the end of smb2_open().
    
    Signed-off-by: ChenXiaoSong <chenxiaosong@kylinos.cn>
    Acked-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
soundwire: stream: Revert "soundwire: stream: fix programming slave ports for non-continous port maps" [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Mon Sep 9 18:47:46 2024 +0200

    soundwire: stream: Revert "soundwire: stream: fix programming slave ports for non-continous port maps"
    
    commit 233a95fd574fde1c375c486540a90304a2d2d49f upstream.
    
    This reverts commit ab8d66d132bc8f1992d3eb6cab8d32dda6733c84 because it
    breaks codecs using non-continuous masks in source and sink ports.  The
    commit missed the point that port numbers are not used as indices for
    iterating over prop.sink_ports or prop.source_ports.
    
    Soundwire core and existing codecs expect that the array passed as
    prop.sink_ports and prop.source_ports is continuous.  The port mask still
    might be non-continuous, but that's unrelated.
    
    Reported-by: Bard Liao <yung-chuan.liao@linux.intel.com>
    Closes: https://lore.kernel.org/all/b6c75eee-761d-44c8-8413-2a5b34ee2f98@linux.intel.com/
    Fixes: ab8d66d132bc ("soundwire: stream: fix programming slave ports for non-continous port maps")
    Acked-by: Bard Liao <yung-chuan.liao@linux.intel.com>
    Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Tested-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Link: https://lore.kernel.org/r/20240909164746.136629-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
spi: geni-qcom: Fix incorrect free_irq() sequence [+ + +]
Author: Jinjie Ruan <ruanjinjie@huawei.com>
Date:   Mon Sep 9 15:31:40 2024 +0800

    spi: geni-qcom: Fix incorrect free_irq() sequence
    
    [ Upstream commit b787a33864121a565aeb0e88561bf6062a19f99c ]
    
    In spi_geni_remove(), the free_irq() sequence is different from that
    on the probe error path. And the IRQ will still remain and it's interrupt
    handler may use the dma channel after release dma channel and before free
    irq, which is not secure, fix it.
    
    Fixes: b59c122484ec ("spi: spi-geni-qcom: Add support for GPI dma")
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://patch.msgid.link/20240909073141.951494-3-ruanjinjie@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

spi: geni-qcom: Undo runtime PM changes at driver exit time [+ + +]
Author: Jinjie Ruan <ruanjinjie@huawei.com>
Date:   Mon Sep 9 15:31:39 2024 +0800

    spi: geni-qcom: Undo runtime PM changes at driver exit time
    
    [ Upstream commit 89e362c883c65ff94b76b9862285f63545fb5274 ]
    
    It's important to undo pm_runtime_use_autosuspend() with
    pm_runtime_dont_use_autosuspend() at driver exit time unless driver
    initially enabled pm_runtime with devm_pm_runtime_enable()
    (which handles it for you).
    
    Hence, switch to devm_pm_runtime_enable() to fix it, so the
    pm_runtime_disable() in probe error path and remove function
    can be removed.
    
    Fixes: cfdab2cd85ec ("spi: spi-geni-qcom: Set an autosuspend delay of 250 ms")
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://patch.msgid.link/20240909073141.951494-2-ruanjinjie@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

spi: nxp-fspi: fix the KASAN report out-of-bounds bug [+ + +]
Author: Han Xu <han.xu@nxp.com>
Date:   Wed Sep 11 16:11:45 2024 -0500

    spi: nxp-fspi: fix the KASAN report out-of-bounds bug
    
    commit 2a8787c1cdc7be24fdd8953ecd1a8743a1006235 upstream.
    
    Change the memcpy length to fix the out-of-bounds issue when writing the
    data that is not 4 byte aligned to TX FIFO.
    
    To reproduce the issue, write 3 bytes data to NOR chip.
    
    dd if=3b of=/dev/mtd0
    [   36.926103] ==================================================================
    [   36.933409] BUG: KASAN: slab-out-of-bounds in nxp_fspi_exec_op+0x26ec/0x2838
    [   36.940514] Read of size 4 at addr ffff00081037c2a0 by task dd/455
    [   36.946721]
    [   36.948235] CPU: 3 UID: 0 PID: 455 Comm: dd Not tainted 6.11.0-rc5-gc7b0e37c8434 #1070
    [   36.956185] Hardware name: Freescale i.MX8QM MEK (DT)
    [   36.961260] Call trace:
    [   36.963723]  dump_backtrace+0x90/0xe8
    [   36.967414]  show_stack+0x18/0x24
    [   36.970749]  dump_stack_lvl+0x78/0x90
    [   36.974451]  print_report+0x114/0x5cc
    [   36.978151]  kasan_report+0xa4/0xf0
    [   36.981670]  __asan_report_load_n_noabort+0x1c/0x28
    [   36.986587]  nxp_fspi_exec_op+0x26ec/0x2838
    [   36.990800]  spi_mem_exec_op+0x8ec/0xd30
    [   36.994762]  spi_mem_no_dirmap_read+0x190/0x1e0
    [   36.999323]  spi_mem_dirmap_write+0x238/0x32c
    [   37.003710]  spi_nor_write_data+0x220/0x374
    [   37.007932]  spi_nor_write+0x110/0x2e8
    [   37.011711]  mtd_write_oob_std+0x154/0x1f0
    [   37.015838]  mtd_write_oob+0x104/0x1d0
    [   37.019617]  mtd_write+0xb8/0x12c
    [   37.022953]  mtdchar_write+0x224/0x47c
    [   37.026732]  vfs_write+0x1e4/0x8c8
    [   37.030163]  ksys_write+0xec/0x1d0
    [   37.033586]  __arm64_sys_write+0x6c/0x9c
    [   37.037539]  invoke_syscall+0x6c/0x258
    [   37.041327]  el0_svc_common.constprop.0+0x160/0x22c
    [   37.046244]  do_el0_svc+0x44/0x5c
    [   37.049589]  el0_svc+0x38/0x78
    [   37.052681]  el0t_64_sync_handler+0x13c/0x158
    [   37.057077]  el0t_64_sync+0x190/0x194
    [   37.060775]
    [   37.062274] Allocated by task 455:
    [   37.065701]  kasan_save_stack+0x2c/0x54
    [   37.069570]  kasan_save_track+0x20/0x3c
    [   37.073438]  kasan_save_alloc_info+0x40/0x54
    [   37.077736]  __kasan_kmalloc+0xa0/0xb8
    [   37.081515]  __kmalloc_noprof+0x158/0x2f8
    [   37.085563]  mtd_kmalloc_up_to+0x120/0x154
    [   37.089690]  mtdchar_write+0x130/0x47c
    [   37.093469]  vfs_write+0x1e4/0x8c8
    [   37.096901]  ksys_write+0xec/0x1d0
    [   37.100332]  __arm64_sys_write+0x6c/0x9c
    [   37.104287]  invoke_syscall+0x6c/0x258
    [   37.108064]  el0_svc_common.constprop.0+0x160/0x22c
    [   37.112972]  do_el0_svc+0x44/0x5c
    [   37.116319]  el0_svc+0x38/0x78
    [   37.119401]  el0t_64_sync_handler+0x13c/0x158
    [   37.123788]  el0t_64_sync+0x190/0x194
    [   37.127474]
    [   37.128977] The buggy address belongs to the object at ffff00081037c2a0
    [   37.128977]  which belongs to the cache kmalloc-8 of size 8
    [   37.141177] The buggy address is located 0 bytes inside of
    [   37.141177]  allocated 3-byte region [ffff00081037c2a0, ffff00081037c2a3)
    [   37.153465]
    [   37.154971] The buggy address belongs to the physical page:
    [   37.160559] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x89037c
    [   37.168596] flags: 0xbfffe0000000000(node=0|zone=2|lastcpupid=0x1ffff)
    [   37.175149] page_type: 0xfdffffff(slab)
    [   37.179021] raw: 0bfffe0000000000 ffff000800002500 dead000000000122 0000000000000000
    [   37.186788] raw: 0000000000000000 0000000080800080 00000001fdffffff 0000000000000000
    [   37.194553] page dumped because: kasan: bad access detected
    [   37.200144]
    [   37.201647] Memory state around the buggy address:
    [   37.206460]  ffff00081037c180: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc
    [   37.213701]  ffff00081037c200: fa fc fc fc 05 fc fc fc 03 fc fc fc 02 fc fc fc
    [   37.220946] >ffff00081037c280: 06 fc fc fc 03 fc fc fc fc fc fc fc fc fc fc fc
    [   37.228186]                                ^
    [   37.232473]  ffff00081037c300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    [   37.239718]  ffff00081037c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    [   37.246962] ==================================================================
    [   37.254394] Disabling lock debugging due to kernel taint
    0+1 records in
    0+1 records out
    3 bytes copied, 0.335911 s, 0.0 kB/s
    
    Fixes: a5356aef6a90 ("spi: spi-mem: Add driver for NXP FlexSPI controller")
    Cc: stable@kernel.org
    Signed-off-by: Han Xu <han.xu@nxp.com>
    Link: https://patch.msgid.link/20240911211146.3337068-1-han.xu@nxp.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tracing/osnoise: Fix build when timerlat is not enabled [+ + +]
Author: Steven Rostedt <rostedt@goodmis.org>
Date:   Mon Sep 9 10:32:31 2024 -0400

    tracing/osnoise: Fix build when timerlat is not enabled
    
    commit af178143343028fdec9d5960a22d17f5587fd3f5 upstream.
    
    To fix some critical section races, the interface_lock was added to a few
    locations. One of those locations was above where the interface_lock was
    declared, so the declaration was moved up before that usage.
    Unfortunately, where it was placed was inside a CONFIG_TIMERLAT_TRACER
    ifdef block. As the interface_lock is used outside that config, this broke
    the build when CONFIG_OSNOISE_TRACER was enabled but
    CONFIG_TIMERLAT_TRACER was not.
    
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Cc: "Helena Anna" <helena.anna.dubel@intel.com>
    Cc: "Luis Claudio R. Goncalves" <lgoncalv@redhat.com>
    Cc: Tomas Glozar <tglozar@redhat.com>
    Link: https://lore.kernel.org/20240909103231.23a289e2@gandalf.local.home
    Fixes: e6a53481da29 ("tracing/timerlat: Only clear timer if a kthread exists")
    Reported-by: "Bityutskiy, Artem" <artem.bityutskiy@intel.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usbnet: ipheth: do not stop RX on failing RX callback [+ + +]
Author: Foster Snowhill <forst@pen.gy>
Date:   Tue Aug 6 19:28:08 2024 +0200

    usbnet: ipheth: do not stop RX on failing RX callback
    
    [ Upstream commit 74efed51e0a4d62f998f806c307778b47fc73395 ]
    
    RX callbacks can fail for multiple reasons:
    
    * Payload too short
    * Payload formatted incorrecly (e.g. bad NCM framing)
    * Lack of memory
    
    None of these should cause the driver to seize up.
    
    Make such failures non-critical and continue processing further
    incoming URBs.
    
    Signed-off-by: Foster Snowhill <forst@pen.gy>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usbnet: ipheth: drop RX URBs with no payload [+ + +]
Author: Foster Snowhill <forst@pen.gy>
Date:   Tue Aug 6 19:28:07 2024 +0200

    usbnet: ipheth: drop RX URBs with no payload
    
    [ Upstream commit 94d7eeb6c0ef0310992944f0d0296929816a2cb0 ]
    
    On iPhone 15 Pro Max one can observe periodic URBs with no payload
    on the "bulk in" (RX) endpoint. These don't seem to do anything
    meaningful. Reproduced on iOS 17.5.1 and 17.6.
    
    This behaviour isn't observed on iPhone 11 on the same iOS version. The
    nature of these zero-length URBs is so far unknown.
    
    Drop RX URBs with no payload.
    
    Signed-off-by: Foster Snowhill <forst@pen.gy>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usbnet: ipheth: fix carrier detection in modes 1 and 4 [+ + +]
Author: Foster Snowhill <forst@pen.gy>
Date:   Tue Aug 6 19:28:09 2024 +0200

    usbnet: ipheth: fix carrier detection in modes 1 and 4
    
    [ Upstream commit 67927a1b255d883881be9467508e0af9a5e0be9d ]
    
    Apart from the standard "configurations", "interfaces" and "alternate
    interface settings" in USB, iOS devices also have a notion of
    "modes". In different modes, the device exposes a different set of
    available configurations.
    
    Depending on the iOS version, and depending on the current mode, the
    length and contents of the carrier state control message differs:
    
    * 1 byte (seen on iOS 4.2.1, 8.4):
        * 03: carrier off (mode 0)
        * 04: carrier on (mode 0)
    * 3 bytes (seen on iOS 10.3.4, 15.7.6):
        * 03 03 03: carrier off (mode 0)
        * 04 04 03: carrier on (mode 0)
    * 4 bytes (seen on iOS 16.5, 17.6):
        * 03 03 03 00: carrier off (mode 0)
        * 04 03 03 00: carrier off (mode 1)
        * 06 03 03 00: carrier off (mode 4)
        * 04 04 03 04: carrier on (mode 0 and 1)
        * 06 04 03 04: carrier on (mode 4)
    
    Before this change, the driver always used the first byte of the
    response to determine carrier state.
    
    From this larger sample, the first byte seems to indicate the number of
    available USB configurations in the current mode (with the exception of
    the default mode 0), and in some cases (namely mode 1 and 4) does not
    correlate with the carrier state.
    
    Previous logic erroneously counted `04 03 03 00` as "carrier on" and
    `06 04 03 04` as "carrier off" on iOS versions that support mode 1 and
    mode 4 respectively.
    
    Only modes 0, 1 and 4 expose the USB Ethernet interfaces necessary for
    the ipheth driver.
    
    Check the second byte of the control message where possible, and fall
    back to checking the first byte on older iOS versions.
    
    Signed-off-by: Foster Snowhill <forst@pen.gy>
    Tested-by: Georgi Valkov <gvalkov@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usbnet: ipheth: remove extraneous rx URB length check [+ + +]
Author: Foster Snowhill <forst@pen.gy>
Date:   Tue Aug 6 19:28:06 2024 +0200

    usbnet: ipheth: remove extraneous rx URB length check
    
    [ Upstream commit 655b46d7a39ac6f049698b27c1568c0f7ff85d1e ]
    
    Rx URB length was already checked in ipheth_rcvbulk_callback_legacy()
    and ipheth_rcvbulk_callback_ncm(), depending on the current mode.
    The check in ipheth_rcvbulk_callback() was thus mostly a duplicate.
    
    The only place in ipheth_rcvbulk_callback() where we care about the URB
    length is for the initial control frame. These frames are always 4 bytes
    long. This has been checked as far back as iOS 4.2.1 on iPhone 3G.
    
    Remove the extraneous URB length check. For control frames, check for
    the specific 4-byte length instead.
    
    Signed-off-by: Foster Snowhill <forst@pen.gy>
    Tested-by: Georgi Valkov <gvalkov@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
wifi: mt76: mt7921: fix NULL pointer access in mt7921_ipv6_addr_change [+ + +]
Author: Bert Karwatzki <spasswolf@web.de>
Date:   Mon Aug 12 12:45:41 2024 +0200

    wifi: mt76: mt7921: fix NULL pointer access in mt7921_ipv6_addr_change
    
    [ Upstream commit 479ffee68d59c599f8aed8fa2dcc8e13e7bd13c3 ]
    
    When disabling wifi mt7921_ipv6_addr_change() is called as a notifier.
    At this point mvif->phy is already NULL so we cannot use it here.
    
    Signed-off-by: Bert Karwatzki <spasswolf@web.de>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://patch.msgid.link/20240812104542.80760-1-spasswolf@web.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
x86/hyperv: fix kexec crash due to VP assist page corruption [+ + +]
Author: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>
Date:   Wed Aug 28 16:51:56 2024 +0530

    x86/hyperv: fix kexec crash due to VP assist page corruption
    
    commit b9af6418279c4cf73ca073f8ea024992b38be8ab upstream.
    
    commit 9636be85cc5b ("x86/hyperv: Fix hyperv_pcpu_input_arg handling when
    CPUs go online/offline") introduces a new cpuhp state for hyperv
    initialization.
    
    cpuhp_setup_state() returns the state number if state is
    CPUHP_AP_ONLINE_DYN or CPUHP_BP_PREPARE_DYN and 0 for all other states.
    For the hyperv case, since a new cpuhp state was introduced it would
    return 0. However, in hv_machine_shutdown(), the cpuhp_remove_state() call
    is conditioned upon "hyperv_init_cpuhp > 0". This will never be true and
    so hv_cpu_die() won't be called on all CPUs. This means the VP assist page
    won't be reset. When the kexec kernel tries to setup the VP assist page
    again, the hypervisor corrupts the memory region of the old VP assist page
    causing a panic in case the kexec kernel is using that memory elsewhere.
    This was originally fixed in commit dfe94d4086e4 ("x86/hyperv: Fix kexec
    panic/hang issues").
    
    Get rid of hyperv_init_cpuhp entirely since we are no longer using a
    dynamic cpuhp state and use CPUHP_AP_HYPERV_ONLINE directly with
    cpuhp_remove_state().
    
    Cc: stable@vger.kernel.org
    Fixes: 9636be85cc5b ("x86/hyperv: Fix hyperv_pcpu_input_arg handling when CPUs go online/offline")
    Signed-off-by: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>
    Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
    Reviewed-by: Michael Kelley <mhklinux@outlook.com>
    Link: https://lore.kernel.org/r/20240828112158.3538342-1-anirudh@anirudhrb.com
    Signed-off-by: Wei Liu <wei.liu@kernel.org>
    Message-ID: <20240828112158.3538342-1-anirudh@anirudhrb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>