Changelog in Linux kernel 6.12.41

 
ALSA: hda/realtek - Add mute LED support for HP Pavilion 15-eg0xxx [+ + +]
Author: Dawid Rezler <[email protected]>
Date:   Sun Jul 20 17:49:08 2025 +0200

    ALSA: hda/realtek - Add mute LED support for HP Pavilion 15-eg0xxx
    
    commit 9744ede7099e8a69c04aa23fbea44c15bc390c04 upstream.
    
    The mute LED on the HP Pavilion Laptop 15-eg0xxx,
    which uses the ALC287 codec, didn't work.
    This patch fixes the issue by enabling the ALC287_FIXUP_HP_GPIO_LED quirk.
    
    Tested on a physical device, the LED now works as intended.
    
    Signed-off-by: Dawid Rezler <[email protected]>
    Cc: <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ALSA: hda/realtek - Add mute LED support for HP Victus 15-fa0xxx [+ + +]
Author: Edip Hazuri <[email protected]>
Date:   Fri Jul 18 00:26:26 2025 +0300

    ALSA: hda/realtek - Add mute LED support for HP Victus 15-fa0xxx
    
    commit 21c8ed9047b7f44c1c49b889d4ba2f555d9ee17e upstream.
    
    The mute led on this laptop is using ALC245 but requires a quirk to work
    This patch enables the existing quirk for the device.
    
    Tested on my Victus 15-fa0xxx Laptop. The LED behaviour works
    as intended.
    
    Cc: <[email protected]>
    Signed-off-by: Edip Hazuri <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ALSA: hda/realtek: Fix mute LED mask on HP OMEN 16 laptop [+ + +]
Author: SHARAN KUMAR M <[email protected]>
Date:   Tue Jul 22 22:52:24 2025 +0530

    ALSA: hda/realtek: Fix mute LED mask on HP OMEN 16 laptop
    
    [ Upstream commit 931837cd924048ab785eedb4cee5b276c90a2924 ]
    
    this patch is to fix my previous Commit <e5182305a519> i have fixed mute
    led but for by This patch corrects the coefficient mask value introduced
    in commit <e5182305a519>, which was intended to enable the mute LED
    functionality. During testing, multiple values were evaluated, and
    an incorrect value was mistakenly included in the final commit.
    This update fixes that error by applying the correct mask value for
    proper mute LED behavior.
    
    Tested on 6.15.5-arch1-1
    
    Fixes: e5182305a519 ("ALSA: hda/realtek: Enable Mute LED on HP OMEN 16 Laptop xd000xx")
    Signed-off-by: SHARAN KUMAR M <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: hda/tegra: Add Tegra264 support [+ + +]
Author: Mohan Kumar D <[email protected]>
Date:   Mon May 12 06:42:58 2025 +0000

    ALSA: hda/tegra: Add Tegra264 support
    
    commit 1c4193917eb3279788968639f24d72ffeebdec6b upstream.
    
    Update HDA driver to support Tegra264 differences from legacy HDA,
    which includes: clocks/resets, always power on, and hardware-managed
    FPCI/IPFS initialization. The driver retrieves this chip-specific
    information from soc_data.
    
    Signed-off-by: Mohan Kumar D <[email protected]>
    Signed-off-by: Sheetal <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Stable-dep-of: e0a911ac8685 ("ALSA: hda: Add missing NVIDIA HDA codec IDs")
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ALSA: hda: Add missing NVIDIA HDA codec IDs [+ + +]
Author: Daniel Dadap <[email protected]>
Date:   Thu Jun 26 16:16:30 2025 -0500

    ALSA: hda: Add missing NVIDIA HDA codec IDs
    
    commit e0a911ac86857a73182edde9e50d9b4b949b7f01 upstream.
    
    Add codec IDs for several NVIDIA products with HDA controllers to the
    snd_hda_id_hdmi[] patch table.
    
    Signed-off-by: Daniel Dadap <[email protected]>
    Cc: <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
arm64/entry: Mask DAIF in cpu_switch_to(), call_on_irq_stack() [+ + +]
Author: Ada Couprie Diaz <[email protected]>
Date:   Fri Jul 18 15:28:14 2025 +0100

    arm64/entry: Mask DAIF in cpu_switch_to(), call_on_irq_stack()
    
    commit d42e6c20de6192f8e4ab4cf10be8c694ef27e8cb upstream.
    
    `cpu_switch_to()` and `call_on_irq_stack()` manipulate SP to change
    to different stacks along with the Shadow Call Stack if it is enabled.
    Those two stack changes cannot be done atomically and both functions
    can be interrupted by SErrors or Debug Exceptions which, though unlikely,
    is very much broken : if interrupted, we can end up with mismatched stacks
    and Shadow Call Stack leading to clobbered stacks.
    
    In `cpu_switch_to()`, it can happen when SP_EL0 points to the new task,
    but x18 stills points to the old task's SCS. When the interrupt handler
    tries to save the task's SCS pointer, it will save the old task
    SCS pointer (x18) into the new task struct (pointed to by SP_EL0),
    clobbering it.
    
    In `call_on_irq_stack()`, it can happen when switching from the task stack
    to the IRQ stack and when switching back. In both cases, we can be
    interrupted when the SCS pointer points to the IRQ SCS, but SP points to
    the task stack. The nested interrupt handler pushes its return addresses
    on the IRQ SCS. It then detects that SP points to the task stack,
    calls `call_on_irq_stack()` and clobbers the task SCS pointer with
    the IRQ SCS pointer, which it will also use !
    
    This leads to tasks returning to addresses on the wrong SCS,
    or even on the IRQ SCS, triggering kernel panics via CONFIG_VMAP_STACK
    or FPAC if enabled.
    
    This is possible on a default config, but unlikely.
    However, when enabling CONFIG_ARM64_PSEUDO_NMI, DAIF is unmasked and
    instead the GIC is responsible for filtering what interrupts the CPU
    should receive based on priority.
    Given the goal of emulating NMIs, pseudo-NMIs can be received by the CPU
    even in `cpu_switch_to()` and `call_on_irq_stack()`, possibly *very*
    frequently depending on the system configuration and workload, leading
    to unpredictable kernel panics.
    
    Completely mask DAIF in `cpu_switch_to()` and restore it when returning.
    Do the same in `call_on_irq_stack()`, but restore and mask around
    the branch.
    Mask DAIF even if CONFIG_SHADOW_CALL_STACK is not enabled for consistency
    of behaviour between all configurations.
    
    Introduce and use an assembly macro for saving and masking DAIF,
    as the existing one saves but only masks IF.
    
    Cc: <[email protected]>
    Signed-off-by: Ada Couprie Diaz <[email protected]>
    Reported-by: Cristian Prundeanu <[email protected]>
    Fixes: 59b37fe52f49 ("arm64: Stash shadow stack pointer in the task struct on interrupt")
    Tested-by: Cristian Prundeanu <[email protected]>
    Acked-by: Will Deacon <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
arm64: dts: qcom: x1-crd: Fix vreg_l2j_1p2 voltage [+ + +]
Author: Stephan Gerhold <[email protected]>
Date:   Thu Jul 24 10:09:23 2025 -0400

    arm64: dts: qcom: x1-crd: Fix vreg_l2j_1p2 voltage
    
    [ Upstream commit 5ce920e6a8db40e4b094c0d863cbd19fdcfbbb7a ]
    
    In the ACPI DSDT table, PPP_RESOURCE_ID_LDO2_J is configured with 1256000
    uV instead of the 1200000 uV we have currently in the device tree. Use the
    same for consistency and correctness.
    
    Cc: [email protected]
    Fixes: bd50b1f5b6f3 ("arm64: dts: qcom: x1e80100: Add Compute Reference Device")
    Signed-off-by: Stephan Gerhold <[email protected]>
    Reviewed-by: Johan Hovold <[email protected]>
    Reviewed-by: Abel Vesa <[email protected]>
    Reviewed-by: Konrad Dybcio <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    [ Change x1e80100-crd.dts instead ]
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

arm64: dts: qcom: x1e78100-t14s: mark l12b and l15b always-on [+ + +]
Author: Johan Hovold <[email protected]>
Date:   Wed Jul 23 21:49:38 2025 -0400

    arm64: dts: qcom: x1e78100-t14s: mark l12b and l15b always-on
    
    [ Upstream commit 673fa129e558c5f1196adb27d97ac90ddfe4f19c ]
    
    The l12b and l15b supplies are used by components that are not (fully)
    described (and some never will be) and must never be disabled.
    
    Mark the regulators as always-on to prevent them from being disabled,
    for example, when consumers probe defer or suspend.
    
    Fixes: 7d1cbe2f4985 ("arm64: dts: qcom: Add X1E78100 ThinkPad T14s Gen 6")
    Cc: [email protected]      # 6.12
    Reviewed-by: Konrad Dybcio <[email protected]>
    Signed-off-by: Johan Hovold <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    [ applied changes to .dts file instead of .dtsi ]
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ARM: 9448/1: Use an absolute path to unified.h in KBUILD_AFLAGS [+ + +]
Author: Nathan Chancellor <[email protected]>
Date:   Mon Jul 28 10:16:34 2025 -0400

    ARM: 9448/1: Use an absolute path to unified.h in KBUILD_AFLAGS
    
    [ Upstream commit 87c4e1459e80bf65066f864c762ef4dc932fad4b ]
    
    After commit d5c8d6e0fa61 ("kbuild: Update assembler calls to use proper
    flags and language target"), which updated as-instr to use the
    'assembler-with-cpp' language option, the Kbuild version of as-instr
    always fails internally for arch/arm with
    
      <command-line>: fatal error: asm/unified.h: No such file or directory
      compilation terminated.
    
    because '-include' flags are now taken into account by the compiler
    driver and as-instr does not have '$(LINUXINCLUDE)', so unified.h is not
    found.
    
    This went unnoticed at the time of the Kbuild change because the last
    use of as-instr in Kbuild that arch/arm could reach was removed in 5.7
    by commit 541ad0150ca4 ("arm: Remove 32bit KVM host support") but a
    stable backport of the Kbuild change to before that point exposed this
    potential issue if one were to be reintroduced.
    
    Follow the general pattern of '-include' paths throughout the tree and
    make unified.h absolute using '$(srctree)' to ensure KBUILD_AFLAGS can
    be used independently.
    
    Closes: https://lore.kernel.org/CACo-S-1qbCX4WAVFA63dWfHtrRHZBTyyr2js8Lx=Az03XHTTHg@mail.gmail.com/
    
    Cc: [email protected]
    Fixes: d5c8d6e0fa61 ("kbuild: Update assembler calls to use proper flags and language target")
    Reported-by: KernelCI bot <[email protected]>
    Reviewed-by: Masahiro Yamada <[email protected]>
    Signed-off-by: Nathan Chancellor <[email protected]>
    Signed-off-by: Russell King (Oracle) <[email protected]>
    [ No KBUILD_RUSTFLAGS in 6.12 ]
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ARM: 9450/1: Fix allowing linker DCE with binutils < 2.36 [+ + +]
Author: Nathan Chancellor <[email protected]>
Date:   Mon Jul 14 20:56:47 2025 +0100

    ARM: 9450/1: Fix allowing linker DCE with binutils < 2.36
    
    commit 53e7e1fb81cc8ba2da1cb31f8917ef397caafe91 upstream.
    
    Commit e7607f7d6d81 ("ARM: 9443/1: Require linker to support KEEP within
    OVERLAY for DCE") accidentally broke the binutils version restriction
    that was added in commit 0d437918fb64 ("ARM: 9414/1: Fix build issue
    with LD_DEAD_CODE_DATA_ELIMINATION"), reintroducing the segmentation
    fault addressed by that workaround.
    
    Restore the binutils version dependency by using
    CONFIG_LD_CAN_USE_KEEP_IN_OVERLAY as an additional condition to ensure
    that CONFIG_HAVE_LD_DEAD_CODE_DATA_ELIMINATION is only enabled with
    binutils >= 2.36 and ld.lld >= 21.0.0.
    
    Closes: https://lore.kernel.org/[email protected]/
    Closes: https://lore.kernel.org/CAFERDQ0zPoya5ZQfpbeuKVZEo_fKsonLf6tJbp32QnSGAtbi+Q@mail.gmail.com/
    
    Cc: [email protected]
    Fixes: e7607f7d6d81 ("ARM: 9443/1: Require linker to support KEEP within OVERLAY for DCE")
    Reported-by: Rob Landley <[email protected]>
    Tested-by: Rob Landley <[email protected]>
    Reported-by: Martin Wetterwald <[email protected]>
    Signed-off-by: Nathan Chancellor <[email protected]>
    Signed-off-by: Russell King (Oracle) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ASoC: mediatek: mt8365-dai-i2s: pass correct size to mt8365_dai_set_priv [+ + +]
Author: Guoqing Jiang <[email protected]>
Date:   Thu Jul 10 09:18:06 2025 +0800

    ASoC: mediatek: mt8365-dai-i2s: pass correct size to mt8365_dai_set_priv
    
    [ Upstream commit 6bea85979d05470e6416a2bb504a9bcd9178304c ]
    
    Given mt8365_dai_set_priv allocate priv_size space to copy priv_data which
    means we should pass mt8365_i2s_priv[i] or "struct mtk_afe_i2s_priv"
    instead of afe_priv which has the size of "struct mt8365_afe_private".
    
    Otherwise the KASAN complains about.
    
    [   59.389765] BUG: KASAN: global-out-of-bounds in mt8365_dai_set_priv+0xc8/0x168 [snd_soc_mt8365_pcm]
    ...
    [   59.394789] Call trace:
    [   59.395167]  dump_backtrace+0xa0/0x128
    [   59.395733]  show_stack+0x20/0x38
    [   59.396238]  dump_stack_lvl+0xe8/0x148
    [   59.396806]  print_report+0x37c/0x5e0
    [   59.397358]  kasan_report+0xac/0xf8
    [   59.397885]  kasan_check_range+0xe8/0x190
    [   59.398485]  asan_memcpy+0x3c/0x98
    [   59.399022]  mt8365_dai_set_priv+0xc8/0x168 [snd_soc_mt8365_pcm]
    [   59.399928]  mt8365_dai_i2s_register+0x1e8/0x2b0 [snd_soc_mt8365_pcm]
    [   59.400893]  mt8365_afe_pcm_dev_probe+0x4d0/0xdf0 [snd_soc_mt8365_pcm]
    [   59.401873]  platform_probe+0xcc/0x228
    [   59.402442]  really_probe+0x340/0x9e8
    [   59.402992]  driver_probe_device+0x16c/0x3f8
    [   59.403638]  driver_probe_device+0x64/0x1d8
    [   59.404256]  driver_attach+0x1dc/0x4c8
    [   59.404840]  bus_for_each_dev+0x100/0x190
    [   59.405442]  driver_attach+0x44/0x68
    [   59.405980]  bus_add_driver+0x23c/0x500
    [   59.406550]  driver_register+0xf8/0x3d0
    [   59.407122]  platform_driver_register+0x68/0x98
    [   59.407810]  mt8365_afe_pcm_driver_init+0x2c/0xff8 [snd_soc_mt8365_pcm]
    
    Fixes: 402bbb13a195 ("ASoC: mediatek: mt8365: Add I2S DAI support")
    Signed-off-by: Guoqing Jiang <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
bus: fsl-mc: Fix potential double device reference in fsl_mc_get_endpoint() [+ + +]
Author: Ma Ke <[email protected]>
Date:   Thu Jul 17 10:23:07 2025 +0800

    bus: fsl-mc: Fix potential double device reference in fsl_mc_get_endpoint()
    
    commit bddbe13d36a02d5097b99cf02354d5752ad1ac60 upstream.
    
    The fsl_mc_get_endpoint() function may call fsl_mc_device_lookup()
    twice, which would increment the device's reference count twice if
    both lookups find a device. This could lead to a reference count leak.
    
    Found by code review.
    
    Cc: [email protected]
    Fixes: 1ac210d128ef ("bus: fsl-mc: add the fsl_mc_get_endpoint function")
    Signed-off-by: Ma Ke <[email protected]>
    Tested-by: Ioana Ciornei <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Fixes: 8567494cebe5 ("bus: fsl-mc: rescan devices if endpoint not found")
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
can: netlink: can_changelink(): fix NULL pointer deref of struct can_priv::do_set_mode [+ + +]
Author: Marc Kleine-Budde <[email protected]>
Date:   Tue Jul 15 22:35:46 2025 +0200

    can: netlink: can_changelink(): fix NULL pointer deref of struct can_priv::do_set_mode
    
    [ Upstream commit c1f3f9797c1f44a762e6f5f72520b2e520537b52 ]
    
    Andrei Lalaev reported a NULL pointer deref when a CAN device is
    restarted from Bus Off and the driver does not implement the struct
    can_priv::do_set_mode callback.
    
    There are 2 code path that call struct can_priv::do_set_mode:
    - directly by a manual restart from the user space, via
      can_changelink()
    - delayed automatic restart after bus off (deactivated by default)
    
    To prevent the NULL pointer deference, refuse a manual restart or
    configure the automatic restart delay in can_changelink() and report
    the error via extack to user space.
    
    As an additional safety measure let can_restart() return an error if
    can_priv::do_set_mode is not set instead of dereferencing it
    unchecked.
    
    Reported-by: Andrei Lalaev <[email protected]>
    Closes: https://lore.kernel.org/all/[email protected]
    Fixes: 39549eef3587 ("can: CAN Network device driver and Netlink interface")
    Link: https://patch.msgid.link/20250718-fix-nullptr-deref-do_set_mode-v1-1-0b520097bb96@pengutronix.de
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
comedi: comedi_test: Fix possible deletion of uninitialized timers [+ + +]
Author: Ian Abbott <[email protected]>
Date:   Tue Jul 8 14:06:27 2025 +0100

    comedi: comedi_test: Fix possible deletion of uninitialized timers
    
    commit 1b98304c09a0192598d0767f1eb8c83d7e793091 upstream.
    
    In `waveform_common_attach()`, the two timers `&devpriv->ai_timer` and
    `&devpriv->ao_timer` are initialized after the allocation of the device
    private data by `comedi_alloc_devpriv()` and the subdevices by
    `comedi_alloc_subdevices()`.  The function may return with an error
    between those function calls.  In that case, `waveform_detach()` will be
    called by the Comedi core to clean up.  The check that
    `waveform_detach()` uses to decide whether to delete the timers is
    incorrect.  It only checks that the device private data was allocated,
    but that does not guarantee that the timers were initialized.  It also
    needs to check that the subdevices were allocated.  Fix it.
    
    Fixes: 73e0e4dfed4c ("staging: comedi: comedi_test: fix timer lock-up")
    Cc: [email protected] # 6.15+
    Signed-off-by: Ian Abbott <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [ changed timer_delete_sync() to del_timer_sync() ]
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
crypto: powerpc/poly1305 - add depends on BROKEN for now [+ + +]
Author: Eric Biggers <[email protected]>
Date:   Wed Jul 23 22:49:21 2025 -0400

    crypto: powerpc/poly1305 - add depends on BROKEN for now
    
    [ Upstream commit bc8169003b41e89fe7052e408cf9fdbecb4017fe ]
    
    As discussed in the thread containing
    https://lore.kernel.org/linux-crypto/20250510053308.GB505731@sol/, the
    Power10-optimized Poly1305 code is currently not safe to call in softirq
    context.  Disable it for now.  It can be re-enabled once it is fixed.
    
    Fixes: ba8f8624fde2 ("crypto: poly1305-p10 - Glue code for optmized Poly1305 implementation for ppc64le")
    Cc: [email protected]
    Signed-off-by: Eric Biggers <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    [ applied to arch/powerpc/crypto/Kconfig ]
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
dpaa2-eth: Fix device reference count leak in MAC endpoint handling [+ + +]
Author: Ma Ke <[email protected]>
Date:   Thu Jul 17 10:23:08 2025 +0800

    dpaa2-eth: Fix device reference count leak in MAC endpoint handling
    
    commit ee9f3a81ab08dfe0538dbd1746f81fd4d5147fdc upstream.
    
    The fsl_mc_get_endpoint() function uses device_find_child() for
    localization, which implicitly calls get_device() to increment the
    device's reference count before returning the pointer. However, the
    caller dpaa2_eth_connect_mac() fails to properly release this
    reference in multiple scenarios. We should call put_device() to
    decrement reference count properly.
    
    As comment of device_find_child() says, 'NOTE: you will need to drop
    the reference with put_device() after use'.
    
    Found by code review.
    
    Cc: [email protected]
    Fixes: 719479230893 ("dpaa2-eth: add MAC/PHY support through phylink")
    Signed-off-by: Ma Ke <[email protected]>
    Tested-by: Ioana Ciornei <[email protected]>
    Reviewed-by: Ioana Ciornei <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
dpaa2-switch: Fix device reference count leak in MAC endpoint handling [+ + +]
Author: Ma Ke <[email protected]>
Date:   Thu Jul 17 10:23:09 2025 +0800

    dpaa2-switch: Fix device reference count leak in MAC endpoint handling
    
    commit 96e056ffba912ef18a72177f71956a5b347b5177 upstream.
    
    The fsl_mc_get_endpoint() function uses device_find_child() for
    localization, which implicitly calls get_device() to increment the
    device's reference count before returning the pointer. However, the
    caller dpaa2_switch_port_connect_mac() fails to properly release this
    reference in multiple scenarios. We should call put_device() to
    decrement reference count properly.
    
    As comment of device_find_child() says, 'NOTE: you will need to drop
    the reference with put_device() after use'.
    
    Found by code review.
    
    Cc: [email protected]
    Fixes: 84cba72956fd ("dpaa2-switch: integrate the MAC endpoint support")
    Signed-off-by: Ma Ke <[email protected]>
    Tested-by: Ioana Ciornei <[email protected]>
    Reviewed-by: Ioana Ciornei <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Drivers: hv: Make the sysfs node size for the ring buffer dynamic [+ + +]
Author: Naman Jain <[email protected]>
Date:   Fri May 2 13:18:11 2025 +0530

    Drivers: hv: Make the sysfs node size for the ring buffer dynamic
    
    commit 65995e97a1caacf0024bebda3332b8d1f0f443c4 upstream.
    
    The ring buffer size varies across VMBus channels. The size of sysfs
    node for the ring buffer is currently hardcoded to 4 MB. Userspace
    clients either use fstat() or hardcode this size for doing mmap().
    To address this, make the sysfs node size dynamic to reflect the
    actual ring buffer size for each channel. This will ensure that
    fstat() on ring sysfs node always returns the correct size of
    ring buffer.
    
    Reviewed-by: Michael Kelley <[email protected]>
    Tested-by: Michael Kelley <[email protected]>
    Reviewed-by: Dexuan Cui <[email protected]>
    Signed-off-by: Naman Jain <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [ The structure "struct attribute_group" does not have bin_size field in
      v6.12.x kernel so the logic of configuring size of sysfs node for ring buffer
      has been moved to vmbus_chan_bin_attr_is_visible().
      Original change was not a fix, but it needs to be backported to fix size
      related discrepancy caused by the commit mentioned in Fixes tag. ]
    Signed-off-by: Naman Jain <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/amdgpu: Reset the clear flag in buddy during resume [+ + +]
Author: Arunpravin Paneer Selvam <[email protected]>
Date:   Wed Jul 16 13:21:24 2025 +0530

    drm/amdgpu: Reset the clear flag in buddy during resume
    
    commit 95a16160ca1d75c66bf7a1c5e0bcaffb18e7c7fc upstream.
    
    - Added a handler in DRM buddy manager to reset the cleared
      flag for the blocks in the freelist.
    
    - This is necessary because, upon resuming, the VRAM becomes
      cluttered with BIOS data, yet the VRAM backend manager
      believes that everything has been cleared.
    
    v2:
      - Add lock before accessing drm_buddy_clear_reset_blocks()(Matthew Auld)
      - Force merge the two dirty blocks.(Matthew Auld)
      - Add a new unit test case for this issue.(Matthew Auld)
      - Having this function being able to flip the state either way would be
        good. (Matthew Brost)
    
    v3(Matthew Auld):
      - Do merge step first to avoid the use of extra reset flag.
    
    Signed-off-by: Arunpravin Paneer Selvam <[email protected]>
    Suggested-by: Christian König <[email protected]>
    Acked-by: Christian König <[email protected]>
    Reviewed-by: Matthew Auld <[email protected]>
    Cc: [email protected]
    Fixes: a68c7eaa7a8f ("drm/amdgpu: Enable clear page functionality")
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3812
    Signed-off-by: Christian König <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/bridge: ti-sn65dsi86: Remove extra semicolon in ti_sn_bridge_probe() [+ + +]
Author: Douglas Anderson <[email protected]>
Date:   Mon Jul 14 13:06:32 2025 -0700

    drm/bridge: ti-sn65dsi86: Remove extra semicolon in ti_sn_bridge_probe()
    
    [ Upstream commit 15a7ca747d9538c2ad8b0c81dd4c1261e0736c82 ]
    
    As reported by the kernel test robot, a recent patch introduced an
    unnecessary semicolon. Remove it.
    
    Fixes: 55e8ff842051 ("drm/bridge: ti-sn65dsi86: Add HPD for DisplayPort connector type")
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
    Reviewed-by: Devarsh Thakkar <[email protected]>
    Signed-off-by: Douglas Anderson <[email protected]>
    Link: https://lore.kernel.org/r/20250714130631.1.I1cfae3222e344a3b3c770d079ee6b6f7f3b5d636@changeid
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/i915/dp: Fix 2.7 Gbps DP_LINK_BW value on g4x [+ + +]
Author: Ville Syrjälä <[email protected]>
Date:   Thu Jul 10 23:17:12 2025 +0300

    drm/i915/dp: Fix 2.7 Gbps DP_LINK_BW value on g4x
    
    commit 9e0c433d0c05fde284025264b89eaa4ad59f0a3e upstream.
    
    On g4x we currently use the 96MHz non-SSC refclk, which can't actually
    generate an exact 2.7 Gbps link rate. In practice we end up with 2.688
    Gbps which seems to be close enough to actually work, but link training
    is currently failing due to miscalculating the DP_LINK_BW value (we
    calcualte it directly from port_clock which reflects the actual PLL
    outpout frequency).
    
    Ideas how to fix this:
    - nudge port_clock back up to 270000 during PLL computation/readout
    - track port_clock and the nominal link rate separately so they might
      differ a bit
    - switch to the 100MHz refclk, but that one should be SSC so perhaps
      not something we want
    
    While we ponder about a better solution apply some band aid to the
    immediate issue of miscalculated DP_LINK_BW value. With this
    I can again use 2.7 Gbps link rate on g4x.
    
    Cc: [email protected]
    Fixes: 665a7b04092c ("drm/i915: Feed the DPLL output freq back into crtc_state")
    Signed-off-by: Ville Syrjälä <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Reviewed-by: Imre Deak <[email protected]>
    (cherry picked from commit a8b874694db5cae7baaf522756f87acd956e6e66)
    Signed-off-by: Rodrigo Vivi <[email protected]>
    [ changed display->platform.g4x to IS_G4X(i915) ]
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/sched: Remove optimization that causes hang when killing dependent jobs [+ + +]
Author: Lin.Cao <[email protected]>
Date:   Thu Jul 17 16:44:53 2025 +0800

    drm/sched: Remove optimization that causes hang when killing dependent jobs
    
    commit 15f77764e90a713ee3916ca424757688e4f565b9 upstream.
    
    When application A submits jobs and application B submits a job with a
    dependency on A's fence, the normal flow wakes up the scheduler after
    processing each job. However, the optimization in
    drm_sched_entity_add_dependency_cb() uses a callback that only clears
    dependencies without waking up the scheduler.
    
    When application A is killed before its jobs can run, the callback gets
    triggered but only clears the dependency without waking up the scheduler,
    causing the scheduler to enter sleep state and application B to hang.
    
    Remove the optimization by deleting drm_sched_entity_clear_dep() and its
    usage, ensuring the scheduler is always woken up when dependencies are
    cleared.
    
    Fixes: 777dbd458c89 ("drm/amdgpu: drop a dummy wakeup scheduler")
    Cc: [email protected] # v4.6+
    Signed-off-by: Lin.Cao <[email protected]>
    Reviewed-by: Christian König <[email protected]>
    Signed-off-by: Philipp Stanner <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
e1000e: disregard NVM checksum on tgp when valid checksum bit is not set [+ + +]
Author: Jacek Kowalski <[email protected]>
Date:   Mon Jun 30 10:33:39 2025 +0200

    e1000e: disregard NVM checksum on tgp when valid checksum bit is not set
    
    commit 536fd741c7ac907d63166cdae1081b1febfab613 upstream.
    
    As described by Vitaly Lifshits:
    
    > Starting from Tiger Lake, LAN NVM is locked for writes by SW, so the
    > driver cannot perform checksum validation and correction. This means
    > that all NVM images must leave the factory with correct checksum and
    > checksum valid bit set. Since Tiger Lake devices were the first to have
    > this lock, some systems in the field did not meet this requirement.
    > Therefore, for these transitional devices we skip checksum update and
    > verification, if the valid bit is not set.
    
    Signed-off-by: Jacek Kowalski <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Reviewed-by: Vitaly Lifshits <[email protected]>
    Fixes: 4051f68318ca9 ("e1000e: Do not take care about recovery NVM checksum")
    Cc: [email protected]
    Tested-by: Mor Bar-Gabay <[email protected]>
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

e1000e: ignore uninitialized checksum word on tgp [+ + +]
Author: Jacek Kowalski <[email protected]>
Date:   Mon Jun 30 10:35:00 2025 +0200

    e1000e: ignore uninitialized checksum word on tgp
    
    commit 61114910a5f6a71d0b6ea3b95082dfe031b19dfe upstream.
    
    As described by Vitaly Lifshits:
    
    > Starting from Tiger Lake, LAN NVM is locked for writes by SW, so the
    > driver cannot perform checksum validation and correction. This means
    > that all NVM images must leave the factory with correct checksum and
    > checksum valid bit set.
    
    Unfortunately some systems have left the factory with an uninitialized
    value of 0xFFFF at register address 0x3F (checksum word location).
    So on Tiger Lake platform we ignore the computed checksum when such
    condition is encountered.
    
    Signed-off-by: Jacek Kowalski <[email protected]>
    Tested-by: Vlad URSU <[email protected]>
    Fixes: 4051f68318ca9 ("e1000e: Do not take care about recovery NVM checksum")
    Cc: [email protected]
    Reviewed-by: Simon Horman <[email protected]>
    Reviewed-by: Vitaly Lifshits <[email protected]>
    Tested-by: Mor Bar-Gabay <[email protected]>
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
erofs: clean up header parsing for ztailpacking and fragments [+ + +]
Author: Gao Xiang <[email protected]>
Date:   Wed Jul 23 09:50:08 2025 -0400

    erofs: clean up header parsing for ztailpacking and fragments
    
    [ Upstream commit 540787d38b10dbc16a7d2bc2845752ab1605403a ]
    
    Simplify the logic in z_erofs_fill_inode_lazy() by combining the
    handling of ztailpacking and fragments, as they are mutually exclusive.
    
    Note that `h->h_clusterbits >> Z_EROFS_FRAGMENT_INODE_BIT` is handled
    above, so no need to duplicate the check.
    
    Reviewed-by: Chao Yu <[email protected]>
    Signed-off-by: Gao Xiang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Stable-dep-of: b44686c8391b ("erofs: fix large fragment handling")
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

erofs: fix large fragment handling [+ + +]
Author: Gao Xiang <[email protected]>
Date:   Wed Jul 23 09:50:09 2025 -0400

    erofs: fix large fragment handling
    
    [ Upstream commit b44686c8391b427fb1c85a31c35077e6947c6d90 ]
    
    Fragments aren't limited by Z_EROFS_PCLUSTER_MAX_DSIZE. However, if
    a fragment's logical length is larger than Z_EROFS_PCLUSTER_MAX_DSIZE
    but the fragment is not the whole inode, it currently returns
    -EOPNOTSUPP because m_flags has the wrong EROFS_MAP_ENCODED flag set.
    It is not intended by design but should be rare, as it can only be
    reproduced by mkfs with `-Eall-fragments` in a specific case.
    
    Let's normalize fragment m_flags using the new EROFS_MAP_FRAGMENT.
    
    Reported-by: Axel Fontaine <[email protected]>
    Closes: https://github.com/erofs/erofs-utils/issues/23
    Fixes: 7c3ca1838a78 ("erofs: restrict pcluster size limitations")
    Signed-off-by: Gao Xiang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

erofs: refine z_erofs_get_extent_compressedlen() [+ + +]
Author: Gao Xiang <[email protected]>
Date:   Wed Jul 23 09:50:05 2025 -0400

    erofs: refine z_erofs_get_extent_compressedlen()
    
    [ Upstream commit 8f9530aeeb4f756bdfa70510b40e5d28ea3c742e ]
    
     - Set `compressedblks = 1` directly for non-bigpcluster cases.  This
       simplifies the logic a bit since lcluster sizes larger than one block
       are unsupported and the details remain unclear.
    
     - For Z_EROFS_LCLUSTER_TYPE_PLAIN pclusters, avoid assuming
       `compressedblks = 1` by default.  Instead, check if
       Z_EROFS_ADVISE_BIG_PCLUSTER_2 is set.
    
    It basically has no impact to existing valid images, but it's useful to
    find the gap to prepare for large PLAIN pclusters.
    
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Gao Xiang <[email protected]>
    Stable-dep-of: b44686c8391b ("erofs: fix large fragment handling")
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

erofs: simplify tail inline pcluster handling [+ + +]
Author: Gao Xiang <[email protected]>
Date:   Wed Jul 23 09:50:07 2025 -0400

    erofs: simplify tail inline pcluster handling
    
    [ Upstream commit b7710262d743aca112877d12abed61ce8a5d0d98 ]
    
    Use `z_idata_size != 0` to indicate that ztailpacking is enabled.
    `Z_EROFS_ADVISE_INLINE_PCLUSTER` cannot be ignored, as `h_idata_size`
    could be non-zero prior to erofs-utils 1.6 [1].
    
    Additionally, merge `z_idataoff` and `z_fragmentoff` since these two
    features are mutually exclusive for a given inode.
    
    [1] https://git.kernel.org/xiang/erofs-utils/c/547bea3cb71a
    Reviewed-by: Chao Yu <[email protected]>
    Signed-off-by: Gao Xiang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Stable-dep-of: b44686c8391b ("erofs: fix large fragment handling")
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

erofs: simplify z_erofs_load_compact_lcluster() [+ + +]
Author: Gao Xiang <[email protected]>
Date:   Wed Jul 23 09:50:04 2025 -0400

    erofs: simplify z_erofs_load_compact_lcluster()
    
    [ Upstream commit 2a810ea79cd7a6d5f134ea69ca2ba726e600cbc4 ]
    
     - Get rid of unpack_compacted_index() and fold it into
       z_erofs_load_compact_lcluster();
    
     - Avoid a goto.
    
    Reviewed-by: Chao Yu <[email protected]>
    Signed-off-by: Gao Xiang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Stable-dep-of: b44686c8391b ("erofs: fix large fragment handling")
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

erofs: use Z_EROFS_LCLUSTER_TYPE_MAX to simplify switches [+ + +]
Author: Hongzhen Luo <[email protected]>
Date:   Wed Jul 23 09:50:06 2025 -0400

    erofs: use Z_EROFS_LCLUSTER_TYPE_MAX to simplify switches
    
    [ Upstream commit 3b7781aeaefb627d4e07c1af9be923f9e8047d8b ]
    
    There's no need to enumerate each type.  No logic changes.
    
    Signed-off-by: Hongzhen Luo <[email protected]>
    Reviewed-by: Gao Xiang <[email protected]>
    Reviewed-by: Chao Yu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Gao Xiang <[email protected]>
    Stable-dep-of: b44686c8391b ("erofs: fix large fragment handling")
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ext4: correct the error handle in ext4_fallocate() [+ + +]
Author: Zhang Yi <[email protected]>
Date:   Wed Jul 23 22:57:17 2025 -0400

    ext4: correct the error handle in ext4_fallocate()
    
    [ Upstream commit 129245cfbd6d79c6d603f357f428010ccc0f0ee7 ]
    
    The error out label of file_modified() should be out_inode_lock in
    ext4_fallocate().
    
    Fixes: 2890e5e0f49e ("ext4: move out common parts into ext4_fallocate()")
    Reported-by: Baokun Li <[email protected]>
    Signed-off-by: Zhang Yi <[email protected]>
    Reviewed-by: Baokun Li <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ext4: don't explicit update times in ext4_fallocate() [+ + +]
Author: Zhang Yi <[email protected]>
Date:   Wed Jul 23 22:57:08 2025 -0400

    ext4: don't explicit update times in ext4_fallocate()
    
    [ Upstream commit 73ae756ecdfa9684446134590eef32b0f067249c ]
    
    After commit 'ad5cd4f4ee4d ("ext4: fix fallocate to use file_modified to
    update permissions consistently"), we can update mtime and ctime
    appropriately through file_modified() when doing zero range, collapse
    rage, insert range and punch hole, hence there is no need to explicit
    update times in those paths, just drop them.
    
    Signed-off-by: Zhang Yi <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Reviewed-by: Ojaswin Mujoo <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Stable-dep-of: 29ec9bed2395 ("ext4: fix incorrect punch max_end")
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ext4: factor out ext4_do_fallocate() [+ + +]
Author: Zhang Yi <[email protected]>
Date:   Wed Jul 23 22:57:13 2025 -0400

    ext4: factor out ext4_do_fallocate()
    
    [ Upstream commit fd2f764826df5489b849a8937b5a093aae5b1816 ]
    
    Now the real job of normal fallocate are open coded in ext4_fallocate(),
    factor out a new helper ext4_do_fallocate() to do the real job, like
    others functions (e.g. ext4_zero_range()) in ext4_fallocate() do, this
    can make the code more clear, no functional changes.
    
    Signed-off-by: Zhang Yi <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Reviewed-by: Ojaswin Mujoo <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Stable-dep-of: 29ec9bed2395 ("ext4: fix incorrect punch max_end")
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ext4: fix incorrect punch max_end [+ + +]
Author: Zhang Yi <[email protected]>
Date:   Wed Jul 23 22:57:16 2025 -0400

    ext4: fix incorrect punch max_end
    
    [ Upstream commit 29ec9bed2395061350249ae356fb300dd82a78e7 ]
    
    For the extents based inodes, the maxbytes should be sb->s_maxbytes
    instead of sbi->s_bitmap_maxbytes. Additionally, for the calculation of
    max_end, the -sb->s_blocksize operation is necessary only for
    indirect-block based inodes. Correct the maxbytes and max_end value to
    correct the behavior of punch hole.
    
    Fixes: 2da376228a24 ("ext4: limit length to bitmap_maxbytes - blocksize in punch_hole")
    Signed-off-by: Zhang Yi <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Reviewed-by: Baokun Li <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Cc: [email protected]
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ext4: fix out of bounds punch offset [+ + +]
Author: Zhang Yi <[email protected]>
Date:   Wed Jul 23 22:57:18 2025 -0400

    ext4: fix out of bounds punch offset
    
    [ Upstream commit b5e58bcd79625423487fa3ecba8e8411b5396327 ]
    
    Punching a hole with a start offset that exceeds max_end is not
    permitted and will result in a negative length in the
    truncate_inode_partial_folio() function while truncating the page cache,
    potentially leading to undesirable consequences.
    
    A simple reproducer:
    
      truncate -s 9895604649994 /mnt/foo
      xfs_io -c "pwrite 8796093022208 4096" /mnt/foo
      xfs_io -c "fpunch 8796093022213 25769803777" /mnt/foo
    
      kernel BUG at include/linux/highmem.h:275!
      Oops: invalid opcode: 0000 [#1] SMP PTI
      CPU: 3 UID: 0 PID: 710 Comm: xfs_io Not tainted 6.15.0-rc3
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
      RIP: 0010:zero_user_segments.constprop.0+0xd7/0x110
      RSP: 0018:ffffc90001cf3b38 EFLAGS: 00010287
      RAX: 0000000000000005 RBX: ffffea0001485e40 RCX: 0000000000001000
      RDX: 000000000040b000 RSI: 0000000000000005 RDI: 000000000040b000
      RBP: 000000000040affb R08: ffff888000000000 R09: ffffea0000000000
      R10: 0000000000000003 R11: 00000000fffc7fc5 R12: 0000000000000005
      R13: 000000000040affb R14: ffffea0001485e40 R15: ffff888031cd3000
      FS:  00007f4f63d0b780(0000) GS:ffff8880d337d000(0000)
      knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 000000001ae0b038 CR3: 00000000536aa000 CR4: 00000000000006f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       <TASK>
       truncate_inode_partial_folio+0x3dd/0x620
       truncate_inode_pages_range+0x226/0x720
       ? bdev_getblk+0x52/0x3e0
       ? ext4_get_group_desc+0x78/0x150
       ? crc32c_arch+0xfd/0x180
       ? __ext4_get_inode_loc+0x18c/0x840
       ? ext4_inode_csum+0x117/0x160
       ? jbd2_journal_dirty_metadata+0x61/0x390
       ? __ext4_handle_dirty_metadata+0xa0/0x2b0
       ? kmem_cache_free+0x90/0x5a0
       ? jbd2_journal_stop+0x1d5/0x550
       ? __ext4_journal_stop+0x49/0x100
       truncate_pagecache_range+0x50/0x80
       ext4_truncate_page_cache_block_range+0x57/0x3a0
       ext4_punch_hole+0x1fe/0x670
       ext4_fallocate+0x792/0x17d0
       ? __count_memcg_events+0x175/0x2a0
       vfs_fallocate+0x121/0x560
       ksys_fallocate+0x51/0xc0
       __x64_sys_fallocate+0x24/0x40
       x64_sys_call+0x18d2/0x4170
       do_syscall_64+0xa7/0x220
       entry_SYSCALL_64_after_hwframe+0x76/0x7e
    
    Fix this by filtering out cases where the punching start offset exceeds
    max_end.
    
    Fixes: 982bf37da09d ("ext4: refactor ext4_punch_hole()")
    Reported-by: Liebes Wang <[email protected]>
    Closes: https://lore.kernel.org/linux-ext4/[email protected]/
    Tested-by: Liebes Wang <[email protected]>
    Signed-off-by: Zhang Yi <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Reviewed-by: Baokun Li <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Cc: [email protected]
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ext4: move out common parts into ext4_fallocate() [+ + +]
Author: Zhang Yi <[email protected]>
Date:   Wed Jul 23 22:57:15 2025 -0400

    ext4: move out common parts into ext4_fallocate()
    
    [ Upstream commit 2890e5e0f49e10f3dadc5f7b7ea434e3e77e12a6 ]
    
    Currently, all zeroing ranges, punch holes, collapse ranges, and insert
    ranges first wait for all existing direct I/O workers to complete, and
    then they acquire the mapping's invalidate lock before performing the
    actual work. These common components are nearly identical, so we can
    simplify the code by factoring them out into the ext4_fallocate().
    
    Signed-off-by: Zhang Yi <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Reviewed-by: Ojaswin Mujoo <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Stable-dep-of: 29ec9bed2395 ("ext4: fix incorrect punch max_end")
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ext4: move out inode_lock into ext4_fallocate() [+ + +]
Author: Zhang Yi <[email protected]>
Date:   Wed Jul 23 22:57:14 2025 -0400

    ext4: move out inode_lock into ext4_fallocate()
    
    [ Upstream commit ea3f17efd36b56c5839289716ba83eaa85893590 ]
    
    Currently, all five sub-functions of ext4_fallocate() acquire the
    inode's i_rwsem at the beginning and release it before exiting. This
    process can be simplified by factoring out the management of i_rwsem
    into the ext4_fallocate() function.
    
    Signed-off-by: Zhang Yi <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Reviewed-by: Ojaswin Mujoo <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Stable-dep-of: 29ec9bed2395 ("ext4: fix incorrect punch max_end")
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ext4: refactor ext4_collapse_range() [+ + +]
Author: Zhang Yi <[email protected]>
Date:   Wed Jul 23 22:57:11 2025 -0400

    ext4: refactor ext4_collapse_range()
    
    [ Upstream commit 162e3c5ad1672ef41dccfb28ad198c704b8aa9e7 ]
    
    Simplify ext4_collapse_range() and align its code style with that of
    ext4_zero_range() and ext4_punch_hole(). Refactor it by: a) renaming
    variables, b) removing redundant input parameter checks and moving
    the remaining checks under i_rwsem in preparation for future
    refactoring, and c) renaming the three stale error tags.
    
    Signed-off-by: Zhang Yi <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Reviewed-by: Ojaswin Mujoo <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Stable-dep-of: 29ec9bed2395 ("ext4: fix incorrect punch max_end")
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ext4: refactor ext4_insert_range() [+ + +]
Author: Zhang Yi <[email protected]>
Date:   Wed Jul 23 22:57:12 2025 -0400

    ext4: refactor ext4_insert_range()
    
    [ Upstream commit 49425504376c335c68f7be54ae7c32312afd9475 ]
    
    Simplify ext4_insert_range() and align its code style with that of
    ext4_collapse_range(). Refactor it by: a) renaming variables, b)
    removing redundant input parameter checks and moving the remaining
    checks under i_rwsem in preparation for future refactoring, and c)
    renaming the three stale error tags.
    
    Signed-off-by: Zhang Yi <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Reviewed-by: Ojaswin Mujoo <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Stable-dep-of: 29ec9bed2395 ("ext4: fix incorrect punch max_end")
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ext4: refactor ext4_punch_hole() [+ + +]
Author: Zhang Yi <[email protected]>
Date:   Wed Jul 23 22:57:09 2025 -0400

    ext4: refactor ext4_punch_hole()
    
    [ Upstream commit 982bf37da09d078570650b691d9084f43805a5de ]
    
    The current implementation of ext4_punch_hole() contains complex
    position calculations and stale error tags. To improve the code's
    clarity and maintainability, it is essential to clean up the code and
    improve its readability, this can be achieved by: a) simplifying and
    renaming variables; b) eliminating unnecessary position calculations;
    c) writing back all data in data=journal mode, and drop page cache from
    the original offset to the end, rather than using aligned blocks,
    d) renaming the stale error tags.
    
    Signed-off-by: Zhang Yi <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Reviewed-by: Ojaswin Mujoo <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Stable-dep-of: 29ec9bed2395 ("ext4: fix incorrect punch max_end")
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ext4: refactor ext4_zero_range() [+ + +]
Author: Zhang Yi <[email protected]>
Date:   Wed Jul 23 22:57:10 2025 -0400

    ext4: refactor ext4_zero_range()
    
    [ Upstream commit 53471e0bedad5891b860d02233819dc0e28189e2 ]
    
    The current implementation of ext4_zero_range() contains complex
    position calculations and stale error tags. To improve the code's
    clarity and maintainability, it is essential to clean up the code and
    improve its readability, this can be achieved by: a) simplifying and
    renaming variables, making the style the same as ext4_punch_hole(); b)
    eliminating unnecessary position calculations, writing back all data in
    data=journal mode, and drop page cache from the original offset to the
    end, rather than using aligned blocks; c) renaming the stale out_mutex
    tags.
    
    Signed-off-by: Zhang Yi <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Reviewed-by: Ojaswin Mujoo <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Stable-dep-of: 29ec9bed2395 ("ext4: fix incorrect punch max_end")
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
gve: Fix stuck TX queue for DQ queue format [+ + +]
Author: Praveen Kaligineedi <[email protected]>
Date:   Thu Jul 17 19:20:24 2025 +0000

    gve: Fix stuck TX queue for DQ queue format
    
    commit b03f15c0192b184078206760c839054ae6eb4eaa upstream.
    
    gve_tx_timeout was calculating missed completions in a way that is only
    relevant in the GQ queue format. Additionally, it was attempting to
    disable device interrupts, which is not needed in either GQ or DQ queue
    formats.
    
    As a result, TX timeouts with the DQ queue format likely would have
    triggered early resets without kicking the queue at all.
    
    This patch drops the check for pending work altogether and always kicks
    the queue after validating the queue has not seen a TX timeout too
    recently.
    
    Cc: [email protected]
    Fixes: 87a7f321bb6a ("gve: Recover from queue stall due to missed IRQ")
    Co-developed-by: Tim Hostetler <[email protected]>
    Signed-off-by: Tim Hostetler <[email protected]>
    Signed-off-by: Praveen Kaligineedi <[email protected]>
    Signed-off-by: Harshitha Ramamurthy <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
i2c: qup: jump out of the loop in case of timeout [+ + +]
Author: Yang Xiwen <[email protected]>
Date:   Mon Jun 16 00:01:10 2025 +0800

    i2c: qup: jump out of the loop in case of timeout
    
    commit a7982a14b3012527a9583d12525cd0dc9f8d8934 upstream.
    
    Original logic only sets the return value but doesn't jump out of the
    loop if the bus is kept active by a client. This is not expected. A
    malicious or buggy i2c client can hang the kernel in this case and
    should be avoided. This is observed during a long time test with a
    PCA953x GPIO extender.
    
    Fix it by changing the logic to not only sets the return value, but also
    jumps out of the loop and return to the caller with -ETIMEDOUT.
    
    Fixes: fbfab1ab0658 ("i2c: qup: reorganization of driver code to remove polling for qup v1")
    Signed-off-by: Yang Xiwen <[email protected]>
    Cc: <[email protected]> # v4.17+
    Signed-off-by: Andi Shyti <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

i2c: tegra: Fix reset error handling with ACPI [+ + +]
Author: Akhil R <[email protected]>
Date:   Thu Jul 10 18:42:04 2025 +0530

    i2c: tegra: Fix reset error handling with ACPI
    
    commit 56344e241c543f17e8102fa13466ad5c3e7dc9ff upstream.
    
    The acpi_evaluate_object() returns an ACPI error code and not
    Linux one. For the some platforms the err will have positive code
    which may be interpreted incorrectly. Use device_reset() for
    reset control which handles it correctly.
    
    Fixes: bd2fdedbf2ba ("i2c: tegra: Add the ACPI support")
    Reported-by: Andy Shevchenko <[email protected]>
    Signed-off-by: Akhil R <[email protected]>
    Cc: <[email protected]> # v5.17+
    Reviewed-by: Andy Shevchenko <[email protected]>
    Signed-off-by: Andi Shyti <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

i2c: virtio: Avoid hang by using interruptible completion wait [+ + +]
Author: Viresh Kumar <[email protected]>
Date:   Thu Jul 3 17:01:02 2025 +0530

    i2c: virtio: Avoid hang by using interruptible completion wait
    
    commit a663b3c47ab10f66130818cf94eb59c971541c3f upstream.
    
    The current implementation uses wait_for_completion(), which can cause
    the caller to hang indefinitely if the transfer never completes.
    
    Switch to wait_for_completion_interruptible() so that the operation can
    be interrupted by signals.
    
    Fixes: 84e1d0bf1d71 ("i2c: virtio: disable timeout handling")
    Signed-off-by: Viresh Kumar <[email protected]>
    Cc: <[email protected]> # v5.16+
    Signed-off-by: Andi Shyti <[email protected]>
    Link: https://lore.kernel.org/r/b8944e9cab8eb959d888ae80add6f2a686159ba2.1751541962.git.viresh.kumar@linaro.org
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
i40e: report VF tx_dropped with tx_errors instead of tx_discards [+ + +]
Author: Dennis Chen <[email protected]>
Date:   Wed Jun 18 15:52:40 2025 -0400

    i40e: report VF tx_dropped with tx_errors instead of tx_discards
    
    [ Upstream commit 50b2af451597ca6eefe9d4543f8bbf8de8aa00e7 ]
    
    Currently the tx_dropped field in VF stats is not updated correctly
    when reading stats from the PF. This is because it reads from
    i40e_eth_stats.tx_discards which seems to be unused for per VSI stats,
    as it is not updated by i40e_update_eth_stats() and the corresponding
    register, GLV_TDPC, is not implemented[1].
    
    Use i40e_eth_stats.tx_errors instead, which is actually updated by
    i40e_update_eth_stats() by reading from GLV_TEPC.
    
    To test, create a VF and try to send bad packets through it:
    
    $ echo 1 > /sys/class/net/enp2s0f0/device/sriov_numvfs
    $ cat test.py
    from scapy.all import *
    
    vlan_pkt = Ether(dst="ff:ff:ff:ff:ff:ff") / Dot1Q(vlan=999) / IP(dst="192.168.0.1") / ICMP()
    ttl_pkt = IP(dst="8.8.8.8", ttl=0) / ICMP()
    
    print("Send packet with bad VLAN tag")
    sendp(vlan_pkt, iface="enp2s0f0v0")
    print("Send packet with TTL=0")
    sendp(ttl_pkt, iface="enp2s0f0v0")
    $ ip -s link show dev enp2s0f0
    16: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
        link/ether 3c:ec:ef:b7:e0:ac brd ff:ff:ff:ff:ff:ff
        RX:  bytes packets errors dropped  missed   mcast
                 0       0      0       0       0       0
        TX:  bytes packets errors dropped carrier collsns
                 0       0      0       0       0       0
        vf 0     link/ether e2:c6:fd:c1:1e:92 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
        RX: bytes  packets  mcast   bcast   dropped
                 0        0       0       0        0
        TX: bytes  packets   dropped
                 0        0        0
    $ python test.py
    Send packet with bad VLAN tag
    .
    Sent 1 packets.
    Send packet with TTL=0
    .
    Sent 1 packets.
    $ ip -s link show dev enp2s0f0
    16: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
        link/ether 3c:ec:ef:b7:e0:ac brd ff:ff:ff:ff:ff:ff
        RX:  bytes packets errors dropped  missed   mcast
                 0       0      0       0       0       0
        TX:  bytes packets errors dropped carrier collsns
                 0       0      0       0       0       0
        vf 0     link/ether e2:c6:fd:c1:1e:92 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
        RX: bytes  packets  mcast   bcast   dropped
                 0        0       0       0        0
        TX: bytes  packets   dropped
                 0        0        0
    
    A packet with non-existent VLAN tag and a packet with TTL = 0 are sent,
    but tx_dropped is not incremented.
    
    After patch:
    
    $ ip -s link show dev enp2s0f0
    19: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
        link/ether 3c:ec:ef:b7:e0:ac brd ff:ff:ff:ff:ff:ff
        RX:  bytes packets errors dropped  missed   mcast
                 0       0      0       0       0       0
        TX:  bytes packets errors dropped carrier collsns
                 0       0      0       0       0       0
        vf 0     link/ether 4a:b7:3d:37:f7:56 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
        RX: bytes  packets  mcast   bcast   dropped
                 0        0       0       0        0
        TX: bytes  packets   dropped
                 0        0        2
    
    Fixes: dc645daef9af5bcbd9c ("i40e: implement VF stats NDO")
    Signed-off-by: Dennis Chen <[email protected]>
    Link: https://www.intel.com/content/www/us/en/content-details/596333/intel-ethernet-controller-x710-tm4-at2-carlsville-datasheet.html
    Reviewed-by: Simon Horman <[email protected]>
    Tested-by: Rafal Romanowski <[email protected]>
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

i40e: When removing VF MAC filters, only check PF-set MAC [+ + +]
Author: Jamie Bainbridge <[email protected]>
Date:   Wed Jun 25 09:29:18 2025 +1000

    i40e: When removing VF MAC filters, only check PF-set MAC
    
    [ Upstream commit 5a0df02999dbe838c3feed54b1d59e9445f68b89 ]
    
    When the PF is processing an Admin Queue message to delete a VF's MACs
    from the MAC filter, we currently check if the PF set the MAC and if
    the VF is trusted.
    
    This results in undesirable behaviour, where if a trusted VF with a
    PF-set MAC sets itself down (which sends an AQ message to delete the
    VF's MAC filters) then the VF MAC is erased from the interface.
    
    This results in the VF losing its PF-set MAC which should not happen.
    
    There is no need to check for trust at all, because an untrusted VF
    cannot change its own MAC. The only check needed is whether the PF set
    the MAC. If the PF set the MAC, then don't erase the MAC on link-down.
    
    Resolve this by changing the deletion check only for PF-set MAC.
    
    (the out-of-tree driver has also intentionally removed the check for VF
    trust here with OOT driver version 2.26.8, this changes the Linux kernel
    driver behaviour and comment to match the OOT driver behaviour)
    
    Fixes: ea2a1cfc3b201 ("i40e: Fix VF MAC filter removal")
    Signed-off-by: Jamie Bainbridge <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Tested-by: Rafal Romanowski <[email protected]>
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ice: Fix a null pointer dereference in ice_copy_and_init_pkg() [+ + +]
Author: Haoxiang Li <[email protected]>
Date:   Thu Jul 3 17:52:32 2025 +0800

    ice: Fix a null pointer dereference in ice_copy_and_init_pkg()
    
    commit 4ff12d82dac119b4b99b5a78b5af3bf2474c0a36 upstream.
    
    Add check for the return value of devm_kmemdup()
    to prevent potential null pointer dereference.
    
    Fixes: c76488109616 ("ice: Implement Dynamic Device Personalization (DDP) download")
    Cc: [email protected]
    Signed-off-by: Haoxiang Li <[email protected]>
    Reviewed-by: Michal Swiatkowski <[email protected]>
    Reviewed-by: Aleksandr Loktionov <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Tested-by: Rinitha S <[email protected]> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
iio: adc: ad7949: use spi_is_bpw_supported() [+ + +]
Author: David Lechner <[email protected]>
Date:   Wed Jun 11 10:04:58 2025 -0500

    iio: adc: ad7949: use spi_is_bpw_supported()
    
    [ Upstream commit 7b86482632788acd48d7b9ee1867f5ad3a32ccbb ]
    
    Use spi_is_bpw_supported() instead of directly accessing spi->controller
    ->bits_per_word_mask. bits_per_word_mask may be 0, which implies that
    8-bits-per-word is supported. spi_is_bpw_supported() takes this into
    account while spi_ctrl_mask == SPI_BPW_MASK(8) does not.
    
    Fixes: 0b2a740b424e ("iio: adc: ad7949: enable use with non 14/16-bit controllers")
    Closes: https://lore.kernel.org/linux-spi/[email protected]/
    Signed-off-by: David Lechner <[email protected]>
    Reviewed-by: Andy Shevchenko <[email protected]>
    Link: https://patch.msgid.link/20250611-iio-adc-ad7949-use-spi_is_bpw_supported-v1-1-c4e15bfd326e@baylibre.com
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

iio: hid-sensor-prox: Fix incorrect OFFSET calculation [+ + +]
Author: Zhang Lixu <[email protected]>
Date:   Thu Jul 24 11:19:22 2025 -0400

    iio: hid-sensor-prox: Fix incorrect OFFSET calculation
    
    [ Upstream commit 79dabbd505210e41c88060806c92c052496dd61c ]
    
    The OFFSET calculation in the prox_read_raw() was incorrectly using the
    unit exponent, which is intended for SCALE calculations.
    
    Remove the incorrect OFFSET calculation and set it to a fixed value of 0.
    
    Cc: [email protected]
    Fixes: 39a3a0138f61 ("iio: hid-sensors: Added Proximity Sensor Driver")
    Signed-off-by: Zhang Lixu <[email protected]>
    Acked-by: Srinivas Pandruvada <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jonathan Cameron <[email protected]>
    [ adapted prox_attr array access to single structure member access ]
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

iio: hid-sensor-prox: Restore lost scale assignments [+ + +]
Author: Zhang Lixu <[email protected]>
Date:   Thu Jul 24 11:12:50 2025 -0400

    iio: hid-sensor-prox: Restore lost scale assignments
    
    [ Upstream commit 83ded7cfaccccd2f4041769c313b58b4c9e265ad ]
    
    The variables `scale_pre_decml`, `scale_post_decml`, and `scale_precision`
    were assigned in commit d68c592e02f6 ("iio: hid-sensor-prox: Fix scale not
    correct issue"), but due to a merge conflict in
    commit 9c15db92a8e5 ("Merge tag 'iio-for-5.13a' of
    https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next"),
    these assignments were lost.
    
    Add back lost assignments and replace `st->prox_attr` with
    `st->prox_attr[0]` because commit 596ef5cf654b ("iio: hid-sensor-prox: Add
    support for more channels") changed `prox_attr` to an array.
    
    Cc: [email protected] # 5.13+
    Fixes: 9c15db92a8e5 ("Merge tag 'iio-for-5.13a' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next")
    Signed-off-by: Zhang Lixu <[email protected]>
    Acked-by: Srinivas Pandruvada <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jonathan Cameron <[email protected]>
    [ changed st->prox_attr[0] array access to st->prox_attr single struct member ]
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Input: gpio-keys - fix a sleep while atomic with PREEMPT_RT [+ + +]
Author: Fabrice Gasnier <[email protected]>
Date:   Fri May 30 15:36:43 2025 -0700

    Input: gpio-keys - fix a sleep while atomic with PREEMPT_RT
    
    commit f4a8f561d08e39f7833d4a278ebfb12a41eef15f upstream.
    
    When enabling PREEMPT_RT, the gpio_keys_irq_timer() callback runs in
    hard irq context, but the input_event() takes a spin_lock, which isn't
    allowed there as it is converted to a rt_spin_lock().
    
    [ 4054.289999] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
    [ 4054.290028] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/0
    ...
    [ 4054.290195]  __might_resched+0x13c/0x1f4
    [ 4054.290209]  rt_spin_lock+0x54/0x11c
    [ 4054.290219]  input_event+0x48/0x80
    [ 4054.290230]  gpio_keys_irq_timer+0x4c/0x78
    [ 4054.290243]  __hrtimer_run_queues+0x1a4/0x438
    [ 4054.290257]  hrtimer_interrupt+0xe4/0x240
    [ 4054.290269]  arch_timer_handler_phys+0x2c/0x44
    [ 4054.290283]  handle_percpu_devid_irq+0x8c/0x14c
    [ 4054.290297]  handle_irq_desc+0x40/0x58
    [ 4054.290307]  generic_handle_domain_irq+0x1c/0x28
    [ 4054.290316]  gic_handle_irq+0x44/0xcc
    
    Considering the gpio_keys_irq_isr() can run in any context, e.g. it can
    be threaded, it seems there's no point in requesting the timer isr to
    run in hard irq context.
    
    Relax the hrtimer not to use the hard context.
    
    Fixes: 019002f20cb5 ("Input: gpio-keys - use hrtimer for release timer")
    Suggested-by: Sebastian Andrzej Siewior <[email protected]>
    Signed-off-by: Fabrice Gasnier <[email protected]>
    Signed-off-by: Gatien Chevallier <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Cc: [email protected]
    Signed-off-by: Dmitry Torokhov <[email protected]>
    [ adjusted context ]
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
interconnect: qcom: sc7280: Add missing num_links to xm_pcie3_1 node [+ + +]
Author: Xilin Wu <[email protected]>
Date:   Fri Jun 13 22:53:38 2025 +0800

    interconnect: qcom: sc7280: Add missing num_links to xm_pcie3_1 node
    
    [ Upstream commit 886a94f008dd1a1702ee66dd035c266f70fd9e90 ]
    
    This allows adding interconnect paths for PCIe 1 in device tree later.
    
    Fixes: 46bdcac533cc ("interconnect: qcom: Add SC7280 interconnect provider driver")
    Signed-off-by: Xilin Wu <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Georgi Djakov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
jfs: reject on-disk inodes of an unsupported type [+ + +]
Author: Dmitry Antipov <[email protected]>
Date:   Thu Nov 7 08:42:28 2024 +0300

    jfs: reject on-disk inodes of an unsupported type
    
    commit 8c3f9a70d2d4dd6c640afe294b05c6a0a45434d9 upstream.
    
    Syzbot has reported the following BUG:
    
    kernel BUG at fs/inode.c:668!
    Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
    CPU: 3 UID: 0 PID: 139 Comm: jfsCommit Not tainted 6.12.0-rc4-syzkaller-00085-g4e46774408d9 #0
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014
    RIP: 0010:clear_inode+0x168/0x190
    Code: 4c 89 f7 e8 ba fe e5 ff e9 61 ff ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 7c c1 4c 89 f7 e8 90 ff e5 ff eb b7
     0b e8 01 5d 7f ff 90 0f 0b e8 f9 5c 7f ff 90 0f 0b e8 f1 5c 7f
    RSP: 0018:ffffc900027dfae8 EFLAGS: 00010093
    RAX: ffffffff82157a87 RBX: 0000000000000001 RCX: ffff888104d4b980
    RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
    RBP: ffffc900027dfc90 R08: ffffffff82157977 R09: fffff520004fbf38
    R10: dffffc0000000000 R11: fffff520004fbf38 R12: dffffc0000000000
    R13: ffff88811315bc00 R14: ffff88811315bda8 R15: ffff88811315bb80
    FS:  0000000000000000(0000) GS:ffff888135f00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00005565222e0578 CR3: 0000000026ef0000 CR4: 00000000000006f0
    Call Trace:
     <TASK>
     ? __die_body+0x5f/0xb0
     ? die+0x9e/0xc0
     ? do_trap+0x15a/0x3a0
     ? clear_inode+0x168/0x190
     ? do_error_trap+0x1dc/0x2c0
     ? clear_inode+0x168/0x190
     ? __pfx_do_error_trap+0x10/0x10
     ? report_bug+0x3cd/0x500
     ? handle_invalid_op+0x34/0x40
     ? clear_inode+0x168/0x190
     ? exc_invalid_op+0x38/0x50
     ? asm_exc_invalid_op+0x1a/0x20
     ? clear_inode+0x57/0x190
     ? clear_inode+0x167/0x190
     ? clear_inode+0x168/0x190
     ? clear_inode+0x167/0x190
     jfs_evict_inode+0xb5/0x440
     ? __pfx_jfs_evict_inode+0x10/0x10
     evict+0x4ea/0x9b0
     ? __pfx_evict+0x10/0x10
     ? iput+0x713/0xa50
     txUpdateMap+0x931/0xb10
     ? __pfx_txUpdateMap+0x10/0x10
     jfs_lazycommit+0x49a/0xb80
     ? _raw_spin_unlock_irqrestore+0x8f/0x140
     ? lockdep_hardirqs_on+0x99/0x150
     ? __pfx_jfs_lazycommit+0x10/0x10
     ? __pfx_default_wake_function+0x10/0x10
     ? __kthread_parkme+0x169/0x1d0
     ? __pfx_jfs_lazycommit+0x10/0x10
     kthread+0x2f2/0x390
     ? __pfx_jfs_lazycommit+0x10/0x10
     ? __pfx_kthread+0x10/0x10
     ret_from_fork+0x4d/0x80
     ? __pfx_kthread+0x10/0x10
     ret_from_fork_asm+0x1a/0x30
     </TASK>
    
    This happens when 'clear_inode()' makes an attempt to finalize an underlying
    JFS inode of unknown type. According to JFS layout description from
    https://jfs.sourceforge.net/project/pub/jfslayout.pdf, inode types from 5 to
    15 are reserved for future extensions and should not be encountered on a valid
    filesystem. So add an extra check for valid inode type in 'copy_from_dinode()'.
    
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=ac2116e48989e84a2893
    Fixes: 79ac5a46c5c1 ("jfs_lookup(): don't bother with . or ..")
    Signed-off-by: Dmitry Antipov <[email protected]>
    Signed-off-by: Dave Kleikamp <[email protected]>
    Signed-off-by: Aditya Dutt <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
kasan: use vmalloc_dump_obj() for vmalloc error reports [+ + +]
Author: Marco Elver <[email protected]>
Date:   Wed Jul 16 17:23:28 2025 +0200

    kasan: use vmalloc_dump_obj() for vmalloc error reports
    
    commit 6ade153349c6bb990d170cecc3e8bdd8628119ab upstream.
    
    Since 6ee9b3d84775 ("kasan: remove kasan_find_vm_area() to prevent
    possible deadlock"), more detailed info about the vmalloc mapping and the
    origin was dropped due to potential deadlocks.
    
    While fixing the deadlock is necessary, that patch was too quick in
    killing an otherwise useful feature, and did no due-diligence in
    understanding if an alternative option is available.
    
    Restore printing more helpful vmalloc allocation info in KASAN reports
    with the help of vmalloc_dump_obj().  Example report:
    
    | BUG: KASAN: vmalloc-out-of-bounds in vmalloc_oob+0x4c9/0x610
    | Read of size 1 at addr ffffc900002fd7f3 by task kunit_try_catch/493
    |
    | CPU: [...]
    | Call Trace:
    |  <TASK>
    |  dump_stack_lvl+0xa8/0xf0
    |  print_report+0x17e/0x810
    |  kasan_report+0x155/0x190
    |  vmalloc_oob+0x4c9/0x610
    |  [...]
    |
    | The buggy address belongs to a 1-page vmalloc region starting at 0xffffc900002fd000 allocated at vmalloc_oob+0x36/0x610
    | The buggy address belongs to the physical page:
    | page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x126364
    | flags: 0x200000000000000(node=0|zone=2)
    | raw: 0200000000000000 0000000000000000 dead000000000122 0000000000000000
    | raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
    | page dumped because: kasan: bad access detected
    |
    | [..]
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 6ee9b3d84775 ("kasan: remove kasan_find_vm_area() to prevent possible deadlock")
    Signed-off-by: Marco Elver <[email protected]>
    Suggested-by: Uladzislau Rezki <[email protected]>
    Acked-by: Uladzislau Rezki (Sony) <[email protected]>
    Cc: Alexander Potapenko <[email protected]>
    Cc: Andrey Konovalov <[email protected]>
    Cc: Andrey Ryabinin <[email protected]>
    Cc: Sebastian Andrzej Siewior <[email protected]>
    Cc: Yeoreum Yun <[email protected]>
    Cc: Yunseong Kim <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
KVM: x86/hyper-v: Skip non-canonical addresses during PV TLB flush [+ + +]
Author: Manuel Andreas <[email protected]>
Date:   Wed Jul 23 11:14:16 2025 -0400

    KVM: x86/hyper-v: Skip non-canonical addresses during PV TLB flush
    
    [ Upstream commit fa787ac07b3ceb56dd88a62d1866038498e96230 ]
    
    In KVM guests with Hyper-V hypercalls enabled, the hypercalls
    HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST and HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX
    allow a guest to request invalidation of portions of a virtual TLB.
    For this, the hypercall parameter includes a list of GVAs that are supposed
    to be invalidated.
    
    However, when non-canonical GVAs are passed, there is currently no
    filtering in place and they are eventually passed to checked invocations of
    INVVPID on Intel / INVLPGA on AMD.  While AMD's INVLPGA silently ignores
    non-canonical addresses (effectively a no-op), Intel's INVVPID explicitly
    signals VM-Fail and ultimately triggers the WARN_ONCE in invvpid_error():
    
      invvpid failed: ext=0x0 vpid=1 gva=0xaaaaaaaaaaaaa000
      WARNING: CPU: 6 PID: 326 at arch/x86/kvm/vmx/vmx.c:482
      invvpid_error+0x91/0xa0 [kvm_intel]
      Modules linked in: kvm_intel kvm 9pnet_virtio irqbypass fuse
      CPU: 6 UID: 0 PID: 326 Comm: kvm-vm Not tainted 6.15.0 #14 PREEMPT(voluntary)
      RIP: 0010:invvpid_error+0x91/0xa0 [kvm_intel]
      Call Trace:
        vmx_flush_tlb_gva+0x320/0x490 [kvm_intel]
        kvm_hv_vcpu_flush_tlb+0x24f/0x4f0 [kvm]
        kvm_arch_vcpu_ioctl_run+0x3013/0x5810 [kvm]
    
    Hyper-V documents that invalid GVAs (those that are beyond a partition's
    GVA space) are to be ignored.  While not completely clear whether this
    ruling also applies to non-canonical GVAs, it is likely fine to make that
    assumption, and manual testing on Azure confirms "real" Hyper-V interprets
    the specification in the same way.
    
    Skip non-canonical GVAs when processing the list of address to avoid
    tripping the INVVPID failure.  Alternatively, KVM could filter out "bad"
    GVAs before inserting into the FIFO, but practically speaking the only
    downside of pushing validation to the final processing is that doing so
    is suboptimal for the guest, and no well-behaved guest will request TLB
    flushes for non-canonical addresses.
    
    Fixes: 260970862c88 ("KVM: x86: hyper-v: Handle HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST{,EX} calls gently")
    Cc: [email protected]
    Signed-off-by: Manuel Andreas <[email protected]>
    Suggested-by: Vitaly Kuznetsov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sean Christopherson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: x86: Add X86EMUL_F_MSR and X86EMUL_F_DT_LOAD to aid canonical checks [+ + +]
Author: Maxim Levitsky <[email protected]>
Date:   Wed Jul 23 11:14:14 2025 -0400

    KVM: x86: Add X86EMUL_F_MSR and X86EMUL_F_DT_LOAD to aid canonical checks
    
    [ Upstream commit c534b37b7584e2abc5d487b4e017f61a61959ca9 ]
    
    Add emulation flags for MSR accesses and Descriptor Tables loads, and pass
    the new flags as appropriate to emul_is_noncanonical_address().  The flags
    will be used to perform the correct canonical check, as the type of access
    affects whether or not CR4.LA57 is consulted when determining the canonical
    bit.
    
    No functional change is intended.
    
    Signed-off-by: Maxim Levitsky <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [sean: split to separate patch, massage changelog]
    Signed-off-by: Sean Christopherson <[email protected]>
    Stable-dep-of: fa787ac07b3c ("KVM: x86/hyper-v: Skip non-canonical addresses during PV TLB flush")
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: x86: drop x86.h include from cpuid.h [+ + +]
Author: Maxim Levitsky <[email protected]>
Date:   Wed Jul 23 11:14:12 2025 -0400

    KVM: x86: drop x86.h include from cpuid.h
    
    [ Upstream commit e52ad1ddd0a3b07777141ec9406d5dc2c9a0de17 ]
    
    Drop x86.h include from cpuid.h to allow the x86.h to include the cpuid.h
    instead.
    
    Also fix various places where x86.h was implicitly included via cpuid.h
    
    Signed-off-by: Maxim Levitsky <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [sean: fixup a missed include in mtrr.c]
    Signed-off-by: Sean Christopherson <[email protected]>
    Stable-dep-of: fa787ac07b3c ("KVM: x86/hyper-v: Skip non-canonical addresses during PV TLB flush")
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: x86: Free vCPUs before freeing VM state [+ + +]
Author: Sean Christopherson <[email protected]>
Date:   Mon Feb 24 15:55:36 2025 -0800

    KVM: x86: Free vCPUs before freeing VM state
    
    commit 17bcd714426386fda741a4bccd96a2870179344b upstream.
    
    Free vCPUs before freeing any VM state, as both SVM and VMX may access
    VM state when "freeing" a vCPU that is currently "in" L2, i.e. that needs
    to be kicked out of nested guest mode.
    
    Commit 6fcee03df6a1 ("KVM: x86: avoid loading a vCPU after .vm_destroy was
    called") partially fixed the issue, but for unknown reasons only moved the
    MMU unloading before VM destruction.  Complete the change, and free all
    vCPU state prior to destroying VM state, as nVMX accesses even more state
    than nSVM.
    
    In addition to the AVIC, KVM can hit a use-after-free on MSR filters:
    
      kvm_msr_allowed+0x4c/0xd0
      __kvm_set_msr+0x12d/0x1e0
      kvm_set_msr+0x19/0x40
      load_vmcs12_host_state+0x2d8/0x6e0 [kvm_intel]
      nested_vmx_vmexit+0x715/0xbd0 [kvm_intel]
      nested_vmx_free_vcpu+0x33/0x50 [kvm_intel]
      vmx_free_vcpu+0x54/0xc0 [kvm_intel]
      kvm_arch_vcpu_destroy+0x28/0xf0
      kvm_vcpu_destroy+0x12/0x50
      kvm_arch_destroy_vm+0x12c/0x1c0
      kvm_put_kvm+0x263/0x3c0
      kvm_vm_release+0x21/0x30
    
    and an upcoming fix to process injectable interrupts on nested VM-Exit
    will access the PIC:
    
      BUG: kernel NULL pointer dereference, address: 0000000000000090
      #PF: supervisor read access in kernel mode
      #PF: error_code(0x0000) - not-present page
      CPU: 23 UID: 1000 PID: 2658 Comm: kvm-nx-lpage-re
      RIP: 0010:kvm_cpu_has_extint+0x2f/0x60 [kvm]
      Call Trace:
       <TASK>
       kvm_cpu_has_injectable_intr+0xe/0x60 [kvm]
       nested_vmx_vmexit+0x2d7/0xdf0 [kvm_intel]
       nested_vmx_free_vcpu+0x40/0x50 [kvm_intel]
       vmx_vcpu_free+0x2d/0x80 [kvm_intel]
       kvm_arch_vcpu_destroy+0x2d/0x130 [kvm]
       kvm_destroy_vcpus+0x8a/0x100 [kvm]
       kvm_arch_destroy_vm+0xa7/0x1d0 [kvm]
       kvm_destroy_vm+0x172/0x300 [kvm]
       kvm_vcpu_release+0x31/0x50 [kvm]
    
    Inarguably, both nSVM and nVMX need to be fixed, but punt on those
    cleanups for the moment.  Conceptually, vCPUs should be freed before VM
    state.  Assets like the I/O APIC and PIC _must_ be allocated before vCPUs
    are created, so it stands to reason that they must be freed _after_ vCPUs
    are destroyed.
    
    Reported-by: Aaron Lewis <[email protected]>
    Closes: https://lore.kernel.org/all/[email protected]
    Cc: Jim Mattson <[email protected]>
    Cc: Yan Zhao <[email protected]>
    Cc: Rick P Edgecombe <[email protected]>
    Cc: Kai Huang <[email protected]>
    Cc: Isaku Yamahata <[email protected]>
    Signed-off-by: Sean Christopherson <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Kevin Cheng <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: x86: model canonical checks more precisely [+ + +]
Author: Maxim Levitsky <[email protected]>
Date:   Wed Jul 23 11:14:15 2025 -0400

    KVM: x86: model canonical checks more precisely
    
    [ Upstream commit 9245fd6b8531497d129a7a6e3eef258042862f85 ]
    
    As a result of a recent investigation, it was determined that x86 CPUs
    which support 5-level paging, don't always respect CR4.LA57 when doing
    canonical checks.
    
    In particular:
    
    1. MSRs which contain a linear address, allow full 57-bitcanonical address
    regardless of CR4.LA57 state. For example: MSR_KERNEL_GS_BASE.
    
    2. All hidden segment bases and GDT/IDT bases also behave like MSRs.
    This means that full 57-bit canonical address can be loaded to them
    regardless of CR4.LA57, both using MSRS (e.g GS_BASE) and instructions
    (e.g LGDT).
    
    3. TLB invalidation instructions also allow the user to use full 57-bit
    address regardless of the CR4.LA57.
    
    Finally, it must be noted that the CPU doesn't prevent the user from
    disabling 5-level paging, even when the full 57-bit canonical address is
    present in one of the registers mentioned above (e.g GDT base).
    
    In fact, this can happen without any userspace help, when the CPU enters
    SMM mode - some MSRs, for example MSR_KERNEL_GS_BASE are left to contain
    a non-canonical address in regard to the new mode.
    
    Since most of the affected MSRs and all segment bases can be read and
    written freely by the guest without any KVM intervention, this patch makes
    the emulator closely follow hardware behavior, which means that the
    emulator doesn't take in the account the guest CPUID support for 5-level
    paging, and only takes in the account the host CPU support.
    
    Signed-off-by: Maxim Levitsky <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sean Christopherson <[email protected]>
    Stable-dep-of: fa787ac07b3c ("KVM: x86/hyper-v: Skip non-canonical addresses during PV TLB flush")
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: x86: Route non-canonical checks in emulator through emulate_ops [+ + +]
Author: Maxim Levitsky <[email protected]>
Date:   Wed Jul 23 11:14:13 2025 -0400

    KVM: x86: Route non-canonical checks in emulator through emulate_ops
    
    [ Upstream commit 16ccadefa295af434ca296e566f078223ecd79ca ]
    
    Add emulate_ops.is_canonical_addr() to perform (non-)canonical checks in
    the emulator, which will allow extending is_noncanonical_address() to
    support different flavors of canonical checks, e.g. for descriptor table
    bases vs. MSRs, without needing duplicate logic in the emulator.
    
    No functional change is intended.
    
    Signed-off-by: Maxim Levitsky <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [sean: separate from additional of flags, massage changelog]
    Signed-off-by: Sean Christopherson <[email protected]>
    Stable-dep-of: fa787ac07b3c ("KVM: x86/hyper-v: Skip non-canonical addresses during PV TLB flush")
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Linux: Linux 6.12.41 [+ + +]
Author: Greg Kroah-Hartman <[email protected]>
Date:   Fri Aug 1 09:48:47 2025 +0100

    Linux 6.12.41
    
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Jon Hunter <[email protected]>
    Tested-by: Salvatore Bonaccorso <[email protected]>
    Tested-by: Mark Brown <[email protected]>
    Tested-by: Brett A C Sheffield <[email protected]>
    Tested-by: Peter Schneider <[email protected]>
    Tested-by: Shuah Khan <[email protected]>
    Tested-by: Harshit Mogalapalli <[email protected]>
    Tested-by: Ron Economos <[email protected]>
    Tested-by: Linux Kernel Functional Testing <[email protected]>
    Tested-by: Brett Mastbergen <[email protected]>
    Tested-by: Miguel Ojeda <[email protected]>
    Tested-by: Hardik Garg <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mm/ksm: fix -Wsometimes-uninitialized from clang-21 in advisor_mode_show() [+ + +]
Author: Nathan Chancellor <[email protected]>
Date:   Tue Jul 15 12:56:16 2025 -0700

    mm/ksm: fix -Wsometimes-uninitialized from clang-21 in advisor_mode_show()
    
    commit 153ad566724fe6f57b14f66e9726d295d22e576d upstream.
    
    After a recent change in clang to expose uninitialized warnings from const
    variables [1], there is a false positive warning from the if statement in
    advisor_mode_show().
    
      mm/ksm.c:3687:11: error: variable 'output' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
       3687 |         else if (ksm_advisor == KSM_ADVISOR_SCAN_TIME)
            |                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      mm/ksm.c:3690:33: note: uninitialized use occurs here
       3690 |         return sysfs_emit(buf, "%s\n", output);
            |                                        ^~~~~~
    
    Rewrite the if statement to implicitly make KSM_ADVISOR_NONE the else
    branch so that it is obvious to the compiler that ksm_advisor can only be
    KSM_ADVISOR_NONE or KSM_ADVISOR_SCAN_TIME due to the assignments in
    advisor_mode_store().
    
    Link: https://lkml.kernel.org/r/20250715-ksm-fix-clang-21-uninit-warning-v1-1-f443feb4bfc4@kernel.org
    Fixes: 66790e9a735b ("mm/ksm: add sysfs knobs for advisor")
    Signed-off-by: Nathan Chancellor <[email protected]>
    Closes: https://github.com/ClangBuiltLinux/linux/issues/2100
    Link: https://github.com/llvm/llvm-project/commit/2464313eef01c5b1edf0eccf57a32cdee01472c7 [1]
    Acked-by: David Hildenbrand <[email protected]>
    Cc: Chengming Zhou <[email protected]>
    Cc: Stefan Roesch <[email protected]>
    Cc: xu xin <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mm/vmscan: fix hwpoisoned large folio handling in shrink_folio_list [+ + +]
Author: Jinjiang Tu <[email protected]>
Date:   Fri Jun 27 20:57:46 2025 +0800

    mm/vmscan: fix hwpoisoned large folio handling in shrink_folio_list
    
    commit 9f1e8cd0b7c4c944e9921b52a6661b5eda2705ab upstream.
    
    In shrink_folio_list(), the hwpoisoned folio may be large folio, which
    can't be handled by unmap_poisoned_folio().  For THP, try_to_unmap_one()
    must be passed with TTU_SPLIT_HUGE_PMD to split huge PMD first and then
    retry.  Without TTU_SPLIT_HUGE_PMD, we will trigger null-ptr deref of
    pvmw.pte.  Even we passed TTU_SPLIT_HUGE_PMD, we will trigger a
    WARN_ON_ONCE due to the page isn't in swapcache.
    
    Since UCE is rare in real world, and race with reclaimation is more rare,
    just skipping the hwpoisoned large folio is enough.  memory_failure() will
    handle it if the UCE is triggered again.
    
    This happens when memory reclaim for large folio races with
    memory_failure(), and will lead to kernel panic.  The race is as
    follows:
    
    cpu0      cpu1
     shrink_folio_list memory_failure
      TestSetPageHWPoison
      unmap_poisoned_folio
      --> trigger BUG_ON due to
      unmap_poisoned_folio couldn't
       handle large folio
    
    [[email protected]: add comment to unmap_poisoned_folio()]
      Link: https://lkml.kernel.org/r/[email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Jinjiang Tu <[email protected]>
    Fixes: 1b0449544c64 ("mm/vmscan: don't try to reclaim hwpoison folio")
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/all/[email protected]/
    Acked-by: David Hildenbrand <[email protected]>
    Reviewed-by: Miaohe Lin <[email protected]>
    Acked-by: Zi Yan <[email protected]>
    Reviewed-by: Oscar Salvador <[email protected]>
    Cc: Kefeng Wang <[email protected]>
    Cc: Michal Hocko <[email protected]>
    Cc: Oscar Salvador <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mm/zsmalloc: do not pass __GFP_MOVABLE if CONFIG_COMPACTION=n [+ + +]
Author: Harry Yoo <[email protected]>
Date:   Fri Jul 4 19:30:53 2025 +0900

    mm/zsmalloc: do not pass __GFP_MOVABLE if CONFIG_COMPACTION=n
    
    commit 694d6b99923eb05a8fd188be44e26077d19f0e21 upstream.
    
    Commit 48b4800a1c6a ("zsmalloc: page migration support") added support for
    migrating zsmalloc pages using the movable_operations migration framework.
    However, the commit did not take into account that zsmalloc supports
    migration only when CONFIG_COMPACTION is enabled.  Tracing shows that
    zsmalloc was still passing the __GFP_MOVABLE flag even when compaction is
    not supported.
    
    This can result in unmovable pages being allocated from movable page
    blocks (even without stealing page blocks), ZONE_MOVABLE and CMA area.
    
    Possible user visible effects:
    - Some ZONE_MOVABLE memory can be not actually movable
    - CMA allocation can fail because of this
    - Increased memory fragmentation due to ignoring the page mobility
      grouping feature
    I'm not really sure who uses kernels without compaction support, though :(
    
    
    To fix this, clear the __GFP_MOVABLE flag when
    !IS_ENABLED(CONFIG_COMPACTION).
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 48b4800a1c6a ("zsmalloc: page migration support")
    Signed-off-by: Harry Yoo <[email protected]>
    Acked-by: David Hildenbrand <[email protected]>
    Reviewed-by: Sergey Senozhatsky <[email protected]>
    Cc: Minchan Kim <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mm: khugepaged: fix call hpage_collapse_scan_file() for anonymous vma [+ + +]
Author: Liu Shixin <[email protected]>
Date:   Sat Jan 11 11:45:11 2025 +0800

    mm: khugepaged: fix call hpage_collapse_scan_file() for anonymous vma
    
    commit f1897f2f08b28ae59476d8b73374b08f856973af upstream.
    
    syzkaller reported such a BUG_ON():
    
     ------------[ cut here ]------------
     kernel BUG at mm/khugepaged.c:1835!
     Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
     ...
     CPU: 6 UID: 0 PID: 8009 Comm: syz.15.106 Kdump: loaded Tainted: G        W          6.13.0-rc6 #22
     Tainted: [W]=WARN
     Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
     pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
     pc : collapse_file+0xa44/0x1400
     lr : collapse_file+0x88/0x1400
     sp : ffff80008afe3a60
     ...
     Call trace:
      collapse_file+0xa44/0x1400 (P)
      hpage_collapse_scan_file+0x278/0x400
      madvise_collapse+0x1bc/0x678
      madvise_vma_behavior+0x32c/0x448
      madvise_walk_vmas.constprop.0+0xbc/0x140
      do_madvise.part.0+0xdc/0x2c8
      __arm64_sys_madvise+0x68/0x88
      invoke_syscall+0x50/0x120
      el0_svc_common.constprop.0+0xc8/0xf0
      do_el0_svc+0x24/0x38
      el0_svc+0x34/0x128
      el0t_64_sync_handler+0xc8/0xd0
      el0t_64_sync+0x190/0x198
    
    This indicates that the pgoff is unaligned.  After analysis, I confirm the
    vma is mapped to /dev/zero.  Such a vma certainly has vm_file, but it is
    set to anonymous by mmap_zero().  So even if it's mmapped by 2m-unaligned,
    it can pass the check in thp_vma_allowable_order() as it is an
    anonymous-mmap, but then be collapsed as a file-mmap.
    
    It seems the problem has existed for a long time, but actually, since we
    have khugepaged_max_ptes_none check before, we will skip collapse it as it
    is /dev/zero and so has no present page.  But commit d8ea7cc8547c limit
    the check for only khugepaged, so the BUG_ON() can be triggered by
    madvise_collapse().
    
    Add vma_is_anonymous() check to make such vma be processed by
    hpage_collapse_scan_pmd().
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: d8ea7cc8547c ("mm/khugepaged: add flag to predicate khugepaged-only behavior")
    Signed-off-by: Liu Shixin <[email protected]>
    Reviewed-by: Yang Shi <[email protected]>
    Acked-by: David Hildenbrand <[email protected]>
    Cc: Chengming Zhou <[email protected]>
    Cc: Johannes Weiner <[email protected]>
    Cc: Kefeng Wang <[email protected]>
    Cc: Mattew Wilcox <[email protected]>
    Cc: Muchun Song <[email protected]>
    Cc: Nanyong Sun <[email protected]>
    Cc: Qi Zheng <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    [acsjakub: backport, clean apply]
    Signed-off-by: Jakub Acs <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mtd: rawnand: qcom: Fix last codeword read in qcom_param_page_type_exec() [+ + +]
Author: Md Sadre Alam <[email protected]>
Date:   Wed Jul 23 22:33:58 2025 -0400

    mtd: rawnand: qcom: Fix last codeword read in qcom_param_page_type_exec()
    
    [ Upstream commit 47bddabbf69da50999ec68be92b58356c687e1d6 ]
    
    For QPIC V2 onwards there is a separate register to read
    last code word "QPIC_NAND_READ_LOCATION_LAST_CW_n".
    
    qcom_param_page_type_exec() is used to read only one code word
    If it configures the number of code words to 1 in QPIC_NAND_DEV0_CFG0
    register then QPIC controller thinks its reading the last code word,
    since we are having separate register to read the last code word,
    we have to configure "QPIC_NAND_READ_LOCATION_LAST_CW_n" register
    to fetch data from QPIC buffer to system memory.
    
    Without this change page read was failing with timeout error
    
    / # hexdump -C /dev/mtd1
    [  129.206113] qcom-nandc 1cc8000.nand-controller: failure to read page/oob
    hexdump: /dev/mtd1: Connection timed out
    
    This issue only seen on SDX targets since SDX target used QPICv2. But
    same working on IPQ targets since IPQ used QPICv1.
    
    Cc: [email protected]
    Fixes: 89550beb098e ("mtd: rawnand: qcom: Implement exec_op()")
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Tested-by: Lakshmi Sowjanya D <[email protected]>
    Signed-off-by: Md Sadre Alam <[email protected]>
    Signed-off-by: Miquel Raynal <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
net/mlx5: E-Switch, Fix peer miss rules to use peer eswitch [+ + +]
Author: Shahar Shitrit <[email protected]>
Date:   Thu Jul 17 15:06:10 2025 +0300

    net/mlx5: E-Switch, Fix peer miss rules to use peer eswitch
    
    [ Upstream commit 5b4c56ad4da0aa00b258ab50b1f5775b7d3108c7 ]
    
    In the original design, it is assumed local and peer eswitches have the
    same number of vfs. However, in new firmware, local and peer eswitches
    can have different number of vfs configured by mlxconfig.  In such
    configuration, it is incorrect to derive the number of vfs from the
    local device's eswitch.
    
    Fix this by updating the peer miss rules add and delete functions to use
    the peer device's eswitch and vf count instead of the local device's
    information, ensuring correct behavior regardless of vf configuration
    differences.
    
    Fixes: ac004b832128 ("net/mlx5e: E-Switch, Add peer miss rules")
    Signed-off-by: Shahar Shitrit <[email protected]>
    Reviewed-by: Mark Bloch <[email protected]>
    Signed-off-by: Tariq Toukan <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net/mlx5: Fix memory leak in cmd_exec() [+ + +]
Author: Chiara Meiohas <[email protected]>
Date:   Thu Jul 17 15:06:09 2025 +0300

    net/mlx5: Fix memory leak in cmd_exec()
    
    [ Upstream commit 3afa3ae3db52e3c216d77bd5907a5a86833806cc ]
    
    If cmd_exec() is called with callback and mlx5_cmd_invoke() returns an
    error, resources allocated in cmd_exec() will not be freed.
    
    Fix the code to release the resources if mlx5_cmd_invoke() returns an
    error.
    
    Fixes: f086470122d5 ("net/mlx5: cmdif, Return value improvements")
    Reported-by: Alex Tereshkin <[email protected]>
    Signed-off-by: Chiara Meiohas <[email protected]>
    Reviewed-by: Moshe Shemesh <[email protected]>
    Signed-off-by: Vlad Dumitrescu <[email protected]>
    Signed-off-by: Tariq Toukan <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net/sched: sch_qfq: Avoid triggering might_sleep in atomic context in qfq_delete_class [+ + +]
Author: Xiang Mei <[email protected]>
Date:   Thu Jul 17 16:01:28 2025 -0700

    net/sched: sch_qfq: Avoid triggering might_sleep in atomic context in qfq_delete_class
    
    [ Upstream commit cf074eca0065bc5142e6004ae236bb35a2687fdf ]
    
    might_sleep could be trigger in the atomic context in qfq_delete_class.
    
    qfq_destroy_class was moved into atomic context locked
    by sch_tree_lock to avoid a race condition bug on
    qfq_aggregate. However, might_sleep could be triggered by
    qfq_destroy_class, which introduced sleeping in atomic context (path:
    qfq_destroy_class->qdisc_put->__qdisc_destroy->lockdep_unregister_key
    ->might_sleep).
    
    Considering the race is on the qfq_aggregate objects, keeping
    qfq_rm_from_agg in the lock but moving the left part out can solve
    this issue.
    
    Fixes: 5e28d5a3f774 ("net/sched: sch_qfq: Fix race condition on qfq_aggregate")
    Reported-by: Dan Carpenter <[email protected]>
    Signed-off-by: Xiang Mei <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Reviewed-by: Cong Wang <[email protected]>
    Reviewed-by: Dan Carpenter <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net: appletalk: Fix use-after-free in AARP proxy probe [+ + +]
Author: Kito Xu (veritas501) <[email protected]>
Date:   Thu Jul 17 01:28:43 2025 +0000

    net: appletalk: Fix use-after-free in AARP proxy probe
    
    [ Upstream commit 6c4a92d07b0850342d3becf2e608f805e972467c ]
    
    The AARP proxy‐probe routine (aarp_proxy_probe_network) sends a probe,
    releases the aarp_lock, sleeps, then re-acquires the lock.  During that
    window an expire timer thread (__aarp_expire_timer) can remove and
    kfree() the same entry, leading to a use-after-free.
    
    race condition:
    
             cpu 0                          |            cpu 1
        atalk_sendmsg()                     |   atif_proxy_probe_device()
        aarp_send_ddp()                     |   aarp_proxy_probe_network()
        mod_timer()                         |   lock(aarp_lock) // LOCK!!
        timeout around 200ms                |   alloc(aarp_entry)
        and then call                       |   proxies[hash] = aarp_entry
        aarp_expire_timeout()               |   aarp_send_probe()
                                            |   unlock(aarp_lock) // UNLOCK!!
        lock(aarp_lock) // LOCK!!           |   msleep(100);
        __aarp_expire_timer(&proxies[ct])   |
        free(aarp_entry)                    |
        unlock(aarp_lock) // UNLOCK!!       |
                                            |   lock(aarp_lock) // LOCK!!
                                            |   UAF aarp_entry !!
    
    ==================================================================
    BUG: KASAN: slab-use-after-free in aarp_proxy_probe_network+0x560/0x630 net/appletalk/aarp.c:493
    Read of size 4 at addr ffff8880123aa360 by task repro/13278
    
    CPU: 3 UID: 0 PID: 13278 Comm: repro Not tainted 6.15.2 #3 PREEMPT(full)
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:94 [inline]
     dump_stack_lvl+0x116/0x1b0 lib/dump_stack.c:120
     print_address_description mm/kasan/report.c:408 [inline]
     print_report+0xc1/0x630 mm/kasan/report.c:521
     kasan_report+0xca/0x100 mm/kasan/report.c:634
     aarp_proxy_probe_network+0x560/0x630 net/appletalk/aarp.c:493
     atif_proxy_probe_device net/appletalk/ddp.c:332 [inline]
     atif_ioctl+0xb58/0x16c0 net/appletalk/ddp.c:857
     atalk_ioctl+0x198/0x2f0 net/appletalk/ddp.c:1818
     sock_do_ioctl+0xdc/0x260 net/socket.c:1190
     sock_ioctl+0x239/0x6a0 net/socket.c:1311
     vfs_ioctl fs/ioctl.c:51 [inline]
     __do_sys_ioctl fs/ioctl.c:906 [inline]
     __se_sys_ioctl fs/ioctl.c:892 [inline]
     __x64_sys_ioctl+0x194/0x200 fs/ioctl.c:892
     do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
     do_syscall_64+0xcb/0x250 arch/x86/entry/syscall_64.c:94
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
     </TASK>
    
    Allocated:
     aarp_alloc net/appletalk/aarp.c:382 [inline]
     aarp_proxy_probe_network+0xd8/0x630 net/appletalk/aarp.c:468
     atif_proxy_probe_device net/appletalk/ddp.c:332 [inline]
     atif_ioctl+0xb58/0x16c0 net/appletalk/ddp.c:857
     atalk_ioctl+0x198/0x2f0 net/appletalk/ddp.c:1818
    
    Freed:
     kfree+0x148/0x4d0 mm/slub.c:4841
     __aarp_expire net/appletalk/aarp.c:90 [inline]
     __aarp_expire_timer net/appletalk/aarp.c:261 [inline]
     aarp_expire_timeout+0x480/0x6e0 net/appletalk/aarp.c:317
    
    The buggy address belongs to the object at ffff8880123aa300
     which belongs to the cache kmalloc-192 of size 192
    The buggy address is located 96 bytes inside of
     freed 192-byte region [ffff8880123aa300, ffff8880123aa3c0)
    
    Memory state around the buggy address:
     ffff8880123aa200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
     ffff8880123aa280: 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc
    >ffff8880123aa300: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                           ^
     ffff8880123aa380: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
     ffff8880123aa400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    ==================================================================
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Kito Xu (veritas501) <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: hns3: default enable tx bounce buffer when smmu enabled [+ + +]
Author: Jijie Shao <[email protected]>
Date:   Tue Jul 22 20:54:23 2025 +0800

    net: hns3: default enable tx bounce buffer when smmu enabled
    
    [ Upstream commit 49ade8630f36e9dca2395592cfb0b7deeb07e746 ]
    
    The SMMU engine on HIP09 chip has a hardware issue.
    SMMU pagetable prefetch features may prefetch and use a invalid PTE
    even the PTE is valid at that time. This will cause the device trigger
    fake pagefaults. The solution is to avoid prefetching by adding a
    SYNC command when smmu mapping a iova. But the performance of nic has a
    sharp drop. Then we do this workaround, always enable tx bounce buffer,
    avoid mapping/unmapping on TX path.
    
    This issue only affects HNS3, so we always enable
    tx bounce buffer when smmu enabled to improve performance.
    
    Fixes: 295ba232a8c3 ("net: hns3: add device version to replace pci revision")
    Signed-off-by: Jian Shen <[email protected]>
    Signed-off-by: Jijie Shao <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: hns3: disable interrupt when ptp init failed [+ + +]
Author: Yonglong Liu <[email protected]>
Date:   Tue Jul 22 20:54:21 2025 +0800

    net: hns3: disable interrupt when ptp init failed
    
    [ Upstream commit cde304655f25d94a996c45b0f9956e7dcc2bc4c0 ]
    
    When ptp init failed, we'd better disable the interrupt and clear the
    flag, to avoid early report interrupt at next probe.
    
    Fixes: 0bf5eb788512 ("net: hns3: add support for PTP")
    Signed-off-by: Yonglong Liu <[email protected]>
    Signed-off-by: Jijie Shao <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: hns3: fix concurrent setting vlan filter issue [+ + +]
Author: Jian Shen <[email protected]>
Date:   Tue Jul 22 20:54:20 2025 +0800

    net: hns3: fix concurrent setting vlan filter issue
    
    [ Upstream commit 4555f8f8b6aa46940f55feb6a07704c2935b6d6e ]
    
    The vport->req_vlan_fltr_en may be changed concurrently by function
    hclge_sync_vlan_fltr_state() called in periodic work task and
    function hclge_enable_vport_vlan_filter() called by user configuration.
    It may cause the user configuration inoperative. Fixes it by protect
    the vport->req_vlan_fltr by vport_lock.
    
    Fixes: 2ba306627f59 ("net: hns3: add support for modify VLAN filter state")
    Signed-off-by: Jian Shen <[email protected]>
    Signed-off-by: Jijie Shao <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: hns3: fixed vf get max channels bug [+ + +]
Author: Jian Shen <[email protected]>
Date:   Tue Jul 22 20:54:22 2025 +0800

    net: hns3: fixed vf get max channels bug
    
    [ Upstream commit b3e75c0bcc53f647311960bc1b0970b9b480ca5a ]
    
    Currently, the queried maximum of vf channels is the maximum of channels
    supported by each TC. However, the actual maximum of channels is
    the maximum of channels supported by the device.
    
    Fixes: 849e46077689 ("net: hns3: add ethtool_ops.get_channels support for VF")
    Signed-off-by: Jian Shen <[email protected]>
    Signed-off-by: Hao Lan <[email protected]>
    Signed-off-by: Jijie Shao <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: ti: icssg-prueth: Fix buffer allocation for ICSSG [+ + +]
Author: Himanshu Mittal <[email protected]>
Date:   Thu Jul 17 15:12:20 2025 +0530

    net: ti: icssg-prueth: Fix buffer allocation for ICSSG
    
    [ Upstream commit 6e86fb73de0fe3ec5cdcd5873ad1d6005f295b64 ]
    
    Fixes overlapping buffer allocation for ICSSG peripheral
    used for storing packets to be received/transmitted.
    There are 3 buffers:
    1. Buffer for Locally Injected Packets
    2. Buffer for Forwarding Packets
    3. Buffer for Host Egress Packets
    
    In existing allocation buffers for 2. and 3. are overlapping causing
    packet corruption.
    
    Packet corruption observations:
    During tcp iperf testing, due to overlapping buffers the received ack
    packet overwrites the packet to be transmitted. So, we see packets on
    wire with the ack packet content inside the content of next TCP packet
    from sender device.
    
    Details for AM64x switch mode:
    -> Allocation by existing driver:
    +---------+-------------------------------------------------------------+
    |         |          SLICE 0             |          SLICE 1             |
    |         +------+--------------+--------+------+--------------+--------+
    |         | Slot | Base Address | Size   | Slot | Base Address | Size   |
    |---------+------+--------------+--------+------+--------------+--------+
    |         | 0    | 70000000     | 0x2000 | 0    | 70010000     | 0x2000 |
    |         | 1    | 70002000     | 0x2000 | 1    | 70012000     | 0x2000 |
    |         | 2    | 70004000     | 0x2000 | 2    | 70014000     | 0x2000 |
    | FWD     | 3    | 70006000     | 0x2000 | 3    | 70016000     | 0x2000 |
    | Buffers | 4    | 70008000     | 0x2000 | 4    | 70018000     | 0x2000 |
    |         | 5    | 7000A000     | 0x2000 | 5    | 7001A000     | 0x2000 |
    |         | 6    | 7000C000     | 0x2000 | 6    | 7001C000     | 0x2000 |
    |         | 7    | 7000E000     | 0x2000 | 7    | 7001E000     | 0x2000 |
    +---------+------+--------------+--------+------+--------------+--------+
    |         | 8    | 70020000     | 0x1000 | 8    | 70028000     | 0x1000 |
    |         | 9    | 70021000     | 0x1000 | 9    | 70029000     | 0x1000 |
    |         | 10   | 70022000     | 0x1000 | 10   | 7002A000     | 0x1000 |
    | Our     | 11   | 70023000     | 0x1000 | 11   | 7002B000     | 0x1000 |
    | LI      | 12   | 00000000     | 0x0    | 12   | 00000000     | 0x0    |
    | Buffers | 13   | 00000000     | 0x0    | 13   | 00000000     | 0x0    |
    |         | 14   | 00000000     | 0x0    | 14   | 00000000     | 0x0    |
    |         | 15   | 00000000     | 0x0    | 15   | 00000000     | 0x0    |
    +---------+------+--------------+--------+------+--------------+--------+
    |         | 16   | 70024000     | 0x1000 | 16   | 7002C000     | 0x1000 |
    |         | 17   | 70025000     | 0x1000 | 17   | 7002D000     | 0x1000 |
    |         | 18   | 70026000     | 0x1000 | 18   | 7002E000     | 0x1000 |
    | Their   | 19   | 70027000     | 0x1000 | 19   | 7002F000     | 0x1000 |
    | LI      | 20   | 00000000     | 0x0    | 20   | 00000000     | 0x0    |
    | Buffers | 21   | 00000000     | 0x0    | 21   | 00000000     | 0x0    |
    |         | 22   | 00000000     | 0x0    | 22   | 00000000     | 0x0    |
    |         | 23   | 00000000     | 0x0    | 23   | 00000000     | 0x0    |
    +---------+------+--------------+--------+------+--------------+--------+
    --> here 16, 17, 18, 19 overlapping with below express buffer
    
    +-----+-----------------------------------------------+
    |     |       SLICE 0       |        SLICE 1          |
    |     +------------+----------+------------+----------+
    |     | Start addr | End addr | Start addr | End addr |
    +-----+------------+----------+------------+----------+
    | EXP | 70024000   | 70028000 | 7002C000   | 70030000 | <-- Overlapping
    | PRE | 70030000   | 70033800 | 70034000   | 70037800 |
    +-----+------------+----------+------------+----------+
    
    +---------------------+----------+----------+
    |                     | SLICE 0  |  SLICE 1 |
    +---------------------+----------+----------+
    | Default Drop Offset | 00000000 | 00000000 |     <-- Field not configured
    +---------------------+----------+----------+
    
    -> Allocation this patch brings:
    +---------+-------------------------------------------------------------+
    |         |          SLICE 0             |          SLICE 1             |
    |         +------+--------------+--------+------+--------------+--------+
    |         | Slot | Base Address | Size   | Slot | Base Address | Size   |
    |---------+------+--------------+--------+------+--------------+--------+
    |         | 0    | 70000000     | 0x2000 | 0    | 70040000     | 0x2000 |
    |         | 1    | 70002000     | 0x2000 | 1    | 70042000     | 0x2000 |
    |         | 2    | 70004000     | 0x2000 | 2    | 70044000     | 0x2000 |
    | FWD     | 3    | 70006000     | 0x2000 | 3    | 70046000     | 0x2000 |
    | Buffers | 4    | 70008000     | 0x2000 | 4    | 70048000     | 0x2000 |
    |         | 5    | 7000A000     | 0x2000 | 5    | 7004A000     | 0x2000 |
    |         | 6    | 7000C000     | 0x2000 | 6    | 7004C000     | 0x2000 |
    |         | 7    | 7000E000     | 0x2000 | 7    | 7004E000     | 0x2000 |
    +---------+------+--------------+--------+------+--------------+--------+
    |         | 8    | 70010000     | 0x1000 | 8    | 70050000     | 0x1000 |
    |         | 9    | 70011000     | 0x1000 | 9    | 70051000     | 0x1000 |
    |         | 10   | 70012000     | 0x1000 | 10   | 70052000     | 0x1000 |
    | Our     | 11   | 70013000     | 0x1000 | 11   | 70053000     | 0x1000 |
    | LI      | 12   | 00000000     | 0x0    | 12   | 00000000     | 0x0    |
    | Buffers | 13   | 00000000     | 0x0    | 13   | 00000000     | 0x0    |
    |         | 14   | 00000000     | 0x0    | 14   | 00000000     | 0x0    |
    |         | 15   | 00000000     | 0x0    | 15   | 00000000     | 0x0    |
    +---------+------+--------------+--------+------+--------------+--------+
    |         | 16   | 70014000     | 0x1000 | 16   | 70054000     | 0x1000 |
    |         | 17   | 70015000     | 0x1000 | 17   | 70055000     | 0x1000 |
    |         | 18   | 70016000     | 0x1000 | 18   | 70056000     | 0x1000 |
    | Their   | 19   | 70017000     | 0x1000 | 19   | 70057000     | 0x1000 |
    | LI      | 20   | 00000000     | 0x0    | 20   | 00000000     | 0x0    |
    | Buffers | 21   | 00000000     | 0x0    | 21   | 00000000     | 0x0    |
    |         | 22   | 00000000     | 0x0    | 22   | 00000000     | 0x0    |
    |         | 23   | 00000000     | 0x0    | 23   | 00000000     | 0x0    |
    +---------+------+--------------+--------+------+--------------+--------+
    
    +-----+-----------------------------------------------+
    |     |       SLICE 0       |        SLICE 1          |
    |     +------------+----------+------------+----------+
    |     | Start addr | End addr | Start addr | End addr |
    +-----+------------+----------+------------+----------+
    | EXP | 70018000   | 7001C000 | 70058000   | 7005C000 |
    | PRE | 7001C000   | 7001F800 | 7005C000   | 7005F800 |
    +-----+------------+----------+------------+----------+
    
    +---------------------+----------+----------+
    |                     | SLICE 0  |  SLICE 1 |
    +---------------------+----------+----------+
    | Default Drop Offset | 7001F800 | 7005F800 |
    +---------------------+----------+----------+
    
    Rootcause: missing buffer configuration for Express frames in
    function: prueth_fw_offload_buffer_setup()
    
    Details:
    Driver implements two distinct buffer configuration functions that are
    invoked based on the driver state and ICSSG firmware:-
    - prueth_fw_offload_buffer_setup()
    - prueth_emac_buffer_setup()
    
    During initialization, driver creates standard network interfaces
    (netdevs) and configures buffers via prueth_emac_buffer_setup().
    This function properly allocates and configures all required memory
    regions including:
    - LI buffers
    - Express packet buffers
    - Preemptible packet buffers
    
    However, when the driver transitions to an offload mode (switch/HSR/PRP),
    buffer reconfiguration is handled by prueth_fw_offload_buffer_setup().
    This function does not reconfigure the buffer regions required for
    Express packets, leading to incorrect buffer allocation.
    
    Fixes: abd5576b9c57 ("net: ti: icssg-prueth: Add support for ICSSG switch firmware")
    Signed-off-by: Himanshu Mittal <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nilfs2: reject invalid file types when reading inodes [+ + +]
Author: Ryusuke Konishi <[email protected]>
Date:   Thu Jul 10 22:49:08 2025 +0900

    nilfs2: reject invalid file types when reading inodes
    
    commit 4aead50caf67e01020c8be1945c3201e8a972a27 upstream.
    
    To prevent inodes with invalid file types from tripping through the vfs
    and causing malfunctions or assertion failures, add a missing sanity check
    when reading an inode from a block device.  If the file type is not valid,
    treat it as a filesystem error.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 05fe58fdc10d ("nilfs2: inode operations")
    Signed-off-by: Ryusuke Konishi <[email protected]>
    Reported-by: [email protected]
    Link: https://syzkaller.appspot.com/bug?extid=895c23f6917da440ed0d
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
platform/mellanox: mlxbf-pmc: Remove newline char from event name input [+ + +]
Author: Shravan Kumar Ramani <[email protected]>
Date:   Wed Jul 2 06:09:01 2025 -0400

    platform/mellanox: mlxbf-pmc: Remove newline char from event name input
    
    [ Upstream commit 44e6ca8faeeed12206f3e7189c5ac618b810bb9c ]
    
    Since the input string passed via the command line appends a newline char,
    it needs to be removed before comparison with the event_list.
    
    Fixes: 1a218d312e65 ("platform/mellanox: mlxbf-pmc: Add Mellanox BlueField PMC driver")
    Signed-off-by: Shravan Kumar Ramani <[email protected]>
    Reviewed-by: David Thompson <[email protected]>
    Link: https://lore.kernel.org/r/4978c18e33313b48fa2ae7f3aa6dbcfce40877e4.1751380187.git.shravankr@nvidia.com
    Reviewed-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

platform/mellanox: mlxbf-pmc: Use kstrtobool() to check 0/1 input [+ + +]
Author: Shravan Kumar Ramani <[email protected]>
Date:   Wed Jul 2 06:09:02 2025 -0400

    platform/mellanox: mlxbf-pmc: Use kstrtobool() to check 0/1 input
    
    [ Upstream commit 0e2cebd72321caeef84b6ba7084e85be0287fb4b ]
    
    For setting the enable value, the input should be 0 or 1 only. Use
    kstrtobool() in place of kstrtoint() in mlxbf_pmc_enable_store() to
    accept only valid input.
    
    Fixes: 423c3361855c ("platform/mellanox: mlxbf-pmc: Add support for BlueField-3")
    Signed-off-by: Shravan Kumar Ramani <[email protected]>
    Reviewed-by: David Thompson <[email protected]>
    Link: https://lore.kernel.org/r/2ee618c59976bcf1379d5ddce2fc60ab5014b3a9.1751380187.git.shravankr@nvidia.com
    [ij: split kstrbool() change to own commit.]
    Reviewed-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

platform/mellanox: mlxbf-pmc: Validate event/enable input [+ + +]
Author: Shravan Kumar Ramani <[email protected]>
Date:   Wed Jul 2 06:09:02 2025 -0400

    platform/mellanox: mlxbf-pmc: Validate event/enable input
    
    [ Upstream commit f8c1311769d3b2c82688b294b4ae03e94f1c326d ]
    
    Before programming the event info, validate the event number received as input
    by checking if it exists in the event_list. Also fix a typo in the comment for
    mlxbf_pmc_get_event_name() to correctly mention that it returns the event name
    when taking the event number as input, and not the other way round.
    
    Fixes: 423c3361855c ("platform/mellanox: mlxbf-pmc: Add support for BlueField-3")
    Signed-off-by: Shravan Kumar Ramani <[email protected]>
    Reviewed-by: David Thompson <[email protected]>
    Link: https://lore.kernel.org/r/2ee618c59976bcf1379d5ddce2fc60ab5014b3a9.1751380187.git.shravankr@nvidia.com
    [ij: split kstrbool() change to own commit.]
    Reviewed-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
platform/x86: asus-nb-wmi: add DMI quirk for ASUS Zenbook Duo UX8406CA [+ + +]
Author: Rahul Chandra <[email protected]>
Date:   Tue Jun 24 03:33:01 2025 -0400

    platform/x86: asus-nb-wmi: add DMI quirk for ASUS Zenbook Duo UX8406CA
    
    [ Upstream commit 7dc6b2d3b5503bcafebbeaf9818112bf367107b4 ]
    
    Add a DMI quirk entry for the ASUS Zenbook Duo UX8406CA 2025 model to use
    the existing zenbook duo keyboard quirk.
    
    Signed-off-by: Rahul Chandra <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

platform/x86: Fix initialization order for firmware_attributes_class [+ + +]
Author: Torsten Hilbrich <[email protected]>
Date:   Fri Jul 11 12:32:54 2025 +0200

    platform/x86: Fix initialization order for firmware_attributes_class
    
    [ Upstream commit 2bfe3ae1aa45f8b61cb0dc462114fd0c9636ad32 ]
    
    The think-lmi driver uses the firwmare_attributes_class. But this class
    is registered after think-lmi, causing the "think-lmi" directory in
    "/sys/class/firmware-attributes" to be missing when the driver is
    compiled as builtin.
    
    Fixes: 55922403807a ("platform/x86: think-lmi: Directly use firmware_attributes_class")
    Signed-off-by: Torsten Hilbrich <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

platform/x86: ideapad-laptop: Fix FnLock not remembered among boots [+ + +]
Author: Rong Zhang <[email protected]>
Date:   Tue Jul 8 00:38:06 2025 +0800

    platform/x86: ideapad-laptop: Fix FnLock not remembered among boots
    
    commit 9533b789df7e8d273543a5991aec92447be043d7 upstream.
    
    On devices supported by ideapad-laptop, the HW/FW can remember the
    FnLock state among boots. However, since the introduction of the FnLock
    LED class device, it is turned off while shutting down, as a side effect
    of the LED class device unregistering sequence.
    
    Many users always turn on FnLock because they use function keys much
    more frequently than multimedia keys. The behavior change is
    inconvenient for them. Thus, set LED_RETAIN_AT_SHUTDOWN on the LED class
    device so that the FnLock state gets remembered, which also aligns with
    the behavior of manufacturer utilities on Windows.
    
    Fixes: 07f48f668fac ("platform/x86: ideapad-laptop: add FnLock LED class device")
    Cc: [email protected]
    Signed-off-by: Rong Zhang <[email protected]>
    Reviewed-by: Hans de Goede <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

platform/x86: ideapad-laptop: Fix kbd backlight not remembered among boots [+ + +]
Author: Rong Zhang <[email protected]>
Date:   Tue Jul 8 00:38:07 2025 +0800

    platform/x86: ideapad-laptop: Fix kbd backlight not remembered among boots
    
    commit e10981075adce203eac0be866389309eeb8ef11e upstream.
    
    On some models supported by ideapad-laptop, the HW/FW can remember the
    state of keyboard backlight among boots. However, it is always turned
    off while shutting down, as a side effect of the LED class device
    unregistering sequence.
    
    This is inconvenient for users who always prefer turning on the
    keyboard backlight. Thus, set LED_RETAIN_AT_SHUTDOWN on the LED class
    device so that the state of keyboard backlight gets remembered, which
    also aligns with the behavior of manufacturer utilities on Windows.
    
    Fixes: 503325f84bc0 ("platform/x86: ideapad-laptop: add keyboard backlight control support")
    Cc: [email protected]
    Signed-off-by: Rong Zhang <[email protected]>
    Reviewed-by: Hans de Goede <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
RDMA/core: Rate limit GID cache warning messages [+ + +]
Author: Maor Gottlieb <[email protected]>
Date:   Mon Jun 16 11:26:21 2025 +0300

    RDMA/core: Rate limit GID cache warning messages
    
    [ Upstream commit 333e4d79316c9ed5877d7aac8b8ed22efc74e96d ]
    
    The GID cache warning messages can flood the kernel log when there are
    multiple failed attempts to add GIDs. This can happen when creating many
    virtual interfaces without having enough space for their GIDs in the GID
    table.
    
    Change pr_warn to pr_warn_ratelimited to prevent log flooding while still
    maintaining visibility of the issue.
    
    Link: https://patch.msgid.link/r/fd45ed4a1078e743f498b234c3ae816610ba1b18.1750062357.git.leon@kernel.org
    Signed-off-by: Maor Gottlieb <[email protected]>
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
regmap: fix potential memory leak of regmap_bus [+ + +]
Author: Abdun Nihaal <[email protected]>
Date:   Thu Jun 26 22:58:21 2025 +0530

    regmap: fix potential memory leak of regmap_bus
    
    [ Upstream commit c871c199accb39d0f4cb941ad0dccabfc21e9214 ]
    
    When __regmap_init() is called from __regmap_init_i2c() and
    __regmap_init_spi() (and their devm versions), the bus argument
    obtained from regmap_get_i2c_bus() and regmap_get_spi_bus(), may be
    allocated using kmemdup() to support quirks. In those cases, the
    bus->free_on_exit field is set to true.
    
    However, inside __regmap_init(), buf is not freed on any error path.
    This could lead to a memory leak of regmap_bus when __regmap_init()
    fails. Fix that by freeing bus on error path when free_on_exit is set.
    
    Fixes: ea030ca68819 ("regmap-i2c: Set regmap max raw r/w from quirks")
    Signed-off-by: Abdun Nihaal <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
regulator: core: fix NULL dereference on unbind due to stale coupling data [+ + +]
Author: Alessandro Carminati <[email protected]>
Date:   Thu Jun 26 08:38:09 2025 +0000

    regulator: core: fix NULL dereference on unbind due to stale coupling data
    
    [ Upstream commit ca46946a482238b0cdea459fb82fc837fb36260e ]
    
    Failing to reset coupling_desc.n_coupled after freeing coupled_rdevs can
    lead to NULL pointer dereference when regulators are accessed post-unbind.
    
    This can happen during runtime PM or other regulator operations that rely
    on coupling metadata.
    
    For example, on ridesx4, unbinding the 'reg-dummy' platform device triggers
    a panic in regulator_lock_recursive() due to stale coupling state.
    
    Ensure n_coupled is set to 0 to prevent access to invalid pointers.
    
    Signed-off-by: Alessandro Carminati <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
resource: fix false warning in __request_region() [+ + +]
Author: Akinobu Mita <[email protected]>
Date:   Sat Jul 19 20:26:04 2025 +0900

    resource: fix false warning in __request_region()
    
    commit 91a229bb7ba86b2592c3f18c54b7b2c5e6fe0f95 upstream.
    
    A warning is raised when __request_region() detects a conflict with a
    resource whose resource.desc is IORES_DESC_DEVICE_PRIVATE_MEMORY.
    
    But this warning is only valid for iomem_resources.
    The hmem device resource uses resource.desc as the numa node id, which can
    cause spurious warnings.
    
    This warning appeared on a machine with multiple cxl memory expanders.
    One of the NUMA node id is 6, which is the same as the value of
    IORES_DESC_DEVICE_PRIVATE_MEMORY.
    
    In this environment it was just a spurious warning, but when I saw the
    warning I suspected a real problem so it's better to fix it.
    
    This change fixes this by restricting the warning to only iomem_resource.
    This also adds a missing new line to the warning message.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 7dab174e2e27 ("dax/hmem: Move hmem device registration to dax_hmem.ko")
    Signed-off-by: Akinobu Mita <[email protected]>
    Reviewed-by: Dan Williams <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Revert "drm/xe/devcoredump: Update handling of xe_force_wake_get return" [+ + +]
Author: Tomita Moeko <[email protected]>
Date:   Tue Jul 29 19:05:24 2025 +0800

    Revert "drm/xe/devcoredump: Update handling of xe_force_wake_get return"
    
    This reverts commit 9ffd6ec2de08ef4ac5f17f6131d1db57613493f9.
    
    The reverted commit updated the handling of xe_force_wake_get to match
    the new "return refcounted domain mask" semantics introduced in commit
    a7ddcea1f5ac ("drm/xe: Error handling in xe_force_wake_get()"). However,
    that API change only exists in 6.13 and later.
    
    In 6.12 stable kernel, xe_force_wake_get still returns a status code.
    The update incorrectly treats the return value as a mask, causing the
    return value of 0 to be misinterpreted as an error
    
    Cc: Rodrigo Vivi <[email protected]>
    Cc: Lucas De Marchi <[email protected]>
    Cc: Himal Prasad Ghimiray <[email protected]>
    Cc: Nirmoy Das <[email protected]>
    Cc: Badal Nilawar <[email protected]>
    Acked-by: Rodrigo Vivi <[email protected]>
    Signed-off-by: Tomita Moeko <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Revert "drm/xe/forcewake: Add a helper xe_force_wake_ref_has_domain()" [+ + +]
Author: Tomita Moeko <[email protected]>
Date:   Tue Jul 29 19:05:25 2025 +0800

    Revert "drm/xe/forcewake: Add a helper xe_force_wake_ref_has_domain()"
    
    This reverts commit deb05f8431f31e08fd6ab99a56069fc98014dbec.
    
    The helper function introduced in the reverted commit is for handling
    the "refcounted domain mask" introduced in commit a7ddcea1f5ac
    ("drm/xe: Error handling in xe_force_wake_get()"). Since that API change
    only exists in 6.13 and later, this helper is unnecessary in 6.12 stable
    kernel.
    
    Cc: Michal Wajdeczko <[email protected]>
    Cc: Badal Nilawar <[email protected]>
    Cc: Himal Prasad Ghimiray <[email protected]>
    Acked-by: Rodrigo Vivi <[email protected]>
    Signed-off-by: Tomita Moeko <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Revert "drm/xe/gt: Update handling of xe_force_wake_get return" [+ + +]
Author: Tomita Moeko <[email protected]>
Date:   Tue Jul 29 19:05:22 2025 +0800

    Revert "drm/xe/gt: Update handling of xe_force_wake_get return"
    
    This reverts commit d42b44736ea29fa6d0c3cb9c75569314134b7732.
    
    The reverted commit updated the handling of xe_force_wake_get to match
    the new "return refcounted domain mask" semantics introduced in commit
    a7ddcea1f5ac ("drm/xe: Error handling in xe_force_wake_get()"). However,
    that API change only exists in 6.13 and later.
    
    In 6.12 stable kernel, xe_force_wake_get still returns a status code.
    The update incorrectly treats the return value as a mask, causing the
    return value of 0 to be misinterpreted as an error. As a result, the
    driver probe fails with -ETIMEDOUT in xe_pci_probe -> xe_device_probe
    -> xe_gt_init_hwconfig -> xe_force_wake_get.
    
    [ 1254.323172] xe 0000:00:02.0: [drm] Found ALDERLAKE_P (device ID 46a6) display version 13.00 stepping D0
    [ 1254.323175] xe 0000:00:02.0: [drm:xe_pci_probe [xe]] ALDERLAKE_P  46a6:000c dgfx:0 gfx:Xe_LP (12.00) media:Xe_M (12.00) display:yes dma_m_s:39 tc:1 gscfi:0 cscfi:0
    [ 1254.323275] xe 0000:00:02.0: [drm:xe_pci_probe [xe]] Stepping = (G:C0, M:C0, B:**)
    [ 1254.323328] xe 0000:00:02.0: [drm:xe_pci_probe [xe]] SR-IOV support: no (mode: none)
    [ 1254.323379] xe 0000:00:02.0: [drm:intel_pch_type [xe]] Found Alder Lake PCH
    [ 1254.323475] xe 0000:00:02.0: probe with driver xe failed with error -110
    
    Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/5373
    Cc: Badal Nilawar <[email protected]>
    Cc: Matthew Brost <[email protected]>
    Cc: Rodrigo Vivi <[email protected]>
    Cc: Lucas De Marchi <[email protected]>
    Cc: Himal Prasad Ghimiray <[email protected]>
    Cc: Nirmoy Das <[email protected]>
    Acked-by: Rodrigo Vivi <[email protected]>
    Signed-off-by: Tomita Moeko <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Revert "drm/xe/tests/mocs: Update xe_force_wake_get() return handling" [+ + +]
Author: Tomita Moeko <[email protected]>
Date:   Tue Jul 29 19:05:23 2025 +0800

    Revert "drm/xe/tests/mocs: Update xe_force_wake_get() return handling"
    
    This reverts commit 95a75ed2b005447f96fbd4ac61758ccda44069d1.
    
    The reverted commit updated the handling of xe_force_wake_get to match
    the new "return refcounted domain mask" semantics introduced in commit
    a7ddcea1f5ac ("drm/xe: Error handling in xe_force_wake_get()"). However,
    that API change only exists in 6.13 and later.
    
    In 6.12 stable kernel, xe_force_wake_get still returns a status code.
    The update incorrectly treats the return value as a mask, causing the
    return value of 0 to be misinterpreted as an error.
    
    Cc: Rodrigo Vivi <[email protected]>
    Cc: Lucas De Marchi <[email protected]>
    Cc: Himal Prasad Ghimiray <[email protected]>
    Cc: Nirmoy Das <[email protected]>
    Cc: Badal Nilawar <[email protected]>
    Acked-by: Rodrigo Vivi <[email protected]>
    Signed-off-by: Tomita Moeko <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Revert "wifi: mt76: mt7925: Update mt7925_mcu_uni_[tx,rx]_ba for MLO" [+ + +]
Author: Sean Wang <[email protected]>
Date:   Thu Jul 24 10:47:04 2025 -0400

    Revert "wifi: mt76: mt7925: Update mt7925_mcu_uni_[tx,rx]_ba for MLO"
    
    [ Upstream commit 766ea2cf5a398c7eed519b12c6c6cf1631143ea2 ]
    
    For MLO, mac80211 will send the BA action for each link to
    the driver, so the driver does not need to handle it itself.
    Therefore, revert this patch.
    
    Fixes: eb2a9a12c609 ("wifi: mt76: mt7925: Update mt7925_mcu_uni_[tx,rx]_ba for MLO")
    Cc: [email protected]
    Signed-off-by: Ming Yen Hsieh <[email protected]>
    Tested-by: Caleb Jorden <[email protected]>
    Signed-off-by: Sean Wang <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Felix Fietkau <[email protected]>
    [ struct mt76_vif_link -> struct mt76_vif ]
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
rust: give Clippy the minimum supported Rust version [+ + +]
Author: Miguel Ojeda <[email protected]>
Date:   Sat Nov 23 23:23:45 2024 +0100

    rust: give Clippy the minimum supported Rust version
    
    commit f0915acd1fc6060a35e3f18673072671583ff0be upstream.
    
    Clippy's lints may avoid emitting a suggestion to use a language or
    library feature that is not supported by the minimum supported version,
    if given by the `msrv` field in the configuration file.
    
    For instance, Clippy should not suggest using `let ... else` in a lint
    if the MSRV did not implement that syntax.
    
    If the MSRV is not provided, Clippy will assume all features are available.
    
    Thus enable it with the minimum Rust version the kernel supports.
    
    Note that there is currently a small disadvantage in doing so: since
    we still use unstable features that nevertheless work in the range
    of versions we support (e.g. `#[expect(...)]`), we lose suggestions
    for those. However, over time we will stop using unstable features
    (especially language and library ones) as it is our goal, thus, in the
    end, we will want to have the `msrv` set.
    
    Rust is also considering adding a similar feature in `rustc` too, which
    we should probably enable if it becomes available [2].
    
    Link: https://github.com/rust-lang/rust-clippy/blob/8298da72e7b81fa30c515631b40fc4c0845948cb/clippy_utils/src/msrvs.rs#L20 [1]
    Link: https://github.com/rust-lang/compiler-team/issues/772 [2]
    Reviewed-by: Alice Ryhl <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Miguel Ojeda <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
s390/ism: fix concurrency management in ism_cmd() [+ + +]
Author: Halil Pasic <[email protected]>
Date:   Tue Jul 22 18:18:17 2025 +0200

    s390/ism: fix concurrency management in ism_cmd()
    
    [ Upstream commit 897e8601b9cff1d054cdd53047f568b0e1995726 ]
    
    The s390x ISM device data sheet clearly states that only one
    request-response sequence is allowable per ISM function at any point in
    time.  Unfortunately as of today the s390/ism driver in Linux does not
    honor that requirement. This patch aims to rectify that.
    
    This problem was discovered based on Aliaksei's bug report which states
    that for certain workloads the ISM functions end up entering error state
    (with PEC 2 as seen from the logs) after a while and as a consequence
    connections handled by the respective function break, and for future
    connection requests the ISM device is not considered -- given it is in a
    dysfunctional state. During further debugging PEC 3A was observed as
    well.
    
    A kernel message like
    [ 1211.244319] zpci: 061a:00:00.0: Event 0x2 reports an error for PCI function 0x61a
    is a reliable indicator of the stated function entering error state
    with PEC 2. Let me also point out that a kernel message like
    [ 1211.244325] zpci: 061a:00:00.0: The ism driver bound to the device does not support error recovery
    is a reliable indicator that the ISM function won't be auto-recovered
    because the ISM driver currently lacks support for it.
    
    On a technical level, without this synchronization, commands (inputs to
    the FW) may be partially or fully overwritten (corrupted) by another CPU
    trying to issue commands on the same function. There is hard evidence that
    this can lead to DMB token values being used as DMB IOVAs, leading to
    PEC 2 PCI events indicating invalid DMA. But this is only one of the
    failure modes imaginable. In theory even completely losing one command
    and executing another one twice and then trying to interpret the outputs
    as if the command we intended to execute was actually executed and not
    the other one is also possible.  Frankly, I don't feel confident about
    providing an exhaustive list of possible consequences.
    
    Fixes: 684b89bc39ce ("s390/ism: add device driver for internal shared memory")
    Reported-by: Aliaksei Makarau <[email protected]>
    Tested-by: Mahanta Jambigi <[email protected]>
    Tested-by: Aliaksei Makarau <[email protected]>
    Signed-off-by: Halil Pasic <[email protected]>
    Reviewed-by: Alexandra Winter <[email protected]>
    Signed-off-by: Alexandra Winter <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
selftests/bpf: Add tests with stack ptr register in conditional jmp [+ + +]
Author: Yonghong Song <[email protected]>
Date:   Fri May 23 21:13:40 2025 -0700

    selftests/bpf: Add tests with stack ptr register in conditional jmp
    
    commit 5ffb537e416ee22dbfb3d552102e50da33fec7f6 upstream.
    
    Add two tests:
      - one test has 'rX <op> r10' where rX is not r10, and
      - another test has 'rX <op> rY' where rX and rY are not r10
        but there is an early insn 'rX = r10'.
    
    Without previous verifier change, both tests will fail.
    
    Signed-off-by: Yonghong Song <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    [ shung-hsi.yu: contains additional hunks for kernel/bpf/verifier.c that
      should be part of the previous patch in the series, commit
      e2d2115e56c4 "bpf: Do not include stack ptr register in precision
      backtracking bookkeeping", which already incorporated. ]
    Link: https://lore.kernel.org/all/[email protected]/
    Signed-off-by: Shung-Hsi Yu <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
selftests: drv-net: wait for iperf client to stop sending [+ + +]
Author: Nimrod Oren <[email protected]>
Date:   Tue Jul 22 15:26:55 2025 +0300

    selftests: drv-net: wait for iperf client to stop sending
    
    [ Upstream commit 86941382508850d58c11bdafe0fec646dfd31b09 ]
    
    A few packets may still be sent out during the termination of iperf
    processes. These late packets cause failures in rss_ctx.py when they
    arrive on queues expected to be empty.
    
    Example failure observed:
    
      Check failed 2 != 0 traffic on inactive queues (context 1):
        [0, 0, 1, 1, 386385, 397196, 0, 0, 0, 0, ...]
    
      Check failed 4 != 0 traffic on inactive queues (context 2):
        [0, 0, 0, 0, 2, 2, 247152, 253013, 0, 0, ...]
    
      Check failed 2 != 0 traffic on inactive queues (context 3):
        [0, 0, 0, 0, 0, 0, 1, 1, 282434, 283070, ...]
    
    To avoid such failures, wait until all client sockets for the requested
    port are either closed or in the TIME_WAIT state.
    
    Fixes: 847aa551fa78 ("selftests: drv-net: rss_ctx: factor out send traffic and check")
    Signed-off-by: Nimrod Oren <[email protected]>
    Reviewed-by: Gal Pressman <[email protected]>
    Reviewed-by: Carolina Jubran <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

selftests: mptcp: connect: also cover alt modes [+ + +]
Author: Matthieu Baerts (NGI0) <[email protected]>
Date:   Tue Jul 15 20:43:28 2025 +0200

    selftests: mptcp: connect: also cover alt modes
    
    commit 37848a456fc38c191aedfe41f662cc24db8c23d9 upstream.
    
    The "mmap" and "sendfile" alternate modes for mptcp_connect.sh/.c are
    available from the beginning, but only tested when mptcp_connect.sh is
    manually launched with "-m mmap" or "-m sendfile", not via the
    kselftests helpers.
    
    The MPTCP CI was manually running "mptcp_connect.sh -m mmap", but not
    "-m sendfile". Plus other CIs, especially the ones validating the stable
    releases, were not validating these alternate modes.
    
    To make sure these modes are validated by these CIs, add two new test
    programs executing mptcp_connect.sh with the alternate modes.
    
    Fixes: 048d19d444be ("mptcp: add basic kselftest for mptcp")
    Cc: [email protected]
    Reviewed-by: Geliang Tang <[email protected]>
    Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

selftests: mptcp: connect: also cover checksum [+ + +]
Author: Matthieu Baerts (NGI0) <[email protected]>
Date:   Tue Jul 15 20:43:29 2025 +0200

    selftests: mptcp: connect: also cover checksum
    
    commit fdf0f60a2bb02ba581d9e71d583e69dd0714a521 upstream.
    
    The checksum mode has been added a while ago, but it is only validated
    when manually launching mptcp_connect.sh with "-C".
    
    The different CIs were then not validating these MPTCP Connect tests
    with checksum enabled. To make sure they do, add a new test program
    executing mptcp_connect.sh with the checksum mode.
    
    Fixes: 94d66ba1d8e4 ("selftests: mptcp: enable checksum in mptcp_connect.sh")
    Cc: [email protected]
    Reviewed-by: Geliang Tang <[email protected]>
    Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
spi: cadence-quadspi: fix cleanup of rx_chan on failure paths [+ + +]
Author: Khairul Anuar Romli <[email protected]>
Date:   Mon Jun 30 17:11:56 2025 +0800

    spi: cadence-quadspi: fix cleanup of rx_chan on failure paths
    
    commit 04a8ff1bc3514808481ddebd454342ad902a3f60 upstream.
    
    Remove incorrect checks on cqspi->rx_chan that cause driver breakage
    during failure cleanup. Ensure proper resource freeing on the success
    path when operating in cqspi->use_direct_mode, preventing leaks and
    improving stability.
    
    Signed-off-by: Khairul Anuar Romli <[email protected]>
    Reviewed-by: Dan Carpenter <[email protected]>
    Link: https://patch.msgid.link/89765a2b94f047ded4f14babaefb7ef92ba07cb2.1751274389.git.khairul.anuar.romli@altera.com
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Linux: sprintf.h requires stdarg.h [+ + +]
Author: Stephen Rothwell <[email protected]>
Date:   Mon Jul 21 16:15:57 2025 +1000

    sprintf.h requires stdarg.h
    
    commit 0dec7201788b9152f06321d0dab46eed93834cda upstream.
    
    In file included from drivers/crypto/intel/qat/qat_common/adf_pm_dbgfs_utils.c:4:
    include/linux/sprintf.h:11:54: error: unknown type name 'va_list'
       11 | __printf(2, 0) int vsprintf(char *buf, const char *, va_list);
          |                                                      ^~~~~~~
    include/linux/sprintf.h:1:1: note: 'va_list' is defined in header '<stdarg.h>'; this is probably fixable by adding '#include <stdarg.h>'
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 39ced19b9e60 ("lib/vsprintf: split out sprintf() and friends")
    Signed-off-by: Stephen Rothwell <[email protected]>
    Cc: Andriy Shevchenko <[email protected]>
    Cc: Herbert Xu <[email protected]>
    Cc: Petr Mladek <[email protected]>
    Cc: Steven Rostedt <[email protected]>
    Cc: Rasmus Villemoes <[email protected]>
    Cc: Sergey Senozhatsky <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
staging: vchiq_arm: Make vchiq_shutdown never fail [+ + +]
Author: Stefan Wahren <[email protected]>
Date:   Tue Jul 15 18:11:08 2025 +0200

    staging: vchiq_arm: Make vchiq_shutdown never fail
    
    [ Upstream commit f2b8ebfb867011ddbefbdf7b04ad62626cbc2afd ]
    
    Most of the users of vchiq_shutdown ignore the return value,
    which is bad because this could lead to resource leaks.
    So instead of changing all calls to vchiq_shutdown, it's easier
    to make vchiq_shutdown never fail.
    
    Fixes: 71bad7f08641 ("staging: add bcm2708 vchiq driver")
    Signed-off-by: Stefan Wahren <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
timekeeping: Zero initialize system_counterval when querying time from phc drivers [+ + +]
Author: Markus Blöchl <[email protected]>
Date:   Sun Jul 20 15:54:51 2025 +0200

    timekeeping: Zero initialize system_counterval when querying time from phc drivers
    
    commit 67c632b4a7fbd6b76a08b86f4950f0f84de93439 upstream.
    
    Most drivers only populate the fields cycles and cs_id of system_counterval
    in their get_time_fn() callback for get_device_system_crosststamp(), unless
    they explicitly provide nanosecond values.
    
    When the use_nsecs field was added to struct system_counterval, most
    drivers did not care.  Clock sources other than CSID_GENERIC could then get
    converted in convert_base_to_cs() based on an uninitialized use_nsecs field,
    which usually results in -EINVAL during the following range check.
    
    Pass in a fully zero initialized system_counterval_t to cure that.
    
    Fixes: 6b2e29977518 ("timekeeping: Provide infrastructure for converting to/from a base clock")
    Signed-off-by: Markus Blöchl <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Acked-by: John Stultz <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
tools/hv: fcopy: Fix incorrect file path conversion [+ + +]
Author: Yasumasa Suenaga <[email protected]>
Date:   Sat Jun 28 11:22:17 2025 +0900

    tools/hv: fcopy: Fix incorrect file path conversion
    
    [ Upstream commit 0d86a8d65c1e69610bfe1a7a774f71ff111ed8c1 ]
    
    The hv_fcopy_uio_daemon fails to correctly handle file copy requests
    from Windows hosts (e.g. via Copy-VMFile) due to wchar_t size
    differences between Windows and Linux. On Linux, wchar_t is 32 bit,
    whereas Windows uses 16 bit wide characters.
    
    Fix this by ensuring that file transfers from host to Linux guest
    succeed with correctly decoded file names and paths.
    
    - Treats file name and path as __u16 arrays, not wchar_t*.
    - Allocates fixed-size buffers (W_MAX_PATH) for converted strings
      instead of using malloc.
    - Adds a check for target path length to prevent snprintf() buffer
      overflow.
    
    Fixes: 82b0945ce2c2 ("tools: hv: Add new fcopy application based on uio driver")
    Signed-off-by: Yasumasa Suenaga <[email protected]>
    Reviewed-by: Naman Jain <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Wei Liu <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
usb: typec: tcpm: allow switching to mode accessory to mux properly [+ + +]
Author: Michael Grzeschik <[email protected]>
Date:   Fri Apr 4 00:43:06 2025 +0200

    usb: typec: tcpm: allow switching to mode accessory to mux properly
    
    commit 8a50da849151e7e12b43c1d8fe7ad302223aef6b upstream.
    
    The funciton tcpm_acc_attach is not setting the proper state when
    calling tcpm_set_role. The function tcpm_set_role is currently only
    handling TYPEC_STATE_USB. For the tcpm_acc_attach to switch into other
    modal states tcpm_set_role needs to be extended by an extra state
    parameter. This patch is handling the proper state change when calling
    tcpm_acc_attach.
    
    Signed-off-by: Michael Grzeschik <[email protected]>
    Reviewed-by: Heikki Krogerus <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Stable-dep-of: bec15191d523 ("usb: typec: tcpm: apply vbus before data bringup in tcpm_src_attach")
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: typec: tcpm: allow to use sink in accessory mode [+ + +]
Author: Michael Grzeschik <[email protected]>
Date:   Fri Apr 4 00:43:04 2025 +0200

    usb: typec: tcpm: allow to use sink in accessory mode
    
    commit 64843d0ba96d3eae297025562111d57585273366 upstream.
    
    Since the function tcpm_acc_attach is not setting the data and role for
    for the sink case we extend it to check for it first.
    
    Signed-off-by: Michael Grzeschik <[email protected]>
    Reviewed-by: Heikki Krogerus <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Stable-dep-of: bec15191d523 ("usb: typec: tcpm: apply vbus before data bringup in tcpm_src_attach")
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: typec: tcpm: apply vbus before data bringup in tcpm_src_attach [+ + +]
Author: RD Babiera <[email protected]>
Date:   Wed Jun 18 23:06:04 2025 +0000

    usb: typec: tcpm: apply vbus before data bringup in tcpm_src_attach
    
    commit bec15191d52300defa282e3fd83820f69e447116 upstream.
    
    This patch fixes Type-C compliance test TD 4.7.6 - Try.SNK DRP Connect
    SNKAS.
    
    tVbusON has a limit of 275ms when entering SRC_ATTACHED. Compliance
    testers can interpret the TryWait.Src to Attached.Src transition after
    Try.Snk as being in Attached.Src the entire time, so ~170ms is lost
    to the debounce timer.
    
    Setting the data role can be a costly operation in host mode, and when
    completed after 100ms can cause Type-C compliance test check TD 4.7.5.V.4
    to fail.
    
    Turn VBUS on before tcpm_set_roles to meet timing requirement.
    
    Fixes: f0690a25a140 ("staging: typec: USB Type-C Port Manager (tcpm)")
    Cc: stable <[email protected]>
    Signed-off-by: RD Babiera <[email protected]>
    Reviewed-by: Badhri Jagan Sridharan <[email protected]>
    Reviewed-by: Heikki Krogerus <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
virtio_net: Enforce minimum TX ring size for reliability [+ + +]
Author: Laurent Vivier <[email protected]>
Date:   Wed May 21 11:22:36 2025 +0200

    virtio_net: Enforce minimum TX ring size for reliability
    
    [ Upstream commit 24b2f5df86aaebbe7bac40304eaf5a146c02367c ]
    
    The `tx_may_stop()` logic stops TX queues if free descriptors
    (`sq->vq->num_free`) fall below the threshold of (`MAX_SKB_FRAGS` + 2).
    If the total ring size (`ring_num`) is not strictly greater than this
    value, queues can become persistently stopped or stop after minimal
    use, severely degrading performance.
    
    A single sk_buff transmission typically requires descriptors for:
    - The virtio_net_hdr (1 descriptor)
    - The sk_buff's linear data (head) (1 descriptor)
    - Paged fragments (up to MAX_SKB_FRAGS descriptors)
    
    This patch enforces that the TX ring size ('ring_num') must be strictly
    greater than (MAX_SKB_FRAGS + 2). This ensures that the ring is
    always large enough to hold at least one maximally-fragmented packet
    plus at least one additional slot.
    
    Reported-by: Lei Yang <[email protected]>
    Signed-off-by: Laurent Vivier <[email protected]>
    Reviewed-by: Xuan Zhuo <[email protected]>
    Acked-by: Jason Wang <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Tested-by: Lei Yang <[email protected]>
    Acked-by: Michael S. Tsirkin <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
virtio_ring: Fix error reporting in virtqueue_resize [+ + +]
Author: Laurent Vivier <[email protected]>
Date:   Wed May 21 11:22:34 2025 +0200

    virtio_ring: Fix error reporting in virtqueue_resize
    
    [ Upstream commit 45ebc7e6c125ce93d2ddf82cd5bea20121bb0258 ]
    
    The virtqueue_resize() function was not correctly propagating error codes
    from its internal resize helper functions, specifically
    virtqueue_resize_packet() and virtqueue_resize_split(). If these helpers
    returned an error, but the subsequent call to virtqueue_enable_after_reset()
    succeeded, the original error from the resize operation would be masked.
    Consequently, virtqueue_resize() could incorrectly report success to its
    caller despite an underlying resize failure.
    
    This change restores the original code behavior:
    
           if (vdev->config->enable_vq_after_reset(_vq))
                   return -EBUSY;
    
           return err;
    
    Fix: commit ad48d53b5b3f ("virtio_ring: separate the logic of reset/enable from virtqueue_resize")
    Cc: [email protected]
    Signed-off-by: Laurent Vivier <[email protected]>
    Acked-by: Jason Wang <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Tested-by: Lei Yang <[email protected]>
    Acked-by: Michael S. Tsirkin <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
wifi: mt76: mt7925: adjust rm BSS flow to prevent next connection failure [+ + +]
Author: Ming Yen Hsieh <[email protected]>
Date:   Thu Jul 24 10:49:50 2025 -0400

    wifi: mt76: mt7925: adjust rm BSS flow to prevent next connection failure
    
    [ Upstream commit 0ebb60da8416c1d8e84c7e511a5687ce76a9467a ]
    
    Removing BSS without removing STAREC first will cause firmware
    abnormal and next connection fail.
    
    Fixes: 816161051a03 ("wifi: mt76: mt7925: Cleanup MLO settings post-disconnection")
    Cc: [email protected]
    Co-developed-by: Sean Wang <[email protected]>
    Signed-off-by: Sean Wang <[email protected]>
    Tested-by: Caleb Jorden <[email protected]>
    Signed-off-by: Ming Yen Hsieh <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Felix Fietkau <[email protected]>
    [ struct mt76_vif_link -> struct mt792x_vif  ]
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
x86/bugs: Fix use of possibly uninit value in amd_check_tsa_microcode() [+ + +]
Author: Michael Zhivich <[email protected]>
Date:   Wed Jul 23 09:40:19 2025 -0400

    x86/bugs: Fix use of possibly uninit value in amd_check_tsa_microcode()
    
    For kernels compiled with CONFIG_INIT_STACK_NONE=y, the value of __reserved
    field in zen_patch_rev union on the stack may be garbage.  If so, it will
    prevent correct microcode check when consulting p.ucode_rev, resulting in
    incorrect mitigation selection.
    
    This is a stable-only fix.
    
    Cc: <[email protected]>
    Signed-off-by: Michael Zhivich <[email protected]>
    Fixes: 7a0395f6607a5 ("x86/bugs: Add a Transient Scheduler Attacks mitigation")
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
x86/hyperv: Fix APIC ID and VP index confusion in hv_snp_boot_ap() [+ + +]
Author: Roman Kisel <[email protected]>
Date:   Wed Jul 23 23:20:27 2025 -0400

    x86/hyperv: Fix APIC ID and VP index confusion in hv_snp_boot_ap()
    
    [ Upstream commit 86c48271e0d60c82665e9fd61277002391efcef7 ]
    
    To start an application processor in SNP-isolated guest, a hypercall
    is used that takes a virtual processor index. The hv_snp_boot_ap()
    function uses that START_VP hypercall but passes as VP index to it
    what it receives as a wakeup_secondary_cpu_64 callback: the APIC ID.
    
    As those two aren't generally interchangeable, that may lead to hung
    APs if the VP index and the APIC ID don't match up.
    
    Update the parameter names to avoid confusion as to what the parameter
    is. Use the APIC ID to the VP index conversion to provide the correct
    input to the hypercall.
    
    Cc: [email protected]
    Fixes: 44676bb9d566 ("x86/hyperv: Add smp support for SEV-SNP guest")
    Signed-off-by: Roman Kisel <[email protected]>
    Reviewed-by: Michael Kelley <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Wei Liu <[email protected]>
    Message-ID: <[email protected]>
    [ changed HVCALL_GET_VP_INDEX_FROM_APIC_ID to HVCALL_GET_VP_ID_FROM_APIC_ID ]
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

x86/hyperv: Fix usage of cpu_online_mask to get valid cpu [+ + +]
Author: Nuno Das Neves <[email protected]>
Date:   Thu Jul 3 15:44:34 2025 -0700

    x86/hyperv: Fix usage of cpu_online_mask to get valid cpu
    
    [ Upstream commit bb169f80ed5a156ec3405e0e49c6b8e9ae264718 ]
    
    Accessing cpu_online_mask here is problematic because the cpus read lock
    is not held in this context.
    
    However, cpu_online_mask isn't needed here since the effective affinity
    mask is guaranteed to be valid in this callback. So, just use
    cpumask_first() to get the cpu instead of ANDing it with cpus_online_mask
    unnecessarily.
    
    Fixes: e39397d1fd68 ("x86/hyperv: implement an MSI domain for root partition")
    Reported-by: Michael Kelley <[email protected]>
    Closes: https://lore.kernel.org/linux-hyperv/SN6PR02MB4157639630F8AD2D8FD8F52FD475A@SN6PR02MB4157.namprd02.prod.outlook.com/
    Suggested-by: Thomas Gleixner <[email protected]>
    Signed-off-by: Nuno Das Neves <[email protected]>
    Reviewed-by: Michael Kelley <[email protected]>
    Link: https://lore.kernel.org/r/1751582677-30930-4-git-send-email-nunodasneves@linux.microsoft.com
    Signed-off-by: Wei Liu <[email protected]>
    Message-ID: <1751582677-30930-4-git-send-email-nunodasneves@linux.microsoft.com>
    Signed-off-by: Sasha Levin <[email protected]>

 
x86/traps: Initialize DR7 by writing its architectural reset value [+ + +]
Author: Xin Li (Intel) <[email protected]>
Date:   Fri Jun 20 16:15:04 2025 -0700

    x86/traps: Initialize DR7 by writing its architectural reset value
    
    commit fa7d0f83c5c4223a01598876352473cb3d3bd4d7 upstream.
    
    Initialize DR7 by writing its architectural reset value to always set
    bit 10, which is reserved to '1', when "clearing" DR7 so as not to
    trigger unanticipated behavior if said bit is ever unreserved, e.g. as
    a feature enabling flag with inverted polarity.
    
    Signed-off-by: Xin Li (Intel) <[email protected]>
    Signed-off-by: Dave Hansen <[email protected]>
    Reviewed-by: H. Peter Anvin (Intel) <[email protected]>
    Reviewed-by: Sohil Mehta <[email protected]>
    Acked-by: Peter Zijlstra (Intel) <[email protected]>
    Acked-by: Sean Christopherson <[email protected]>
    Tested-by: Sohil Mehta <[email protected]>
    Cc:[email protected]
    Link: https://lore.kernel.org/all/20250620231504.2676902-3-xin%40zytor.com
    [ context adjusted: no KVM_DEBUGREG_AUTO_SWITCH flag test" ]
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
 
xfrm: interface: fix use-after-free after changing collect_md xfrm interface [+ + +]
Author: Eyal Birger <[email protected]>
Date:   Thu Jul 3 10:02:58 2025 -0700

    xfrm: interface: fix use-after-free after changing collect_md xfrm interface
    
    [ Upstream commit a90b2a1aaacbcf0f91d7e4868ad6c51c5dee814b ]
    
    collect_md property on xfrm interfaces can only be set on device creation,
    thus xfrmi_changelink() should fail when called on such interfaces.
    
    The check to enforce this was done only in the case where the xi was
    returned from xfrmi_locate() which doesn't look for the collect_md
    interface, and thus the validation was never reached.
    
    Calling changelink would thus errornously place the special interface xi
    in the xfrmi_net->xfrmi hash, but since it also exists in the
    xfrmi_net->collect_md_xfrmi pointer it would lead to a double free when
    the net namespace was taken down [1].
    
    Change the check to use the xi from netdev_priv which is available earlier
    in the function to prevent changes in xfrm collect_md interfaces.
    
    [1] resulting oops:
    [    8.516540] kernel BUG at net/core/dev.c:12029!
    [    8.516552] Oops: invalid opcode: 0000 [#1] SMP NOPTI
    [    8.516559] CPU: 0 UID: 0 PID: 12 Comm: kworker/u80:0 Not tainted 6.15.0-virtme #5 PREEMPT(voluntary)
    [    8.516565] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
    [    8.516569] Workqueue: netns cleanup_net
    [    8.516579] RIP: 0010:unregister_netdevice_many_notify+0x101/0xab0
    [    8.516590] Code: 90 0f 0b 90 48 8b b0 78 01 00 00 48 8b 90 80 01 00 00 48 89 56 08 48 89 32 4c 89 80 78 01 00 00 48 89 b8 80 01 00 00 eb ac 90 <0f> 0b 48 8b 45 00 4c 8d a0 88 fe ff ff 48 39 c5 74 5c 41 80 bc 24
    [    8.516593] RSP: 0018:ffffa93b8006bd30 EFLAGS: 00010206
    [    8.516598] RAX: ffff98fe4226e000 RBX: ffffa93b8006bd58 RCX: ffffa93b8006bc60
    [    8.516601] RDX: 0000000000000004 RSI: 0000000000000000 RDI: dead000000000122
    [    8.516603] RBP: ffffa93b8006bdd8 R08: dead000000000100 R09: ffff98fe4133c100
    [    8.516605] R10: 0000000000000000 R11: 00000000000003d2 R12: ffffa93b8006be00
    [    8.516608] R13: ffffffff96c1a510 R14: ffffffff96c1a510 R15: ffffa93b8006be00
    [    8.516615] FS:  0000000000000000(0000) GS:ffff98fee73b7000(0000) knlGS:0000000000000000
    [    8.516619] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [    8.516622] CR2: 00007fcd2abd0700 CR3: 000000003aa40000 CR4: 0000000000752ef0
    [    8.516625] PKRU: 55555554
    [    8.516627] Call Trace:
    [    8.516632]  <TASK>
    [    8.516635]  ? rtnl_is_locked+0x15/0x20
    [    8.516641]  ? unregister_netdevice_queue+0x29/0xf0
    [    8.516650]  ops_undo_list+0x1f2/0x220
    [    8.516659]  cleanup_net+0x1ad/0x2e0
    [    8.516664]  process_one_work+0x160/0x380
    [    8.516673]  worker_thread+0x2aa/0x3c0
    [    8.516679]  ? __pfx_worker_thread+0x10/0x10
    [    8.516686]  kthread+0xfb/0x200
    [    8.516690]  ? __pfx_kthread+0x10/0x10
    [    8.516693]  ? __pfx_kthread+0x10/0x10
    [    8.516697]  ret_from_fork+0x82/0xf0
    [    8.516705]  ? __pfx_kthread+0x10/0x10
    [    8.516709]  ret_from_fork_asm+0x1a/0x30
    [    8.516718]  </TASK>
    
    Fixes: abc340b38ba2 ("xfrm: interface: support collect metadata mode")
    Reported-by: Lonial Con <[email protected]>
    Signed-off-by: Eyal Birger <[email protected]>
    Signed-off-by: Steffen Klassert <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

xfrm: Set transport header to fix UDP GRO handling [+ + +]
Author: Tobias Brunner <[email protected]>
Date:   Tue Jun 24 14:47:20 2025 +0200

    xfrm: Set transport header to fix UDP GRO handling
    
    [ Upstream commit 3ac9e29211fa2df5539ba0d742c8fe9fe95fdc79 ]
    
    The referenced commit replaced a call to __xfrm4|6_udp_encap_rcv() with
    a custom check for non-ESP markers.  But what the called function also
    did was setting the transport header to the ESP header.  The function
    that follows, esp4|6_gro_receive(), relies on that being set when it calls
    xfrm_parse_spi().  We have to set the full offset as the skb's head was
    not moved yet so adding just the UDP header length won't work.
    
    Fixes: e3fd05777685 ("xfrm: Fix UDP GRO handling for some corner cases")
    Signed-off-by: Tobias Brunner <[email protected]>
    Signed-off-by: Steffen Klassert <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

xfrm: state: initialize state_ptrs earlier in xfrm_state_find [+ + +]
Author: Sabrina Dubroca <[email protected]>
Date:   Fri May 23 17:11:17 2025 +0200

    xfrm: state: initialize state_ptrs earlier in xfrm_state_find
    
    [ Upstream commit 94d077c331730510d5611b438640a292097341f0 ]
    
    In case of preemption, xfrm_state_look_at will find a different
    pcpu_id and look up states for that other CPU. If we matched a state
    for CPU2 in the state_cache while the lookup started on CPU1, we will
    jump to "found", but the "best" state that we got will be ignored and
    we will enter the "acquire" block. This block uses state_ptrs, which
    isn't initialized at this point.
    
    Let's initialize state_ptrs just after taking rcu_read_lock. This will
    also prevent a possible misuse in the future, if someone adjusts this
    function.
    
    Reported-by: [email protected]
    Fixes: e952837f3ddb ("xfrm: state: fix out-of-bounds read during lookup")
    Signed-off-by: Sabrina Dubroca <[email protected]>
    Reviewed-by: Florian Westphal <[email protected]>
    Signed-off-by: Steffen Klassert <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

xfrm: state: use a consistent pcpu_id in xfrm_state_find [+ + +]
Author: Sabrina Dubroca <[email protected]>
Date:   Fri May 23 17:11:18 2025 +0200

    xfrm: state: use a consistent pcpu_id in xfrm_state_find
    
    [ Upstream commit 7eb11c0ab70777b9e5145a5ba1c0a2312c3980b2 ]
    
    If we get preempted during xfrm_state_find, we could run
    xfrm_state_look_at using a different pcpu_id than the one
    xfrm_state_find saw. This could lead to ignoring states that should
    have matched, and triggering acquires on a CPU that already has a pcpu
    state.
    
        xfrm_state_find starts on CPU1
        pcpu_id = 1
        lookup starts
        <preemption, we're now on CPU2>
        xfrm_state_look_at pcpu_id = 2
           finds a state
    found:
        best->pcpu_num != pcpu_id (2 != 1)
        if (!x && !error && !acquire_in_progress) {
            ...
            xfrm_state_alloc
            xfrm_init_tempstate
            ...
    
    This can be avoided by passing the original pcpu_id down to all
    xfrm_state_look_at() calls.
    
    Also switch to raw_smp_processor_id, disabling preempting just to
    re-enable it immediately doesn't really make sense.
    
    Fixes: 1ddf9916ac09 ("xfrm: Add support for per cpu xfrm state handling.")
    Signed-off-by: Sabrina Dubroca <[email protected]>
    Reviewed-by: Florian Westphal <[email protected]>
    Signed-off-by: Steffen Klassert <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>