Changelog in Linux kernel 6.15.5

 
8250: microchip: pci1xxxx: Add PCIe Hot reset disable support for Rev C0 and later devices [+ + +]
Author: Rengarajan S <[email protected]>
Date:   Fri Apr 25 20:25:00 2025 +0530

    8250: microchip: pci1xxxx: Add PCIe Hot reset disable support for Rev C0 and later devices
    
    [ Upstream commit c40b91e38eb8d4489def095d62ab476d45871323 ]
    
    Systems that issue PCIe hot reset requests during a suspend/resume
    cycle cause PCI1XXXX device revisions prior to C0 to get its UART
    configuration registers reset to hardware default values. This results
    in device inaccessibility and data transfer failures. Starting with
    Revision C0, support was added in the device hardware (via the Hot
    Reset Disable Bit) to allow resetting only the PCIe interface and its
    associated logic, but preserving the UART configuration during a hot
    reset. This patch enables the hot reset disable feature during suspend/
    resume for C0 and later revisions of the device.
    
    Signed-off-by: Rengarajan S <[email protected]>
    Reviewed-by: Jiri Slaby <[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]>

 
af_unix: Don't leave consecutive consumed OOB skbs. [+ + +]
Author: Kuniyuki Iwashima <[email protected]>
Date:   Wed Jun 18 21:13:55 2025 -0700

    af_unix: Don't leave consecutive consumed OOB skbs.
    
    [ Upstream commit 32ca245464e1479bfea8592b9db227fdc1641705 ]
    
    Jann Horn reported a use-after-free in unix_stream_read_generic().
    
    The following sequences reproduce the issue:
    
      $ python3
      from socket import *
      s1, s2 = socketpair(AF_UNIX, SOCK_STREAM)
      s1.send(b'x', MSG_OOB)
      s2.recv(1, MSG_OOB)     # leave a consumed OOB skb
      s1.send(b'y', MSG_OOB)
      s2.recv(1, MSG_OOB)     # leave a consumed OOB skb
      s1.send(b'z', MSG_OOB)
      s2.recv(1)              # recv 'z' illegally
      s2.recv(1, MSG_OOB)     # access 'z' skb (use-after-free)
    
    Even though a user reads OOB data, the skb holding the data stays on
    the recv queue to mark the OOB boundary and break the next recv().
    
    After the last send() in the scenario above, the sk2's recv queue has
    2 leading consumed OOB skbs and 1 real OOB skb.
    
    Then, the following happens during the next recv() without MSG_OOB
    
      1. unix_stream_read_generic() peeks the first consumed OOB skb
      2. manage_oob() returns the next consumed OOB skb
      3. unix_stream_read_generic() fetches the next not-yet-consumed OOB skb
      4. unix_stream_read_generic() reads and frees the OOB skb
    
    , and the last recv(MSG_OOB) triggers KASAN splat.
    
    The 3. above occurs because of the SO_PEEK_OFF code, which does not
    expect unix_skb_len(skb) to be 0, but this is true for such consumed
    OOB skbs.
    
      while (skip >= unix_skb_len(skb)) {
        skip -= unix_skb_len(skb);
        skb = skb_peek_next(skb, &sk->sk_receive_queue);
        ...
      }
    
    In addition to this use-after-free, there is another issue that
    ioctl(SIOCATMARK) does not function properly with consecutive consumed
    OOB skbs.
    
    So, nothing good comes out of such a situation.
    
    Instead of complicating manage_oob(), ioctl() handling, and the next
    ECONNRESET fix by introducing a loop for consecutive consumed OOB skbs,
    let's not leave such consecutive OOB unnecessarily.
    
    Now, while receiving an OOB skb in unix_stream_recv_urg(), if its
    previous skb is a consumed OOB skb, it is freed.
    
    [0]:
    BUG: KASAN: slab-use-after-free in unix_stream_read_actor (net/unix/af_unix.c:3027)
    Read of size 4 at addr ffff888106ef2904 by task python3/315
    
    CPU: 2 UID: 0 PID: 315 Comm: python3 Not tainted 6.16.0-rc1-00407-gec315832f6f9 #8 PREEMPT(voluntary)
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-4.fc42 04/01/2014
    Call Trace:
     <TASK>
     dump_stack_lvl (lib/dump_stack.c:122)
     print_report (mm/kasan/report.c:409 mm/kasan/report.c:521)
     kasan_report (mm/kasan/report.c:636)
     unix_stream_read_actor (net/unix/af_unix.c:3027)
     unix_stream_read_generic (net/unix/af_unix.c:2708 net/unix/af_unix.c:2847)
     unix_stream_recvmsg (net/unix/af_unix.c:3048)
     sock_recvmsg (net/socket.c:1063 (discriminator 20) net/socket.c:1085 (discriminator 20))
     __sys_recvfrom (net/socket.c:2278)
     __x64_sys_recvfrom (net/socket.c:2291 (discriminator 1) net/socket.c:2287 (discriminator 1) net/socket.c:2287 (discriminator 1))
     do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))
     entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
    RIP: 0033:0x7f8911fcea06
    Code: 5d e8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 75 19 83 e2 39 83 fa 08 75 11 e8 26 ff ff ff 66 0f 1f 44 00 00 48 8b 45 10 0f 05 <48> 8b 5d f8 c9 c3 0f 1f 40 00 f3 0f 1e fa 55 48 89 e5 48 83 ec 08
    RSP: 002b:00007fffdb0dccb0 EFLAGS: 00000202 ORIG_RAX: 000000000000002d
    RAX: ffffffffffffffda RBX: 00007fffdb0dcdc8 RCX: 00007f8911fcea06
    RDX: 0000000000000001 RSI: 00007f8911a5e060 RDI: 0000000000000006
    RBP: 00007fffdb0dccd0 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000001 R11: 0000000000000202 R12: 00007f89119a7d20
    R13: ffffffffc4653600 R14: 0000000000000000 R15: 0000000000000000
     </TASK>
    
    Allocated by task 315:
     kasan_save_stack (mm/kasan/common.c:48)
     kasan_save_track (mm/kasan/common.c:60 (discriminator 1) mm/kasan/common.c:69 (discriminator 1))
     __kasan_slab_alloc (mm/kasan/common.c:348)
     kmem_cache_alloc_node_noprof (./include/linux/kasan.h:250 mm/slub.c:4148 mm/slub.c:4197 mm/slub.c:4249)
     __alloc_skb (net/core/skbuff.c:660 (discriminator 4))
     alloc_skb_with_frags (./include/linux/skbuff.h:1336 net/core/skbuff.c:6668)
     sock_alloc_send_pskb (net/core/sock.c:2993)
     unix_stream_sendmsg (./include/net/sock.h:1847 net/unix/af_unix.c:2256 net/unix/af_unix.c:2418)
     __sys_sendto (net/socket.c:712 (discriminator 20) net/socket.c:727 (discriminator 20) net/socket.c:2226 (discriminator 20))
     __x64_sys_sendto (net/socket.c:2233 (discriminator 1) net/socket.c:2229 (discriminator 1) net/socket.c:2229 (discriminator 1))
     do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))
     entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
    
    Freed by task 315:
     kasan_save_stack (mm/kasan/common.c:48)
     kasan_save_track (mm/kasan/common.c:60 (discriminator 1) mm/kasan/common.c:69 (discriminator 1))
     kasan_save_free_info (mm/kasan/generic.c:579 (discriminator 1))
     __kasan_slab_free (mm/kasan/common.c:271)
     kmem_cache_free (mm/slub.c:4643 (discriminator 3) mm/slub.c:4745 (discriminator 3))
     unix_stream_read_generic (net/unix/af_unix.c:3010)
     unix_stream_recvmsg (net/unix/af_unix.c:3048)
     sock_recvmsg (net/socket.c:1063 (discriminator 20) net/socket.c:1085 (discriminator 20))
     __sys_recvfrom (net/socket.c:2278)
     __x64_sys_recvfrom (net/socket.c:2291 (discriminator 1) net/socket.c:2287 (discriminator 1) net/socket.c:2287 (discriminator 1))
     do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))
     entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
    
    The buggy address belongs to the object at ffff888106ef28c0
     which belongs to the cache skbuff_head_cache of size 224
    The buggy address is located 68 bytes inside of
     freed 224-byte region [ffff888106ef28c0, ffff888106ef29a0)
    
    The buggy address belongs to the physical page:
    page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff888106ef3cc0 pfn:0x106ef2
    head: order:1 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
    flags: 0x200000000000040(head|node=0|zone=2)
    page_type: f5(slab)
    raw: 0200000000000040 ffff8881001d28c0 ffffea000422fe00 0000000000000004
    raw: ffff888106ef3cc0 0000000080190010 00000000f5000000 0000000000000000
    head: 0200000000000040 ffff8881001d28c0 ffffea000422fe00 0000000000000004
    head: ffff888106ef3cc0 0000000080190010 00000000f5000000 0000000000000000
    head: 0200000000000001 ffffea00041bbc81 00000000ffffffff 00000000ffffffff
    head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
    page dumped because: kasan: bad access detected
    
    Memory state around the buggy address:
     ffff888106ef2800: 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc
     ffff888106ef2880: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb
    >ffff888106ef2900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                       ^
     ffff888106ef2980: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc
     ffff888106ef2a00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    
    Fixes: 314001f0bf92 ("af_unix: Add OOB support")
    Reported-by: Jann Horn <[email protected]>
    Signed-off-by: Kuniyuki Iwashima <[email protected]>
    Reviewed-by: Jann Horn <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

af_unix: Don't set -ECONNRESET for consumed OOB skb. [+ + +]
Author: Kuniyuki Iwashima <[email protected]>
Date:   Wed Jun 18 21:13:57 2025 -0700

    af_unix: Don't set -ECONNRESET for consumed OOB skb.
    
    [ Upstream commit 2a5a4841846b079b5fca5752fe94e59346fbda40 ]
    
    Christian Brauner reported that even after MSG_OOB data is consumed,
    calling close() on the receiver socket causes the peer's recv() to
    return -ECONNRESET:
    
      1. send() and recv() an OOB data.
    
        >>> from socket import *
        >>> s1, s2 = socketpair(AF_UNIX, SOCK_STREAM)
        >>> s1.send(b'x', MSG_OOB)
        1
        >>> s2.recv(1, MSG_OOB)
        b'x'
    
      2. close() for s2 sets ECONNRESET to s1->sk_err even though
         s2 consumed the OOB data
    
        >>> s2.close()
        >>> s1.recv(10, MSG_DONTWAIT)
        ...
        ConnectionResetError: [Errno 104] Connection reset by peer
    
    Even after being consumed, the skb holding the OOB 1-byte data stays in
    the recv queue to mark the OOB boundary and break recv() at that point.
    
    This must be considered while close()ing a socket.
    
    Let's skip the leading consumed OOB skb while checking the -ECONNRESET
    condition in unix_release_sock().
    
    Fixes: 314001f0bf92 ("af_unix: Add OOB support")
    Reported-by: Christian Brauner <[email protected]>
    Closes: https://lore.kernel.org/netdev/20250529-sinkt-abfeuern-e7b08200c6b0@brauner/
    Signed-off-by: Kuniyuki Iwashima <[email protected]>
    Acked-by: Christian Brauner <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ALSA: hda/realtek: Fix built-in mic on ASUS VivoBook X507UAR [+ + +]
Author: Salvatore Bonaccorso <[email protected]>
Date:   Wed Jun 25 20:41:28 2025 +0200

    ALSA: hda/realtek: Fix built-in mic on ASUS VivoBook X507UAR
    
    [ Upstream commit 7ab6847a03229e73bb7c58ca397630f699e79b53 ]
    
    The built-in mic of ASUS VivoBook X507UAR is broken recently by the fix
    of the pin sort. The fixup ALC256_FIXUP_ASUS_MIC_NO_PRESENCE is working
    for addressing the regression, too.
    
    Fixes: 3b4309546b48 ("ALSA: hda: Fix headset detection failure due to unstable sort")
    Reported-by: Igor Tamara <[email protected]>
    Closes: https://bugs.debian.org/1108069
    Signed-off-by: Salvatore Bonaccorso <[email protected]>
    Link: https://lore.kernel.org/CADdHDco7_o=4h_epjEAb92Dj-vUz_PoTC2-W9g5ncT2E0NzfeQ@mail.gmail.com
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: hda: Add new pci id for AMD GPU display HD audio controller [+ + +]
Author: Vijendar Mukunda <[email protected]>
Date:   Thu May 29 11:08:13 2025 +0530

    ALSA: hda: Add new pci id for AMD GPU display HD audio controller
    
    [ Upstream commit ab72bfce7647522e01a181e3600c3d14ff5c143e ]
    
    Add new pci id for AMD GPU display HD audio controller(device id- 0xab40).
    
    Signed-off-by: Vijendar Mukunda <[email protected]>
    Reviewed-by: Alex Deucher <[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: Ignore unsol events for cards being shut down [+ + +]
Author: Cezary Rojewski <[email protected]>
Date:   Fri May 30 16:13:09 2025 +0200

    ALSA: hda: Ignore unsol events for cards being shut down
    
    [ Upstream commit 3f100f524e75586537e337b34d18c8d604b398e7 ]
    
    For the classic snd_hda_intel driver, codec->card and bus->card point to
    the exact same thing. When snd_card_diconnect() fires, bus->shutdown is
    set thanks to azx_dev_disconnect(). card->shutdown is already set when
    that happens but both provide basically the same functionality.
    
    For the DSP snd_soc_avs driver where multiple codecs are located on
    multiple cards, bus->shutdown 'shortcut' is not sufficient. One codec
    card may be unregistered while other codecs are still operational.
    Proper check in form of card->shutdown must be used to verify whether
    the codec's card is being shut down.
    
    Reviewed-by: Amadeusz Sławiński <[email protected]>
    Signed-off-by: Cezary Rojewski <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: usb-audio: Add a quirk for Lenovo Thinkpad Thunderbolt 3 dock [+ + +]
Author: Mario Limonciello <[email protected]>
Date:   Tue May 27 12:26:56 2025 -0500

    ALSA: usb-audio: Add a quirk for Lenovo Thinkpad Thunderbolt 3 dock
    
    [ Upstream commit 4919353c7789b8047e06a9b2b943f775a8f72883 ]
    
    The audio controller in the Lenovo Thinkpad Thunderbolt 3 dock doesn't
    support reading the sampling rate.
    
    Add a quirk for it.
    
    Suggested-by: Takashi Iwai <[email protected]>
    Signed-off-by: Mario Limonciello <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: usb-audio: Fix out-of-bounds read in snd_usb_get_audioformat_uac3() [+ + +]
Author: Youngjun Lee <[email protected]>
Date:   Mon Jun 23 20:05:25 2025 +0900

    ALSA: usb-audio: Fix out-of-bounds read in snd_usb_get_audioformat_uac3()
    
    [ Upstream commit fb4e2a6e8f28a3c0ad382e363aeb9cd822007b8a ]
    
    In snd_usb_get_audioformat_uac3(), the length value returned from
    snd_usb_ctl_msg() is used directly for memory allocation without
    validation. This length is controlled by the USB device.
    
    The allocated buffer is cast to a uac3_cluster_header_descriptor
    and its fields are accessed without verifying that the buffer
    is large enough. If the device returns a smaller than expected
    length, this leads to an out-of-bounds read.
    
    Add a length check to ensure the buffer is large enough for
    uac3_cluster_header_descriptor.
    
    Signed-off-by: Youngjun Lee <[email protected]>
    Fixes: 9a2fe9b801f5 ("ALSA: usb: initial USB Audio Device Class 3.0 support")
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
amd/amdkfd: fix a kfd_process ref leak [+ + +]
Author: Yifan Zhang <[email protected]>
Date:   Wed May 21 18:06:28 2025 +0800

    amd/amdkfd: fix a kfd_process ref leak
    
    [ Upstream commit 90237b16ec1d7afa16e2173cc9a664377214cdd9 ]
    
    This patch is to fix a kfd_prcess ref leak.
    
    Signed-off-by: Yifan Zhang <[email protected]>
    Reviewed-by: Philip Yang <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
arm64: dts: qcom: Commonize X1 CRD DTSI [+ + +]
Author: Konrad Dybcio <[email protected]>
Date:   Mon Feb 3 15:43:24 2025 +0100

    arm64: dts: qcom: Commonize X1 CRD DTSI
    
    [ Upstream commit fbf5e007588f3f2bace84309b4a0d428ad619322 ]
    
    Certain X1 SKUs vary very noticeably, but the CRDs based on them don't.
    
    Commonize the existing X1E80100 DTSI to allow reuse.
    
    Signed-off-by: Konrad Dybcio <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: qcom: x1-crd: Fix vreg_l2j_1p2 voltage [+ + +]
Author: Stephan Gerhold <[email protected]>
Date:   Wed Apr 23 09:30:07 2025 +0200

    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]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: qcom: x1e78100-t14s: fix missing HID supplies [+ + +]
Author: Sasha Levin <[email protected]>
Date:   Tue Jul 1 21:58:48 2025 -0400

    arm64: dts: qcom: x1e78100-t14s: fix missing HID supplies
    
    [ Upstream commit 55e52d055393f11ba0193975d3db87af36f4b273 ]
    
    Add the missing HID supplies to avoid relying on other consumers to keep
    them on.
    
    This also avoids the following warnings on boot:
    
            i2c_hid_of 0-0010: supply vdd not found, using dummy regulator
            i2c_hid_of 0-0010: supply vddl not found, using dummy regulator
            i2c_hid_of 1-0015: supply vdd not found, using dummy regulator
            i2c_hid_of 1-002c: supply vdd not found, using dummy regulator
            i2c_hid_of 1-0015: supply vddl not found, using dummy regulator
            i2c_hid_of 1-002c: supply vddl not found, using dummy regulator
            i2c_hid_of 1-003a: supply vdd not found, using dummy regulator
            i2c_hid_of 1-003a: supply vddl not found, using dummy regulator
    
    Note that VCC3B is also used for things like the modem which are not yet
    described so mark the regulator as always-on for now.
    
    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]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: qcom: x1e78100-t14s: mark l12b and l15b always-on [+ + +]
Author: Sasha Levin <[email protected]>
Date:   Tue Jul 1 21:17:43 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]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: qcom: x1e80100-crd: mark l12b and l15b always-on [+ + +]
Author: Johan Hovold <[email protected]>
Date:   Fri Mar 14 15:54:33 2025 +0100

    arm64: dts: qcom: x1e80100-crd: mark l12b and l15b always-on
    
    [ Upstream commit abf89bc4bb09c16a53d693b09ea85225cf57ff39 ]
    
    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: bd50b1f5b6f3 ("arm64: dts: qcom: x1e80100: Add Compute Reference Device")
    Cc: [email protected]      # 6.8
    Cc: Abel Vesa <[email protected]>
    Cc: Rajendra Nayak <[email protected]>
    Cc: Sibi Sankar <[email protected]>
    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]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ASoC: amd: ps: fix for soundwire failures during hibernation exit sequence [+ + +]
Author: Vijendar Mukunda <[email protected]>
Date:   Mon Jun 23 14:14:55 2025 +0530

    ASoC: amd: ps: fix for soundwire failures during hibernation exit sequence
    
    [ Upstream commit dc6458ed95e40146699f9c523e34cb13ff127170 ]
    
    During the hibernate entry sequence, ACP registers will be reset to
    default values and acp ip will be completely powered off including acp
    SoundWire pads. During resume sequence, if acp SoundWire pad keeper enable
    register is not restored along with pad pulldown control register value,
    then SoundWire manager links won't be powered on correctly results in
    peripheral register access failures and completely audio function is
    broken.
    
    Add code to store the acp SoundWire pad keeper enable register and acp pad
    pulldown ctrl register values before entering into suspend state and
    restore the register values during resume sequence based on condition check
    for acp SoundWire pad keeper enable register for ACP6.3, ACP7.0 & ACP7.1
    platforms.
    
    Fixes: 491628388005 ("ASoC: amd: ps: add callback functions for acp pci driver pm ops")
    Signed-off-by: Vijendar Mukunda <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: amd: yc: Add DMI quirk for Lenovo IdeaPad Slim 5 15 [+ + +]
Author: Oliver Schramm <[email protected]>
Date:   Sun Jun 22 00:30:01 2025 +0200

    ASoC: amd: yc: Add DMI quirk for Lenovo IdeaPad Slim 5 15
    
    commit bf39286adc5e10ce3e32eb86ad316ae56f3b52a0 upstream.
    
    It's smaller brother has already received the patch to enable the microphone,
    now add it too to the DMI quirk table.
    
    Cc: [email protected]
    Signed-off-by: Oliver Schramm <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ASoC: codec: wcd9335: Convert to GPIO descriptors [+ + +]
Author: Peng Fan <[email protected]>
Date:   Mon Mar 24 19:51:29 2025 +0800

    ASoC: codec: wcd9335: Convert to GPIO descriptors
    
    [ Upstream commit d5099bc1b56417733f4cccf10c61ee74dadd5562 ]
    
    of_gpio.h is deprecated, update the driver to use GPIO descriptors.
    - Use dev_gpiod_get to get GPIO descriptor.
    - Use gpiod_set_value to configure output value.
    
    With legacy of_gpio API, the driver set gpio value 0 to assert reset,
    and 1 to deassert reset. And the reset-gpios use GPIO_ACTIVE_LOW flag in
    DTS, so set GPIOD_OUT_LOW when get GPIO descriptors, and set value 1 means
    output low, set value 0 means output high with gpiod API.
    
    The in-tree DTS files have the right polarity set up already so we can
    expect this to "just work"
    
    Reviewed-by: Linus Walleij <[email protected]>
    Signed-off-by: Peng Fan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Reviewed-by: Bartosz Golaszewski <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>
    Stable-dep-of: 9079db287fc3 ("ASoC: codecs: wcd9335: Fix missing free of regulator supplies")
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: codecs: wcd9335: Fix missing free of regulator supplies [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Mon May 26 11:47:01 2025 +0200

    ASoC: codecs: wcd9335: Fix missing free of regulator supplies
    
    [ Upstream commit 9079db287fc3e38e040b0edeb0a25770bb679c8e ]
    
    Driver gets and enables all regulator supplies in probe path
    (wcd9335_parse_dt() and wcd9335_power_on_reset()), but does not cleanup
    in final error paths and in unbind (missing remove() callback).  This
    leads to leaked memory and unbalanced regulator enable count during
    probe errors or unbind.
    
    Fix this by converting entire code into devm_regulator_bulk_get_enable()
    which also greatly simplifies the code.
    
    Fixes: 20aedafdf492 ("ASoC: wcd9335: add support to wcd9335 codec")
    Cc: [email protected]
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Link: https://patch.msgid.link/20250526-b4-b4-asoc-wcd9395-vdd-px-fixes-v1-1-0b8a2993b7d3@linaro.org
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: rt1320: fix speaker noise when volume bar is 100% [+ + +]
Author: Shuming Fan <[email protected]>
Date:   Mon Jun 2 16:58:51 2025 +0800

    ASoC: rt1320: fix speaker noise when volume bar is 100%
    
    [ Upstream commit 9adf2de86611ac108d07e769a699556d87f052e2 ]
    
    This patch updates the settings to fix the speaker noise.
    
    Signed-off-by: Shuming Fan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ata: ahci: Use correct DMI identifier for ASUSPRO-D840SA LPM quirk [+ + +]
Author: Niklas Cassel <[email protected]>
Date:   Tue Jun 24 09:40:30 2025 +0200

    ata: ahci: Use correct DMI identifier for ASUSPRO-D840SA LPM quirk
    
    commit 3e0809b1664b9dc650d9dbca9a2d3ac690d4f661 upstream.
    
    ASUS store the board name in DMI_PRODUCT_NAME rather than
    DMI_PRODUCT_VERSION. (Apparently it is only Lenovo that stores the
    model-name in DMI_PRODUCT_VERSION.)
    
    Use the correct DMI identifier, DMI_PRODUCT_NAME, to match the
    ASUSPRO-D840SA board, such that the quirk actually gets applied.
    
    Cc: [email protected]
    Reported-by: Andy Yang <[email protected]>
    Tested-by: Andy Yang <[email protected]>
    Closes: https://lore.kernel.org/linux-ide/aFb3wXAwJSSJUB7o@ryzen/
    Fixes: b5acc3628898 ("ata: ahci: Disallow LPM for ASUSPRO-D840SA motherboard")
    Reviewed-by: Hans de Goede <[email protected]>
    Reviewed-by: Damien Le Moal <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Niklas Cassel <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
atm: clip: prevent NULL deref in clip_push() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Fri Jun 20 14:28:44 2025 +0000

    atm: clip: prevent NULL deref in clip_push()
    
    [ Upstream commit b993ea46b3b601915ceaaf3c802adf11e7d6bac6 ]
    
    Blamed commit missed that vcc_destroy_socket() calls
    clip_push() with a NULL skb.
    
    If clip_devs is NULL, clip_push() then crashes when reading
    skb->truesize.
    
    Fixes: 93a2014afbac ("atm: fix a UAF in lec_arp_clear_vccs()")
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/netdev/[email protected]/T/#u
    Signed-off-by: Eric Dumazet <[email protected]>
    Cc: Cong Wang <[email protected]>
    Cc: Gengming Liu <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

atm: Release atm_dev_mutex after removing procfs in atm_dev_deregister(). [+ + +]
Author: Kuniyuki Iwashima <[email protected]>
Date:   Tue Jun 24 14:45:00 2025 -0700

    atm: Release atm_dev_mutex after removing procfs in atm_dev_deregister().
    
    [ Upstream commit a433791aeaea6e84df709e0b9584b9bbe040cd1c ]
    
    syzbot reported a warning below during atm_dev_register(). [0]
    
    Before creating a new device and procfs/sysfs for it, atm_dev_register()
    looks up a duplicated device by __atm_dev_lookup().  These operations are
    done under atm_dev_mutex.
    
    However, when removing a device in atm_dev_deregister(), it releases the
    mutex just after removing the device from the list that __atm_dev_lookup()
    iterates over.
    
    So, there will be a small race window where the device does not exist on
    the device list but procfs/sysfs are still not removed, triggering the
    splat.
    
    Let's hold the mutex until procfs/sysfs are removed in
    atm_dev_deregister().
    
    [0]:
    proc_dir_entry 'atm/atmtcp:0' already registered
    WARNING: CPU: 0 PID: 5919 at fs/proc/generic.c:377 proc_register+0x455/0x5f0 fs/proc/generic.c:377
    Modules linked in:
    CPU: 0 UID: 0 PID: 5919 Comm: syz-executor284 Not tainted 6.16.0-rc2-syzkaller-00047-g52da431bf03b #0 PREEMPT(full)
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
    RIP: 0010:proc_register+0x455/0x5f0 fs/proc/generic.c:377
    Code: 48 89 f9 48 c1 e9 03 80 3c 01 00 0f 85 a2 01 00 00 48 8b 44 24 10 48 c7 c7 20 c0 c2 8b 48 8b b0 d8 00 00 00 e8 0c 02 1c ff 90 <0f> 0b 90 90 48 c7 c7 80 f2 82 8e e8 0b de 23 09 48 8b 4c 24 28 48
    RSP: 0018:ffffc9000466fa30 EFLAGS: 00010282
    RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817ae248
    RDX: ffff888026280000 RSI: ffffffff817ae255 RDI: 0000000000000001
    RBP: ffff8880232bed48 R08: 0000000000000001 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000001 R12: ffff888076ed2140
    R13: dffffc0000000000 R14: ffff888078a61340 R15: ffffed100edda444
    FS:  00007f38b3b0c6c0(0000) GS:ffff888124753000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f38b3bdf953 CR3: 0000000076d58000 CR4: 00000000003526f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
     proc_create_data+0xbe/0x110 fs/proc/generic.c:585
     atm_proc_dev_register+0x112/0x1e0 net/atm/proc.c:361
     atm_dev_register+0x46d/0x890 net/atm/resources.c:113
     atmtcp_create+0x77/0x210 drivers/atm/atmtcp.c:369
     atmtcp_attach drivers/atm/atmtcp.c:403 [inline]
     atmtcp_ioctl+0x2f9/0xd60 drivers/atm/atmtcp.c:464
     do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159
     sock_do_ioctl+0x115/0x280 net/socket.c:1190
     sock_ioctl+0x227/0x6b0 net/socket.c:1311
     vfs_ioctl fs/ioctl.c:51 [inline]
     __do_sys_ioctl fs/ioctl.c:907 [inline]
     __se_sys_ioctl fs/ioctl.c:893 [inline]
     __x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:893
     do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
     do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    RIP: 0033:0x7f38b3b74459
    Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007f38b3b0c198 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
    RAX: ffffffffffffffda RBX: 00007f38b3bfe318 RCX: 00007f38b3b74459
    RDX: 0000000000000000 RSI: 0000000000006180 RDI: 0000000000000005
    RBP: 00007f38b3bfe310 R08: 65732f636f72702f R09: 65732f636f72702f
    R10: 65732f636f72702f R11: 0000000000000246 R12: 00007f38b3bcb0ac
    R13: 00007f38b3b0c1a0 R14: 0000200000000200 R15: 00007f38b3bcb03b
     </TASK>
    
    Fixes: 64bf69ddff76 ("[ATM]: deregistration removes device from atm_devs list immediately")
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/netdev/[email protected]/
    Tested-by: [email protected]
    Signed-off-by: Kuniyuki Iwashima <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
attach_recursive_mnt(): do not lock the covering tree when sliding something under it [+ + +]
Author: Al Viro <[email protected]>
Date:   Sun Jun 22 18:03:29 2025 -0400

    attach_recursive_mnt(): do not lock the covering tree when sliding something under it
    
    [ Upstream commit ce7df19686530920f2f6b636e71ce5eb1d9303ef ]
    
    If we are propagating across the userns boundary, we need to lock the
    mounts added there.  However, in case when something has already
    been mounted there and we end up sliding a new tree under that,
    the stuff that had been there before should not get locked.
    
    IOW, lock_mnt_tree() should be called before we reparent the
    preexisting tree on top of what we are adding.
    
    Fixes: 3bd045cc9c4b ("separate copying and locking mount tree on cross-userns copies")
    Signed-off-by: Al Viro <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
bcache: fix NULL pointer in cache_set_flush() [+ + +]
Author: Linggang Zeng <[email protected]>
Date:   Tue May 27 13:15:59 2025 +0800

    bcache: fix NULL pointer in cache_set_flush()
    
    [ Upstream commit 1e46ed947ec658f89f1a910d880cd05e42d3763e ]
    
    1. LINE#1794 - LINE#1887 is some codes about function of
       bch_cache_set_alloc().
    2. LINE#2078 - LINE#2142 is some codes about function of
       register_cache_set().
    3. register_cache_set() will call bch_cache_set_alloc() in LINE#2098.
    
     1794 struct cache_set *bch_cache_set_alloc(struct cache_sb *sb)
     1795 {
     ...
     1860         if (!(c->devices = kcalloc(c->nr_uuids, sizeof(void *), GFP_KERNEL)) ||
     1861             mempool_init_slab_pool(&c->search, 32, bch_search_cache) ||
     1862             mempool_init_kmalloc_pool(&c->bio_meta, 2,
     1863                                 sizeof(struct bbio) + sizeof(struct bio_vec) *
     1864                                 bucket_pages(c)) ||
     1865             mempool_init_kmalloc_pool(&c->fill_iter, 1, iter_size) ||
     1866             bioset_init(&c->bio_split, 4, offsetof(struct bbio, bio),
     1867                         BIOSET_NEED_BVECS|BIOSET_NEED_RESCUER) ||
     1868             !(c->uuids = alloc_bucket_pages(GFP_KERNEL, c)) ||
     1869             !(c->moving_gc_wq = alloc_workqueue("bcache_gc",
     1870                                                 WQ_MEM_RECLAIM, 0)) ||
     1871             bch_journal_alloc(c) ||
     1872             bch_btree_cache_alloc(c) ||
     1873             bch_open_buckets_alloc(c) ||
     1874             bch_bset_sort_state_init(&c->sort, ilog2(c->btree_pages)))
     1875                 goto err;
                          ^^^^^^^^
     1876
     ...
     1883         return c;
     1884 err:
     1885         bch_cache_set_unregister(c);
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^
     1886         return NULL;
     1887 }
     ...
     2078 static const char *register_cache_set(struct cache *ca)
     2079 {
     ...
     2098         c = bch_cache_set_alloc(&ca->sb);
     2099         if (!c)
     2100                 return err;
                          ^^^^^^^^^^
     ...
     2128         ca->set = c;
     2129         ca->set->cache[ca->sb.nr_this_dev] = ca;
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     ...
     2138         return NULL;
     2139 err:
     2140         bch_cache_set_unregister(c);
     2141         return err;
     2142 }
    
    (1) If LINE#1860 - LINE#1874 is true, then do 'goto err'(LINE#1875) and
        call bch_cache_set_unregister()(LINE#1885).
    (2) As (1) return NULL(LINE#1886), LINE#2098 - LINE#2100 would return.
    (3) As (2) has returned, LINE#2128 - LINE#2129 would do *not* give the
        value to c->cache[], it means that c->cache[] is NULL.
    
    LINE#1624 - LINE#1665 is some codes about function of cache_set_flush().
    As (1), in LINE#1885 call
    bch_cache_set_unregister()
    ---> bch_cache_set_stop()
         ---> closure_queue()
              -.-> cache_set_flush() (as below LINE#1624)
    
     1624 static void cache_set_flush(struct closure *cl)
     1625 {
     ...
     1654         for_each_cache(ca, c, i)
     1655                 if (ca->alloc_thread)
                              ^^
     1656                         kthread_stop(ca->alloc_thread);
     ...
     1665 }
    
    (4) In LINE#1655 ca is NULL(see (3)) in cache_set_flush() then the
        kernel crash occurred as below:
    [  846.712887] bcache: register_cache() error drbd6: cannot allocate memory
    [  846.713242] bcache: register_bcache() error : failed to register device
    [  846.713336] bcache: cache_set_free() Cache set 2f84bdc1-498a-4f2f-98a7-01946bf54287 unregistered
    [  846.713768] BUG: unable to handle kernel NULL pointer dereference at 00000000000009f8
    [  846.714790] PGD 0 P4D 0
    [  846.715129] Oops: 0000 [#1] SMP PTI
    [  846.715472] CPU: 19 PID: 5057 Comm: kworker/19:16 Kdump: loaded Tainted: G           OE    --------- -  - 4.18.0-147.5.1.el8_1.5es.3.x86_64 #1
    [  846.716082] Hardware name: ESPAN GI-25212/X11DPL-i, BIOS 2.1 06/15/2018
    [  846.716451] Workqueue: events cache_set_flush [bcache]
    [  846.716808] RIP: 0010:cache_set_flush+0xc9/0x1b0 [bcache]
    [  846.717155] Code: 00 4c 89 a5 b0 03 00 00 48 8b 85 68 f6 ff ff a8 08 0f 84 88 00 00 00 31 db 66 83 bd 3c f7 ff ff 00 48 8b 85 48 ff ff ff 74 28 <48> 8b b8 f8 09 00 00 48 85 ff 74 05 e8 b6 58 a2 e1 0f b7 95 3c f7
    [  846.718026] RSP: 0018:ffffb56dcf85fe70 EFLAGS: 00010202
    [  846.718372] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
    [  846.718725] RDX: 0000000000000001 RSI: 0000000040000001 RDI: 0000000000000000
    [  846.719076] RBP: ffffa0ccc0f20df8 R08: ffffa0ce1fedb118 R09: 000073746e657665
    [  846.719428] R10: 8080808080808080 R11: 0000000000000000 R12: ffffa0ce1fee8700
    [  846.719779] R13: ffffa0ccc0f211a8 R14: ffffa0cd1b902840 R15: ffffa0ccc0f20e00
    [  846.720132] FS:  0000000000000000(0000) GS:ffffa0ce1fec0000(0000) knlGS:0000000000000000
    [  846.720726] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  846.721073] CR2: 00000000000009f8 CR3: 00000008ba00a005 CR4: 00000000007606e0
    [  846.721426] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [  846.721778] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [  846.722131] PKRU: 55555554
    [  846.722467] Call Trace:
    [  846.722814]  process_one_work+0x1a7/0x3b0
    [  846.723157]  worker_thread+0x30/0x390
    [  846.723501]  ? create_worker+0x1a0/0x1a0
    [  846.723844]  kthread+0x112/0x130
    [  846.724184]  ? kthread_flush_work_fn+0x10/0x10
    [  846.724535]  ret_from_fork+0x35/0x40
    
    Now, check whether that ca is NULL in LINE#1655 to fix the issue.
    
    Signed-off-by: Linggang Zeng <[email protected]>
    Signed-off-by: Mingzhe Zou <[email protected]>
    Signed-off-by: Coly Li <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

bcache: remove unnecessary select MIN_HEAP [+ + +]
Author: Kuan-Wei Chiu <[email protected]>
Date:   Sun Jun 15 04:23:53 2025 +0800

    bcache: remove unnecessary select MIN_HEAP
    
    commit 95b2e31e1752494d477c5da89d6789f769b0d67b upstream.
    
    After reverting the transition to the generic min heap library, bcache no
    longer depends on MIN_HEAP.  The select entry can be removed to reduce
    code size and shrink the kernel's attack surface.
    
    This change effectively reverts the bcache-related part of commit
    92a8b224b833 ("lib/min_heap: introduce non-inline versions of min heap API
    functions").
    
    This is part of a series of changes to address a performance regression
    caused by the use of the generic min_heap implementation.
    
    As reported by Robert, bcache now suffers from latency spikes, with P100
    (max) latency increasing from 600 ms to 2.4 seconds every 5 minutes.
    These regressions degrade bcache's effectiveness as a low-latency cache
    layer and lead to frequent timeouts and application stalls in production
    environments.
    
    Link: https://lore.kernel.org/lkml/CAJhEC05+0S69z+3+FB2Cd0hD+pCRyWTKLEOsc8BOmH73p1m+KQ@mail.gmail.com
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 866898efbb25 ("bcache: remove heap-related macros and switch to generic min_heap")
    Fixes: 92a8b224b833 ("lib/min_heap: introduce non-inline versions of min heap API functions")
    Signed-off-by: Kuan-Wei Chiu <[email protected]>
    Reported-by: Robert Pang <[email protected]>
    Closes: https://lore.kernel.org/linux-bcache/CAJhEC06F_AtrPgw2-7CvCqZgeStgCtitbD-ryuPpXQA-JG5XXw@mail.gmail.com
    Acked-by: Coly Li <[email protected]>
    Cc: Ching-Chun (Jim) Huang <[email protected]>
    Cc: Kent Overstreet <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Bluetooth: hci_core: Fix use-after-free in vhci_flush() [+ + +]
Author: Kuniyuki Iwashima <[email protected]>
Date:   Tue Jun 17 09:58:13 2025 -0700

    Bluetooth: hci_core: Fix use-after-free in vhci_flush()
    
    [ Upstream commit 1d6123102e9fbedc8d25bf4731da6d513173e49e ]
    
    syzbot reported use-after-free in vhci_flush() without repro. [0]
    
    From the splat, a thread close()d a vhci file descriptor while
    its device was being used by iotcl() on another thread.
    
    Once the last fd refcnt is released, vhci_release() calls
    hci_unregister_dev(), hci_free_dev(), and kfree() for struct
    vhci_data, which is set to hci_dev->dev->driver_data.
    
    The problem is that there is no synchronisation after unlinking
    hdev from hci_dev_list in hci_unregister_dev().  There might be
    another thread still accessing the hdev which was fetched before
    the unlink operation.
    
    We can use SRCU for such synchronisation.
    
    Let's run hci_dev_reset() under SRCU and wait for its completion
    in hci_unregister_dev().
    
    Another option would be to restore hci_dev->destruct(), which was
    removed in commit 587ae086f6e4 ("Bluetooth: Remove unused
    hci-destruct cb").  However, this would not be a good solution, as
    we should not run hci_unregister_dev() while there are in-flight
    ioctl() requests, which could lead to another data-race KCSAN splat.
    
    Note that other drivers seem to have the same problem, for exmaple,
    virtbt_remove().
    
    [0]:
    BUG: KASAN: slab-use-after-free in skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline]
    BUG: KASAN: slab-use-after-free in skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937
    Read of size 8 at addr ffff88807cb8d858 by task syz.1.219/6718
    
    CPU: 1 UID: 0 PID: 6718 Comm: syz.1.219 Not tainted 6.16.0-rc1-syzkaller-00196-g08207f42d3ff #0 PREEMPT(full)
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
    Call Trace:
     <TASK>
     dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
     print_address_description mm/kasan/report.c:408 [inline]
     print_report+0xd2/0x2b0 mm/kasan/report.c:521
     kasan_report+0x118/0x150 mm/kasan/report.c:634
     skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline]
     skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937
     skb_queue_purge include/linux/skbuff.h:3368 [inline]
     vhci_flush+0x44/0x50 drivers/bluetooth/hci_vhci.c:69
     hci_dev_do_reset net/bluetooth/hci_core.c:552 [inline]
     hci_dev_reset+0x420/0x5c0 net/bluetooth/hci_core.c:592
     sock_do_ioctl+0xd9/0x300 net/socket.c:1190
     sock_ioctl+0x576/0x790 net/socket.c:1311
     vfs_ioctl fs/ioctl.c:51 [inline]
     __do_sys_ioctl fs/ioctl.c:907 [inline]
     __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893
     do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
     do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    RIP: 0033:0x7fcf5b98e929
    Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007fcf5c7b9038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
    RAX: ffffffffffffffda RBX: 00007fcf5bbb6160 RCX: 00007fcf5b98e929
    RDX: 0000000000000000 RSI: 00000000400448cb RDI: 0000000000000009
    RBP: 00007fcf5ba10b39 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
    R13: 0000000000000000 R14: 00007fcf5bbb6160 R15: 00007ffd6353d528
     </TASK>
    
    Allocated by task 6535:
     kasan_save_stack mm/kasan/common.c:47 [inline]
     kasan_save_track+0x3e/0x80 mm/kasan/common.c:68
     poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
     __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394
     kasan_kmalloc include/linux/kasan.h:260 [inline]
     __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359
     kmalloc_noprof include/linux/slab.h:905 [inline]
     kzalloc_noprof include/linux/slab.h:1039 [inline]
     vhci_open+0x57/0x360 drivers/bluetooth/hci_vhci.c:635
     misc_open+0x2bc/0x330 drivers/char/misc.c:161
     chrdev_open+0x4c9/0x5e0 fs/char_dev.c:414
     do_dentry_open+0xdf0/0x1970 fs/open.c:964
     vfs_open+0x3b/0x340 fs/open.c:1094
     do_open fs/namei.c:3887 [inline]
     path_openat+0x2ee5/0x3830 fs/namei.c:4046
     do_filp_open+0x1fa/0x410 fs/namei.c:4073
     do_sys_openat2+0x121/0x1c0 fs/open.c:1437
     do_sys_open fs/open.c:1452 [inline]
     __do_sys_openat fs/open.c:1468 [inline]
     __se_sys_openat fs/open.c:1463 [inline]
     __x64_sys_openat+0x138/0x170 fs/open.c:1463
     do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
     do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Freed by task 6535:
     kasan_save_stack mm/kasan/common.c:47 [inline]
     kasan_save_track+0x3e/0x80 mm/kasan/common.c:68
     kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576
     poison_slab_object mm/kasan/common.c:247 [inline]
     __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264
     kasan_slab_free include/linux/kasan.h:233 [inline]
     slab_free_hook mm/slub.c:2381 [inline]
     slab_free mm/slub.c:4643 [inline]
     kfree+0x18e/0x440 mm/slub.c:4842
     vhci_release+0xbc/0xd0 drivers/bluetooth/hci_vhci.c:671
     __fput+0x44c/0xa70 fs/file_table.c:465
     task_work_run+0x1d1/0x260 kernel/task_work.c:227
     exit_task_work include/linux/task_work.h:40 [inline]
     do_exit+0x6ad/0x22e0 kernel/exit.c:955
     do_group_exit+0x21c/0x2d0 kernel/exit.c:1104
     __do_sys_exit_group kernel/exit.c:1115 [inline]
     __se_sys_exit_group kernel/exit.c:1113 [inline]
     __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1113
     x64_sys_call+0x21ba/0x21c0 arch/x86/include/generated/asm/syscalls_64.h:232
     do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
     do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    The buggy address belongs to the object at ffff88807cb8d800
     which belongs to the cache kmalloc-1k of size 1024
    The buggy address is located 88 bytes inside of
     freed 1024-byte region [ffff88807cb8d800, ffff88807cb8dc00)
    
    Fixes: bf18c7118cf8 ("Bluetooth: vhci: Free driver_data on file release")
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=f62d64848fc4c7c30cd6
    Signed-off-by: Kuniyuki Iwashima <[email protected]>
    Acked-by: Paul Menzel <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: L2CAP: Fix L2CAP MTU negotiation [+ + +]
Author: Frédéric Danis <[email protected]>
Date:   Thu Jun 12 09:50:34 2025 +0200

    Bluetooth: L2CAP: Fix L2CAP MTU negotiation
    
    commit 042bb9603c44620dce98717a2d23235ca57a00d7 upstream.
    
    OBEX download from iPhone is currently slow due to small packet size
    used to transfer data which doesn't follow the MTU negotiated during
    L2CAP connection, i.e. 672 bytes instead of 32767:
    
      < ACL Data TX: Handle 11 flags 0x00 dlen 12
          L2CAP: Connection Request (0x02) ident 18 len 4
            PSM: 4103 (0x1007)
            Source CID: 72
      > ACL Data RX: Handle 11 flags 0x02 dlen 16
          L2CAP: Connection Response (0x03) ident 18 len 8
            Destination CID: 14608
            Source CID: 72
            Result: Connection successful (0x0000)
            Status: No further information available (0x0000)
      < ACL Data TX: Handle 11 flags 0x00 dlen 27
          L2CAP: Configure Request (0x04) ident 20 len 19
            Destination CID: 14608
            Flags: 0x0000
            Option: Maximum Transmission Unit (0x01) [mandatory]
              MTU: 32767
            Option: Retransmission and Flow Control (0x04) [mandatory]
              Mode: Enhanced Retransmission (0x03)
              TX window size: 63
              Max transmit: 3
              Retransmission timeout: 2000
              Monitor timeout: 12000
              Maximum PDU size: 1009
      > ACL Data RX: Handle 11 flags 0x02 dlen 26
          L2CAP: Configure Request (0x04) ident 72 len 18
            Destination CID: 72
            Flags: 0x0000
            Option: Retransmission and Flow Control (0x04) [mandatory]
              Mode: Enhanced Retransmission (0x03)
              TX window size: 32
              Max transmit: 255
              Retransmission timeout: 0
              Monitor timeout: 0
              Maximum PDU size: 65527
            Option: Frame Check Sequence (0x05) [mandatory]
              FCS: 16-bit FCS (0x01)
      < ACL Data TX: Handle 11 flags 0x00 dlen 29
          L2CAP: Configure Response (0x05) ident 72 len 21
            Source CID: 14608
            Flags: 0x0000
            Result: Success (0x0000)
            Option: Maximum Transmission Unit (0x01) [mandatory]
              MTU: 672
            Option: Retransmission and Flow Control (0x04) [mandatory]
              Mode: Enhanced Retransmission (0x03)
              TX window size: 32
              Max transmit: 255
              Retransmission timeout: 2000
              Monitor timeout: 12000
              Maximum PDU size: 1009
      > ACL Data RX: Handle 11 flags 0x02 dlen 32
          L2CAP: Configure Response (0x05) ident 20 len 24
            Source CID: 72
            Flags: 0x0000
            Result: Success (0x0000)
            Option: Maximum Transmission Unit (0x01) [mandatory]
              MTU: 32767
            Option: Retransmission and Flow Control (0x04) [mandatory]
              Mode: Enhanced Retransmission (0x03)
              TX window size: 63
              Max transmit: 3
              Retransmission timeout: 2000
              Monitor timeout: 12000
              Maximum PDU size: 1009
            Option: Frame Check Sequence (0x05) [mandatory]
              FCS: 16-bit FCS (0x01)
      ...
      > ACL Data RX: Handle 11 flags 0x02 dlen 680
          Channel: 72 len 676 ctrl 0x0202 [PSM 4103 mode Enhanced Retransmission (0x03)] {chan 8}
          I-frame: Unsegmented TxSeq 1 ReqSeq 2
      < ACL Data TX: Handle 11 flags 0x00 dlen 13
          Channel: 14608 len 9 ctrl 0x0204 [PSM 4103 mode Enhanced Retransmission (0x03)] {chan 8}
          I-frame: Unsegmented TxSeq 2 ReqSeq 2
      > ACL Data RX: Handle 11 flags 0x02 dlen 680
          Channel: 72 len 676 ctrl 0x0304 [PSM 4103 mode Enhanced Retransmission (0x03)] {chan 8}
          I-frame: Unsegmented TxSeq 2 ReqSeq 3
    
    The MTUs are negotiated for each direction. In this traces 32767 for
    iPhone->localhost and no MTU for localhost->iPhone, which based on
    '4.4 L2CAP_CONFIGURATION_REQ' (Core specification v5.4, Vol. 3, Part
    A):
    
      The only parameters that should be included in the
      L2CAP_CONFIGURATION_REQ packet are those that require different
      values than the default or previously agreed values.
      ...
      Any missing configuration parameters are assumed to have their
      most recently explicitly or implicitly accepted values.
    
    and '5.1 Maximum transmission unit (MTU)':
    
      If the remote device sends a positive L2CAP_CONFIGURATION_RSP
      packet it should include the actual MTU to be used on this channel
      for traffic flowing into the local device.
      ...
      The default value is 672 octets.
    
    is set by BlueZ to 672 bytes.
    
    It seems that the iPhone used the lowest negotiated value to transfer
    data to the localhost instead of the negotiated one for the incoming
    direction.
    
    This could be fixed by using the MTU negotiated for the other
    direction, if exists, in the L2CAP_CONFIGURATION_RSP.
    This allows to use segmented packets as in the following traces:
    
      < ACL Data TX: Handle 11 flags 0x00 dlen 12
            L2CAP: Connection Request (0x02) ident 22 len 4
              PSM: 4103 (0x1007)
              Source CID: 72
      < ACL Data TX: Handle 11 flags 0x00 dlen 27
            L2CAP: Configure Request (0x04) ident 24 len 19
              Destination CID: 2832
              Flags: 0x0000
              Option: Maximum Transmission Unit (0x01) [mandatory]
                MTU: 32767
              Option: Retransmission and Flow Control (0x04) [mandatory]
                Mode: Enhanced Retransmission (0x03)
                TX window size: 63
                Max transmit: 3
                Retransmission timeout: 2000
                Monitor timeout: 12000
                Maximum PDU size: 1009
      > ACL Data RX: Handle 11 flags 0x02 dlen 26
            L2CAP: Configure Request (0x04) ident 15 len 18
              Destination CID: 72
              Flags: 0x0000
              Option: Retransmission and Flow Control (0x04) [mandatory]
                Mode: Enhanced Retransmission (0x03)
                TX window size: 32
                Max transmit: 255
                Retransmission timeout: 0
                Monitor timeout: 0
                Maximum PDU size: 65527
              Option: Frame Check Sequence (0x05) [mandatory]
                FCS: 16-bit FCS (0x01)
      < ACL Data TX: Handle 11 flags 0x00 dlen 29
            L2CAP: Configure Response (0x05) ident 15 len 21
              Source CID: 2832
              Flags: 0x0000
              Result: Success (0x0000)
              Option: Maximum Transmission Unit (0x01) [mandatory]
                MTU: 32767
              Option: Retransmission and Flow Control (0x04) [mandatory]
                Mode: Enhanced Retransmission (0x03)
                TX window size: 32
                Max transmit: 255
                Retransmission timeout: 2000
                Monitor timeout: 12000
                Maximum PDU size: 1009
      > ACL Data RX: Handle 11 flags 0x02 dlen 32
            L2CAP: Configure Response (0x05) ident 24 len 24
              Source CID: 72
              Flags: 0x0000
              Result: Success (0x0000)
              Option: Maximum Transmission Unit (0x01) [mandatory]
                MTU: 32767
              Option: Retransmission and Flow Control (0x04) [mandatory]
                Mode: Enhanced Retransmission (0x03)
                TX window size: 63
                Max transmit: 3
                Retransmission timeout: 2000
                Monitor timeout: 12000
                Maximum PDU size: 1009
              Option: Frame Check Sequence (0x05) [mandatory]
                FCS: 16-bit FCS (0x01)
      ...
      > ACL Data RX: Handle 11 flags 0x02 dlen 1009
            Channel: 72 len 1005 ctrl 0x4202 [PSM 4103 mode Enhanced Retransmission (0x03)] {chan 8}
            I-frame: Start (len 21884) TxSeq 1 ReqSeq 2
      > ACL Data RX: Handle 11 flags 0x02 dlen 1009
            Channel: 72 len 1005 ctrl 0xc204 [PSM 4103 mode Enhanced Retransmission (0x03)] {chan 8}
            I-frame: Continuation TxSeq 2 ReqSeq 2
    
    This has been tested with kernel 5.4 and BlueZ 5.77.
    
    Cc: [email protected]
    Signed-off-by: Frédéric Danis <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
bnxt: properly flush XDP redirect lists [+ + +]
Author: Yan Zhai <[email protected]>
Date:   Mon Jun 23 09:06:38 2025 -0700

    bnxt: properly flush XDP redirect lists
    
    [ Upstream commit 9caca6ac0e26cd20efd490d8b3b2ffb1c7c00f6f ]
    
    We encountered following crash when testing a XDP_REDIRECT feature
    in production:
    
    [56251.579676] list_add corruption. next->prev should be prev (ffff93120dd40f30), but was ffffb301ef3a6740. (next=ffff93120dd
    40f30).
    [56251.601413] ------------[ cut here ]------------
    [56251.611357] kernel BUG at lib/list_debug.c:29!
    [56251.621082] Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
    [56251.632073] CPU: 111 UID: 0 PID: 0 Comm: swapper/111 Kdump: loaded Tainted: P           O       6.12.33-cloudflare-2025.6.
    3 #1
    [56251.653155] Tainted: [P]=PROPRIETARY_MODULE, [O]=OOT_MODULE
    [56251.663877] Hardware name: MiTAC GC68B-B8032-G11P6-GPU/S8032GM-HE-CFR, BIOS V7.020.B10-sig 01/22/2025
    [56251.682626] RIP: 0010:__list_add_valid_or_report+0x4b/0xa0
    [56251.693203] Code: 0e 48 c7 c7 68 e7 d9 97 e8 42 16 fe ff 0f 0b 48 8b 52 08 48 39 c2 74 14 48 89 f1 48 c7 c7 90 e7 d9 97 48
     89 c6 e8 25 16 fe ff <0f> 0b 4c 8b 02 49 39 f0 74 14 48 89 d1 48 c7 c7 e8 e7 d9 97 4c 89
    [56251.725811] RSP: 0018:ffff93120dd40b80 EFLAGS: 00010246
    [56251.736094] RAX: 0000000000000075 RBX: ffffb301e6bba9d8 RCX: 0000000000000000
    [56251.748260] RDX: 0000000000000000 RSI: ffff9149afda0b80 RDI: ffff9149afda0b80
    [56251.760349] RBP: ffff9131e49c8000 R08: 0000000000000000 R09: ffff93120dd40a18
    [56251.772382] R10: ffff9159cf2ce1a8 R11: 0000000000000003 R12: ffff911a80850000
    [56251.784364] R13: ffff93120fbc7000 R14: 0000000000000010 R15: ffff9139e7510e40
    [56251.796278] FS:  0000000000000000(0000) GS:ffff9149afd80000(0000) knlGS:0000000000000000
    [56251.809133] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [56251.819561] CR2: 00007f5e85e6f300 CR3: 00000038b85e2006 CR4: 0000000000770ef0
    [56251.831365] PKRU: 55555554
    [56251.838653] Call Trace:
    [56251.845560]  <IRQ>
    [56251.851943]  cpu_map_enqueue.cold+0x5/0xa
    [56251.860243]  xdp_do_redirect+0x2d9/0x480
    [56251.868388]  bnxt_rx_xdp+0x1d8/0x4c0 [bnxt_en]
    [56251.877028]  bnxt_rx_pkt+0x5f7/0x19b0 [bnxt_en]
    [56251.885665]  ? cpu_max_write+0x1e/0x100
    [56251.893510]  ? srso_alias_return_thunk+0x5/0xfbef5
    [56251.902276]  __bnxt_poll_work+0x190/0x340 [bnxt_en]
    [56251.911058]  bnxt_poll+0xab/0x1b0 [bnxt_en]
    [56251.919041]  ? srso_alias_return_thunk+0x5/0xfbef5
    [56251.927568]  ? srso_alias_return_thunk+0x5/0xfbef5
    [56251.935958]  ? srso_alias_return_thunk+0x5/0xfbef5
    [56251.944250]  __napi_poll+0x2b/0x160
    [56251.951155]  bpf_trampoline_6442548651+0x79/0x123
    [56251.959262]  __napi_poll+0x5/0x160
    [56251.966037]  net_rx_action+0x3d2/0x880
    [56251.973133]  ? srso_alias_return_thunk+0x5/0xfbef5
    [56251.981265]  ? srso_alias_return_thunk+0x5/0xfbef5
    [56251.989262]  ? __hrtimer_run_queues+0x162/0x2a0
    [56251.996967]  ? srso_alias_return_thunk+0x5/0xfbef5
    [56252.004875]  ? srso_alias_return_thunk+0x5/0xfbef5
    [56252.012673]  ? bnxt_msix+0x62/0x70 [bnxt_en]
    [56252.019903]  handle_softirqs+0xcf/0x270
    [56252.026650]  irq_exit_rcu+0x67/0x90
    [56252.032933]  common_interrupt+0x85/0xa0
    [56252.039498]  </IRQ>
    [56252.044246]  <TASK>
    [56252.048935]  asm_common_interrupt+0x26/0x40
    [56252.055727] RIP: 0010:cpuidle_enter_state+0xb8/0x420
    [56252.063305] Code: dc 01 00 00 e8 f9 79 3b ff e8 64 f7 ff ff 49 89 c5 0f 1f 44 00 00 31 ff e8 a5 32 3a ff 45 84 ff 0f 85 ae
     01 00 00 fb 45 85 f6 <0f> 88 88 01 00 00 48 8b 04 24 49 63 ce 4c 89 ea 48 6b f1 68 48 29
    [56252.088911] RSP: 0018:ffff93120c97fe98 EFLAGS: 00000202
    [56252.096912] RAX: ffff9149afd80000 RBX: ffff9141d3a72800 RCX: 0000000000000000
    [56252.106844] RDX: 00003329176c6b98 RSI: ffffffe36db3fdc7 RDI: 0000000000000000
    [56252.116733] RBP: 0000000000000002 R08: 0000000000000002 R09: 000000000000004e
    [56252.126652] R10: ffff9149afdb30c4 R11: 071c71c71c71c71c R12: ffffffff985ff860
    [56252.136637] R13: 00003329176c6b98 R14: 0000000000000002 R15: 0000000000000000
    [56252.146667]  ? cpuidle_enter_state+0xab/0x420
    [56252.153909]  cpuidle_enter+0x2d/0x40
    [56252.160360]  do_idle+0x176/0x1c0
    [56252.166456]  cpu_startup_entry+0x29/0x30
    [56252.173248]  start_secondary+0xf7/0x100
    [56252.179941]  common_startup_64+0x13e/0x141
    [56252.186886]  </TASK>
    
    From the crash dump, we found that the cpu_map_flush_list inside
    redirect info is partially corrupted: its list_head->next points to
    itself, but list_head->prev points to a valid list of unflushed bq
    entries.
    
    This turned out to be a result of missed XDP flush on redirect lists. By
    digging in the actual source code, we found that
    commit 7f0a168b0441 ("bnxt_en: Add completion ring pointer in TX and RX
    ring structures") incorrectly overwrites the event mask for XDP_REDIRECT
    in bnxt_rx_xdp. We can stably reproduce this crash by returning XDP_TX
    and XDP_REDIRECT randomly for incoming packets in a naive XDP program.
    Properly propagate the XDP_REDIRECT events back fixes the crash.
    
    Fixes: a7559bc8c17c ("bnxt: support transmit and free of aggregation buffers")
    Tested-by: Andrew Rzeznik <[email protected]>
    Signed-off-by: Yan Zhai <[email protected]>
    Acked-by: Jesper Dangaard Brouer <[email protected]>
    Reviewed-by: Michael Chan <[email protected]>
    Reviewed-by: Andy Gospodarek <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
bridge: mcast: Fix use-after-free during router port configuration [+ + +]
Author: Ido Schimmel <[email protected]>
Date:   Thu Jun 19 21:22:28 2025 +0300

    bridge: mcast: Fix use-after-free during router port configuration
    
    [ Upstream commit 7544f3f5b0b58c396f374d060898b5939da31709 ]
    
    The bridge maintains a global list of ports behind which a multicast
    router resides. The list is consulted during forwarding to ensure
    multicast packets are forwarded to these ports even if the ports are not
    member in the matching MDB entry.
    
    When per-VLAN multicast snooping is enabled, the per-port multicast
    context is disabled on each port and the port is removed from the global
    router port list:
    
     # ip link add name br1 up type bridge vlan_filtering 1 mcast_snooping 1
     # ip link add name dummy1 up master br1 type dummy
     # ip link set dev dummy1 type bridge_slave mcast_router 2
     $ bridge -d mdb show | grep router
     router ports on br1: dummy1
     # ip link set dev br1 type bridge mcast_vlan_snooping 1
     $ bridge -d mdb show | grep router
    
    However, the port can be re-added to the global list even when per-VLAN
    multicast snooping is enabled:
    
     # ip link set dev dummy1 type bridge_slave mcast_router 0
     # ip link set dev dummy1 type bridge_slave mcast_router 2
     $ bridge -d mdb show | grep router
     router ports on br1: dummy1
    
    Since commit 4b30ae9adb04 ("net: bridge: mcast: re-implement
    br_multicast_{enable, disable}_port functions"), when per-VLAN multicast
    snooping is enabled, multicast disablement on a port will disable the
    per-{port, VLAN} multicast contexts and not the per-port one. As a
    result, a port will remain in the global router port list even after it
    is deleted. This will lead to a use-after-free [1] when the list is
    traversed (when adding a new port to the list, for example):
    
     # ip link del dev dummy1
     # ip link add name dummy2 up master br1 type dummy
     # ip link set dev dummy2 type bridge_slave mcast_router 2
    
    Similarly, stale entries can also be found in the per-VLAN router port
    list. When per-VLAN multicast snooping is disabled, the per-{port, VLAN}
    contexts are disabled on each port and the port is removed from the
    per-VLAN router port list:
    
     # ip link add name br1 up type bridge vlan_filtering 1 mcast_snooping 1 mcast_vlan_snooping 1
     # ip link add name dummy1 up master br1 type dummy
     # bridge vlan add vid 2 dev dummy1
     # bridge vlan global set vid 2 dev br1 mcast_snooping 1
     # bridge vlan set vid 2 dev dummy1 mcast_router 2
     $ bridge vlan global show dev br1 vid 2 | grep router
           router ports: dummy1
     # ip link set dev br1 type bridge mcast_vlan_snooping 0
     $ bridge vlan global show dev br1 vid 2 | grep router
    
    However, the port can be re-added to the per-VLAN list even when
    per-VLAN multicast snooping is disabled:
    
     # bridge vlan set vid 2 dev dummy1 mcast_router 0
     # bridge vlan set vid 2 dev dummy1 mcast_router 2
     $ bridge vlan global show dev br1 vid 2 | grep router
           router ports: dummy1
    
    When the VLAN is deleted from the port, the per-{port, VLAN} multicast
    context will not be disabled since multicast snooping is not enabled
    on the VLAN. As a result, the port will remain in the per-VLAN router
    port list even after it is no longer member in the VLAN. This will lead
    to a use-after-free [2] when the list is traversed (when adding a new
    port to the list, for example):
    
     # ip link add name dummy2 up master br1 type dummy
     # bridge vlan add vid 2 dev dummy2
     # bridge vlan del vid 2 dev dummy1
     # bridge vlan set vid 2 dev dummy2 mcast_router 2
    
    Fix these issues by removing the port from the relevant (global or
    per-VLAN) router port list in br_multicast_port_ctx_deinit(). The
    function is invoked during port deletion with the per-port multicast
    context and during VLAN deletion with the per-{port, VLAN} multicast
    context.
    
    Note that deleting the multicast router timer is not enough as it only
    takes care of the temporary multicast router states (1 or 3) and not the
    permanent one (2).
    
    [1]
    BUG: KASAN: slab-out-of-bounds in br_multicast_add_router.part.0+0x3f1/0x560
    Write of size 8 at addr ffff888004a67328 by task ip/384
    [...]
    Call Trace:
     <TASK>
     dump_stack_lvl+0x6f/0xa0
     print_address_description.constprop.0+0x6f/0x350
     print_report+0x108/0x205
     kasan_report+0xdf/0x110
     br_multicast_add_router.part.0+0x3f1/0x560
     br_multicast_set_port_router+0x74e/0xac0
     br_setport+0xa55/0x1870
     br_port_slave_changelink+0x95/0x120
     __rtnl_newlink+0x5e8/0xa40
     rtnl_newlink+0x627/0xb00
     rtnetlink_rcv_msg+0x6fb/0xb70
     netlink_rcv_skb+0x11f/0x350
     netlink_unicast+0x426/0x710
     netlink_sendmsg+0x75a/0xc20
     __sock_sendmsg+0xc1/0x150
     ____sys_sendmsg+0x5aa/0x7b0
     ___sys_sendmsg+0xfc/0x180
     __sys_sendmsg+0x124/0x1c0
     do_syscall_64+0xbb/0x360
     entry_SYSCALL_64_after_hwframe+0x4b/0x53
    
    [2]
    BUG: KASAN: slab-use-after-free in br_multicast_add_router.part.0+0x378/0x560
    Read of size 8 at addr ffff888009f00840 by task bridge/391
    [...]
    Call Trace:
     <TASK>
     dump_stack_lvl+0x6f/0xa0
     print_address_description.constprop.0+0x6f/0x350
     print_report+0x108/0x205
     kasan_report+0xdf/0x110
     br_multicast_add_router.part.0+0x378/0x560
     br_multicast_set_port_router+0x6f9/0xac0
     br_vlan_process_options+0x8b6/0x1430
     br_vlan_rtm_process_one+0x605/0xa30
     br_vlan_rtm_process+0x396/0x4c0
     rtnetlink_rcv_msg+0x2f7/0xb70
     netlink_rcv_skb+0x11f/0x350
     netlink_unicast+0x426/0x710
     netlink_sendmsg+0x75a/0xc20
     __sock_sendmsg+0xc1/0x150
     ____sys_sendmsg+0x5aa/0x7b0
     ___sys_sendmsg+0xfc/0x180
     __sys_sendmsg+0x124/0x1c0
     do_syscall_64+0xbb/0x360
     entry_SYSCALL_64_after_hwframe+0x4b/0x53
    
    Fixes: 2796d846d74a ("net: bridge: vlan: convert mcast router global option to per-vlan entry")
    Fixes: 4b30ae9adb04 ("net: bridge: mcast: re-implement br_multicast_{enable, disable}_port functions")
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/all/[email protected]/T/
    Signed-off-by: Ido Schimmel <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
btrfs: fix a race between renames and directory logging [+ + +]
Author: Filipe Manana <[email protected]>
Date:   Wed May 28 12:28:27 2025 +0100

    btrfs: fix a race between renames and directory logging
    
    commit 3ca864de852bc91007b32d2a0d48993724f4abad upstream.
    
    We have a race between a rename and directory inode logging that if it
    happens and we crash/power fail before the rename completes, the next time
    the filesystem is mounted, the log replay code will end up deleting the
    file that was being renamed.
    
    This is best explained following a step by step analysis of an interleaving
    of steps that lead into this situation.
    
    Consider the initial conditions:
    
    1) We are at transaction N;
    
    2) We have directories A and B created in a past transaction (< N);
    
    3) We have inode X corresponding to a file that has 2 hardlinks, one in
       directory A and the other in directory B, so we'll name them as
       "A/foo_link1" and "B/foo_link2". Both hard links were persisted in a
       past transaction (< N);
    
    4) We have inode Y corresponding to a file that as a single hard link and
       is located in directory A, we'll name it as "A/bar". This file was also
       persisted in a past transaction (< N).
    
    The steps leading to a file loss are the following and for all of them we
    are under transaction N:
    
     1) Link "A/foo_link1" is removed, so inode's X last_unlink_trans field
        is updated to N, through btrfs_unlink() -> btrfs_record_unlink_dir();
    
     2) Task A starts a rename for inode Y, with the goal of renaming from
        "A/bar" to "A/baz", so we enter btrfs_rename();
    
     3) Task A inserts the new BTRFS_INODE_REF_KEY for inode Y by calling
        btrfs_insert_inode_ref();
    
     4) Because the rename happens in the same directory, we don't set the
        last_unlink_trans field of directoty A's inode to the current
        transaction id, that is, we don't cal btrfs_record_unlink_dir();
    
     5) Task A then removes the entries from directory A (BTRFS_DIR_ITEM_KEY
        and BTRFS_DIR_INDEX_KEY items) when calling __btrfs_unlink_inode()
        (actually the dir index item is added as a delayed item, but the
        effect is the same);
    
     6) Now before task A adds the new entry "A/baz" to directory A by
        calling btrfs_add_link(), another task, task B is logging inode X;
    
     7) Task B starts a fsync of inode X and after logging inode X, at
        btrfs_log_inode_parent() it calls btrfs_log_all_parents(), since
        inode X has a last_unlink_trans value of N, set at in step 1;
    
     8) At btrfs_log_all_parents() we search for all parent directories of
        inode X using the commit root, so we find directories A and B and log
        them. Bu when logging direct A, we don't have a dir index item for
        inode Y anymore, neither the old name "A/bar" nor for the new name
        "A/baz" since the rename has deleted the old name but has not yet
        inserted the new name - task A hasn't called yet btrfs_add_link() to
        do that.
    
        Note that logging directory A doesn't fallback to a transaction
        commit because its last_unlink_trans has a lower value than the
        current transaction's id (see step 4);
    
     9) Task B finishes logging directories A and B and gets back to
        btrfs_sync_file() where it calls btrfs_sync_log() to persist the log
        tree;
    
    10) Task B successfully persisted the log tree, btrfs_sync_log() completed
        with success, and a power failure happened.
    
        We have a log tree without any directory entry for inode Y, so the
        log replay code deletes the entry for inode Y, name "A/bar", from the
        subvolume tree since it doesn't exist in the log tree and the log
        tree is authorative for its index (we logged a BTRFS_DIR_LOG_INDEX_KEY
        item that covers the index range for the dentry that corresponds to
        "A/bar").
    
        Since there's no other hard link for inode Y and the log replay code
        deletes the name "A/bar", the file is lost.
    
    The issue wouldn't happen if task B synced the log only after task A
    called btrfs_log_new_name(), which would update the log with the new name
    for inode Y ("A/bar").
    
    Fix this by pinning the log root during renames before removing the old
    directory entry, and unpinning after btrfs_log_new_name() is called.
    
    Fixes: 259c4b96d78d ("btrfs: stop doing unnecessary log updates during a rename")
    CC: [email protected] # 5.18+
    Reviewed-by: Boris Burkov <[email protected]>
    Signed-off-by: Filipe Manana <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

btrfs: fix invalid inode pointer dereferences during log replay [+ + +]
Author: Filipe Manana <[email protected]>
Date:   Tue Jun 3 19:29:01 2025 +0100

    btrfs: fix invalid inode pointer dereferences during log replay
    
    commit 2dcf838cf5c2f0f4501edaa1680fcad03618d760 upstream.
    
    In a few places where we call read_one_inode(), if we get a NULL pointer
    we end up jumping into an error path, or fallthrough in case of
    __add_inode_ref(), where we then do something like this:
    
       iput(&inode->vfs_inode);
    
    which results in an invalid inode pointer that triggers an invalid memory
    access, resulting in a crash.
    
    Fix this by making sure we don't do such dereferences.
    
    Fixes: b4c50cbb01a1 ("btrfs: return a btrfs_inode from read_one_inode()")
    CC: [email protected] # 6.15+
    Signed-off-by: Filipe Manana <[email protected]>
    Reviewed-by: David Sterba <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

btrfs: fix qgroup reservation leak on failure to allocate ordered extent [+ + +]
Author: Filipe Manana <[email protected]>
Date:   Wed May 7 13:05:36 2025 +0100

    btrfs: fix qgroup reservation leak on failure to allocate ordered extent
    
    [ Upstream commit 1f2889f5594a2bc4c6a52634c4a51b93e785def5 ]
    
    If we fail to allocate an ordered extent for a COW write we end up leaking
    a qgroup data reservation since we called btrfs_qgroup_release_data() but
    we didn't call btrfs_qgroup_free_refroot() (which would happen when
    running the respective data delayed ref created by ordered extent
    completion or when finishing the ordered extent in case an error happened).
    
    So make sure we call btrfs_qgroup_free_refroot() if we fail to allocate an
    ordered extent for a COW write.
    
    Fixes: 7dbeaad0af7d ("btrfs: change timing for qgroup reserved space for ordered extents to fix reserved space leak")
    CC: [email protected] # 6.1+
    Reviewed-by: Boris Burkov <[email protected]>
    Reviewed-by: Qu Wenruo <[email protected]>
    Signed-off-by: Filipe Manana <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

btrfs: fix race between async reclaim worker and close_ctree() [+ + +]
Author: Filipe Manana <[email protected]>
Date:   Wed Jun 4 16:54:44 2025 +0100

    btrfs: fix race between async reclaim worker and close_ctree()
    
    [ Upstream commit a26bf338cdad3643a6e7c3d78a172baadba15c1a ]
    
    Syzbot reported an assertion failure due to an attempt to add a delayed
    iput after we have set BTRFS_FS_STATE_NO_DELAYED_IPUT in the fs_info
    state:
    
      WARNING: CPU: 0 PID: 65 at fs/btrfs/inode.c:3420 btrfs_add_delayed_iput+0x2f8/0x370 fs/btrfs/inode.c:3420
      Modules linked in:
      CPU: 0 UID: 0 PID: 65 Comm: kworker/u8:4 Not tainted 6.15.0-next-20250530-syzkaller #0 PREEMPT(full)
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
      Workqueue: btrfs-endio-write btrfs_work_helper
      RIP: 0010:btrfs_add_delayed_iput+0x2f8/0x370 fs/btrfs/inode.c:3420
      Code: 4e ad 5d (...)
      RSP: 0018:ffffc9000213f780 EFLAGS: 00010293
      RAX: ffffffff83c635b7 RBX: ffff888058920000 RCX: ffff88801c769e00
      RDX: 0000000000000000 RSI: 0000000000000100 RDI: 0000000000000000
      RBP: 0000000000000001 R08: ffff888058921b67 R09: 1ffff1100b12436c
      R10: dffffc0000000000 R11: ffffed100b12436d R12: 0000000000000001
      R13: dffffc0000000000 R14: ffff88807d748000 R15: 0000000000000100
      FS:  0000000000000000(0000) GS:ffff888125c53000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00002000000bd038 CR3: 000000006a142000 CR4: 00000000003526f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       <TASK>
       btrfs_put_ordered_extent+0x19f/0x470 fs/btrfs/ordered-data.c:635
       btrfs_finish_one_ordered+0x11d8/0x1b10 fs/btrfs/inode.c:3312
       btrfs_work_helper+0x399/0xc20 fs/btrfs/async-thread.c:312
       process_one_work kernel/workqueue.c:3238 [inline]
       process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321
       worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402
       kthread+0x70e/0x8a0 kernel/kthread.c:464
       ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148
       ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
       </TASK>
    
    This can happen due to a race with the async reclaim worker like this:
    
    1) The async metadata reclaim worker enters shrink_delalloc(), which calls
       btrfs_start_delalloc_roots() with an nr_pages argument that has a value
       less than LONG_MAX, and that in turn enters start_delalloc_inodes(),
       which sets the local variable 'full_flush' to false because
       wbc->nr_to_write is less than LONG_MAX;
    
    2) There it finds inode X in a root's delalloc list, grabs a reference for
       inode X (with igrab()), and triggers writeback for it with
       filemap_fdatawrite_wbc(), which creates an ordered extent for inode X;
    
    3) The unmount sequence starts from another task, we enter close_ctree()
       and we flush the workqueue fs_info->endio_write_workers, which waits
       for the ordered extent for inode X to complete and when dropping the
       last reference of the ordered extent, with btrfs_put_ordered_extent(),
       when we call btrfs_add_delayed_iput() we don't add the inode to the
       list of delayed iputs because it has a refcount of 2, so we decrement
       it to 1 and return;
    
    4) Shortly after at close_ctree() we call btrfs_run_delayed_iputs() which
       runs all delayed iputs, and then we set BTRFS_FS_STATE_NO_DELAYED_IPUT
       in the fs_info state;
    
    5) The async reclaim worker, after calling filemap_fdatawrite_wbc(), now
       calls btrfs_add_delayed_iput() for inode X and there we trigger an
       assertion failure since the fs_info state has the flag
       BTRFS_FS_STATE_NO_DELAYED_IPUT set.
    
    Fix this by setting BTRFS_FS_STATE_NO_DELAYED_IPUT only after we wait for
    the async reclaim workers to finish, after we call cancel_work_sync() for
    them at close_ctree(), and by running delayed iputs after wait for the
    reclaim workers to finish and before setting the bit.
    
    This race was recently introduced by commit 19e60b2a95f5 ("btrfs: add
    extra warning if delayed iput is added when it's not allowed"). Without
    the new validation at btrfs_add_delayed_iput(), this described scenario
    was safe because close_ctree() later calls btrfs_commit_super(). That
    will run any final delayed iputs added by reclaim workers in the window
    between the btrfs_run_delayed_iputs() and the the reclaim workers being
    shut down.
    
    Reported-by: [email protected]
    Link: https://lore.kernel.org/linux-btrfs/[email protected]/T/#u
    Fixes: 19e60b2a95f5 ("btrfs: add extra warning if delayed iput is added when it's not allowed")
    Reviewed-by: Boris Burkov <[email protected]>
    Signed-off-by: Filipe Manana <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

btrfs: handle csum tree error with rescue=ibadroots correctly [+ + +]
Author: Qu Wenruo <[email protected]>
Date:   Sat Jun 7 09:18:43 2025 +0930

    btrfs: handle csum tree error with rescue=ibadroots correctly
    
    [ Upstream commit 547e836661554dcfa15c212a3821664e85b4191a ]
    
    [BUG]
    There is syzbot based reproducer that can crash the kernel, with the
    following call trace: (With some debug output added)
    
     DEBUG: rescue=ibadroots parsed
     BTRFS: device fsid 14d642db-7b15-43e4-81e6-4b8fac6a25f8 devid 1 transid 8 /dev/loop0 (7:0) scanned by repro (1010)
     BTRFS info (device loop0): first mount of filesystem 14d642db-7b15-43e4-81e6-4b8fac6a25f8
     BTRFS info (device loop0): using blake2b (blake2b-256-generic) checksum algorithm
     BTRFS info (device loop0): using free-space-tree
     BTRFS warning (device loop0): checksum verify failed on logical 5312512 mirror 1 wanted 0xb043382657aede36608fd3386d6b001692ff406164733d94e2d9a180412c6003 found 0x810ceb2bacb7f0f9eb2bf3b2b15c02af867cb35ad450898169f3b1f0bd818651 level 0
     DEBUG: read tree root path failed for tree csum, ret=-5
     BTRFS warning (device loop0): checksum verify failed on logical 5328896 mirror 1 wanted 0x51be4e8b303da58e6340226815b70e3a93592dac3f30dd510c7517454de8567a found 0x51be4e8b303da58e634022a315b70e3a93592dac3f30dd510c7517454de8567a level 0
     BTRFS warning (device loop0): checksum verify failed on logical 5292032 mirror 1 wanted 0x1924ccd683be9efc2fa98582ef58760e3848e9043db8649ee382681e220cdee4 found 0x0cb6184f6e8799d9f8cb335dccd1d1832da1071d12290dab3b85b587ecacca6e level 0
     process 'repro' launched './file2' with NULL argv: empty string added
     DEBUG: no csum root, idatacsums=0 ibadroots=134217728
     Oops: general protection fault, probably for non-canonical address 0xdffffc0000000041: 0000 [#1] SMP KASAN NOPTI
     KASAN: null-ptr-deref in range [0x0000000000000208-0x000000000000020f]
     CPU: 5 UID: 0 PID: 1010 Comm: repro Tainted: G           OE       6.15.0-custom+ #249 PREEMPT(full)
     Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022
     RIP: 0010:btrfs_lookup_csum+0x93/0x3d0 [btrfs]
     Call Trace:
      <TASK>
      btrfs_lookup_bio_sums+0x47a/0xdf0 [btrfs]
      btrfs_submit_bbio+0x43e/0x1a80 [btrfs]
      submit_one_bio+0xde/0x160 [btrfs]
      btrfs_readahead+0x498/0x6a0 [btrfs]
      read_pages+0x1c3/0xb20
      page_cache_ra_order+0x4b5/0xc20
      filemap_get_pages+0x2d3/0x19e0
      filemap_read+0x314/0xde0
      __kernel_read+0x35b/0x900
      bprm_execve+0x62e/0x1140
      do_execveat_common.isra.0+0x3fc/0x520
      __x64_sys_execveat+0xdc/0x130
      do_syscall_64+0x54/0x1d0
      entry_SYSCALL_64_after_hwframe+0x76/0x7e
     ---[ end trace 0000000000000000 ]---
    
    [CAUSE]
    Firstly the fs has a corrupted csum tree root, thus to mount the fs we
    have to go "ro,rescue=ibadroots" mount option.
    
    Normally with that mount option, a bad csum tree root should set
    BTRFS_FS_STATE_NO_DATA_CSUMS flag, so that any future data read will
    ignore csum search.
    
    But in this particular case, we have the following call trace that
    caused NULL csum root, but not setting BTRFS_FS_STATE_NO_DATA_CSUMS:
    
    load_global_roots_objectid():
    
                    ret = btrfs_search_slot();
                    /* Succeeded */
                    btrfs_item_key_to_cpu()
                    found = true;
                    /* We found the root item for csum tree. */
                    root = read_tree_root_path();
                    if (IS_ERR(root)) {
                            if (!btrfs_test_opt(fs_info, IGNOREBADROOTS))
                            /*
                             * Since we have rescue=ibadroots mount option,
                             * @ret is still 0.
                             */
                            break;
            if (!found || ret) {
                    /* @found is true, @ret is 0, error handling for csum
                     * tree is skipped.
                     */
            }
    
    This means we completely skipped to set BTRFS_FS_STATE_NO_DATA_CSUMS if
    the csum tree is corrupted, which results unexpected later csum lookup.
    
    [FIX]
    If read_tree_root_path() failed, always populate @ret to the error
    number.
    
    As at the end of the function, we need @ret to determine if we need to
    do the extra error handling for csum tree.
    
    Fixes: abed4aaae4f7 ("btrfs: track the csum, extent, and free space trees in a rb tree")
    Reported-by: Zhiyu Zhang <[email protected]>
    Reported-by: Longxing Li <[email protected]>
    Reviewed-by: David Sterba <[email protected]>
    Signed-off-by: Qu Wenruo <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

btrfs: update superblock's device bytes_used when dropping chunk [+ + +]
Author: Mark Harmstone <[email protected]>
Date:   Thu May 29 10:37:44 2025 +0100

    btrfs: update superblock's device bytes_used when dropping chunk
    
    commit ae4477f937569d097ca5dbce92a89ba384b49bc6 upstream.
    
    Each superblock contains a copy of the device item for that device. In a
    transaction which drops a chunk but doesn't create any new ones, we were
    correctly updating the device item in the chunk tree but not copying
    over the new bytes_used value to the superblock.
    
    This can be seen by doing the following:
    
      # dd if=/dev/zero of=test bs=4096 count=2621440
      # mkfs.btrfs test
      # mount test /root/temp
    
      # cd /root/temp
      # for i in {00..10}; do dd if=/dev/zero of=$i bs=4096 count=32768; done
      # sync
      # rm *
      # sync
      # btrfs balance start -dusage=0 .
      # sync
    
      # cd
      # umount /root/temp
      # btrfs check test
    
    For btrfs-check to detect this, you will also need my patch at
    https://github.com/kdave/btrfs-progs/pull/991.
    
    Change btrfs_remove_dev_extents() so that it adds the devices to the
    fs_info->post_commit_list if they're not there already. This causes
    btrfs_commit_device_sizes() to be called, which updates the bytes_used
    value in the superblock.
    
    Fixes: bbbf7243d62d ("btrfs: combine device update operations during transaction commit")
    CC: [email protected] # 5.10+
    Reviewed-by: Qu Wenruo <[email protected]>
    Signed-off-by: Mark Harmstone <[email protected]>
    Reviewed-by: David Sterba <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

btrfs: use unsigned types for constants defined as bit shifts [+ + +]
Author: David Sterba <[email protected]>
Date:   Tue Apr 22 17:55:41 2025 +0200

    btrfs: use unsigned types for constants defined as bit shifts
    
    [ Upstream commit 05a6ec865d091fe8244657df8063f74e704d1711 ]
    
    The unsigned type is a recommended practice (CWE-190, CWE-194) for bit
    shifts to avoid problems with potential unwanted sign extensions.
    Although there are no such cases in btrfs codebase, follow the
    recommendation.
    
    Reviewed-by: Boris Burkov <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Stable-dep-of: 1f2889f5594a ("btrfs: fix qgroup reservation leak on failure to allocate ordered extent")
    Signed-off-by: Sasha Levin <[email protected]>

 
bus: mhi: host: pci_generic: Add Telit FN920C04 modem support [+ + +]
Author: Daniele Palmas <[email protected]>
Date:   Tue Apr 1 11:34:58 2025 +0200

    bus: mhi: host: pci_generic: Add Telit FN920C04 modem support
    
    [ Upstream commit 6348f62ef7ecc5855b710a7d4ea682425c38bb80 ]
    
    Add SDX35 based modem Telit FN920C04.
    
    $ lspci -vv
    01:00.0 Unassigned class [ff00]: Qualcomm Device 011a
            Subsystem: Device 1c5d:2020
    
    Signed-off-by: Daniele Palmas <[email protected]>
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
ceph: fix possible integer overflow in ceph_zero_objects() [+ + +]
Author: Dmitry Kandybka <[email protected]>
Date:   Tue Apr 22 12:32:04 2025 +0300

    ceph: fix possible integer overflow in ceph_zero_objects()
    
    [ Upstream commit 0abd87942e0c93964e93224836944712feba1d91 ]
    
    In 'ceph_zero_objects', promote 'object_size' to 'u64' to avoid possible
    integer overflow.
    
    Compile tested only.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Signed-off-by: Dmitry Kandybka <[email protected]>
    Reviewed-by: Viacheslav Dubeyko <[email protected]>
    Signed-off-by: Ilya Dryomov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
cifs: Correctly set SMB1 SessionKey field in Session Setup Request [+ + +]
Author: Pali Rohár <[email protected]>
Date:   Sat Nov 2 17:58:31 2024 +0100

    cifs: Correctly set SMB1 SessionKey field in Session Setup Request
    
    [ Upstream commit 89381c72d52094988e11d23ef24a00066a0fa458 ]
    
    [MS-CIFS] specification in section 2.2.4.53.1 where is described
    SMB_COM_SESSION_SETUP_ANDX Request, for SessionKey field says:
    
        The client MUST set this field to be equal to the SessionKey field in
        the SMB_COM_NEGOTIATE Response for this SMB connection.
    
    Linux SMB client currently set this field to zero. This is working fine
    against Windows NT SMB servers thanks to [MS-CIFS] product behavior <94>:
    
        Windows NT Server ignores the client's SessionKey.
    
    For compatibility with [MS-CIFS], set this SessionKey field in Session
    Setup Request to value retrieved from Negotiate response.
    
    Signed-off-by: Pali Rohár <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>
cifs: Fix cifs_query_path_info() for Windows NT servers [+ + +]
Author: Pali Rohár <[email protected]>
Date:   Tue Dec 31 16:06:22 2024 +0100

    cifs: Fix cifs_query_path_info() for Windows NT servers
    
    [ Upstream commit a3e771afbb3bce91c8296828304903e7348003fe ]
    
    For TRANS2 QUERY_PATH_INFO request when the path does not exist, the
    Windows NT SMB server returns error response STATUS_OBJECT_NAME_NOT_FOUND
    or ERRDOS/ERRbadfile without the SMBFLG_RESPONSE flag set. Similarly it
    returns STATUS_DELETE_PENDING when the file is being deleted. And looks
    like that any error response from TRANS2 QUERY_PATH_INFO does not have
    SMBFLG_RESPONSE flag set.
    
    So relax check in check_smb_hdr() for detecting if the packet is response
    for this special case.
    
    This change fixes stat() operation against Windows NT SMB servers and also
    all operations which depends on -ENOENT result from stat like creat() or
    mkdir().
    
    Signed-off-by: Pali Rohár <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

cifs: Fix encoding of SMB1 Session Setup NTLMSSP Request in non-UNICODE mode [+ + +]
Author: Pali Rohár <[email protected]>
Date:   Sun Oct 6 19:24:29 2024 +0200

    cifs: Fix encoding of SMB1 Session Setup NTLMSSP Request in non-UNICODE mode
    
    [ Upstream commit 6510ef4230b68c960309e0c1d6eb3e32eb785142 ]
    
    SMB1 Session Setup NTLMSSP Request in non-UNICODE mode is similar to
    UNICODE mode, just strings are encoded in ASCII and not in UTF-16.
    
    With this change it is possible to setup SMB1 session with NTLM
    authentication in non-UNICODE mode with Windows SMB server.
    
    This change fixes mounting SMB1 servers with -o nounicode mount option
    together with -o sec=ntlmssp mount option (which is the default sec=).
    
    Signed-off-by: Pali Rohár <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
coresight: Only check bottom two claim bits [+ + +]
Author: James Clark <[email protected]>
Date:   Tue Mar 25 11:58:47 2025 +0000

    coresight: Only check bottom two claim bits
    
    [ Upstream commit a4e65842e1142aa18ef36113fbd81d614eaefe5a ]
    
    The use of the whole register and == could break the claim mechanism if
    any of the other bits are used in the future. The referenced doc "PSCI -
    ARM DEN 0022D" also says to only read and clear the bottom two bits.
    
    Use FIELD_GET() to extract only the relevant part.
    
    Reviewed-by: Leo Yan <[email protected]>
    Reviewed-by: Yeoreum Yun <[email protected]>
    Signed-off-by: James Clark <[email protected]>
    Signed-off-by: Suzuki K Poulose <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
crypto: powerpc/poly1305 - add depends on BROKEN for now [+ + +]
Author: Eric Biggers <[email protected]>
Date:   Tue May 20 10:39:29 2025 +0800

    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]>
    Signed-off-by: Sasha Levin <[email protected]>

 
cxl/ras: Fix CPER handler device confusion [+ + +]
Author: Dan Williams <[email protected]>
Date:   Thu Jun 12 12:20:43 2025 -0700

    cxl/ras: Fix CPER handler device confusion
    
    [ Upstream commit 3c70ec71abdaf4e4fa48cd8fdfbbd864d78235a8 ]
    
    By inspection, cxl_cper_handle_prot_err() is making a series of fragile
    assumptions that can lead to crashes:
    
    1/ It assumes that endpoints identified in the record are a CXL-type-3
       device, nothing guarantees that.
    
    2/ It assumes that the device is bound to the cxl_pci driver, nothing
       guarantees that.
    
    3/ Minor, it holds the device lock over the switch-port tracing for no
       reason as the trace is 100% generated from data in the record.
    
    Correct those by checking that the PCIe endpoint parents a cxl_memdev
    before assuming the format of the driver data, and move the lock to where
    it is required. Consequently this also makes the implementation ready for
    CXL accelerators that are not bound to cxl_pci.
    
    Fixes: 36f257e3b0ba ("acpi/ghes, cxl/pci: Process CXL CPER Protocol Errors")
    Cc: Terry Bowman <[email protected]>
    Cc: Li Ming <[email protected]>
    Cc: Alison Schofield <[email protected]>
    Cc: Ira Weiny <[email protected]>
    Cc: Tony Luck <[email protected]>
    Reviewed-by: Smita Koralahalli <[email protected]>
    Reviewed-by: Dave Jiang <[email protected]>
    Signed-off-by: Dan Williams <[email protected]>
    Reviewed-by: Jonathan Cameron <[email protected]>
    Reviewed-by: Li Ming <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Dave Jiang <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
cxl/region: Add a dev_err() on missing target list entries [+ + +]
Author: Robert Richter <[email protected]>
Date:   Fri May 9 17:06:58 2025 +0200

    cxl/region: Add a dev_err() on missing target list entries
    
    [ Upstream commit d90acdf49e18029cfe4194475c45ef143657737a ]
    
    Broken target lists are hard to discover as the driver fails at a
    later initialization stage. Add an error message for this.
    
    Example log messages:
    
      cxl_mem mem1: failed to find endpoint6:0000:e0:01.3 in target list of decoder1.1
      cxl_port endpoint6: failed to register decoder6.0: -6
      cxl_port endpoint6: probe: 0
    
    Signed-off-by: Robert Richter <[email protected]>
    Reviewed-by: Gregory Price <[email protected]>
    Reviewed-by: Jonathan Cameron <[email protected]>
    Reviewed-by: Dave Jiang <[email protected]>
    Reviewed-by: Dan Williams <[email protected]>
    Reviewed-by: Alison Schofield <[email protected]>
    Reviewed-by: "Fabio M. De Francesco" <[email protected]>
    Tested-by: Gregory Price <[email protected]>
    Acked-by: Dan Williams <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Dave Jiang <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
cxl: core/region - ignore interleave granularity when ways=1 [+ + +]
Author: Gregory Price <[email protected]>
Date:   Wed Apr 2 19:25:52 2025 -0400

    cxl: core/region - ignore interleave granularity when ways=1
    
    [ Upstream commit ce32b0c9c522e5a69ef9c62a56d6ca08fb036d67 ]
    
    When validating decoder IW/IG when setting up regions, the granularity
    is irrelevant when iw=1 - all accesses will always route to the only
    target anyway - so all ig values are "correct". Loosen the requirement
    that `ig = (parent_iw * parent_ig)` when iw=1.
    
    On some Zen5 platforms, the platform BIOS specifies a 256-byte
    interleave granularity window for host bridges when there is only
    one target downstream.  This leads to Linux rejecting the configuration
    of a region with a x2 root with two x1 hostbridges.
    
    Decoder Programming:
       root - iw:2 ig:256
       hb1  - iw:1 ig:256  (Linux expects 512)
       hb2  - iw:1 ig:256  (Linux expects 512)
       ep1  - iw:2 ig:256
       ep2  - iw:2 ig:256
    
    This change allows all decoders downstream of a passthrough decoder to
    also be configured as passthrough (iw:1 ig:X), but still disallows
    downstream decoders from applying subsequent interleaves.
    
    e.g. in the above example if there was another decoder south of hb1
    attempting to interleave 2 endpoints - Linux would enforce hb1.ig=512
    because the southern decoder would have iw:2 and require ig=pig*piw.
    
    [DJ: Fixed up against 6.15-rc1]
    
    Signed-off-by: Gregory Price <[email protected]>
    Reviewed-by: Dave Jiang <[email protected]>
    Tested-by: Li Zhijian <[email protected]>
    Reviewed-by: Davidlohr Bueso <[email protected]>
    Reviewed-by: Jonathan Cameron <[email protected]>
    Reviewed-by: Dan Williams <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Dave Jiang <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
dm vdo indexer: don't read request structure after enqueuing [+ + +]
Author: Matthew Sakai <[email protected]>
Date:   Mon May 12 21:10:10 2025 -0400

    dm vdo indexer: don't read request structure after enqueuing
    
    [ Upstream commit 3da732687d72078e52cc7f334a482383e84ca156 ]
    
    The function get_volume_page_protected may place a request on
    a queue for another thread to process asynchronously. When this
    happens, the volume should not read the request from the original
    thread. This can not currently cause problems, due to the way
    request processing is handled, but it is not safe in general.
    
    Reviewed-by: Ken Raeburn <[email protected]>
    Signed-off-by: Matthew Sakai <[email protected]>
    Signed-off-by: Mikulas Patocka <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
dm-raid: fix variable in journal device check [+ + +]
Author: Heinz Mauelshagen <[email protected]>
Date:   Tue Jun 10 20:53:30 2025 +0200

    dm-raid: fix variable in journal device check
    
    commit db53805156f1e0aa6d059c0d3f9ac660d4ef3eb4 upstream.
    
    Replace "rdev" with correct loop variable name "r".
    
    Signed-off-by: Heinz Mauelshagen <[email protected]>
    Cc: [email protected]
    Fixes: 63c32ed4afc2 ("dm raid: add raid4/5/6 journaling support")
    Signed-off-by: Mikulas Patocka <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
dmaengine: idxd: Check availability of workqueue allocated by idxd wq driver before using [+ + +]
Author: Yi Sun <[email protected]>
Date:   Fri May 9 08:03:04 2025 +0800

    dmaengine: idxd: Check availability of workqueue allocated by idxd wq driver before using
    
    [ Upstream commit 17502e7d7b7113346296f6758324798d536c31fd ]
    
    Running IDXD workloads in a container with the /dev directory mounted can
    trigger a call trace or even a kernel panic when the parent process of the
    container is terminated.
    
    This issue occurs because, under certain configurations, Docker does not
    properly propagate the mount replica back to the original mount point.
    
    In this case, when the user driver detaches, the WQ is destroyed but it
    still calls destroy_workqueue() attempting to completes all pending work.
    It's necessary to check wq->wq and skip the drain if it no longer exists.
    
    Signed-off-by: Yi Sun <[email protected]>
    Reviewed-by: Dave Jiang <[email protected]>
    Reviewed-by: Anil S Keshavamurthy <[email protected]>
    
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

dmaengine: xilinx_dma: Set dma_device directions [+ + +]
Author: Thomas Gessler <[email protected]>
Date:   Wed May 7 20:21:01 2025 +0200

    dmaengine: xilinx_dma: Set dma_device directions
    
    [ Upstream commit 7e01511443c30a55a5ae78d3debd46d4d872517e ]
    
    Coalesce the direction bits from the enabled TX and/or RX channels into
    the directions bit mask of dma_device. Without this mask set,
    dma_get_slave_caps() in the DMAEngine fails, which prevents the driver
    from being used with an IIO DMAEngine buffer.
    
    Signed-off-by: Thomas Gessler <[email protected]>
    Reviewed-by: Suraj Gupta <[email protected]>
    Tested-by: Folker Schwesinger <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amd/display: Add dc cap for dp tunneling [+ + +]
Author: Peichen Huang <[email protected]>
Date:   Mon May 26 16:04:10 2025 +0800

    drm/amd/display: Add dc cap for dp tunneling
    
    commit 3251b69b7efb82eba24c9e168a6142a3078de72f upstream.
    
    [WHAT]
    1. add dc cap for dp tunneling
    2. add function to get index of host router
    
    Cc: Mario Limonciello <[email protected]>
    Cc: Alex Deucher <[email protected]>
    Reviewed-by: Cruise Hung <[email protected]>
    Signed-off-by: Peichen Huang <[email protected]>
    Signed-off-by: Alex Hung <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit 29e178d13979cf6fdb42c5fe2dfec2da2306c4ad)
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amd/display: Add debugging message for brightness caps [+ + +]
Author: Mario Limonciello <[email protected]>
Date:   Wed May 14 16:00:43 2025 -0500

    drm/amd/display: Add debugging message for brightness caps
    
    commit 4b61b8a390511a1864f26cc42bab72881e93468d upstream.
    
    [Why]
    Default BIOS brightness caps are buried in ACPI.
    
    [How]
    Add extra dynamic debug that can show default brightness caps.
    
    Reviewed-by: Alex Hung <[email protected]>
    Signed-off-by: Mario Limonciello <[email protected]>
    Signed-off-by: Wayne Lin <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amd/display: Add early 8b/10b channel equalization test pattern sequence [+ + +]
Author: Michael Strauss <[email protected]>
Date:   Mon Dec 4 16:30:39 2023 +0800

    drm/amd/display: Add early 8b/10b channel equalization test pattern sequence
    
    commit 8989cb919b27cd0d2aadb7f1d144cedbb12e6fca upstream.
    
    [WHY]
    Early EQ pattern sequence is required for some LTTPR + old dongle
    combinations.
    
    [HOW]
    If DP_EARLY_8B10B_TPS2 chip cap is set, this new sequence programs phy
    to output TPS2 before initiating link training and writes TPS1 to
    LTTPR training pattern register as instructed by vendor.
    
    Add function to get embedded LTTPR target address offset.
    
    Reviewed-by: Wenjing Liu <[email protected]>
    Signed-off-by: Michael Strauss <[email protected]>
    Signed-off-by: TungYu Lu <[email protected]>
    Signed-off-by: Ray Wu <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amd/display: Add more checks for DSC / HUBP ONO guarantees [+ + +]
Author: Nicholas Kazlauskas <[email protected]>
Date:   Wed May 21 16:40:25 2025 -0400

    drm/amd/display: Add more checks for DSC / HUBP ONO guarantees
    
    commit 0d57dd1765d311111d9885346108c4deeae1deb4 upstream.
    
    [WHY]
    For non-zero DSC instances it's possible that the HUBP domain required
    to drive it for sequential ONO ASICs isn't met, potentially causing
    the logic to the tile to enter an undefined state leading to a system
    hang.
    
    [HOW]
    Add more checks to ensure that the HUBP domain matching the DSC instance
    is appropriately powered.
    
    Cc: Mario Limonciello <[email protected]>
    Cc: Alex Deucher <[email protected]>
    Reviewed-by: Duncan Ma <[email protected]>
    Signed-off-by: Nicholas Kazlauskas <[email protected]>
    Signed-off-by: Alex Hung <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit da63df07112e5a9857a8d2aaa04255c4206754ec)
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amd/display: Add null pointer check for get_first_active_display() [+ + +]
Author: Wentao Liang <[email protected]>
Date:   Mon May 26 10:37:31 2025 +0800

    drm/amd/display: Add null pointer check for get_first_active_display()
    
    commit c3e9826a22027a21d998d3e64882fa377b613006 upstream.
    
    The function mod_hdcp_hdcp1_enable_encryption() calls the function
    get_first_active_display(), but does not check its return value.
    The return value is a null pointer if the display list is empty.
    This will lead to a null pointer dereference in
    mod_hdcp_hdcp2_enable_encryption().
    
    Add a null pointer check for get_first_active_display() and return
    MOD_HDCP_STATUS_DISPLAY_NOT_FOUND if the function return null.
    
    Fixes: 2deade5ede56 ("drm/amd/display: Remove hdcp display state with mst fix")
    Signed-off-by: Wentao Liang <[email protected]>
    Reviewed-by: Alex Hung <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: [email protected] # v5.8
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amd/display: Add sanity checks for drm_edid_raw() [+ + +]
Author: Takashi Iwai <[email protected]>
Date:   Mon Jun 16 18:08:41 2025 +0200

    drm/amd/display: Add sanity checks for drm_edid_raw()
    
    commit 6847b3b6e84ef37451c074e6a8db3fbd250c8dbf upstream.
    
    When EDID is retrieved via drm_edid_raw(), it doesn't guarantee to
    return proper EDID bytes the caller wants: it may be either NULL (that
    leads to an Oops) or with too long bytes over the fixed size raw_edid
    array (that may lead to memory corruption).  The latter was reported
    actually when connected with a bad adapter.
    
    Add sanity checks for drm_edid_raw() to address the above corner
    cases, and return EDID_BAD_INPUT accordingly.
    
    Fixes: 48edb2a4256e ("drm/amd/display: switch amdgpu_dm_connector to use struct drm_edid")
    Link: https://bugzilla.suse.com/show_bug.cgi?id=1236415
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit 648d3f4d209725d51900d6a3ed46b7b600140cdf)
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amd/display: Check dce_hwseq before dereferencing it [+ + +]
Author: Alex Hung <[email protected]>
Date:   Tue Jun 3 18:30:55 2025 -0600

    drm/amd/display: Check dce_hwseq before dereferencing it
    
    commit b669507b637eb6b1aaecf347f193efccc65d756e upstream.
    
    [WHAT]
    
    hws was checked for null earlier in dce110_blank_stream, indicating hws
    can be null, and should be checked whenever it is used.
    
    Cc: Mario Limonciello <[email protected]>
    Cc: Alex Deucher <[email protected]>
    Reviewed-by: Aurabindo Pillai <[email protected]>
    Signed-off-by: Alex Hung <[email protected]>
    Signed-off-by: Aurabindo Pillai <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit 79db43611ff61280b6de58ce1305e0b2ecf675ad)
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amd/display: Correct non-OLED pre_T11_delay. [+ + +]
Author: Zhongwei Zhang <[email protected]>
Date:   Tue May 13 16:45:59 2025 +0800

    drm/amd/display: Correct non-OLED pre_T11_delay.
    
    commit 893f07452bca56ff146a6be02b3294a9ea23d18a upstream.
    
    [Why]
    Only OLED panels require non-zero pre_T11_delay defaultly.
    Others should be controlled by power sequence.
    
    [How]
    For non OLED, pre_T11_delay delay in code should be zero.
    Also post_T7_delay.
    
    Cc: Mario Limonciello <[email protected]>
    Cc: Alex Deucher <[email protected]>
    Cc: [email protected]
    Reviewed-by: Charlene Liu <[email protected]>
    Signed-off-by: Zhongwei Zhang <[email protected]>
    Signed-off-by: Wayne Lin <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amd/display: Export full brightness range to userspace [+ + +]
Author: Mario Limonciello <[email protected]>
Date:   Thu May 29 09:46:32 2025 -0500

    drm/amd/display: Export full brightness range to userspace
    
    commit 16dc8bc27c2aa3c93905d3e885e27f1e3535f09a upstream.
    
    [WHY]
    Userspace currently is offered a range from 0-0xFF but the PWM is
    programmed from 0-0xFFFF.  This can be limiting to some software
    that wants to apply greater granularity.
    
    [HOW]
    Convert internally to firmware values only when mapping custom
    brightness curves because these are in 0-0xFF range. Advertise full
    PWM range to userspace.
    
    Cc: Mario Limonciello <[email protected]>
    Cc: Alex Deucher <[email protected]>
    Reviewed-by: Roman Li <[email protected]>
    Signed-off-by: Mario Limonciello <[email protected]>
    Signed-off-by: Alex Hung <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit 8dbd72cb790058ce52279af38a43c2b302fdd3e5)
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amd/display: Fix AMDGPU_MAX_BL_LEVEL value [+ + +]
Author: Mario Limonciello <[email protected]>
Date:   Mon Jun 23 12:11:13 2025 -0500

    drm/amd/display: Fix AMDGPU_MAX_BL_LEVEL value
    
    commit 66abb996999de0d440a02583a6e70c2c24deab45 upstream.
    
    [Why]
    commit 16dc8bc27c2a ("drm/amd/display: Export full brightness range to
    userspace") adjusted the brightness range to scale to larger values, but
    missed updating AMDGPU_MAX_BL_LEVEL which is needed to make sure that
    scaling works properly with custom brightness curves.
    
    [How]
    As the change for max brightness of 0xFFFF only applies to devices
    supporting DC, use existing DC define MAX_BACKLIGHT_LEVEL.
    
    Fixes: 16dc8bc27c2a ("drm/amd/display: Export full brightness range to userspace")
    Acked-by: Alex Deucher <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mario Limonciello <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit 5b852044eb0d3e1f1c946d32e05fcb068e0a20a0)
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amd/display: Fix default DC and AC levels [+ + +]
Author: Mario Limonciello <[email protected]>
Date:   Wed May 14 16:06:40 2025 -0500

    drm/amd/display: Fix default DC and AC levels
    
    commit 8b5f3a229a70d242322b78c8e13744ca00212def upstream.
    
    [Why]
    DC and AC levels are advertised in a percentage, not a luminance.
    
    [How]
    Scale DC and AC levels to supported values.
    
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4221
    Reviewed-by: Alex Hung <[email protected]>
    Signed-off-by: Mario Limonciello <[email protected]>
    Signed-off-by: Wayne Lin <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amd/display: Fix mpv playback corruption on weston [+ + +]
Author: Alex Hung <[email protected]>
Date:   Thu May 29 10:59:19 2025 -0600

    drm/amd/display: Fix mpv playback corruption on weston
    
    commit 8724a5380c4390eed81e271d22f34ff06453ded9 upstream.
    
    [WHAT]
    Severe video playback corruption is observed in the following setup:
    
    weston 14.0.90 (built from source) + mpv v0.40.0 with command:
    mpv bbb_sunflower_1080p_60fps_normal.mp4 --vo=gpu
    
    [HOW]
    ABGR16161616 needs to be included in dml2/2.1 translation.
    
    Cc: Mario Limonciello <[email protected]>
    Cc: Alex Deucher <[email protected]>
    Acked-by: Aurabindo Pillai <[email protected]>
    Reviewed-by: Harry Wentland <[email protected]>
    Reviewed-by: Austin Zheng <[email protected]>
    Signed-off-by: Alex Hung <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit d023de809f85307ca819a9dbbceee6ae1f50e2ad)
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amd/display: Fix RMCM programming seq errors [+ + +]
Author: Yihan Zhu <[email protected]>
Date:   Tue May 27 16:47:40 2025 -0400

    drm/amd/display: Fix RMCM programming seq errors
    
    commit 158f9944ac05dafd2d3a23d0688e6cf40ef68b90 upstream.
    
    [WHY & HOW]
    Fix RMCM programming sequence errors and mapping issues to pass the RMCM
    test.
    
    Cc: Mario Limonciello <[email protected]>
    Cc: Alex Deucher <[email protected]>
    Reviewed-by: Dmytro Laktyushkin <[email protected]>
    Signed-off-by: Yihan Zhu <[email protected]>
    Signed-off-by: Alex Hung <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit 11baa4975025033547f45f5894087a0dda6efbb8)
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amd/display: Get LTTPR IEEE OUI/Device ID From Closest LTTPR To Host [+ + +]
Author: Michael Strauss <[email protected]>
Date:   Wed Feb 26 10:03:48 2025 -0500

    drm/amd/display: Get LTTPR IEEE OUI/Device ID From Closest LTTPR To Host
    
    commit d358a51444c88bcc995e471dc8cc840f19e4b374 upstream.
    
    [WHY]
    These fields are read for the explicit purpose of detecting embedded LTTPRs
    (i.e. between host ASIC and the user-facing port), and thus need to
    calculate the correct DPCD address offset based on LTTPR count to target
    the appropriate LTTPR's DPCD register space with these queries.
    
    [HOW]
    Cascaded LTTPRs in a link each snoop and increment LTTPR count when queried
    via DPCD read, so an LTTPR embedded in a source device (e.g. USB4 port on a
    laptop) will always be addressible using the max LTTPR count seen by the
    host. Therefore we simply need to use a recently added helper function to
    calculate the correct DPCD address to target potentially embedded LTTPRs
    based on the received LTTPR count.
    
    Cc: Mario Limonciello <[email protected]>
    Cc: Alex Deucher <[email protected]>
    Reviewed-by: Wenjing Liu <[email protected]>
    Signed-off-by: Michael Strauss <[email protected]>
    Signed-off-by: Alex Hung <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit 791897f5c77a2a65d0e500be4743af2ddf6eb061)
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amd/display: Only read ACPI backlight caps once [+ + +]
Author: Mario Limonciello <[email protected]>
Date:   Thu May 29 11:33:44 2025 -0500

    drm/amd/display: Only read ACPI backlight caps once
    
    commit ffcaed1d7ecef31198000dfbbea791f30f7ca437 upstream.
    
    [WHY]
    Backlight caps are read already in amdgpu_dm_update_backlight_caps().
    They may be updated by update_connector_ext_caps(). Reading again when
    registering backlight device may cause wrong values to be used.
    
    [HOW]
    Use backlight caps already registered to the dm.
    
    Cc: Mario Limonciello <[email protected]>
    Cc: Alex Deucher <[email protected]>
    Reviewed-by: Roman Li <[email protected]>
    Signed-off-by: Mario Limonciello <[email protected]>
    Signed-off-by: Alex Hung <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit 148144f6d2f14b02eaaa39b86bbe023cbff350bd)
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amd/display: Optimize custom brightness curve [+ + +]
Author: Mario Limonciello <[email protected]>
Date:   Mon Mar 24 12:57:25 2025 -0500

    drm/amd/display: Optimize custom brightness curve
    
    commit 03b979e1025fba1d47cae005022fcdbba140f043 upstream.
    
    [Why]
    When BIOS includes a lot of custom brightness data points, walking
    the entire list can be time consuming.  This is most noticed when
    dragging a power slider.  The "higher" values are "slower" to drag
    around.
    
    [How]
    Move custom brightness calculation loop into a static function. Before
    starting the loop check the "half way" data point to see how it compares
    to the input.  If greater than the half way data point use that as the
    starting point instead.
    
    Reviewed-by: Alex Hung <[email protected]>
    Signed-off-by: Mario Limonciello <[email protected]>
    Signed-off-by: Roman Li <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/amd: Adjust output for discovery error handling [+ + +]
Author: Mario Limonciello <[email protected]>
Date:   Tue Jun 17 13:30:52 2025 -0500

    drm/amd: Adjust output for discovery error handling
    
    [ Upstream commit 73eab78721f7b85216f1ca8c7b732f13213b5b32 ]
    
    commit 017fbb6690c2 ("drm/amdgpu/discovery: check ip_discovery fw file
    available") added support for reading an amdgpu IP discovery bin file
    for some specific products. If it's not found then it will fallback to
    hardcoded values. However if it's not found there is also a lot of noise
    about missing files and errors.
    
    Adjust the error handling to decrease most messages to DEBUG and to show
    users less about missing files.
    
    Reviewed-by: Lijo Lazar <[email protected]>
    Reported-by: Marcus Seyfarth <[email protected]>
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4312
    Tested-by: Marcus Seyfarth <[email protected]>
    Fixes: 017fbb6690c2 ("drm/amdgpu/discovery: check ip_discovery fw file available")
    Acked-by: Alex Deucher <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mario Limonciello <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit 49f1f9f6c3c9febf8ba93f94a8d9c8d03e1ea0a1)
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amdgpu/mes: add compatibility checks for set_hw_resource_1 [+ + +]
Author: Alex Deucher <[email protected]>
Date:   Tue May 20 10:02:14 2025 -0400

    drm/amdgpu/mes: add compatibility checks for set_hw_resource_1
    
    commit 99579c55c3d6132a5236926652c0a72a526b809d upstream.
    
    Seems some older MES firmware versions do not properly support
    this packet.  Add back some the compatibility checks.
    
    v2: switch to fw version check (Shaoyun)
    
    Fixes: f81cd793119e ("drm/amd/amdgpu: Fix MES init sequence")
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4295
    Cc: Shaoyun Liu <[email protected]>
    Reviewed-by: shaoyun.liu <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit 0180e0a5dd5c6ff118043ee42dbbbddaf881f283)
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amdgpu/mes: add missing locking in helper functions [+ + +]
Author: Alex Deucher <[email protected]>
Date:   Mon May 19 15:46:25 2025 -0400

    drm/amdgpu/mes: add missing locking in helper functions
    
    [ Upstream commit 40f970ba7a4ab77be2ffe6d50a70416c8876496a ]
    
    We need to take the MES lock.
    
    Reviewed-by: Michael Chen <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: [email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amdgpu/vcn2.5: read back register after written [+ + +]
Author: David (Ming Qiang) Wu <[email protected]>
Date:   Wed May 14 18:54:01 2025 -0400

    drm/amdgpu/vcn2.5: read back register after written
    
    [ Upstream commit d9e688b9148bb23629d32017344888dd67ec2ab1 ]
    
    The addition of register read-back in VCN v2.5 is intended to prevent
    potential race conditions.
    
    Reviewed-by: Ruijing Dong <[email protected]>
    Signed-off-by: David (Ming Qiang) Wu <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amdgpu/vcn3: read back register after written [+ + +]
Author: David (Ming Qiang) Wu <[email protected]>
Date:   Wed May 14 18:54:39 2025 -0400

    drm/amdgpu/vcn3: read back register after written
    
    [ Upstream commit b7a4842a917e3a251b5a6aa1a21a5daf6d396ef3 ]
    
    The addition of register read-back in VCN v3.0 is intended to prevent
    potential race conditions.
    
    Reviewed-by: Ruijing Dong <[email protected]>
    Signed-off-by: David (Ming Qiang) Wu <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amdgpu/vcn4: read back register after written [+ + +]
Author: David (Ming Qiang) Wu <[email protected]>
Date:   Wed May 14 18:55:27 2025 -0400

    drm/amdgpu/vcn4: read back register after written
    
    [ Upstream commit a3810a5e37c58329aa2c7992f3172a423f4ae194 ]
    
    The addition of register read-back in VCN v4.0.0 is intended to prevent
    potential race conditions.
    
    Reviewed-by: Ruijing Dong <[email protected]>
    Signed-off-by: David (Ming Qiang) Wu <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amdgpu/vcn5.0.1: read back register after written [+ + +]
Author: David (Ming Qiang) Wu <[email protected]>
Date:   Wed May 14 18:59:11 2025 -0400

    drm/amdgpu/vcn5.0.1: read back register after written
    
    [ Upstream commit bf394d28548c3c0a01e113fdef20ddb6cd2df106 ]
    
    The addition of register read-back in VCN v5.0.1 is intended to prevent
    potential race conditions.
    
    Reviewed-by: Ruijing Dong <[email protected]>
    Signed-off-by: David (Ming Qiang) Wu <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amdgpu: Add kicker device detection [+ + +]
Author: Frank Min <[email protected]>
Date:   Wed Jun 4 21:00:44 2025 +0800

    drm/amdgpu: Add kicker device detection
    
    commit 0bbf5fd86c585d437b75003f11365b324360a5d6 upstream.
    
    1. add kicker device list
    2. add kicker device checking helper function
    
    Signed-off-by: Frank Min <[email protected]>
    Reviewed-by: Hawking Zhang <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit 09aa2b408f4ab689c3541d22b0968de0392ee406)
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amdgpu: add kicker fws loading for gfx11/smu13/psp13 [+ + +]
Author: Frank Min <[email protected]>
Date:   Wed Jun 4 21:17:05 2025 +0800

    drm/amdgpu: add kicker fws loading for gfx11/smu13/psp13
    
    commit 854171405e7f093532b33d8ed0875b9e34fc55b4 upstream.
    
    1. Add kicker firmwares loading for gfx11/smu13/psp13
    2. Register additional MODULE_FIRMWARE entries for kicker fws
       - gc_11_0_0_rlc_kicker.bin
       - gc_11_0_0_imu_kicker.bin
       - psp_13_0_0_sos_kicker.bin
       - psp_13_0_0_ta_kicker.bin
       - smu_13_0_0_kicker.bin
    
    Signed-off-by: Frank Min <[email protected]>
    Reviewed-by: Hawking Zhang <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit fb5ec2174d70a8989bc207d257db90ffeca3b163)
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amdgpu: amdgpu_vram_mgr_new(): Clamp lpfn to total vram [+ + +]
Author: John Olender <[email protected]>
Date:   Tue Apr 29 07:24:28 2025 -0400

    drm/amdgpu: amdgpu_vram_mgr_new(): Clamp lpfn to total vram
    
    commit 4d2f6b4e4c7ed32e7fa39fcea37344a9eab99094 upstream.
    
    The drm_mm allocator tolerated being passed end > mm->size, but the
    drm_buddy allocator does not.
    
    Restore the pre-buddy-allocator behavior of allowing such placements.
    
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3448
    Signed-off-by: John Olender <[email protected]>
    Reviewed-by: Alex Deucher <[email protected]>
    Reviewed-by: Arunpravin Paneer Selvam <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amdgpu: disable workload profile switching when OD is enabled [+ + +]
Author: Alex Deucher <[email protected]>
Date:   Tue May 27 10:13:31 2025 -0400

    drm/amdgpu: disable workload profile switching when OD is enabled
    
    commit 5cccf10f652122a17b40df9d672ccf2ed69cd82f upstream.
    
    Users have reported that they have to reduce the level of undervolting
    to acheive stability when dynamic workload profiles are enabled on
    GC 10.3.x. Disable dynamic workload profiles if the user has enabled
    OD.
    
    Fixes: b9467983b774 ("drm/amdgpu: add dynamic workload profile switching for gfx10")
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4262
    Reviewed-by: Kenneth Feng <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: [email protected] # 6.15.x
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amdgpu: Fix SDMA UTC_L1 handling during start/stop sequences [+ + +]
Author: Jesse Zhang <[email protected]>
Date:   Mon Jun 16 19:21:41 2025 +0800

    drm/amdgpu: Fix SDMA UTC_L1 handling during start/stop sequences
    
    commit 7f3b16f3f229e37cc3e02e9e4e7106c523b119e9 upstream.
    
    This commit makes two key fixes to SDMA v4.4.2 handling:
    
    1. disable UTC_L1 in sdma_cntl register when stopping SDMA engines
       by reading the current value before modifying UTC_L1_ENABLE bit.
    
    2. Ensure UTC_L1_ENABLE is consistently managed by:
       - Adding the missing register write when enabling UTC_L1 during start
       - Keeping UTC_L1 enabled by default as per hardware requirements
    
    v2: Correct SDMA_CNTL setting (Philip)
    
    Suggested-by: Jonathan Kim <[email protected]>
    Signed-off-by: Jesse Zhang <[email protected]>
    Acked-by: Alex Deucher <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit 375bf564654e85a7b1b0657b191645b3edca1bda)
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amdgpu: seq64 memory unmap uses uninterruptible lock [+ + +]
Author: Philip Yang <[email protected]>
Date:   Wed May 14 11:13:52 2025 -0400

    drm/amdgpu: seq64 memory unmap uses uninterruptible lock
    
    [ Upstream commit a359288ccb4dd8edb086e7de8fdf6e36f544c922 ]
    
    To unmap and free seq64 memory when drm node close to free vm, if there
    is signal accepted, then taking vm lock failed and leaking seq64 va
    mapping, and then dmesg has error log "still active bo inside vm".
    
    Change to use uninterruptible lock fix the mapping leaking and no dmesg
    error log.
    
    Signed-off-by: Philip Yang <[email protected]>
    Reviewed-by: Christian König <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amdgpu: switch job hw_fence to amdgpu_fence [+ + +]
Author: Alex Deucher <[email protected]>
Date:   Mon Jun 2 11:31:52 2025 -0400

    drm/amdgpu: switch job hw_fence to amdgpu_fence
    
    commit ebe43542702c3d15d1a1d95e8e13b1b54076f05a upstream.
    
    Use the amdgpu fence container so we can store additional
    data in the fence.  This also fixes the start_time handling
    for MCBP since we were casting the fence to an amdgpu_fence
    and it wasn't.
    
    Fixes: 3f4c175d62d8 ("drm/amdgpu: MCBP based on DRM scheduler (v9)")
    Reviewed-by: Christian König <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit bf1cd14f9e2e1fdf981eed273ddd595863f5288c)
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amdgpu: VCN v5_0_1 to prevent FW checking RB during DPG pause [+ + +]
Author: Sonny Jiang <[email protected]>
Date:   Thu Jun 12 11:01:08 2025 -0400

    drm/amdgpu: VCN v5_0_1 to prevent FW checking RB during DPG pause
    
    commit 46e15197b513e60786a44107759d6ca293d6288c upstream.
    
    Add a protection to ensure programming are all complete prior VCPU
    starting. This is a WA for an unintended VCPU running.
    
    Signed-off-by: Sonny Jiang <[email protected]>
    Acked-by: Leo Liu <[email protected]>
    Reviewed-by: Ruijing Dong <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit c29521b529fa5e225feaf709d863a636ca0cbbfa)
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/amdkfd: Fix race in GWS queue scheduling [+ + +]
Author: Jay Cornwall <[email protected]>
Date:   Wed Jun 11 09:52:14 2025 -0500

    drm/amdkfd: Fix race in GWS queue scheduling
    
    commit cfb05257ae168a0496c7637e1d9e3ab8a25cbffe upstream.
    
    q->gws is not updated atomically with qpd->mapped_gws_queue. If a
    runlist is created between pqm_set_gws and update_queue it will
    contain a queue which uses GWS in a process with no GWS allocated.
    This will result in a scheduler hang.
    
    Use q->properties.is_gws which is changed while holding the DQM lock.
    
    Signed-off-by: Jay Cornwall <[email protected]>
    Reviewed-by: Harish Kasiviswanathan <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit b98370220eb3110e82248e3354e16a489a492cfb)
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/ast: Fix comment on modeset lock [+ + +]
Author: Thomas Zimmermann <[email protected]>
Date:   Mon Mar 24 10:44:09 2025 +0100

    drm/ast: Fix comment on modeset lock
    
    commit 7cce65f3789e04c0f7668a66563e680d81d54493 upstream.
    
    The ast driver protects the commit tail against concurrent reads
    of the display modes by acquiring a lock. The comment is misleading
    as the lock is not released in atomic_flush, but at the end of the
    commit-tail helper. Rewrite the comment.
    
    Signed-off-by: Thomas Zimmermann <[email protected]>
    Fixes: 1fe182154984 ("drm/ast: Acquire I/O-register lock in atomic_commit_tail function")
    Cc: Thomas Zimmermann <[email protected]>
    Cc: Jocelyn Falempe <[email protected]>
    Cc: Dave Airlie <[email protected]>
    Cc: [email protected]
    Cc: <[email protected]> # v6.2+
    Reviewed-by: Jocelyn Falempe <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/bridge: cdns-dsi: Check return value when getting default PHY config [+ + +]
Author: Aradhya Bhatia <[email protected]>
Date:   Sat Mar 29 17:09:15 2025 +0530

    drm/bridge: cdns-dsi: Check return value when getting default PHY config
    
    commit c6a7ef0d4856b9629df390e9935d7fd67fe39f81 upstream.
    
    Check for the return value of the phy_mipi_dphy_get_default_config()
    call, and in case of an error, return back the same.
    
    Fixes: fced5a364dee ("drm/bridge: cdns: Convert to phy framework")
    Cc: [email protected]
    Reviewed-by: Tomi Valkeinen <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Tested-by: Tomi Valkeinen <[email protected]>
    Signed-off-by: Aradhya Bhatia <[email protected]>
    Signed-off-by: Aradhya Bhatia <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/bridge: cdns-dsi: Fix connecting to next bridge [+ + +]
Author: Aradhya Bhatia <[email protected]>
Date:   Sat Mar 29 17:09:12 2025 +0530

    drm/bridge: cdns-dsi: Fix connecting to next bridge
    
    commit 688eb4d465484bc2a3471a6a6f06f833b58c7867 upstream.
    
    Fix the OF node pointer passed to the of_drm_find_bridge() call to find
    the next bridge in the display chain.
    
    The code to find the next panel (and create its panel-bridge) works
    fine, but to find the next (non-panel) bridge does not.
    
    To find the next bridge in the pipeline, we need to pass "np" - the OF
    node pointer of the next entity in the devicetree chain. Passing
    "of_node" to of_drm_find_bridge (which is what the code does currently)
    will fetch the bridge for the cdns-dsi which is not what's required.
    
    Fix that.
    
    Fixes: e19233955d9e ("drm/bridge: Add Cadence DSI driver")
    Cc: [email protected]
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Reviewed-by: Tomi Valkeinen <[email protected]>
    Tested-by: Tomi Valkeinen <[email protected]>
    Signed-off-by: Aradhya Bhatia <[email protected]>
    Signed-off-by: Aradhya Bhatia <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/bridge: cdns-dsi: Fix phy de-init and flag it so [+ + +]
Author: Aradhya Bhatia <[email protected]>
Date:   Sat Mar 29 17:09:13 2025 +0530

    drm/bridge: cdns-dsi: Fix phy de-init and flag it so
    
    commit fd2611c13f69cbbc6b81d9fc7502abf4f7031d21 upstream.
    
    The driver code doesn't have a Phy de-initialization path as yet, and so
    it does not clear the phy_initialized flag while suspending. This is a
    problem because after resume the driver looks at this flag to determine
    if a Phy re-initialization is required or not. It is in fact required
    because the hardware is resuming from a suspend, but the driver does not
    carry out any re-initialization causing the D-Phy to not work at all.
    
    Call the counterparts of phy_init() and phy_power_on(), that are
    phy_exit() and phy_power_off(), from _bridge_post_disable(), and clear
    the flags so that the Phy can be initialized again when required.
    
    Fixes: fced5a364dee ("drm/bridge: cdns: Convert to phy framework")
    Cc: [email protected]
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Reviewed-by: Tomi Valkeinen <[email protected]>
    Tested-by: Tomi Valkeinen <[email protected]>
    Signed-off-by: Aradhya Bhatia <[email protected]>
    Signed-off-by: Aradhya Bhatia <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/bridge: cdns-dsi: Fix the clock variable for mode_valid() [+ + +]
Author: Aradhya Bhatia <[email protected]>
Date:   Sat Mar 29 17:09:14 2025 +0530

    drm/bridge: cdns-dsi: Fix the clock variable for mode_valid()
    
    commit 132bdcec399be6ae947582249a134b38cf56731c upstream.
    
    The crtc_* mode parameters do not get generated (duplicated in this
    case) from the regular parameters before the mode validation phase
    begins.
    
    The rest of the code conditionally uses the crtc_* parameters only
    during the bridge enable phase, but sticks to the regular parameters
    for mode validation. In this singular instance, however, the driver
    tries to use the crtc_clock parameter even during the mode validation,
    causing the validation to fail.
    
    Allow the D-Phy config checks to use mode->clock instead of
    mode->crtc_clock during mode_valid checks, like everywhere else in the
    driver.
    
    Fixes: fced5a364dee ("drm/bridge: cdns: Convert to phy framework")
    Cc: [email protected]
    Reviewed-by: Tomi Valkeinen <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Tested-by: Tomi Valkeinen <[email protected]>
    Signed-off-by: Aradhya Bhatia <[email protected]>
    Signed-off-by: Aradhya Bhatia <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/bridge: cdns-dsi: Wait for Clk and Data Lanes to be ready [+ + +]
Author: Aradhya Bhatia <[email protected]>
Date:   Sat Mar 29 17:09:16 2025 +0530

    drm/bridge: cdns-dsi: Wait for Clk and Data Lanes to be ready
    
    commit 47c03e6660e96cbba0239125b1d4a9db3c724b1d upstream.
    
    Once the DSI Link and DSI Phy are initialized, the code needs to wait
    for Clk and Data Lanes to be ready, before continuing configuration.
    This is in accordance with the DSI Start-up procedure, found in the
    Technical Reference Manual of Texas Instrument's J721E SoC[0] which
    houses this DSI TX controller.
    
    If the previous bridge (or crtc/encoder) are configured pre-maturely,
    the input signal FIFO gets corrupt. This introduces a color-shift on the
    display.
    
    Allow the driver to wait for the clk and data lanes to get ready during
    DSI enable.
    
    [0]: See section 12.6.5.7.3 "Start-up Procedure" in J721E SoC TRM
         TRM Link: http://www.ti.com/lit/pdf/spruil1
    
    Fixes: e19233955d9e ("drm/bridge: Add Cadence DSI driver")
    Cc: [email protected]
    Tested-by: Dominik Haller <[email protected]>
    Reviewed-by: Tomi Valkeinen <[email protected]>
    Tested-by: Tomi Valkeinen <[email protected]>
    Signed-off-by: Aradhya Bhatia <[email protected]>
    Signed-off-by: Aradhya Bhatia <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/bridge: ti-sn65dsi86: Add HPD for DisplayPort connector type [+ + +]
Author: Jayesh Choudhary <[email protected]>
Date:   Tue Jun 24 10:18:35 2025 +0530

    drm/bridge: ti-sn65dsi86: Add HPD for DisplayPort connector type
    
    [ Upstream commit 55e8ff842051b1150461d7595d8f1d033c69d66b ]
    
    By default, HPD was disabled on SN65DSI86 bridge. When the driver was
    added (commit "a095f15c00e27"), the HPD_DISABLE bit was set in pre-enable
    call which was moved to other function calls subsequently.
    Later on, commit "c312b0df3b13" added detect utility for DP mode. But with
    HPD_DISABLE bit set, all the HPD events are disabled[0] and the debounced
    state always return 1 (always connected state).
    
    Set HPD_DISABLE bit conditionally based on display sink's connector type.
    Since the HPD_STATE is reflected correctly only after waiting for debounce
    time (~100-400ms) and adding this delay in detect() is not feasible
    owing to the performace impact (glitches and frame drop), remove runtime
    calls in detect() and add hpd_enable()/disable() bridge hooks with runtime
    calls, to detect hpd properly without any delay.
    
    [0]: <https://www.ti.com/lit/gpn/SN65DSI86> (Pg. 32)
    
    Fixes: c312b0df3b13 ("drm/bridge: ti-sn65dsi86: Implement bridge connector operations for DP")
    Cc: Max Krummenacher <[email protected]>
    Reviewed-by: Douglas Anderson <[email protected]>
    Tested-by: Ernest Van Hoecke <[email protected]>
    Signed-off-by: Jayesh Choudhary <[email protected]>
    Signed-off-by: Douglas Anderson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

drm/bridge: ti-sn65dsi86: make use of debugfs_init callback [+ + +]
Author: Wolfram Sang <[email protected]>
Date:   Sat Mar 15 21:15:11 2025 +0100

    drm/bridge: ti-sn65dsi86: make use of debugfs_init callback
    
    [ Upstream commit 1d1f7b15cb9c11974cebfd39da51dc69b8cb31ff ]
    
    Do not create a custom directory in debugfs-root, but use the
    debugfs_init callback to create a custom directory at the given place
    for the bridge. The new directory layout looks like this on a Renesas
    GrayHawk-Single with a R-Car V4M SoC:
    
            /sys/kernel/debug/dri/feb00000.display/DP-1/1-002c
    
    Signed-off-by: Wolfram Sang <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Reviewed-by: Douglas Anderson <[email protected]>
    Signed-off-by: Douglas Anderson <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Stable-dep-of: 55e8ff842051 ("drm/bridge: ti-sn65dsi86: Add HPD for DisplayPort connector type")
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/cirrus-qemu: Fix pitch programming [+ + +]
Author: Thomas Zimmermann <[email protected]>
Date:   Fri Mar 28 10:17:05 2025 +0100

    drm/cirrus-qemu: Fix pitch programming
    
    commit 4bfb389a0136a13f0802eeb5e97a0e76d88f77ae upstream.
    
    Do not set CR1B[6] when programming the pitch. The bit effects VGA
    text mode and is not interpreted by qemu. [1] It has no affect on
    the scanline pitch.
    
    The scanline bit that is set into CR1B[6] belongs into CR13[7], which
    the driver sets up correctly.
    
    This bug goes back to the driver's initial commit.
    
    Signed-off-by: Thomas Zimmermann <[email protected]>
    Acked-by: Gerd Hoffmann <[email protected]>
    Link: https://gitlab.com/qemu-project/qemu/-/blob/stable-9.2/hw/display/cirrus_vga.c?ref_type=heads#L1112 # 1
    Fixes: f9aa76a85248 ("drm/kms: driver for virtual cirrus under qemu")
    Cc: Adam Jackson <[email protected]>
    Cc: Dave Airlie <[email protected]>
    Cc: Maarten Lankhorst <[email protected]>
    Cc: Maxime Ripard <[email protected]>
    Cc: Thomas Zimmermann <[email protected]>
    Cc: <[email protected]> # v3.5+
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/etnaviv: Protect the scheduler's pending list with its lock [+ + +]
Author: Maíra Canal <[email protected]>
Date:   Mon Jun 2 10:22:16 2025 -0300

    drm/etnaviv: Protect the scheduler's pending list with its lock
    
    commit 61ee19dedb8d753249e20308782bf4e9e2fb7344 upstream.
    
    Commit 704d3d60fec4 ("drm/etnaviv: don't block scheduler when GPU is still
    active") ensured that active jobs are returned to the pending list when
    extending the timeout. However, it didn't use the pending list's lock to
    manipulate the list, which causes a race condition as the scheduler's
    workqueues are running.
    
    Hold the lock while manipulating the scheduler's pending list to prevent
    a race.
    
    Cc: [email protected]
    Fixes: 704d3d60fec4 ("drm/etnaviv: don't block scheduler when GPU is still active")
    Reported-by: Philipp Stanner <[email protected]>
    Closes: https://lore.kernel.org/dri-devel/[email protected]/
    Reviewed-by: Lucas Stach <[email protected]>
    Reviewed-by: Philipp Stanner <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Maíra Canal <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/i915/display: Add check for alloc_ordered_workqueue() and alloc_workqueue() [+ + +]
Author: Haoxiang Li <[email protected]>
Date:   Fri May 16 15:16:54 2025 +0300

    drm/i915/display: Add check for alloc_ordered_workqueue() and alloc_workqueue()
    
    [ Upstream commit f4c7baa0699b69edb6887a992283b389761e0e81 ]
    
    Add check for the return value of alloc_ordered_workqueue()
    and alloc_workqueue(). Furthermore, if some allocations fail,
    cleanup works are added to avoid potential memory leak problem.
    
    Fixes: 40053823baad ("drm/i915/display: move modeset probe/remove functions to intel_display_driver.c")
    Cc: [email protected]
    Signed-off-by: Haoxiang Li <[email protected]>
    Reviewed-by: Matthew Auld <[email protected]>
    Link: https://lore.kernel.org/r/20d3d096c6a4907636f8a1389b3b4dd753ca356e.1747397638.git.jani.nikula@intel.com
    Signed-off-by: Jani Nikula <[email protected]>
    (cherry picked from commit dcab7a228f4ea9cda3f5b0a1f0679e046d23d7f7)
    Signed-off-by: Joonas Lahtinen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/i915/dp_mst: Work around Thunderbolt sink disconnect after SINK_COUNT_ESI read [+ + +]
Author: Imre Deak <[email protected]>
Date:   Mon May 19 16:34:17 2025 +0300

    drm/i915/dp_mst: Work around Thunderbolt sink disconnect after SINK_COUNT_ESI read
    
    commit 9cb15478916e849d62a6ec44b10c593b9663328c upstream.
    
    Due to a problem in the iTBT DP-in adapter's firmware the sink on a TBT
    link may get disconnected inadvertently if the SINK_COUNT_ESI and the
    DP_LINK_SERVICE_IRQ_VECTOR_ESI0 registers are read in a single AUX
    transaction. Work around the issue by reading these registers in
    separate transactions.
    
    The issue affects MTL+ platforms and will be fixed in the DP-in adapter
    firmware, however releasing that firmware fix may take some time and is
    not guaranteed to be available for all systems. Based on this apply the
    workaround on affected platforms.
    
    See HSD #13013007775.
    
    v2: Cc'ing Mika Westerberg.
    
    Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13760
    Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14147
    Cc: Mika Westerberg <[email protected]>
    Cc: [email protected]
    Reviewed-by: Mika Westerberg <[email protected]>
    Signed-off-by: Imre Deak <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    (cherry picked from commit c3a48363cf1f76147088b1adb518136ac5df86a0)
    Signed-off-by: Joonas Lahtinen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/i915/dsi: Fix off by one in BXT_MIPI_TRANS_VTOTAL [+ + +]
Author: Ville Syrjälä <[email protected]>
Date:   Fri Mar 14 17:01:34 2025 +0200

    drm/i915/dsi: Fix off by one in BXT_MIPI_TRANS_VTOTAL
    
    commit c464ce6af332e7c802c36cd337cacf81db05400c upstream.
    
    BXT_MIPI_TRANS_VTOTAL must be programmed with vtotal-1
    instead of vtotal. Make it so.
    
    Cc: [email protected]
    Signed-off-by: Ville Syrjälä <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Reviewed-by: Jani Nikula <[email protected]>
    (cherry picked from commit 7b3685c9b38c3097f465efec8b24dbed63258cf6)
    Signed-off-by: Joonas Lahtinen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/i915/gem: Allow EXEC_CAPTURE on recoverable contexts on DG1 [+ + +]
Author: Ville Syrjälä <[email protected]>
Date:   Mon May 12 21:22:15 2025 +0200

    drm/i915/gem: Allow EXEC_CAPTURE on recoverable contexts on DG1
    
    [ Upstream commit 25eeba495b2fc16037647c1a51bcdf6fc157af5c ]
    
    The intel-media-driver is currently broken on DG1 because
    it uses EXEC_CAPTURE with recovarable contexts. Relax the
    check to allow that.
    
    I've also submitted a fix for the intel-media-driver:
    https://github.com/intel/media-driver/pull/1920
    
    Cc: [email protected] # v6.0+
    Cc: Matthew Auld <[email protected]>
    Cc: Thomas Hellström <[email protected]>
    Testcase: igt/gem_exec_capture/capture-invisible
    Fixes: 71b1669ea9bd ("drm/i915/uapi: tweak error capture on recoverable contexts")
    Reviewed-by: Andi Shyti <[email protected]>
    Signed-off-by: Ville Syrjälä <[email protected]>
    Signed-off-by: Andi Shyti <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    (cherry picked from commit d6e020819612a4a06207af858e0978be4d3e3140)
    Signed-off-by: Joonas Lahtinen <[email protected]>
    Stable-dep-of: ed5915cfce2a ("Revert "drm/i915/gem: Allow EXEC_CAPTURE on recoverable contexts on DG1"")
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/i915/ptl: Use everywhere the correct DDI port clock select mask [+ + +]
Author: Imre Deak <[email protected]>
Date:   Mon May 12 17:26:00 2025 +0300

    drm/i915/ptl: Use everywhere the correct DDI port clock select mask
    
    commit a38b3232d618653155032a51208e974511c151e4 upstream.
    
    The PTL XELPDP_PORT_CLOCK_CTL register XELPDP_DDI_CLOCK_SELECT field's
    size is 5 bits vs. the earlier platforms where its size is 4 bits. Make
    sure the field is read-out/programmed everywhere correctly, according to
    the above.
    
    Cc: Mika Kahola <[email protected]>
    Cc: [email protected] # v6.13+
    Tested-by: Mika Kahola <[email protected]>
    Reviewed-by: Mika Kahola <[email protected]>
    Signed-off-by: Imre Deak <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    (cherry picked from commit d0bf684bd42db22e7d131a038f8f78927fa6a72a)
    Signed-off-by: Joonas Lahtinen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/i915/snps_hdmi_pll: Fix 64-bit divisor truncation by using div64_u64 [+ + +]
Author: Ankit Nautiyal <[email protected]>
Date:   Wed Jun 18 18:39:50 2025 +0530

    drm/i915/snps_hdmi_pll: Fix 64-bit divisor truncation by using div64_u64
    
    commit 9205999e9f13a07cb29d5a8836c25afdca186007 upstream.
    
    DIV_ROUND_CLOSEST_ULL uses do_div(), which expects a 32-bit divisor.
    When passing a 64-bit constant like CURVE2_MULTIPLIER, the value is
    silently truncated to u32, potentially leading to incorrect results
    on large divisors.
    
    Replace DIV_ROUND_CLOSEST_ULL with DIV64_U64_ROUND_CLOSEST which correctly
    handles full 64-bit division.
    
    v2: Use DIV64_U64_ROUND_CLOSEST instead of div64_u64 macro. (Jani)
    
    Fixes: 5947642004bf ("drm/i915/display: Add support for SNPS PHY HDMI PLL algorithm for DG2")
    Reported-by: Vas Novikov <[email protected]>
    Closes: https://lore.kernel.org/all/[email protected]/
    Cc: Ankit Nautiyal <[email protected]>
    Cc: Suraj Kandpal <[email protected]>
    Cc: Jani Nikula <[email protected]>
    Cc: Vas Novikov <[email protected]>
    Cc: [email protected] # v6.15+
    Reviewed-by: Jani Nikula <[email protected]>
    Signed-off-by: Ankit Nautiyal <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    (cherry picked from commit b300a175a11e6a934d728317dc39787723cc7917)
    Signed-off-by: Joonas Lahtinen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/i915: fix build error some more [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Fri Jun 20 13:18:18 2025 +0200

    drm/i915: fix build error some more
    
    [ Upstream commit d02b2103a08b6d6908f1d3d8e8783d3f342555ac ]
    
    An earlier patch fixed a build failure with clang, but I still see the
    same problem with some configurations using gcc:
    
    drivers/gpu/drm/i915/i915_pmu.c: In function 'config_mask':
    include/linux/compiler_types.h:568:38: error: call to '__compiletime_assert_462' declared with attribute error: BUILD_BUG_ON failed: bit > BITS_PER_TYPE(typeof_member(struct i915_pmu, enable)) - 1
    drivers/gpu/drm/i915/i915_pmu.c:116:3: note: in expansion of macro 'BUILD_BUG_ON'
      116 |   BUILD_BUG_ON(bit >
    
    As I understand it, the problem is that the function is not always fully
    inlined, but the __builtin_constant_p() can still evaluate the argument
    as being constant.
    
    Marking it as __always_inline so far works for me in all configurations.
    
    Fixes: a7137b1825b5 ("drm/i915/pmu: Fix build error with GCOV and AutoFDO enabled")
    Fixes: a644fde77ff7 ("drm/i915/pmu: Change bitmask of enabled events to u32")
    Reviewed-by: Rodrigo Vivi <[email protected]>
    Signed-off-by: Arnd Bergmann <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Rodrigo Vivi <[email protected]>
    (cherry picked from commit ef69f9dd1cd7301cdf04ba326ed28152a3affcf6)
    Signed-off-by: Joonas Lahtinen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/msm/gpu: Fix crash when throttling GPU immediately during boot [+ + +]
Author: Stephan Gerhold <[email protected]>
Date:   Tue Apr 29 10:33:56 2025 +0200

    drm/msm/gpu: Fix crash when throttling GPU immediately during boot
    
    commit b71717735be48d7743a34897e9e44a0b53e30c0e upstream.
    
    There is a small chance that the GPU is already hot during boot. In that
    case, the call to of_devfreq_cooling_register() will immediately try to
    apply devfreq cooling, as seen in the following crash:
    
      Unable to handle kernel paging request at virtual address 0000000000014110
      pc : a6xx_gpu_busy+0x1c/0x58 [msm]
      lr : msm_devfreq_get_dev_status+0xbc/0x140 [msm]
      Call trace:
       a6xx_gpu_busy+0x1c/0x58 [msm] (P)
       devfreq_simple_ondemand_func+0x3c/0x150
       devfreq_update_target+0x44/0xd8
       qos_max_notifier_call+0x30/0x84
       blocking_notifier_call_chain+0x6c/0xa0
       pm_qos_update_target+0xd0/0x110
       freq_qos_apply+0x3c/0x74
       apply_constraint+0x88/0x148
       __dev_pm_qos_update_request+0x7c/0xcc
       dev_pm_qos_update_request+0x38/0x5c
       devfreq_cooling_set_cur_state+0x98/0xf0
       __thermal_cdev_update+0x64/0xb4
       thermal_cdev_update+0x4c/0x58
       step_wise_manage+0x1f0/0x318
       __thermal_zone_device_update+0x278/0x424
       __thermal_cooling_device_register+0x2bc/0x308
       thermal_of_cooling_device_register+0x10/0x1c
       of_devfreq_cooling_register_power+0x240/0x2bc
       of_devfreq_cooling_register+0x14/0x20
       msm_devfreq_init+0xc4/0x1a0 [msm]
       msm_gpu_init+0x304/0x574 [msm]
       adreno_gpu_init+0x1c4/0x2e0 [msm]
       a6xx_gpu_init+0x5c8/0x9c8 [msm]
       adreno_bind+0x2a8/0x33c [msm]
       ...
    
    At this point we haven't initialized the GMU at all yet, so we cannot read
    the GMU registers inside a6xx_gpu_busy(). A similar issue was fixed before
    in commit 6694482a70e9 ("drm/msm: Avoid unclocked GMU register access in
    6xx gpu_busy"): msm_devfreq_init() does call devfreq_suspend_device(), but
    unlike msm_devfreq_suspend(), it doesn't set the df->suspended flag
    accordingly. This means the df->suspended flag does not match the actual
    devfreq state after initialization and msm_devfreq_get_dev_status() will
    end up accessing GMU registers, causing the crash.
    
    Fix this by setting df->suspended correctly during initialization.
    
    Cc: [email protected]
    Fixes: 6694482a70e9 ("drm/msm: Avoid unclocked GMU register access in 6xx gpu_busy")
    Signed-off-by: Stephan Gerhold <[email protected]>
    Reviewed-by: Douglas Anderson <[email protected]>
    Reviewed-by: Konrad Dybcio <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/650772/
    Signed-off-by: Rob Clark <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/panel: simple: Tianma TM070JDHG34-00: add delays [+ + +]
Author: Luca Ceresoli <[email protected]>
Date:   Fri Apr 11 21:19:45 2025 +0200

    drm/panel: simple: Tianma TM070JDHG34-00: add delays
    
    commit 716c75afd83c837f14042309126e838de040658b upstream.
    
    Add power on/off delays for the Tianma TM070JDHG34-00.
    
    Fixes: bf6daaa281f7 ("drm/panel: simple: Add Tianma TM070JDHG34-00 panel support")
    Cc: [email protected]
    Signed-off-by: Luca Ceresoli <[email protected]>
    Reviewed-by: Neil Armstrong <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Neil Armstrong <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/scheduler: signal scheduled fence when kill job [+ + +]
Author: Lin.Cao <[email protected]>
Date:   Thu May 15 10:07:13 2025 +0800

    drm/scheduler: signal scheduled fence when kill job
    
    [ Upstream commit 471db2c2d4f80ee94225a1ef246e4f5011733e50 ]
    
    When an entity from application B is killed, drm_sched_entity_kill()
    removes all jobs belonging to that entity through
    drm_sched_entity_kill_jobs_work(). If application A's job depends on a
    scheduled fence from application B's job, and that fence is not properly
    signaled during the killing process, application A's dependency cannot be
    cleared.
    
    This leads to application A hanging indefinitely while waiting for a
    dependency that will never be resolved. Fix this issue by ensuring that
    scheduled fences are properly signaled when an entity is killed, allowing
    dependent applications to continue execution.
    
    Signed-off-by: Lin.Cao <[email protected]>
    Reviewed-by: Philipp Stanner <[email protected]>
    Signed-off-by: Christian König <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/simpledrm: Do not upcast in release helpers [+ + +]
Author: Thomas Zimmermann <[email protected]>
Date:   Mon Apr 7 15:47:24 2025 +0200

    drm/simpledrm: Do not upcast in release helpers
    
    commit d231cde7c84359fb18fb268cf6cff03b5bce48ff upstream.
    
    The res pointer passed to simpledrm_device_release_clocks() and
    simpledrm_device_release_regulators() points to an instance of
    struct simpledrm_device. No need to upcast from struct drm_device.
    The upcast is harmless, as DRM device is the first field in struct
    simpledrm_device.
    
    Signed-off-by: Thomas Zimmermann <[email protected]>
    Fixes: 11e8f5fd223b ("drm: Add simpledrm driver")
    Cc: <[email protected]> # v5.14+
    Reviewed-by: Javier Martinez Canillas <[email protected]>
    Reviewed-by: Jocelyn Falempe <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/tegra: Assign plane type before registration [+ + +]
Author: Thierry Reding <[email protected]>
Date:   Mon Apr 21 11:13:05 2025 -0500

    drm/tegra: Assign plane type before registration
    
    commit 9ff4fdf4f44b69237c0afc1d3a8dac916ce66f3e upstream.
    
    Changes to a plane's type after it has been registered aren't propagated
    to userspace automatically. This could possibly be achieved by updating
    the property, but since we can already determine which type this should
    be before the registration, passing in the right type from the start is
    a much better solution.
    
    Suggested-by: Aaron Kling <[email protected]>
    Signed-off-by: Thierry Reding <[email protected]>
    Cc: [email protected]
    Fixes: 473079549f27 ("drm/tegra: dc: Add Tegra186 support")
    Signed-off-by: Aaron Kling <[email protected]>
    Signed-off-by: Thierry Reding <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/tegra: Fix a possible null pointer dereference [+ + +]
Author: Qiu-ji Chen <[email protected]>
Date:   Wed Nov 6 17:59:06 2024 +0800

    drm/tegra: Fix a possible null pointer dereference
    
    commit 780351a5f61416ed2ba1199cc57e4a076fca644d upstream.
    
    In tegra_crtc_reset(), new memory is allocated with kzalloc(), but
    no check is performed. Before calling __drm_atomic_helper_crtc_reset,
    state should be checked to prevent possible null pointer dereference.
    
    Fixes: b7e0b04ae450 ("drm/tegra: Convert to using __drm_atomic_helper_crtc_reset() for reset.")
    Cc: [email protected]
    Signed-off-by: Qiu-ji Chen <[email protected]>
    Signed-off-by: Thierry Reding <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/udl: Unregister device before cleaning up on disconnect [+ + +]
Author: Thomas Zimmermann <[email protected]>
Date:   Mon Mar 3 15:52:56 2025 +0100

    drm/udl: Unregister device before cleaning up on disconnect
    
    commit ff9cb6d2035c586ea7c8f1754d4409eec7a2d26d upstream.
    
    Disconnecting a DisplayLink device results in the following kernel
    error messages
    
    [   93.041748] [drm:udl_urb_completion [udl]] *ERROR* udl_urb_completion - nonzero write bulk status received: -115
    [   93.055299] [drm:udl_submit_urb [udl]] *ERROR* usb_submit_urb error fffffffe
    [   93.065363] [drm:udl_urb_completion [udl]] *ERROR* udl_urb_completion - nonzero write bulk status received: -115
    [   93.078207] [drm:udl_submit_urb [udl]] *ERROR* usb_submit_urb error fffffffe
    
    coming from KMS poll helpers. Shutting down poll helpers runs them
    one final time when the USB device is already gone.
    
    Run drm_dev_unplug() first in udl's USB disconnect handler. Udl's
    polling code already handles disconnects gracefully if the device has
    been marked as unplugged.
    
    Signed-off-by: Thomas Zimmermann <[email protected]>
    Fixes: b1a981bd5576 ("drm/udl: drop drm_driver.release hook")
    Cc: [email protected]
    Cc: <[email protected]> # v5.8+
    Reviewed-by: Patrik Jakobsson <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/xe/display: Add check for alloc_ordered_workqueue() [+ + +]
Author: Haoxiang Li <[email protected]>
Date:   Fri May 16 15:16:55 2025 +0300

    drm/xe/display: Add check for alloc_ordered_workqueue()
    
    commit 62207293479e6c03ef498a70f2914c51f4d31d2c upstream.
    
    Add check for the return value of alloc_ordered_workqueue()
    in xe_display_create() to catch potential exception.
    
    Fixes: 44e694958b95 ("drm/xe/display: Implement display support")
    Cc: [email protected]
    Signed-off-by: Haoxiang Li <[email protected]>
    Reviewed-by: Matthew Auld <[email protected]>
    Link: https://lore.kernel.org/r/4ee1b0e5d1626ce1dde2e82af05c2edaed50c3aa.1747397638.git.jani.nikula@intel.com
    Signed-off-by: Jani Nikula <[email protected]>
    (cherry picked from commit 5b62d63395d5b7d4094e7cd380bccae4b25415cb)
    Signed-off-by: Thomas Hellström <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/xe/guc: Explicitly exit CT safe mode on unwind [+ + +]
Author: Michal Wajdeczko <[email protected]>
Date:   Fri Jun 13 00:09:37 2025 +0200

    drm/xe/guc: Explicitly exit CT safe mode on unwind
    
    [ Upstream commit ad40098da5c3b43114d860a5b5740e7204158534 ]
    
    During driver probe we might be briefly using CT safe mode, which
    is based on a delayed work, but usually we are able to stop this
    once we have IRQ fully operational.  However, if we abort the probe
    quite early then during unwind we might try to destroy the workqueue
    while there is still a pending delayed work that attempts to restart
    itself which triggers a WARN.
    
    This was recently observed during unsuccessful VF initialization:
    
     [ ] xe 0000:00:02.1: probe with driver xe failed with error -62
     [ ] ------------[ cut here ]------------
     [ ] workqueue: cannot queue safe_mode_worker_func [xe] on wq xe-g2h-wq
     [ ] WARNING: CPU: 9 PID: 0 at kernel/workqueue.c:2257 __queue_work+0x287/0x710
     [ ] RIP: 0010:__queue_work+0x287/0x710
     [ ] Call Trace:
     [ ]  delayed_work_timer_fn+0x19/0x30
     [ ]  call_timer_fn+0xa1/0x2a0
    
    Exit the CT safe mode on unwind to avoid that warning.
    
    Fixes: 09b286950f29 ("drm/xe/guc: Allow CTB G2H processing without G2H IRQ")
    Signed-off-by: Michal Wajdeczko <[email protected]>
    Cc: Matthew Brost <[email protected]>
    Reviewed-by: Matthew Brost <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    (cherry picked from commit 2ddbb73ec20b98e70a5200cb85deade22ccea2ec)
    Signed-off-by: Thomas Hellström <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/xe/guc_submit: add back fix [+ + +]
Author: Matthew Auld <[email protected]>
Date:   Tue Jun 3 18:42:14 2025 +0100

    drm/xe/guc_submit: add back fix
    
    commit 2e824747cfbdf1fba88df5e5800d284b2602ae8f upstream.
    
    Daniele noticed that the fix in commit 2d2be279f1ca ("drm/xe: fix UAF
    around queue destruction") looks to have been unintentionally removed as
    part of handling a conflict in some past merge commit. Add it back.
    
    Fixes: ac44ff7cec33 ("Merge tag 'drm-xe-fixes-2024-10-10' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes")
    Reported-by: Daniele Ceraolo Spurio <[email protected]>
    Signed-off-by: Matthew Auld <[email protected]>
    Cc: Matthew Brost <[email protected]>
    Cc: <[email protected]> # v6.12+
    Reviewed-by: Matthew Brost <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    (cherry picked from commit 9d9fca62dc49d96f97045b6d8e7402a95f8cf92a)
    Signed-off-by: Thomas Hellström <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/xe/sched: stop re-submitting signalled jobs [+ + +]
Author: Matthew Auld <[email protected]>
Date:   Wed May 28 12:33:29 2025 +0100

    drm/xe/sched: stop re-submitting signalled jobs
    
    commit 0ee54d5cacc0276ec631ac149825a24b59c51c38 upstream.
    
    Customer is reporting a really subtle issue where we get random DMAR
    faults, hangs and other nasties for kernel migration jobs when stressing
    stuff like s2idle/s3/s4. The explosions seems to happen somewhere
    after resuming the system with splats looking something like:
    
    PM: suspend exit
    rfkill: input handler disabled
    xe 0000:00:02.0: [drm] GT0: Engine reset: engine_class=bcs, logical_mask: 0x2, guc_id=0
    xe 0000:00:02.0: [drm] GT0: Timedout job: seqno=24496, lrc_seqno=24496, guc_id=0, flags=0x13 in no process [-1]
    xe 0000:00:02.0: [drm] GT0: Kernel-submitted job timed out
    
    The likely cause appears to be a race between suspend cancelling the
    worker that processes the free_job()'s, such that we still have pending
    jobs to be freed after the cancel. Following from this, on resume the
    pending_list will now contain at least one already complete job, but it
    looks like we call drm_sched_resubmit_jobs(), which will then call
    run_job() on everything still on the pending_list. But if the job was
    already complete, then all the resources tied to the job, like the bb
    itself, any memory that is being accessed, the iommu mappings etc. might
    be long gone since those are usually tied to the fence signalling.
    
    This scenario can be seen in ftrace when running a slightly modified
    xe_pm IGT (kernel was only modified to inject artificial latency into
    free_job to make the race easier to hit):
    
    xe_sched_job_run: dev=0000:00:02.0, fence=0xffff888276cc8540, seqno=0, lrc_seqno=0, gt=0, guc_id=0, batch_addr=0x000000146910 ...
    xe_exec_queue_stop:   dev=0000:00:02.0, 3:0x2, gt=0, width=1, guc_id=0, guc_state=0x0, flags=0x13
    xe_exec_queue_stop:   dev=0000:00:02.0, 3:0x2, gt=0, width=1, guc_id=1, guc_state=0x0, flags=0x4
    xe_exec_queue_stop:   dev=0000:00:02.0, 4:0x1, gt=1, width=1, guc_id=0, guc_state=0x0, flags=0x3
    xe_exec_queue_stop:   dev=0000:00:02.0, 1:0x1, gt=1, width=1, guc_id=1, guc_state=0x0, flags=0x3
    xe_exec_queue_stop:   dev=0000:00:02.0, 4:0x1, gt=1, width=1, guc_id=2, guc_state=0x0, flags=0x3
    xe_exec_queue_resubmit: dev=0000:00:02.0, 3:0x2, gt=0, width=1, guc_id=0, guc_state=0x0, flags=0x13
    xe_sched_job_run: dev=0000:00:02.0, fence=0xffff888276cc8540, seqno=0, lrc_seqno=0, gt=0, guc_id=0, batch_addr=0x000000146910 ...
    .....
    xe_exec_queue_memory_cat_error: dev=0000:00:02.0, 3:0x2, gt=0, width=1, guc_id=0, guc_state=0x3, flags=0x13
    
    So the job_run() is clearly triggered twice for the same job, even
    though the first must have already signalled to completion during
    suspend. We can also see a CAT error after the re-submit.
    
    To prevent this only resubmit jobs on the pending_list that have not yet
    signalled.
    
    v2:
      - Make sure to re-arm the fence callbacks with sched_start().
    v3 (Matt B):
      - Stop using drm_sched_resubmit_jobs(), which appears to be deprecated
        and just open-code a simple loop such that we skip calling run_job()
        on anything already signalled.
    
    Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4856
    Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
    Signed-off-by: Matthew Auld <[email protected]>
    Cc: Thomas Hellström <[email protected]>
    Cc: Matthew Brost <[email protected]>
    Cc: William Tseng <[email protected]>
    Cc: <[email protected]> # v6.8+
    Reviewed-by: Matthew Brost <[email protected]>
    Reviewed-by: Tejas Upadhyay <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    (cherry picked from commit 38fafa9f392f3110d2de431432d43f4eef99cd1b)
    Signed-off-by: Thomas Hellström <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/xe/vm: move rebind_work init earlier [+ + +]
Author: Matthew Auld <[email protected]>
Date:   Wed May 14 16:24:25 2025 +0100

    drm/xe/vm: move rebind_work init earlier
    
    commit a63e99b4d6d3a0353ef47146dd5bd562f08e1786 upstream.
    
    In xe_vm_close_and_put() we need to be able to call
    flush_work(rebind_work), however during vm creation we can call this on
    the error path, before having actually set up the worker, leading to a
    splat from flush_work().
    
    It looks like we can simply move the worker init step earlier to fix
    this.
    
    Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
    Signed-off-by: Matthew Auld <[email protected]>
    Cc: Matthew Brost <[email protected]>
    Cc: <[email protected]> # v6.8+
    Reviewed-by: Matthew Brost <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    (cherry picked from commit 96af397aa1a2d1032a6e28ff3f4bc0ab4be40e1d)
    Signed-off-by: Thomas Hellström <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/xe: Fix early wedge on GuC load failure [+ + +]
Author: Daniele Ceraolo Spurio <[email protected]>
Date:   Wed Jun 11 14:44:54 2025 -0700

    drm/xe: Fix early wedge on GuC load failure
    
    commit a39d082c3553d35b4fe5585e1e2fb221c130cae8 upstream.
    
    When the GuC fails to load we declare the device wedged. However, the
    very first GuC load attempt on GT0 (from xe_gt_init_hwconfig) is done
    before the GT1 GuC objects are initialized, so things go bad when the
    wedge code attempts to cleanup GT1. To fix this, check the initialization
    status in the functions called during wedge.
    
    Fixes: 7dbe8af13c18 ("drm/xe: Wedge the entire device")
    Signed-off-by: Daniele Ceraolo Spurio <[email protected]>
    Cc: Rodrigo Vivi <[email protected]>
    Cc: Matthew Brost <[email protected]>
    Cc: Jonathan Cavitt <[email protected]>
    Cc: Lucas De Marchi <[email protected]>
    Cc: Zhanjun Dong <[email protected]>
    Cc: [email protected] # v6.12+: 1e1981b16bb1: drm/xe: Fix taking invalid lock on wedge
    Cc: [email protected] # v6.12+
    Reviewed-by: Jonathan Cavitt <[email protected]>
    Reviewed-by: Lucas De Marchi <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lucas De Marchi <[email protected]>
    (cherry picked from commit 0b93b7dcd9eb888a6ac7546560877705d4ad61bf)
    Signed-off-by: Thomas Hellström <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/xe: Fix memset on iomem [+ + +]
Author: Lucas De Marchi <[email protected]>
Date:   Thu Jun 12 15:14:12 2025 -0700

    drm/xe: Fix memset on iomem
    
    commit 87a15c89d8c7b00b0fc94e0d4f554f7ee2fe6961 upstream.
    
    It should rather use xe_map_memset() as the BO is created with
    XE_BO_FLAG_VRAM_IF_DGFX in xe_guc_pc_init().
    
    Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
    Cc: [email protected]
    Reviewed-by: Matthew Brost <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lucas De Marchi <[email protected]>
    (cherry picked from commit 21cf47d89fba353b2d5915ba4718040c4cb955d3)
    Signed-off-by: Thomas Hellström <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/xe: Fix taking invalid lock on wedge [+ + +]
Author: Lucas De Marchi <[email protected]>
Date:   Wed Apr 2 22:38:05 2025 -0700

    drm/xe: Fix taking invalid lock on wedge
    
    commit 1e1981b16bb1bbe2fafa57ed439b45cb5b34e32d upstream.
    
    If device wedges on e.g. GuC upload, the submission is not yet enabled
    and the state is not even initialized. Protect the wedge call so it does
    nothing in this case. It fixes the following splat:
    
            [] xe 0000:bf:00.0: [drm] device wedged, needs recovery
            [] ------------[ cut here ]------------
            [] DEBUG_LOCKS_WARN_ON(lock->magic != lock)
            [] WARNING: CPU: 48 PID: 312 at kernel/locking/mutex.c:564 __mutex_lock+0x8a1/0xe60
            ...
            [] RIP: 0010:__mutex_lock+0x8a1/0xe60
            []  mutex_lock_nested+0x1b/0x30
            []  xe_guc_submit_wedge+0x80/0x2b0 [xe]
    
    Reviewed-by: Balasubramani Vivekanandan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lucas De Marchi <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/xe: move DPT l2 flush to a more sensible place [+ + +]
Author: Matthew Auld <[email protected]>
Date:   Fri Jun 6 11:45:48 2025 +0100

    drm/xe: move DPT l2 flush to a more sensible place
    
    commit f16873f42a06b620669d48a4b5c3f888cb3653a1 upstream.
    
    Only need the flush for DPT host updates here. Normal GGTT updates don't
    need special flush.
    
    Fixes: 01570b446939 ("drm/xe/bmg: implement Wa_16023588340")
    Signed-off-by: Matthew Auld <[email protected]>
    Cc: Maarten Lankhorst <[email protected]>
    Cc: [email protected] # v6.12+
    Reviewed-by: Ville Syrjälä <[email protected]>
    Reviewed-by: Lucas De Marchi <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lucas De Marchi <[email protected]>
    (cherry picked from commit 35db1da40c8cfd7511dc42f342a133601eb45449)
    Signed-off-by: Thomas Hellström <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/xe: Move DSB l2 flush to a more sensible place [+ + +]
Author: Maarten Lankhorst <[email protected]>
Date:   Fri Jun 6 11:45:47 2025 +0100

    drm/xe: Move DSB l2 flush to a more sensible place
    
    commit a4b1b51ae132ac199412028a2df7b6c267888190 upstream.
    
    Flushing l2 is only needed after all data has been written.
    
    Fixes: 01570b446939 ("drm/xe/bmg: implement Wa_16023588340")
    Signed-off-by: Maarten Lankhorst <[email protected]>
    Cc: Matthew Auld <[email protected]>
    Cc: [email protected] # v6.12+
    Reviewed-by: Matthew Auld <[email protected]>
    Signed-off-by: Matthew Auld <[email protected]>
    Reviewed-by: Lucas De Marchi <[email protected]>
    Reviewed-by: Ville Syrjälä <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lucas De Marchi <[email protected]>
    (cherry picked from commit 0dd2dd0182bc444a62652e89d08c7f0e4fde15ba)
    Signed-off-by: Thomas Hellström <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/xe: Process deferred GGTT node removals on device unwind [+ + +]
Author: Michal Wajdeczko <[email protected]>
Date:   Fri Jun 13 00:09:36 2025 +0200

    drm/xe: Process deferred GGTT node removals on device unwind
    
    [ Upstream commit af2b588abe006bd55ddd358c4c3b87523349c475 ]
    
    While we are indirectly draining our dedicated workqueue ggtt->wq
    that we use to complete asynchronous removal of some GGTT nodes,
    this happends as part of the managed-drm unwinding (ggtt_fini_early),
    which could be later then manage-device unwinding, where we could
    already unmap our MMIO/GMS mapping (mmio_fini).
    
    This was recently observed during unsuccessful VF initialization:
    
     [ ] xe 0000:00:02.1: probe with driver xe failed with error -62
     [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747340 __xe_bo_unpin_map_no_vm (16 bytes)
     [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747540 __xe_bo_unpin_map_no_vm (16 bytes)
     [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747240 __xe_bo_unpin_map_no_vm (16 bytes)
     [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747040 tiles_fini (16 bytes)
     [ ] xe 0000:00:02.1: DEVRES REL ffff88811e746840 mmio_fini (16 bytes)
     [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747f40 xe_bo_pinned_fini (16 bytes)
     [ ] xe 0000:00:02.1: DEVRES REL ffff88811e746b40 devm_drm_dev_init_release (16 bytes)
     [ ] xe 0000:00:02.1: [drm:drm_managed_release] drmres release begin
     [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef81640 __fini_relay (8 bytes)
     [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80d40 guc_ct_fini (8 bytes)
     [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80040 __drmm_mutex_release (8 bytes)
     [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80140 ggtt_fini_early (8 bytes)
    
    and this was leading to:
    
     [ ] BUG: unable to handle page fault for address: ffffc900058162a0
     [ ] #PF: supervisor write access in kernel mode
     [ ] #PF: error_code(0x0002) - not-present page
     [ ] Oops: Oops: 0002 [#1] SMP NOPTI
     [ ] Tainted: [W]=WARN
     [ ] Workqueue: xe-ggtt-wq ggtt_node_remove_work_func [xe]
     [ ] RIP: 0010:xe_ggtt_set_pte+0x6d/0x350 [xe]
     [ ] Call Trace:
     [ ]  <TASK>
     [ ]  xe_ggtt_clear+0xb0/0x270 [xe]
     [ ]  ggtt_node_remove+0xbb/0x120 [xe]
     [ ]  ggtt_node_remove_work_func+0x30/0x50 [xe]
     [ ]  process_one_work+0x22b/0x6f0
     [ ]  worker_thread+0x1e8/0x3d
    
    Add managed-device action that will explicitly drain the workqueue
    with all pending node removals prior to releasing MMIO/GSM mapping.
    
    Fixes: 919bb54e989c ("drm/xe: Fix missing runtime outer protection for ggtt_remove_node")
    Signed-off-by: Michal Wajdeczko <[email protected]>
    Cc: Rodrigo Vivi <[email protected]>
    Cc: Lucas De Marchi <[email protected]>
    Reviewed-by: Rodrigo Vivi <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    (cherry picked from commit 89d2835c3680ab1938e22ad81b1c9f8c686bd391)
    Signed-off-by: Thomas Hellström <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm: writeback: Fix drm_writeback_connector_cleanup signature [+ + +]
Author: Louis Chauvet <[email protected]>
Date:   Tue Apr 29 10:36:23 2025 +0200

    drm: writeback: Fix drm_writeback_connector_cleanup signature
    
    [ Upstream commit fb721b2c35b1829b8ecf62e3adb41cf30260316a ]
    
    The drm_writeback_connector_cleanup have the signature:
    
         static void drm_writeback_connector_cleanup(
                    struct drm_device *dev,
                    struct drm_writeback_connector *wb_connector)
    
    But it is stored and used as a drmres_release_t
    
        typedef void (*drmres_release_t)(struct drm_device *dev, void *res);
    
    While the current code is valid and does not produce any warning, the
    CFI runtime check (CONFIG_CFI_CLANG) can fail because the function
    signature is not the same as drmres_release_t.
    
    In order to fix this, change the function signature to match what is
    expected by drmres_release_t.
    
    Fixes: 1914ba2b91ea ("drm: writeback: Create drmm variants for drm_writeback_connector initialization")
    
    Suggested-by: Mark Yacoub <[email protected]>
    Reviewed-by: Maíra Canal <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Louis Chauvet <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
dt-bindings: serial: 8250: Make clocks and clock-frequency exclusive [+ + +]
Author: Yao Zi <[email protected]>
Date:   Mon Jun 23 09:34:45 2025 +0000

    dt-bindings: serial: 8250: Make clocks and clock-frequency exclusive
    
    commit 09812134071b3941fb81def30b61ed36d3a5dfb5 upstream.
    
    The 8250 binding before converting to json-schema states,
    
      - clock-frequency : the input clock frequency for the UART
            or
      - clocks phandle to refer to the clk used as per Documentation/devicetree
    
    for clock-related properties, where "or" indicates these properties
    shouldn't exist at the same time.
    
    Additionally, the behavior of Linux's driver is strange when both clocks
    and clock-frequency are specified: it ignores clocks and obtains the
    frequency from clock-frequency, left the specified clocks unclaimed. It
    may even be disabled, which is undesired most of the time.
    
    But "anyOf" doesn't prevent these two properties from coexisting, as it
    considers the object valid as long as there's at LEAST one match.
    
    Let's switch to "oneOf" and disallows the other property if one exists,
    precisely matching the original binding and avoiding future confusion on
    the driver's behavior.
    
    Fixes: e69f5dc623f9 ("dt-bindings: serial: Convert 8250 to json-schema")
    Cc: stable <[email protected]>
    Signed-off-by: Yao Zi <[email protected]>
    Reviewed-by: Conor Dooley <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
EDAC/amd64: Fix size calculation for Non-Power-of-Two DIMMs [+ + +]
Author: Avadhut Naik <[email protected]>
Date:   Thu May 29 20:50:04 2025 +0000

    EDAC/amd64: Fix size calculation for Non-Power-of-Two DIMMs
    
    commit a3f3040657417aeadb9622c629d4a0c2693a0f93 upstream.
    
    Each Chip-Select (CS) of a Unified Memory Controller (UMC) on AMD Zen-based
    SOCs has an Address Mask and a Secondary Address Mask register associated with
    it. The amd64_edac module logs DIMM sizes on a per-UMC per-CS granularity
    during init using these two registers.
    
    Currently, the module primarily considers only the Address Mask register for
    computing DIMM sizes. The Secondary Address Mask register is only considered
    for odd CS. Additionally, if it has been considered, the Address Mask register
    is ignored altogether for that CS. For power-of-two DIMMs i.e. DIMMs whose
    total capacity is a power of two (32GB, 64GB, etc), this is not an issue
    since only the Address Mask register is used.
    
    For non-power-of-two DIMMs i.e., DIMMs whose total capacity is not a power of
    two (48GB, 96GB, etc), however, the Secondary Address Mask register is used
    in conjunction with the Address Mask register. However, since the module only
    considers either of the two registers for a CS, the size computed by the
    module is incorrect. The Secondary Address Mask register is not considered for
    even CS, and the Address Mask register is not considered for odd CS.
    
    Introduce a new helper function so that both Address Mask and Secondary
    Address Mask registers are considered, when valid, for computing DIMM sizes.
    Furthermore, also rename some variables for greater clarity.
    
    Fixes: 81f5090db843 ("EDAC/amd64: Support asymmetric dual-rank DIMMs")
    Closes: https://lore.kernel.org/[email protected]
    Reported-by: Žilvinas Žaltiena <[email protected]>
    Signed-off-by: Avadhut Naik <[email protected]>
    Signed-off-by: Borislav Petkov (AMD) <[email protected]>
    Reviewed-by: Yazen Ghannam <[email protected]>
    Tested-by: Žilvinas Žaltiena <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ethernet: ionic: Fix DMA mapping tests [+ + +]
Author: Thomas Fourier <[email protected]>
Date:   Thu Jun 19 11:45:30 2025 +0200

    ethernet: ionic: Fix DMA mapping tests
    
    [ Upstream commit d5e3241c5a386a2425823c8c7afb77a465bd040f ]
    
    Change error values of `ionic_tx_map_single()` and `ionic_tx_map_frag()`
    from 0 to `DMA_MAPPING_ERROR` to prevent collision with 0 as a valid
    address.
    
    This also fixes the use of `dma_mapping_error()` to test against 0 in
    `ionic_xdp_post_frame()`
    
    Fixes: 0f3154e6bcb3 ("ionic: Add Tx and Rx handling")
    Fixes: 56e41ee12d2d ("ionic: better dma-map error handling")
    Fixes: ac8813c0ab7d ("ionic: convert Rx queue buffers to use page_pool")
    Signed-off-by: Thomas Fourier <[email protected]>
    Reviewed-by: Brett Creeley <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
f2fs: don't over-report free space or inodes in statvfs [+ + +]
Author: Chao Yu <[email protected]>
Date:   Tue May 13 19:25:38 2025 +0800

    f2fs: don't over-report free space or inodes in statvfs
    
    [ Upstream commit a9201960623287927bf5776de3f70fb2fbde7e02 ]
    
    This fixes an analogus bug that was fixed in modern filesystems:
    a) xfs in commit 4b8d867ca6e2 ("xfs: don't over-report free space or
    inodes in statvfs")
    b) ext4 in commit f87d3af74193 ("ext4: don't over-report free space
    or inodes in statvfs")
    where statfs can report misleading / incorrect information where
    project quota is enabled, and the free space is less than the
    remaining quota.
    
    This commit will resolve a test failure in generic/762 which tests
    for this bug.
    
    generic/762       - output mismatch (see /share/git/fstests/results//generic/762.out.bad)
    #    --- tests/generic/762.out   2025-04-15 10:21:53.371067071 +0800
    #    +++ /share/git/fstests/results//generic/762.out.bad 2025-05-13 16:13:37.000000000 +0800
    #    @@ -6,8 +6,10 @@
    #     root blocks2 is in range
    #     dir blocks2 is in range
    #     root bavail2 is in range
    #    -dir bavail2 is in range
    #    +dir bavail2 has value of 1539066
    #    +dir bavail2 is NOT in range 304734.87 .. 310891.13
    #     root blocks3 is in range
    #    ...
    #    (Run 'diff -u /share/git/fstests/tests/generic/762.out /share/git/fstests/results//generic/762.out.bad'  to see the entire diff)
    
    HINT: You _MAY_ be missing kernel fix:
          XXXXXXXXXXXXXX xfs: don't over-report free space or inodes in statvfs
    
    Cc: [email protected]
    Fixes: ddc34e328d06 ("f2fs: introduce f2fs_statfs_project")
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix to zero post-eof page [+ + +]
Author: Chao Yu <[email protected]>
Date:   Thu Jun 5 11:26:33 2025 +0800

    f2fs: fix to zero post-eof page
    
    commit ba8dac350faf16afc129ce6303ca4feaf083ccb1 upstream.
    
    fstest reports a f2fs bug:
    
    #generic/363 42s ... [failed, exit status 1]- output mismatch (see /share/git/fstests/results//generic/363.out.bad)
    #    --- tests/generic/363.out   2025-01-12 21:57:40.271440542 +0800
    #    +++ /share/git/fstests/results//generic/363.out.bad 2025-05-19 19:55:58.000000000 +0800
    #    @@ -1,2 +1,78 @@
    #     QA output created by 363
    #     fsx -q -S 0 -e 1 -N 100000
    #    +READ BAD DATA: offset = 0xd6fb, size = 0xf044, fname = /mnt/f2fs/junk
    #    +OFFSET      GOOD    BAD     RANGE
    #    +0x1540d     0x0000  0x2a25  0x0
    #    +operation# (mod 256) for the bad data may be 37
    #    +0x1540e     0x0000  0x2527  0x1
    #    ...
    #    (Run 'diff -u /share/git/fstests/tests/generic/363.out /share/git/fstests/results//generic/363.out.bad'  to see the entire diff)
    Ran: generic/363
    Failures: generic/363
    Failed 1 of 1 tests
    
    The root cause is user can update post-eof page via mmap [1], however, f2fs
    missed to zero post-eof page in below operations, so, once it expands i_size,
    then it will include dummy data locates previous post-eof page, so during
    below operations, we need to zero post-eof page.
    
    Operations which can include dummy data after previous i_size after expanding
    i_size:
    - write
    - mapwrite [1]
    - truncate
    - fallocate
     * preallocate
     * zero_range
     * insert_range
     * collapse_range
    - clone_range (doesn’t support in f2fs)
    - copy_range (doesn’t support in f2fs)
    
    [1] https://man7.org/linux/man-pages/man2/mmap.2.html 'BUG section'
    
    Cc: [email protected]
    Signed-off-by: Chao Yu <[email protected]>
    Reviewed-by: Zhiguo Niu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
fs/proc/task_mmu: fix PAGE_IS_PFNZERO detection for the huge zero folio [+ + +]
Author: David Hildenbrand <[email protected]>
Date:   Tue Jun 17 16:35:32 2025 +0200

    fs/proc/task_mmu: fix PAGE_IS_PFNZERO detection for the huge zero folio
    
    commit 4a5e85f4eb8fd18b1266342d100e4f0849544ca0 upstream.
    
    is_zero_pfn() does not work for the huge zero folio. Fix it by using
    is_huge_zero_pmd().
    
    This can cause the PAGEMAP_SCAN ioctl against /proc/pid/pagemap to
    present pages as PAGE_IS_PRESENT rather than as PAGE_IS_PFNZERO.
    
    Found by code inspection.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 52526ca7fdb9 ("fs/proc/task_mmu: implement IOCTL to get and optionally clear info about PTEs")
    Signed-off-by: David Hildenbrand <[email protected]>
    Cc: Muhammad Usama Anjum <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
fuse: fix race between concurrent setattrs from multiple nodes [+ + +]
Author: Guang Yuan Wu <[email protected]>
Date:   Fri May 2 04:04:21 2025 +0000

    fuse: fix race between concurrent setattrs from multiple nodes
    
    [ Upstream commit 69efbff69f89c9b2b72c4d82ad8b59706add768a ]
    
    When mounting a user-space filesystem on multiple clients, after
    concurrent ->setattr() calls from different node, stale inode
    attributes may be cached in some node.
    
    This is caused by fuse_setattr() racing with
    fuse_reverse_inval_inode().
    
    When filesystem server receives setattr request, the client node
    with valid iattr cached will be required to update the fuse_inode's
    attr_version and invalidate the cache by fuse_reverse_inval_inode(),
    and at the next call to ->getattr() they will be fetched from user
    space.
    
    The race scenario is:
    1. client-1 sends setattr (iattr-1) request to server
    2. client-1 receives the reply from server
    3. before client-1 updates iattr-1 to the cached attributes by
       fuse_change_attributes_common(), server receives another setattr
       (iattr-2) request from client-2
    4. server requests client-1 to update the inode attr_version and
       invalidate the cached iattr, and iattr-1 becomes staled
    5. client-2 receives the reply from server, and caches iattr-2
    6. continue with step 2, client-1 invokes
       fuse_change_attributes_common(), and caches iattr-1
    
    The issue has been observed from concurrent of chmod, chown, or
    truncate, which all invoke ->setattr() call.
    
    The solution is to use fuse_inode's attr_version to check whether
    the attributes have been modified during the setattr request's
    lifetime.  If so, mark the attributes as invalid in the function
    fuse_change_attributes_common().
    
    Signed-off-by: Guang Yuan Wu <[email protected]>
    Reviewed-by: Bernd Schubert <[email protected]>
    Signed-off-by: Miklos Szeredi <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

fuse: fix runtime warning on truncate_folio_batch_exceptionals() [+ + +]
Author: Haiyue Wang <[email protected]>
Date:   Sun Jun 22 01:13:51 2025 +0800

    fuse: fix runtime warning on truncate_folio_batch_exceptionals()
    
    commit befd9a71d859ea625eaa84dae1b243efb3df3eca upstream.
    
    The WARN_ON_ONCE is introduced on truncate_folio_batch_exceptionals() to
    capture whether the filesystem has removed all DAX entries or not.
    
    And the fix has been applied on the filesystem xfs and ext4 by the commit
    0e2f80afcfa6 ("fs/dax: ensure all pages are idle prior to filesystem
    unmount").
    
    Apply the missed fix on filesystem fuse to fix the runtime warning:
    
    [    2.011450] ------------[ cut here ]------------
    [    2.011873] WARNING: CPU: 0 PID: 145 at mm/truncate.c:89 truncate_folio_batch_exceptionals+0x272/0x2b0
    [    2.012468] Modules linked in:
    [    2.012718] CPU: 0 UID: 1000 PID: 145 Comm: weston Not tainted 6.16.0-rc2-WSL2-STABLE #2 PREEMPT(undef)
    [    2.013292] RIP: 0010:truncate_folio_batch_exceptionals+0x272/0x2b0
    [    2.013704] Code: 48 63 d0 41 29 c5 48 8d 1c d5 00 00 00 00 4e 8d 6c 2a 01 49 c1 e5 03 eb 09 48 83 c3 08 49 39 dd 74 83 41 f6 44 1c 08 01 74 ef <0f> 0b 49 8b 34 1e 48 89 ef e8 10 a2 17 00 eb df 48 8b 7d 00 e8 35
    [    2.014845] RSP: 0018:ffffa47ec33f3b10 EFLAGS: 00010202
    [    2.015279] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
    [    2.015884] RDX: 0000000000000000 RSI: ffffa47ec33f3ca0 RDI: ffff98aa44f3fa80
    [    2.016377] RBP: ffff98aa44f3fbf0 R08: ffffa47ec33f3ba8 R09: 0000000000000000
    [    2.016942] R10: 0000000000000001 R11: 0000000000000000 R12: ffffa47ec33f3ca0
    [    2.017437] R13: 0000000000000008 R14: ffffa47ec33f3ba8 R15: 0000000000000000
    [    2.017972] FS:  000079ce006afa40(0000) GS:ffff98aade441000(0000) knlGS:0000000000000000
    [    2.018510] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [    2.018987] CR2: 000079ce03e74000 CR3: 000000010784f006 CR4: 0000000000372eb0
    [    2.019518] Call Trace:
    [    2.019729]  <TASK>
    [    2.019901]  truncate_inode_pages_range+0xd8/0x400
    [    2.020280]  ? timerqueue_add+0x66/0xb0
    [    2.020574]  ? get_nohz_timer_target+0x2a/0x140
    [    2.020904]  ? timerqueue_add+0x66/0xb0
    [    2.021231]  ? timerqueue_del+0x2e/0x50
    [    2.021646]  ? __remove_hrtimer+0x39/0x90
    [    2.022017]  ? srso_alias_untrain_ret+0x1/0x10
    [    2.022497]  ? psi_group_change+0x136/0x350
    [    2.023046]  ? _raw_spin_unlock+0xe/0x30
    [    2.023514]  ? finish_task_switch.isra.0+0x8d/0x280
    [    2.024068]  ? __schedule+0x532/0xbd0
    [    2.024551]  fuse_evict_inode+0x29/0x190
    [    2.025131]  evict+0x100/0x270
    [    2.025641]  ? _atomic_dec_and_lock+0x39/0x50
    [    2.026316]  ? __pfx_generic_delete_inode+0x10/0x10
    [    2.026843]  __dentry_kill+0x71/0x180
    [    2.027335]  dput+0xeb/0x1b0
    [    2.027725]  __fput+0x136/0x2b0
    [    2.028054]  __x64_sys_close+0x3d/0x80
    [    2.028469]  do_syscall_64+0x6d/0x1b0
    [    2.028832]  ? clear_bhb_loop+0x30/0x80
    [    2.029182]  ? clear_bhb_loop+0x30/0x80
    [    2.029533]  ? clear_bhb_loop+0x30/0x80
    [    2.029902]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
    [    2.030423] RIP: 0033:0x79ce03d0d067
    [    2.030820] Code: b8 ff ff ff ff e9 3e ff ff ff 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 c3 a7 f8 ff
    [    2.032354] RSP: 002b:00007ffef0498948 EFLAGS: 00000246 ORIG_RAX: 0000000000000003
    [    2.032939] RAX: ffffffffffffffda RBX: 00007ffef0498960 RCX: 000079ce03d0d067
    [    2.033612] RDX: 0000000000000003 RSI: 0000000000001000 RDI: 000000000000000d
    [    2.034289] RBP: 00007ffef0498a30 R08: 000000000000000d R09: 0000000000000000
    [    2.034944] R10: 00007ffef0498978 R11: 0000000000000246 R12: 0000000000000001
    [    2.035610] R13: 00007ffef0498960 R14: 000079ce03e09ce0 R15: 0000000000000003
    [    2.036301]  </TASK>
    [    2.036532] ---[ end trace 0000000000000000 ]---
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: bde708f1a65d ("fs/dax: always remove DAX page-cache entries when breaking layouts")
    Signed-off-by: Haiyue Wang <[email protected]>
    Cc: Alistair Popple <[email protected]>
    Cc: Dan Williams <[email protected]>
    Cc: Miklos Szeredi <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
HID: appletb-kbd: fix "appletb_backlight" backlight device reference counting [+ + +]
Author: Qasim Ijaz <[email protected]>
Date:   Sun Jun 15 23:59:41 2025 +0100

    HID: appletb-kbd: fix "appletb_backlight" backlight device reference counting
    
    commit 4540e41e753a7d69ecd3f5bad51fe620205c3a18 upstream.
    
    During appletb_kbd_probe, probe attempts to get the backlight device
    by name. When this happens backlight_device_get_by_name looks for a
    device in the backlight class which has name "appletb_backlight" and
    upon finding a match it increments the reference count for the device
    and returns it to the caller. However this reference is never released
    leading to a reference leak.
    
    Fix this by decrementing the backlight device reference count on removal
    via put_device and on probe failure.
    
    Fixes: 93a0fc489481 ("HID: hid-appletb-kbd: add support for automatic brightness control while using the touchbar")
    Cc: [email protected]
    Signed-off-by: Qasim Ijaz <[email protected]>
    Reviewed-by: Aditya Garg <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

HID: Intel-thc-hid: Intel-quicki2c: Enhance QuickI2C reset flow [+ + +]
Author: Even Xu <[email protected]>
Date:   Wed May 14 14:26:38 2025 +0800

    HID: Intel-thc-hid: Intel-quicki2c: Enhance QuickI2C reset flow
    
    [ Upstream commit 73f3a7415d93cf418c7625d03bce72da84344406 ]
    
    During customer board enabling, it was found: some touch devices
    prepared reset response, but either forgot sending interrupt or
    THC missed reset interrupt because of timing issue. THC QuickI2C
    driver depends on interrupt to read reset response, in this case,
    it will cause driver waiting timeout.
    
    This patch enhances the flow by adding manually reset response
    reading after waiting for reset interrupt timeout.
    
    Signed-off-by: Even Xu <[email protected]>
    Tested-by: Chong Han <[email protected]>
    Fixes: 66b59bfce6d9 ("HID: intel-thc-hid: intel-quicki2c: Complete THC QuickI2C driver")
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

HID: lenovo: Restrict F7/9/11 mode to compact keyboards only [+ + +]
Author: Iusico Maxim <[email protected]>
Date:   Thu Jun 5 19:55:50 2025 +0200

    HID: lenovo: Restrict F7/9/11 mode to compact keyboards only
    
    commit 9327e3ee5b077c4ab4495a09b67624f670ed88b6 upstream.
    
    Commit 2f2bd7cbd1d1 ("hid: lenovo: Resend all settings on reset_resume
    for compact keyboards") introduced a regression for ThinkPad TrackPoint
    Keyboard II by removing the conditional check for enabling F7/9/11 mode
    needed for compact keyboards only. As a result, the non-compact
    keyboards can no longer toggle Fn-lock via Fn+Esc, although it can be
    controlled via sysfs knob that directly sends raw commands.
    
    This patch restores the previous conditional check without any
    additions.
    
    Cc: [email protected]
    Fixes: 2f2bd7cbd1d1 ("hid: lenovo: Resend all settings on reset_resume for compact keyboards")
    Signed-off-by: Iusico Maxim <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

HID: wacom: fix crash in wacom_aes_battery_handler() [+ + +]
Author: Thomas Zeitlhofer <[email protected]>
Date:   Mon May 19 10:54:46 2025 +0200

    HID: wacom: fix crash in wacom_aes_battery_handler()
    
    [ Upstream commit f3054152c12e2eed1e72704aff47b0ea58229584 ]
    
    Commit fd2a9b29dc9c ("HID: wacom: Remove AES power_supply after extended
    inactivity") introduced wacom_aes_battery_handler() which is scheduled
    as a delayed work (aes_battery_work).
    
    In wacom_remove(), aes_battery_work is not canceled. Consequently, if
    the device is removed while aes_battery_work is still pending, then hard
    crashes or "Oops: general protection fault..." are experienced when
    wacom_aes_battery_handler() is finally called. E.g., this happens with
    built-in USB devices after resume from hibernate when aes_battery_work
    was still pending at the time of hibernation.
    
    So, take care to cancel aes_battery_work in wacom_remove().
    
    Fixes: fd2a9b29dc9c ("HID: wacom: Remove AES power_supply after extended inactivity")
    Signed-off-by: Thomas Zeitlhofer <[email protected]>
    Acked-by: Ping Cheng <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

HID: wacom: fix kobject reference count leak [+ + +]
Author: Qasim Ijaz <[email protected]>
Date:   Fri Jun 6 19:49:59 2025 +0100

    HID: wacom: fix kobject reference count leak
    
    commit 85a720f4337f0ddf1603c8b75a8f1ffbbe022ef9 upstream.
    
    When sysfs_create_files() fails in wacom_initialize_remotes() the error
    is returned and the cleanup action will not have been registered yet.
    
    As a result the kobject???s refcount is never dropped, so the
    kobject can never be freed leading to a reference leak.
    
    Fix this by calling kobject_put() before returning.
    
    Fixes: 83e6b40e2de6 ("HID: wacom: EKR: have the wacom resources dynamically allocated")
    Acked-by: Ping Cheng <[email protected]>
    Cc: [email protected]
    Signed-off-by: Qasim Ijaz <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

HID: wacom: fix memory leak on kobject creation failure [+ + +]
Author: Qasim Ijaz <[email protected]>
Date:   Fri Jun 6 19:49:57 2025 +0100

    HID: wacom: fix memory leak on kobject creation failure
    
    commit 5ae416c5b1e2e816aee7b3fc8347adf70afabb4c upstream.
    
    During wacom_initialize_remotes() a fifo buffer is allocated
    with kfifo_alloc() and later a cleanup action is registered
    during devm_add_action_or_reset() to clean it up.
    
    However if the code fails to create a kobject and register it
    with sysfs the code simply returns -ENOMEM before the cleanup
    action is registered leading to a memory leak.
    
    Fix this by ensuring the fifo is freed when the kobject creation
    and registration process fails.
    
    Fixes: 83e6b40e2de6 ("HID: wacom: EKR: have the wacom resources dynamically allocated")
    Reviewed-by: Ping Cheng <[email protected]>
    Cc: [email protected]
    Signed-off-by: Qasim Ijaz <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

HID: wacom: fix memory leak on sysfs attribute creation failure [+ + +]
Author: Qasim Ijaz <[email protected]>
Date:   Fri Jun 6 19:49:58 2025 +0100

    HID: wacom: fix memory leak on sysfs attribute creation failure
    
    commit 1a19ae437ca5d5c7d9ec2678946fb339b1c706bf upstream.
    
    When sysfs_create_files() fails during wacom_initialize_remotes() the
    fifo buffer is not freed leading to a memory leak.
    
    Fix this by calling kfifo_free() before returning.
    
    Fixes: 83e6b40e2de6 ("HID: wacom: EKR: have the wacom resources dynamically allocated")
    Reviewed-by: Ping Cheng <[email protected]>
    Cc: [email protected]
    Signed-off-by: Qasim Ijaz <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
hwmon: (isl28022) Fix current reading calculation [+ + +]
Author: Yikai Tsai <[email protected]>
Date:   Mon May 19 16:40:51 2025 +0800

    hwmon: (isl28022) Fix current reading calculation
    
    [ Upstream commit b2446a16dbf2347a07af0cf994ca36576d94df77 ]
    
    According to the ISL28022 datasheet, bit15 of the current register is
    representing -32768. Fix the calculation to properly handle this bit,
    ensuring correct measurements for negative values.
    
    Signed-off-by: Yikai Tsai <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

hwmon: (pmbus/max34440) Fix support for max34451 [+ + +]
Author: Alexis Czezar Torreno <[email protected]>
Date:   Mon Apr 7 11:47:24 2025 +0800

    hwmon: (pmbus/max34440) Fix support for max34451
    
    [ Upstream commit 19932f844f3f51646f762f3eac4744ec3a405064 ]
    
    The max344** family has an issue with some PMBUS address being switched.
    This includes max34451 however version MAX34451-NA6 and later has this
    issue fixed and this commit supports that update.
    
    Signed-off-by: Alexis Czezar Torreno <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
i2c: imx: fix emulated smbus block read [+ + +]
Author: Lukasz Kucharczyk <[email protected]>
Date:   Tue May 20 14:22:52 2025 +0200

    i2c: imx: fix emulated smbus block read
    
    commit a5d0b9e32745277644cda8d7d334e7080bd339bf upstream.
    
    Acknowledge the byte count submitted by the target.
    When I2C_SMBUS_BLOCK_DATA read operation is executed by
    i2c_smbus_xfer_emulated(), the length of the second (read) message is set
    to 1. Length of the block is supposed to be obtained from the target by the
    underlying bus driver.
    The i2c_imx_isr_read() function should emit the acknowledge on i2c bus
    after reading the first byte (i.e., byte count) while processing such
    message (as defined in Section 6.5.7 of System Management Bus
    Specification [1]). Without this acknowledge, the target does not submit
    subsequent bytes and the controller only reads 0xff's.
    
    In addition, store the length of block data obtained from the target in
    the buffer provided by i2c_smbus_xfer_emulated() - otherwise the first
    byte of actual data is erroneously interpreted as length of the data
    block.
    
    [1] https://smbus.org/specs/SMBus_3_3_20240512.pdf
    
    Fixes: 5f5c2d4579ca ("i2c: imx: prevent rescheduling in non dma mode")
    Signed-off-by: Lukasz Kucharczyk <[email protected]>
    Cc: <[email protected]> # v6.13+
    Acked-by: Oleksij Rempel <[email protected]>
    Reviewed-by: Stefan Eichenberger <[email protected]>
    Reviewed-by: Carlos Song <[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: omap: Fix an error handling path in omap_i2c_probe() [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Sat Jun 14 16:59:26 2025 +0200

    i2c: omap: Fix an error handling path in omap_i2c_probe()
    
    commit 666c23af755dccca8c25b5d5200ca28153c69a05 upstream.
    
    If an error occurs after calling mux_state_select(), mux_state_deselect()
    should be called as already done in the remove function.
    
    Fixes: b6ef830c60b6 ("i2c: omap: Add support for setting mux")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Cc: <[email protected]> # v6.15+
    Signed-off-by: Andi Shyti <[email protected]>
    Link: https://lore.kernel.org/r/998542981b6d2435c057dd8b9fe71743927babab.1749913149.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

i2c: robotfuzz-osif: disable zero-length read messages [+ + +]
Author: Wolfram Sang <[email protected]>
Date:   Thu May 22 08:42:35 2025 +0200

    i2c: robotfuzz-osif: disable zero-length read messages
    
    commit 56ad91c1aa9c18064348edf69308080b03c9dc48 upstream.
    
    This driver passes the length of an i2c_msg directly to
    usb_control_msg(). If the message is now a read and of length 0, it
    violates the USB protocol and a warning will be printed. Enable the
    I2C_AQ_NO_ZERO_LEN_READ quirk for this adapter thus forbidding 0-length
    read messages altogether.
    
    Fixes: 83e53a8f120f ("i2c: Add bus driver for for OSIF USB i2c device.")
    Signed-off-by: Wolfram Sang <[email protected]>
    Cc: <[email protected]> # v3.14+
    Signed-off-by: Andi Shyti <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

i2c: tiny-usb: disable zero-length read messages [+ + +]
Author: Wolfram Sang <[email protected]>
Date:   Thu May 22 08:43:49 2025 +0200

    i2c: tiny-usb: disable zero-length read messages
    
    commit cbdb25ccf7566eee0c2b945e35cb98baf9ed0aa6 upstream.
    
    This driver passes the length of an i2c_msg directly to
    usb_control_msg(). If the message is now a read and of length 0, it
    violates the USB protocol and a warning will be printed. Enable the
    I2C_AQ_NO_ZERO_LEN_READ quirk for this adapter thus forbidding 0-length
    read messages altogether.
    
    Fixes: e8c76eed2ecd ("i2c: New i2c-tiny-usb bus driver")
    Signed-off-by: Wolfram Sang <[email protected]>
    Cc: <[email protected]> # v2.6.22+
    Signed-off-by: Andi Shyti <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
iio: adc: ad7606_spi: check error in ad7606B_sw_mode_config() [+ + +]
Author: David Lechner <[email protected]>
Date:   Tue Mar 18 17:52:10 2025 -0500

    iio: adc: ad7606_spi: check error in ad7606B_sw_mode_config()
    
    [ Upstream commit 4d71bf6021818a039a534c5954acefdfc4d6962c ]
    
    Add missing error check in ad7606B_sw_mode_config().
    
    Reviewed-by: Nuno Sá <[email protected]>
    Signed-off-by: David Lechner <[email protected]>
    Link: https://patch.msgid.link/20250318-iio-adc-ad7606-improvements-v2-2-4b605427774c@baylibre.com
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

iio: adc: ad_sigma_delta: Fix use of uninitialized status_pos [+ + +]
Author: Purva Yeshi <[email protected]>
Date:   Thu Apr 10 22:34:08 2025 +0530

    iio: adc: ad_sigma_delta: Fix use of uninitialized status_pos
    
    [ Upstream commit e5cdb098a3cb165d52282ffc3a6448642953ea13 ]
    
    Fix Smatch-detected issue:
    drivers/iio/adc/ad_sigma_delta.c:604 ad_sd_trigger_handler() error:
    uninitialized symbol 'status_pos'.
    
    The variable `status_pos` was only initialized in specific switch cases
    (1, 2, 3, 4), which could leave it uninitialized if `reg_size` had an
    unexpected value.
    
    Fix by adding a default case to the switch block to catch unexpected
    values of `reg_size`. Use `dev_err_ratelimited()` for error logging and
    `goto irq_handled` instead of returning early.
    
    Signed-off-by: Purva Yeshi <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

iio: dac: adi-axi-dac: add cntrl chan check [+ + +]
Author: Angelo Dureghello <[email protected]>
Date:   Wed Apr 9 20:36:28 2025 +0200

    iio: dac: adi-axi-dac: add cntrl chan check
    
    [ Upstream commit 029035636de37395124a602c830152ef39a35fab ]
    
    Add validity check on CNTRL_X channels (valid as 0 to 15).
    
    Reviewed-by: Nuno Sá <[email protected]>
    Signed-off-by: Angelo Dureghello <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

iio: hid-sensor-prox: Add support for 16-bit report size [+ + +]
Author: Zhang Lixu <[email protected]>
Date:   Mon Mar 17 09:36:34 2025 +0800

    iio: hid-sensor-prox: Add support for 16-bit report size
    
    [ Upstream commit ad02ca57e44e9936fca5095840fad9d4b47c5559 ]
    
    On Intel platforms, the HID_USAGE_SENSOR_HUMAN_PROXIMITY report size is 16
    bits. This patch adds support for handling 16-bit report sizes for the
    HID_USAGE_SENSOR_HUMAN_PROXIMITY usage in the HID sensor proximity driver.
    
    Previously, the driver only supported 8-bit and 32-bit report sizes. With
    this change, the driver can now correctly process 16-bit proximity data,
    ensuring accurate human presence detection on platforms where this report
    size is used.
    
    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]>
    Signed-off-by: Sasha Levin <[email protected]>

iio: light: al3000a: Fix an error handling path in al3000a_probe() [+ + +]
Author: David Heidelberg <[email protected]>
Date:   Wed Apr 2 21:33:25 2025 +0200

    iio: light: al3000a: Fix an error handling path in al3000a_probe()
    
    [ Upstream commit c0461f8e842495041c18b2c67647501d55c17441 ]
    
    If regmap_write() fails in al3000a_init(), al3000a_set_pwr_off is
    not called.
    
    In order to avoid such a situation, move the devm_add_action_or_reset()
    which calls al3000a_set_pwr_off right after a successful
    al3000a_set_pwr_on.
    
    Signed-off-by: David Heidelberg <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

iio: pressure: zpa2326: Use aligned_s64 for the timestamp [+ + +]
Author: Jonathan Cameron <[email protected]>
Date:   Sun Apr 13 11:34:41 2025 +0100

    iio: pressure: zpa2326: Use aligned_s64 for the timestamp
    
    [ Upstream commit 886a446b76afddfad307488e95e87f23a08ffd51 ]
    
    On x86_32 s64 fields are only 32-bit aligned.  Hence force the alignment of
    the field and padding in the structure by using aligned_s64 instead.
    
    Reviewed-by: David Lechner <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
io_uring/kbuf: flag partial buffer mappings [+ + +]
Author: Jens Axboe <[email protected]>
Date:   Thu Jun 26 12:17:48 2025 -0600

    io_uring/kbuf: flag partial buffer mappings
    
    Commit 178b8ff66ff827c41b4fa105e9aabb99a0b5c537 upstream.
    
    A previous commit aborted mapping more for a non-incremental ring for
    bundle peeking, but depending on where in the process this peeking
    happened, it would not necessarily prevent a retry by the user. That can
    create gaps in the received/read data.
    
    Add struct buf_sel_arg->partial_map, which can pass this information
    back. The networking side can then map that to internal state and use it
    to gate retry as well.
    
    Since this necessitates a new flag, change io_sr_msg->retry to a
    retry_flags member, and store both the retry and partial map condition
    in there.
    
    Cc: [email protected]
    Fixes: 26ec15e4b0c1 ("io_uring/kbuf: don't truncate end buffer for multiple buffer peeks")
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
io_uring/net: mark iov as dynamically allocated even for single segments [+ + +]
Author: Jens Axboe <[email protected]>
Date:   Wed Jun 25 10:17:06 2025 -0600

    io_uring/net: mark iov as dynamically allocated even for single segments
    
    [ Upstream commit 9a709b7e98e6fa51600b5f2d24c5068efa6d39de ]
    
    A bigger array of vecs could've been allocated, but
    io_ring_buffers_peek() still decided to cap the mapped range depending
    on how much data was available. Hence don't rely on the segment count
    to know if the request should be marked as needing cleanup, always
    check upfront if the iov array is different than the fast_iov array.
    
    Fixes: 26ec15e4b0c1 ("io_uring/kbuf: don't truncate end buffer for multiple buffer peeks")
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
io_uring/rsrc: don't rely on user vaddr alignment [+ + +]
Author: Pavel Begunkov <[email protected]>
Date:   Tue Jun 24 14:40:34 2025 +0100

    io_uring/rsrc: don't rely on user vaddr alignment
    
    commit 3a3c6d61577dbb23c09df3e21f6f9eda1ecd634b upstream.
    
    There is no guaranteed alignment for user pointers, however the
    calculation of an offset of the first page into a folio after coalescing
    uses some weird bit mask logic, get rid of it.
    
    Cc: [email protected]
    Reported-by: David Hildenbrand <[email protected]>
    Fixes: a8edbb424b139 ("io_uring/rsrc: enable multi-hugepage buffer coalescing")
    Signed-off-by: Pavel Begunkov <[email protected]>
    Link: https://lore.kernel.org/io-uring/e387b4c78b33f231105a601d84eefd8301f57954.1750771718.git.asml.silence@gmail.com/
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

io_uring/rsrc: fix folio unpinning [+ + +]
Author: Pavel Begunkov <[email protected]>
Date:   Tue Jun 24 14:40:33 2025 +0100

    io_uring/rsrc: fix folio unpinning
    
    commit 5afb4bf9fc62d828647647ec31745083637132e4 upstream.
    
    syzbot complains about an unmapping failure:
    
    [  108.070381][   T14] kernel BUG at mm/gup.c:71!
    [  108.070502][   T14] Internal error: Oops - BUG: 00000000f2000800 [#1]  SMP
    [  108.123672][   T14] Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20250221-8.fc42 02/21/2025
    [  108.127458][   T14] Workqueue: iou_exit io_ring_exit_work
    [  108.174205][   T14] Call trace:
    [  108.175649][   T14]  sanity_check_pinned_pages+0x7cc/0x7d0 (P)
    [  108.178138][   T14]  unpin_user_page+0x80/0x10c
    [  108.180189][   T14]  io_release_ubuf+0x84/0xf8
    [  108.182196][   T14]  io_free_rsrc_node+0x250/0x57c
    [  108.184345][   T14]  io_rsrc_data_free+0x148/0x298
    [  108.186493][   T14]  io_sqe_buffers_unregister+0x84/0xa0
    [  108.188991][   T14]  io_ring_ctx_free+0x48/0x480
    [  108.191057][   T14]  io_ring_exit_work+0x764/0x7d8
    [  108.193207][   T14]  process_one_work+0x7e8/0x155c
    [  108.195431][   T14]  worker_thread+0x958/0xed8
    [  108.197561][   T14]  kthread+0x5fc/0x75c
    [  108.199362][   T14]  ret_from_fork+0x10/0x20
    
    We can pin a tail page of a folio, but then io_uring will try to unpin
    the head page of the folio. While it should be fine in terms of keeping
    the page actually alive, mm folks say it's wrong and triggers a debug
    warning. Use unpin_user_folio() instead of unpin_user_page*.
    
    Cc: [email protected]
    Debugged-by: David Hildenbrand <[email protected]>
    Reported-by: [email protected]
    Closes: https://lkml.kernel.org/r/[email protected]
    Fixes: a8edbb424b139 ("io_uring/rsrc: enable multi-hugepage buffer coalescing")
    Signed-off-by: Pavel Begunkov <[email protected]>
    Link: https://lore.kernel.org/io-uring/a28b0f87339ac2acf14a645dad1e95bbcbf18acd.1750771718.git.asml.silence@gmail.com/
    [axboe: adapt to current tree, massage commit message]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
io_uring/zcrx: fix area release on registration failure [+ + +]
Author: Pavel Begunkov <[email protected]>
Date:   Tue May 27 18:07:33 2025 +0100

    io_uring/zcrx: fix area release on registration failure
    
    [ Upstream commit 0ec33c81d9c7342f03864101ddb2e717a0cce03e ]
    
    On area registration failure there might be no ifq set and it's not safe
    to access area->ifq in the release path without checking it first.
    
    Cc: [email protected]
    Fixes: f12ecf5e1c5ec ("io_uring/zcrx: fix late dma unmap for a dead dev")
    Signed-off-by: Pavel Begunkov <[email protected]>
    Link: https://lore.kernel.org/r/bc02878678a5fec28bc77d33355cdba735418484.1748365640.git.asml.silence@gmail.com
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

io_uring/zcrx: improve area validation [+ + +]
Author: Pavel Begunkov <[email protected]>
Date:   Thu May 1 13:17:14 2025 +0100

    io_uring/zcrx: improve area validation
    
    [ Upstream commit d760d3f59f0d8d0df2895db30d36cf23106d6b05 ]
    
    dmabuf backed area will be taking an offset instead of addresses, and
    io_buffer_validate() is not flexible enough to facilitate it. It also
    takes an iovec, which may truncate the u64 length zcrx takes. Add a new
    helper function for validation.
    
    Signed-off-by: Pavel Begunkov <[email protected]>
    Link: https://lore.kernel.org/r/0b3b735391a0a8f8971bf0121c19765131fddd3b.1746097431.git.asml.silence@gmail.com
    Signed-off-by: Jens Axboe <[email protected]>
    Stable-dep-of: 0ec33c81d9c7 ("io_uring/zcrx: fix area release on registration failure")
    Signed-off-by: Sasha Levin <[email protected]>

io_uring/zcrx: move io_zcrx_iov_page [+ + +]
Author: Pavel Begunkov <[email protected]>
Date:   Sun Apr 20 10:31:16 2025 +0100

    io_uring/zcrx: move io_zcrx_iov_page
    
    [ Upstream commit a79154ae5df9e21dbacb1eb77fad984fd4c45cca ]
    
    We'll need io_zcrx_iov_page at the top to keep offset calculations
    closer together, move it there.
    
    Reviewed-by: David Wei <[email protected]>
    Signed-off-by: Pavel Begunkov <[email protected]>
    Link: https://lore.kernel.org/r/575617033a8b84a5985c7eb760b7121efdbe7e56.1745141261.git.asml.silence@gmail.com
    Signed-off-by: Jens Axboe <[email protected]>
    Stable-dep-of: 0ec33c81d9c7 ("io_uring/zcrx: fix area release on registration failure")
    Signed-off-by: Sasha Levin <[email protected]>

io_uring/zcrx: split out memory holders from area [+ + +]
Author: Pavel Begunkov <[email protected]>
Date:   Thu May 1 13:17:16 2025 +0100

    io_uring/zcrx: split out memory holders from area
    
    [ Upstream commit 782dfa329ac9d1b5ca7b6df56a7696bac58cb829 ]
    
    In the data path users of struct io_zcrx_area don't need to know what
    kind of memory it's backed by. Only keep there generic bits in there and
    and split out memory type dependent fields into a new structure. It also
    logically separates the step that actually imports the memory, e.g.
    pinning user pages, from the generic area initialisation.
    
    Signed-off-by: Pavel Begunkov <[email protected]>
    Link: https://lore.kernel.org/r/b60fc09c76921bf69e77eb17e07eb4decedb3bf4.1746097431.git.asml.silence@gmail.com
    Signed-off-by: Jens Axboe <[email protected]>
    Stable-dep-of: 0ec33c81d9c7 ("io_uring/zcrx: fix area release on registration failure")
    Signed-off-by: Sasha Levin <[email protected]>

 
io_uring: don't assume uaddr alignment in io_vec_fill_bvec [+ + +]
Author: Pavel Begunkov <[email protected]>
Date:   Tue Jun 24 14:40:35 2025 +0100

    io_uring: don't assume uaddr alignment in io_vec_fill_bvec
    
    commit e1d7727b73a1f78035316ac35ee184d477059f0b upstream.
    
    There is no guaranteed alignment for user pointers. Don't use mask
    trickery and adjust the offset by bv_offset.
    
    Cc: [email protected]
    Reported-by: David Hildenbrand <[email protected]>
    Fixes: 9ef4cbbcb4ac3 ("io_uring: add infra for importing vectored reg buffers")
    Signed-off-by: Pavel Begunkov <[email protected]>
    Link: https://lore.kernel.org/io-uring/19530391f5c361a026ac9b401ff8e123bde55d98.1750771718.git.asml.silence@gmail.com/
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

io_uring: gate REQ_F_ISREG on !S_ANON_INODE as well [+ + +]
Author: Jens Axboe <[email protected]>
Date:   Sun Jun 29 16:48:28 2025 -0600

    io_uring: gate REQ_F_ISREG on !S_ANON_INODE as well
    
    commit 6f11adcc6f36ffd8f33dbdf5f5ce073368975bc3 upstream.
    
    io_uring marks a request as dealing with a regular file on S_ISREG. This
    drives things like retries on short reads or writes, which is generally
    not expected on a regular file (or bdev). Applications tend to not
    expect that, so io_uring tries hard to ensure it doesn't deliver short
    IO on regular files.
    
    However, a recent commit added S_IFREG to anonymous inodes. When
    io_uring is used to read from various things that are backed by anon
    inodes, like eventfd, timerfd, etc, then it'll now all of a sudden wait
    for more data when rather than deliver what was read or written in a
    single operation. This breaks applications that issue reads on anon
    inodes, if they ask for more data than a single read delivers.
    
    Add a check for !S_ANON_INODE as well before setting REQ_F_ISREG to
    prevent that.
    
    Cc: Christian Brauner <[email protected]>
    Cc: [email protected]
    Link: https://github.com/ghostty-org/ghostty/discussions/7720
    Fixes: cfd86ef7e8e7 ("anon_inode: use a proper mode internally")
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ksmbd: allow a filename to contain special characters on SMB3.1.1 posix extension [+ + +]
Author: Namjae Jeon <[email protected]>
Date:   Tue May 27 11:23:01 2025 +0900

    ksmbd: allow a filename to contain special characters on SMB3.1.1 posix extension
    
    [ Upstream commit dc3e0f17f74558e8a2fce00608855f050de10230 ]
    
    If client send SMB2_CREATE_POSIX_CONTEXT to ksmbd, Allow a filename
    to contain special characters.
    
    Reported-by: Philipp Kerling <[email protected]>
    Signed-off-by: Namjae Jeon <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ksmbd: provide zero as a unique ID to the Mac client [+ + +]
Author: Namjae Jeon <[email protected]>
Date:   Wed May 21 09:02:29 2025 +0900

    ksmbd: provide zero as a unique ID to the Mac client
    
    [ Upstream commit 571781eb7ffefa65b0e922c8031e42b4411a40d4 ]
    
    The Mac SMB client code seems to expect the on-disk file identifier
    to have the semantics of HFS+ Catalog Node Identifier (CNID).
    ksmbd provides the inode number as a unique ID to the client,
    but in the case of subvolumes of btrfs, there are cases where different
    files have the same inode number, so the mac smb client treats it
    as an error. There is a report that a similar problem occurs
    when the share is ZFS.
    Returning UniqueId of zero will make the Mac client to stop using and
    trusting the file id returned from the server.
    
    Reported-by: Justin Turner Arthur <[email protected]>
    Signed-off-by: Namjae Jeon <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
leds: multicolor: Fix intensity setting while SW blinking [+ + +]
Author: Sven Schwermer <[email protected]>
Date:   Fri Apr 4 20:40:36 2025 +0200

    leds: multicolor: Fix intensity setting while SW blinking
    
    [ Upstream commit e35ca991a777ef513040cbb36bc8245a031a2633 ]
    
    When writing to the multi_intensity file, don't unconditionally call
    led_set_brightness. By only doing this if blinking is inactive we
    prevent blinking from stopping if the blinking is in its off phase while
    the file is written.
    
    Instead, if blinking is active, the changed intensity values are applied
    upon the next blink. This is consistent with changing the brightness on
    monochrome LEDs with active blinking.
    
    Suggested-by: Jacek Anaszewski <[email protected]>
    Acked-by: Jacek Anaszewski <[email protected]>
    Acked-by: Pavel Machek <[email protected]>
    Reviewed-by: Tobias Deiminger <[email protected]>
    Tested-by: Sven Schuchmann <[email protected]>
    Signed-off-by: Sven Schwermer <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
lib/group_cpus: fix NULL pointer dereference from group_cpus_evenly() [+ + +]
Author: Yu Kuai <[email protected]>
Date:   Thu Jun 19 21:26:55 2025 +0800

    lib/group_cpus: fix NULL pointer dereference from group_cpus_evenly()
    
    commit df831e97739405ecbaddb85516bc7d4d1c933d6b upstream.
    
    While testing null_blk with configfs, echo 0 > poll_queues will trigger
    following panic:
    
    BUG: kernel NULL pointer dereference, address: 0000000000000010
    Oops: Oops: 0000 [#1] SMP NOPTI
    CPU: 27 UID: 0 PID: 920 Comm: bash Not tainted 6.15.0-02023-gadbdb95c8696-dirty #1238 PREEMPT(undef)
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014
    RIP: 0010:__bitmap_or+0x48/0x70
    Call Trace:
     <TASK>
     __group_cpus_evenly+0x822/0x8c0
     group_cpus_evenly+0x2d9/0x490
     blk_mq_map_queues+0x1e/0x110
     null_map_queues+0xc9/0x170 [null_blk]
     blk_mq_update_queue_map+0xdb/0x160
     blk_mq_update_nr_hw_queues+0x22b/0x560
     nullb_update_nr_hw_queues+0x71/0xf0 [null_blk]
     nullb_device_poll_queues_store+0xa4/0x130 [null_blk]
     configfs_write_iter+0x109/0x1d0
     vfs_write+0x26e/0x6f0
     ksys_write+0x79/0x180
     __x64_sys_write+0x1d/0x30
     x64_sys_call+0x45c4/0x45f0
     do_syscall_64+0xa5/0x240
     entry_SYSCALL_64_after_hwframe+0x76/0x7e
    
    Root cause is that numgrps is set to 0, and ZERO_SIZE_PTR is returned from
    kcalloc(), and later ZERO_SIZE_PTR will be deferenced.
    
    Fix the problem by checking numgrps first in group_cpus_evenly(), and
    return NULL directly if numgrps is zero.
    
    [[email protected]: also fix the non-SMP version]
      Link: https://lkml.kernel.org/r/[email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 6a6dcae8f486 ("blk-mq: Build default queue map via group_cpus_evenly()")
    Signed-off-by: Yu Kuai <[email protected]>
    Reviewed-by: Ming Lei <[email protected]>
    Reviewed-by: Jens Axboe <[email protected]>
    Cc: ErKun Yang <[email protected]>
    Cc: John Garry <[email protected]>
    Cc: Thomas Gleinxer <[email protected]>
    Cc: "zhangyi (F)" <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
libbpf: Fix null pointer dereference in btf_dump__free on allocation failure [+ + +]
Author: Yuan Chen <[email protected]>
Date:   Wed Jun 18 09:19:33 2025 +0800

    libbpf: Fix null pointer dereference in btf_dump__free on allocation failure
    
    [ Upstream commit aa485e8789d56a4573f7c8d000a182b749eaa64d ]
    
    When btf_dump__new() fails to allocate memory for the internal hashmap
    (btf_dump->type_names), it returns an error code. However, the cleanup
    function btf_dump__free() does not check if btf_dump->type_names is NULL
    before attempting to free it. This leads to a null pointer dereference
    when btf_dump__free() is called on a btf_dump object.
    
    Fixes: 351131b51c7a ("libbpf: add btf_dump API for BTF-to-C conversion")
    Signed-off-by: Yuan Chen <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

libbpf: Fix possible use-after-free for externs [+ + +]
Author: Adin Scannell <[email protected]>
Date:   Tue Jun 24 22:02:15 2025 -0700

    libbpf: Fix possible use-after-free for externs
    
    [ Upstream commit fa6f092cc0a02d0fcee37e9e8172eda372a03d33 ]
    
    The `name` field in `obj->externs` points into the BTF data at initial
    open time. However, some functions may invalidate this after opening and
    before loading (e.g. `bpf_map__set_value_size`), which results in
    pointers into freed memory and undefined behavior.
    
    The simplest solution is to simply `strdup` these strings, similar to
    the `essent_name`, and free them at the same time.
    
    In order to test this path, the `global_map_resize` BPF selftest is
    modified slightly to ensure the presence of an extern, which causes this
    test to fail prior to the fix. Given there isn't an obvious API or error
    to test against, I opted to add this to the existing test as an aspect
    of the resizing feature rather than duplicate the test.
    
    Fixes: 9d0a23313b1a ("libbpf: Add capability for resizing datasec maps")
    Signed-off-by: Adin Scannell <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
Linux: Linux 6.15.5 [+ + +]
Author: Greg Kroah-Hartman <[email protected]>
Date:   Sun Jul 6 11:04:26 2025 +0200

    Linux 6.15.5
    
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Ronald Warsow <[email protected]>
    Tested-by: Florian Fainelli <[email protected]>
    Tested-by: Christian Heusel <[email protected]>
    Tested-by: Salvatore Bonaccorso <[email protected]>
    Tested-by: Hardik Garg <[email protected]>
    Tested-by: Shuah Khan <[email protected]>
    Tested-by: Ron Economos <[email protected]>
    Tested-by: Pascal Ernster <[email protected]>
    Tested-By: Achill Gilgenast <[email protected]>
    Tested-by: Takeshi Ogasawara <[email protected]>
    Tested-by: Luna Jernberg <[email protected]>
    Tested-by: Jon Hunter <[email protected]>
    Tested-by: Linux Kernel Functional Testing <[email protected]>
    Tested-by: Mark Brown <[email protected]>
    Tested-by: Markus Reichelt <[email protected]>
    Tested-by: Miguel Ojeda <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Ronald Warsow <[email protected]>
    Tested-by: Mark Brown <[email protected]>
    Tested-by: Markus Reichelt <[email protected]>
    Tested-by: Miguel Ojeda <[email protected]>
    Tested-by: Takeshi Ogasawara <[email protected]>
    Tested-by: Peter Schneider <[email protected]>
    Tested-by: Luna Jernberg <[email protected]>
    Tested-by: Florian Fainelli <[email protected]>
    Tested-By: Achill Gilgenast <[email protected]>
    Tested-by: Pascal Ernster <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
LoongArch: KVM: Add address alignment check for IOCSR emulation [+ + +]
Author: Bibo Mao <[email protected]>
Date:   Fri Jun 27 18:27:44 2025 +0800

    LoongArch: KVM: Add address alignment check for IOCSR emulation
    
    commit 9159c5e733cfa35ec863fa81960a3e7435f831fb upstream.
    
    IOCSR instruction supports 1/2/4/8 bytes access, the address should be
    naturally aligned with its access size. Here address alignment check is
    added in the EIOINTC kernel emulation.
    
    Cc: [email protected]
    Fixes: 3956a52bc05b ("LoongArch: KVM: Add EIOINTC read and write functions")
    Signed-off-by: Bibo Mao <[email protected]>
    Signed-off-by: Huacai Chen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

LoongArch: KVM: Avoid overflow with array index [+ + +]
Author: Bibo Mao <[email protected]>
Date:   Thu Jun 26 20:07:27 2025 +0800

    LoongArch: KVM: Avoid overflow with array index
    
    commit 080e8d2ecdfde588897aa8a87a8884061f4dbbbb upstream.
    
    The variable index is modified and reused as array index when modify
    register EIOINTC_ENABLE. There will be array index overflow problem.
    
    Cc: [email protected]
    Fixes: 3956a52bc05b ("LoongArch: KVM: Add EIOINTC read and write functions")
    Signed-off-by: Bibo Mao <[email protected]>
    Signed-off-by: Huacai Chen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

LoongArch: KVM: Check interrupt route from physical CPU [+ + +]
Author: Bibo Mao <[email protected]>
Date:   Fri Jun 27 18:27:44 2025 +0800

    LoongArch: KVM: Check interrupt route from physical CPU
    
    commit 45515c643d0abb75c2cc760a6bc6b235eadafd66 upstream.
    
    With EIOINTC interrupt controller, physical CPU ID is set for irq route.
    However the function kvm_get_vcpu() is used to get destination vCPU when
    delivering irq. With API kvm_get_vcpu(), the logical CPU ID is used.
    
    With API kvm_get_vcpu_by_cpuid(), vCPU ID can be searched from physical
    CPU ID.
    
    Cc: [email protected]
    Fixes: 3956a52bc05b ("LoongArch: KVM: Add EIOINTC read and write functions")
    Signed-off-by: Bibo Mao <[email protected]>
    Signed-off-by: Huacai Chen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

LoongArch: KVM: Check validity of "num_cpu" from user space [+ + +]
Author: Bibo Mao <[email protected]>
Date:   Fri Jun 27 18:27:44 2025 +0800

    LoongArch: KVM: Check validity of "num_cpu" from user space
    
    commit cc8d5b209e09d3b52bca1ffe00045876842d96ae upstream.
    
    The maximum supported cpu number is EIOINTC_ROUTE_MAX_VCPUS about
    irqchip EIOINTC, here add validation about cpu number to avoid array
    pointer overflow.
    
    Cc: [email protected]
    Fixes: 1ad7efa552fd ("LoongArch: KVM: Add EIOINTC user mode read and write functions")
    Signed-off-by: Bibo Mao <[email protected]>
    Signed-off-by: Huacai Chen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

LoongArch: KVM: Disable updating of "num_cpu" and "feature" [+ + +]
Author: Bibo Mao <[email protected]>
Date:   Fri Jun 27 18:27:44 2025 +0800

    LoongArch: KVM: Disable updating of "num_cpu" and "feature"
    
    commit 955853cf83657faa58572ef3f08b44f0f88885c1 upstream.
    
    Property "num_cpu" and "feature" are read-only once eiointc is created,
    which are set with KVM_DEV_LOONGARCH_EXTIOI_GRP_CTRL attr group before
    device creation.
    
    Attr group KVM_DEV_LOONGARCH_EXTIOI_GRP_SW_STATUS is to update register
    and software state for migration and reset usage, property "num_cpu" and
    "feature" can not be update again if it is created already.
    
    Here discard write operation with property "num_cpu" and "feature" in
    attr group KVM_DEV_LOONGARCH_EXTIOI_GRP_CTRL.
    
    Cc: [email protected]
    Fixes: 1ad7efa552fd ("LoongArch: KVM: Add EIOINTC user mode read and write functions")
    Signed-off-by: Bibo Mao <[email protected]>
    Signed-off-by: Huacai Chen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

LoongArch: KVM: Fix interrupt route update with EIOINTC [+ + +]
Author: Bibo Mao <[email protected]>
Date:   Fri Jun 27 18:27:44 2025 +0800

    LoongArch: KVM: Fix interrupt route update with EIOINTC
    
    commit c34bbc2c990700ba07b271fc7c8113b0bc3e4093 upstream.
    
    With function eiointc_update_sw_coremap(), there is forced assignment
    like val = *(u64 *)pvalue. Parameter pvalue may be pointer to char type
    or others, there is problem with forced assignment with u64 type.
    
    Here the detailed value is passed rather address pointer.
    
    Cc: [email protected]
    Fixes: 3956a52bc05b ("LoongArch: KVM: Add EIOINTC read and write functions")
    Signed-off-by: Bibo Mao <[email protected]>
    Signed-off-by: Huacai Chen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mailbox: Not protect module_put with spin_lock_irqsave [+ + +]
Author: Peng Fan <[email protected]>
Date:   Fri Apr 11 21:14:10 2025 +0800

    mailbox: Not protect module_put with spin_lock_irqsave
    
    [ Upstream commit dddbd233e67e792bb0a3f9694a4707e6be29b2c6 ]
    
    &chan->lock is not supposed to protect 'chan->mbox'.
    And in __mbox_bind_client, try_module_get is also not protected
    by &chan->lock. So move module_put out of the lock protected
    region.
    
    Signed-off-by: Peng Fan <[email protected]>
    Signed-off-by: Jassi Brar <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
maple_tree: fix MA_STATE_PREALLOC flag in mas_preallocate() [+ + +]
Author: Liam R. Howlett <[email protected]>
Date:   Mon Jun 16 14:45:20 2025 -0400

    maple_tree: fix MA_STATE_PREALLOC flag in mas_preallocate()
    
    commit fba46a5d83ca8decb338722fb4899026d8d9ead2 upstream.
    
    Temporarily clear the preallocation flag when explicitly requesting
    allocations.  Pre-existing allocations are already counted against the
    request through mas_node_count_gfp(), but the allocations will not happen
    if the MA_STATE_PREALLOC flag is set.  This flag is meant to avoid
    re-allocating in bulk allocation mode, and to detect issues with
    preallocation calculations.
    
    The MA_STATE_PREALLOC flag should also always be set on zero allocations
    so that detection of underflow allocations will print a WARN_ON() during
    consumption.
    
    User visible effect of this flaw is a WARN_ON() followed by a null pointer
    dereference when subsequent requests for larger number of nodes is
    ignored, such as the vma merge retry in mmap_region() caused by drivers
    altering the vma flags (which happens in v6.6, at least)
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 54a611b60590 ("Maple Tree: add new data structure")
    Signed-off-by: Liam R. Howlett <[email protected]>
    Reported-by: Zhaoyang Huang <[email protected]>
    Reported-by: Hailong Liu <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]/
    Link: https://lore.kernel.org/all/[email protected]/
    Link: https://lore.kernel.org/all/[email protected]/
    Cc: Lorenzo Stoakes <[email protected]>
    Cc: Suren Baghdasaryan <[email protected]>
    Cc: Hailong Liu <[email protected]>
    Cc: [email protected] <[email protected]>
    Cc: Steve Kang <[email protected]>
    Cc: Matthew Wilcox <[email protected]>
    Cc: Sidhartha Kumar <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
md/md-bitmap: fix dm-raid max_write_behind setting [+ + +]
Author: Yu Kuai <[email protected]>
Date:   Sat May 24 14:13:10 2025 +0800

    md/md-bitmap: fix dm-raid max_write_behind setting
    
    [ Upstream commit 2afe17794cfed5f80295b1b9facd66e6f65e5002 ]
    
    It's supposed to be COUNTER_MAX / 2, not COUNTER_MAX.
    
    Link: https://lore.kernel.org/linux-raid/[email protected]
    Signed-off-by: Yu Kuai <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Reviewed-by: Hannes Reinecke <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
media: uvcvideo: Create uvc_pm_(get|put) functions [+ + +]
Author: Ricardo Ribalda <[email protected]>
Date:   Thu Mar 27 21:05:28 2025 +0000

    media: uvcvideo: Create uvc_pm_(get|put) functions
    
    [ Upstream commit 2f101572c0a3ae4630f2a57c8033b78ee84ac5a6 ]
    
    Most of the times that we have to call uvc_status_(get|put) we need to
    call the usb_autopm_ functions.
    
    Create a new pair of functions that automate this for us. This
    simplifies the current code and future PM changes in the driver.
    
    Reviewed-by: Hans de Goede <[email protected]>
    Signed-off-by: Ricardo Ribalda <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Hans de Goede <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Stable-dep-of: a70705d3c020 ("media: uvcvideo: Rollback non processed entities on error")
    Signed-off-by: Sasha Levin <[email protected]>

media: uvcvideo: Increase/decrease the PM counter per IOCTL [+ + +]
Author: Ricardo Ribalda <[email protected]>
Date:   Thu Mar 27 21:05:29 2025 +0000

    media: uvcvideo: Increase/decrease the PM counter per IOCTL
    
    [ Upstream commit 10acb9101355484c3e4f2625003cd1b6c203cfe4 ]
    
    Now we call uvc_pm_get/put from the device open/close. This low
    level of granularity might leave the camera powered on in situations
    where it is not needed.
    
    Increase the granularity by increasing and decreasing the Power
    Management counter per ioctl. There are two special cases where the
    power management outlives the ioctl: async controls and streamon. Handle
    those cases as well.
    
    In a future patch, we will remove the uvc_pm_get/put from open/close.
    
    Reviewed-by: Hans de Goede <[email protected]>
    Signed-off-by: Ricardo Ribalda <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Hans de Goede <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Stable-dep-of: a70705d3c020 ("media: uvcvideo: Rollback non processed entities on error")
    Signed-off-by: Sasha Levin <[email protected]>

media: uvcvideo: Keep streaming state in the file handle [+ + +]
Author: Ricardo Ribalda <[email protected]>
Date:   Thu Mar 27 21:05:27 2025 +0000

    media: uvcvideo: Keep streaming state in the file handle
    
    [ Upstream commit 14f6e205e5599c2217b68c05b903ce162e7c1e27 ]
    
    Add a variable in the file handle state to figure out if a camera is in
    the streaming state or not. This variable will be used in the future for
    power management policies.
    
    Now that we are at it, make use of guards to simplify the code.
    
    Reviewed-by: Laurent Pinchart <[email protected]>
    Reviewed-by: Hans de Goede <[email protected]>
    Signed-off-by: Ricardo Ribalda <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Hans de Goede <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Stable-dep-of: a70705d3c020 ("media: uvcvideo: Rollback non processed entities on error")
    Signed-off-by: Sasha Levin <[email protected]>

media: uvcvideo: Rollback non processed entities on error [+ + +]
Author: Ricardo Ribalda <[email protected]>
Date:   Mon Feb 24 10:34:55 2025 +0000

    media: uvcvideo: Rollback non processed entities on error
    
    [ Upstream commit a70705d3c020d0d5c3ab6a5cc93e011ac35e7d48 ]
    
    If we fail to commit an entity, we need to restore the
    UVC_CTRL_DATA_BACKUP for the other uncommitted entities. Otherwise the
    control cache and the device would be out of sync.
    
    Cc: [email protected]
    Fixes: b4012002f3a3 ("[media] uvcvideo: Add support for control events")
    Reported-by: Hans de Goede <[email protected]>
    Closes: https://lore.kernel.org/linux-media/[email protected]/
    Signed-off-by: Ricardo Ribalda <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Hans de Goede <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mfd: 88pm886: Fix wakeup source leaks on device unbind [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Sun Apr 6 21:50:09 2025 +0200

    mfd: 88pm886: Fix wakeup source leaks on device unbind
    
    [ Upstream commit 6d0b2398b2638208d68ba06601f776cd5d983b75 ]
    
    Device can be unbound, so driver must also release memory for the wakeup
    source.
    
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Reviewed-by: Karel Balej <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mfd: max14577: Fix wakeup source leaks on device unbind [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Sun Apr 6 21:50:11 2025 +0200

    mfd: max14577: Fix wakeup source leaks on device unbind
    
    [ Upstream commit d905d06e64b0eb3da43af6186c132f5282197998 ]
    
    Device can be unbound, so driver must also release memory for the wakeup
    source.
    
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mfd: max77541: Fix wakeup source leaks on device unbind [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Sun Apr 6 21:50:12 2025 +0200

    mfd: max77541: Fix wakeup source leaks on device unbind
    
    [ Upstream commit 6c7115cdf6440e1e2f15e21efe92e2b757940627 ]
    
    Device can be unbound, so driver must also release memory for the wakeup
    source.
    
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mfd: max77705: Fix wakeup source leaks on device unbind [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Sun Apr 6 21:50:13 2025 +0200

    mfd: max77705: Fix wakeup source leaks on device unbind
    
    [ Upstream commit a59a56cc4fb1f7d101f7ce1f5396ceaa2e304b71 ]
    
    Device can be unbound, so driver must also release memory for the wakeup
    source.
    
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mfd: sprd-sc27xx: Fix wakeup source leaks on device unbind [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Sun Apr 6 21:50:16 2025 +0200

    mfd: sprd-sc27xx: Fix wakeup source leaks on device unbind
    
    [ Upstream commit 37ef4aa4039c42f4b15dc7e40d3e437b7f031522 ]
    
    Device can be unbound, so driver must also release memory for the wakeup
    source.
    
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Reviewed-by: Baolin Wang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
misc: tps6594-pfsm: Add NULL pointer check in tps6594_pfsm_probe() [+ + +]
Author: Chenyuan Yang <[email protected]>
Date:   Mon Mar 10 20:05:11 2025 -0500

    misc: tps6594-pfsm: Add NULL pointer check in tps6594_pfsm_probe()
    
    [ Upstream commit a99b598d836c9c6411110c70a2da134c78d96e67 ]
    
    The returned value, pfsm->miscdev.name, from devm_kasprintf()
    could be NULL.
    A pointer check is added to prevent potential NULL pointer dereference.
    This is similar to the fix in commit 3027e7b15b02
    ("ice: Fix some null pointer dereference issues in ice_ptp.c").
    
    This issue is found by our static analysis tool.
    
    Signed-off-by: Chenyuan Yang <[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]>

 
mm/damon/sysfs-schemes: free old damon_sysfs_scheme_filter->memcg_path on write [+ + +]
Author: SeongJae Park <[email protected]>
Date:   Thu Jun 19 11:36:07 2025 -0700

    mm/damon/sysfs-schemes: free old damon_sysfs_scheme_filter->memcg_path on write
    
    commit 4f489fe6afb395dbc79840efa3c05440b760d883 upstream.
    
    memcg_path_store() assigns a newly allocated memory buffer to
    filter->memcg_path, without deallocating the previously allocated and
    assigned memory buffer.  As a result, users can leak kernel memory by
    continuously writing a data to memcg_path DAMOS sysfs file.  Fix the leak
    by deallocating the previously set memory buffer.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 7ee161f18b5d ("mm/damon/sysfs-schemes: implement filter directory")
    Signed-off-by: SeongJae Park <[email protected]>
    Cc: Shuah Khan <[email protected]>
    Cc: <[email protected]>            [6.3.x]
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mm/gup: revert "mm: gup: fix infinite loop within __get_longterm_locked" [+ + +]
Author: David Hildenbrand <[email protected]>
Date:   Wed Jun 11 15:13:14 2025 +0200

    mm/gup: revert "mm: gup: fix infinite loop within __get_longterm_locked"
    
    commit 517f496e1e61bd169d585dab4dd77e7147506322 upstream.
    
    After commit 1aaf8c122918 ("mm: gup: fix infinite loop within
    __get_longterm_locked") we are able to longterm pin folios that are not
    supposed to get longterm pinned, simply because they temporarily have the
    LRU flag cleared (esp.  temporarily isolated).
    
    For example, two __get_longterm_locked() callers can race, or
    __get_longterm_locked() can race with anything else that temporarily
    isolates folios.
    
    The introducing commit mentions the use case of a driver that uses
    vm_ops->fault to insert pages allocated through cma_alloc() into the page
    tables, assuming they can later get longterm pinned.  These pages/ folios
    would never have the LRU flag set and consequently cannot get isolated.
    There is no known in-tree user making use of that so far, fortunately.
    
    To handle that in the future -- and avoid retrying forever to
    isolate/migrate them -- we will need a different mechanism for the CMA
    area *owner* to indicate that it actually already allocated the page and
    is fine with longterm pinning it.  The LRU flag is not suitable for that.
    
    Probably we can lookup the relevant CMA area and query the bitmap; we only
    have have to care about some races, probably.  If already allocated, we
    could just allow longterm pinning)
    
    Anyhow, let's fix the "must not be longterm pinned" problem first by
    reverting the original commit.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 1aaf8c122918 ("mm: gup: fix infinite loop within __get_longterm_locked")
    Signed-off-by: David Hildenbrand <[email protected]>
    Closes: https://lore.kernel.org/all/20250522092755.GA3277597@tiffany/
    Reported-by: Hyesoo Yu <[email protected]>
    Reviewed-by: John Hubbard <[email protected]>
    Cc: Jason Gunthorpe <[email protected]>
    Cc: Peter Xu <[email protected]>
    Cc: Zhaoyang Huang <[email protected]>
    Cc: Aijun Sun <[email protected]>
    Cc: Alistair Popple <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mm/shmem, swap: fix softlockup with mTHP swapin [+ + +]
Author: Kairui Song <[email protected]>
Date:   Tue Jun 10 01:17:51 2025 +0800

    mm/shmem, swap: fix softlockup with mTHP swapin
    
    commit a05dd8ae5cbb1cb45f349922cfea4f548a5e5d6f upstream.
    
    Following softlockup can be easily reproduced on my test machine with:
    
    echo always > /sys/kernel/mm/transparent_hugepage/hugepages-64kB/enabled
    swapon /dev/zram0 # zram0 is a 48G swap device
    mkdir -p /sys/fs/cgroup/memory/test
    echo 1G > /sys/fs/cgroup/test/memory.max
    echo $BASHPID > /sys/fs/cgroup/test/cgroup.procs
    while true; do
        dd if=/dev/zero of=/tmp/test.img bs=1M count=5120
        cat /tmp/test.img > /dev/null
        rm /tmp/test.img
    done
    
    Then after a while:
    watchdog: BUG: soft lockup - CPU#0 stuck for 763s! [cat:5787]
    Modules linked in: zram virtiofs
    CPU: 0 UID: 0 PID: 5787 Comm: cat Kdump: loaded Tainted: G             L      6.15.0.orig-gf3021d9246bc-dirty #118 PREEMPT(voluntary)·
    Tainted: [L]=SOFTLOCKUP
    Hardware name: Red Hat KVM/RHEL-AV, BIOS 0.0.0 02/06/2015
    RIP: 0010:mpol_shared_policy_lookup+0xd/0x70
    Code: e9 b8 b4 ff ff 31 c0 c3 cc cc cc cc 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 41 54 55 53 <48> 8b 1f 48 85 db 74 41 4c 8d 67 08 48 89 fb 48 89 f5 4c 89 e7 e8
    RSP: 0018:ffffc90002b1fc28 EFLAGS: 00000202
    RAX: 00000000001c20ca RBX: 0000000000724e1e RCX: 0000000000000001
    RDX: ffff888118e214c8 RSI: 0000000000057d42 RDI: ffff888118e21518
    RBP: 000000000002bec8 R08: 0000000000000001 R09: 0000000000000000
    R10: 0000000000000bf4 R11: 0000000000000000 R12: 0000000000000001
    R13: 00000000001c20ca R14: 00000000001c20ca R15: 0000000000000000
    FS:  00007f03f995c740(0000) GS:ffff88a07ad9a000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f03f98f1000 CR3: 0000000144626004 CR4: 0000000000770eb0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    PKRU: 55555554
    Call Trace:
     <TASK>
     shmem_alloc_folio+0x31/0xc0
     shmem_swapin_folio+0x309/0xcf0
     ? filemap_get_entry+0x117/0x1e0
     ? xas_load+0xd/0xb0
     ? filemap_get_entry+0x101/0x1e0
     shmem_get_folio_gfp+0x2ed/0x5b0
     shmem_file_read_iter+0x7f/0x2e0
     vfs_read+0x252/0x330
     ksys_read+0x68/0xf0
     do_syscall_64+0x4c/0x1c0
     entry_SYSCALL_64_after_hwframe+0x76/0x7e
    RIP: 0033:0x7f03f9a46991
    Code: 00 48 8b 15 81 14 10 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd e8 20 ad 01 00 f3 0f 1e fa 80 3d 35 97 10 00 00 74 13 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 4f c3 66 0f 1f 44 00 00 55 48 89 e5 48 83 ec
    RSP: 002b:00007fff3c52bd28 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
    RAX: ffffffffffffffda RBX: 0000000000040000 RCX: 00007f03f9a46991
    RDX: 0000000000040000 RSI: 00007f03f98ba000 RDI: 0000000000000003
    RBP: 00007fff3c52bd50 R08: 0000000000000000 R09: 00007f03f9b9a380
    R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000040000
    R13: 00007f03f98ba000 R14: 0000000000000003 R15: 0000000000000000
     </TASK>
    
    The reason is simple, readahead brought some order 0 folio in swap cache,
    and the swapin mTHP folio being allocated is in conflict with it, so
    swapcache_prepare fails and causes shmem_swap_alloc_folio to return
    -EEXIST, and shmem simply retries again and again causing this loop.
    
    Fix it by applying a similar fix for anon mTHP swapin.
    
    The performance change is very slight, time of swapin 10g zero folios
    with shmem (test for 12 times):
    Before:  2.47s
    After:   2.48s
    
    [[email protected]: add comment]
      Link: https://lkml.kernel.org/r/[email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 1dd44c0af4fa ("mm: shmem: skip swapcache for swapin of synchronous swap device")
    Signed-off-by: Kairui Song <[email protected]>
    Reviewed-by: Barry Song <[email protected]>
    Acked-by: Nhat Pham <[email protected]>
    Reviewed-by: Baolin Wang <[email protected]>
    Cc: Baoquan He <[email protected]>
    Cc: Chris Li <[email protected]>
    Cc: Hugh Dickins <[email protected]>
    Cc: Kemeng Shi <[email protected]>
    Cc: Usama Arif <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mm: userfaultfd: fix race of userfaultfd_move and swap cache [+ + +]
Author: Kairui Song <[email protected]>
Date:   Wed Jun 4 23:10:38 2025 +0800

    mm: userfaultfd: fix race of userfaultfd_move and swap cache
    
    commit 0ea148a799198518d8ebab63ddd0bb6114a103bc upstream.
    
    This commit fixes two kinds of races, they may have different results:
    
    Barry reported a BUG_ON in commit c50f8e6053b0, we may see the same
    BUG_ON if the filemap lookup returned NULL and folio is added to swap
    cache after that.
    
    If another kind of race is triggered (folio changed after lookup) we
    may see RSS counter is corrupted:
    
    [  406.893936] BUG: Bad rss-counter state mm:ffff0000c5a9ddc0
    type:MM_ANONPAGES val:-1
    [  406.894071] BUG: Bad rss-counter state mm:ffff0000c5a9ddc0
    type:MM_SHMEMPAGES val:1
    
    Because the folio is being accounted to the wrong VMA.
    
    I'm not sure if there will be any data corruption though, seems no.
    The issues above are critical already.
    
    
    On seeing a swap entry PTE, userfaultfd_move does a lockless swap cache
    lookup, and tries to move the found folio to the faulting vma.  Currently,
    it relies on checking the PTE value to ensure that the moved folio still
    belongs to the src swap entry and that no new folio has been added to the
    swap cache, which turns out to be unreliable.
    
    While working and reviewing the swap table series with Barry, following
    existing races are observed and reproduced [1]:
    
    In the example below, move_pages_pte is moving src_pte to dst_pte, where
    src_pte is a swap entry PTE holding swap entry S1, and S1 is not in the
    swap cache:
    
    CPU1                               CPU2
    userfaultfd_move
      move_pages_pte()
        entry = pte_to_swp_entry(orig_src_pte);
        // Here it got entry = S1
        ... < interrupted> ...
                                       <swapin src_pte, alloc and use folio A>
                                       // folio A is a new allocated folio
                                       // and get installed into src_pte
                                       <frees swap entry S1>
                                       // src_pte now points to folio A, S1
                                       // has swap count == 0, it can be freed
                                       // by folio_swap_swap or swap
                                       // allocator's reclaim.
                                       <try to swap out another folio B>
                                       // folio B is a folio in another VMA.
                                       <put folio B to swap cache using S1 >
                                       // S1 is freed, folio B can use it
                                       // for swap out with no problem.
                                       ...
        folio = filemap_get_folio(S1)
        // Got folio B here !!!
        ... < interrupted again> ...
                                       <swapin folio B and free S1>
                                       // Now S1 is free to be used again.
                                       <swapout src_pte & folio A using S1>
                                       // Now src_pte is a swap entry PTE
                                       // holding S1 again.
        folio_trylock(folio)
        move_swap_pte
          double_pt_lock
          is_pte_pages_stable
          // Check passed because src_pte == S1
          folio_move_anon_rmap(...)
          // Moved invalid folio B here !!!
    
    The race window is very short and requires multiple collisions of multiple
    rare events, so it's very unlikely to happen, but with a deliberately
    constructed reproducer and increased time window, it can be reproduced
    easily.
    
    This can be fixed by checking if the folio returned by filemap is the
    valid swap cache folio after acquiring the folio lock.
    
    Another similar race is possible: filemap_get_folio may return NULL, but
    folio (A) could be swapped in and then swapped out again using the same
    swap entry after the lookup.  In such a case, folio (A) may remain in the
    swap cache, so it must be moved too:
    
    CPU1                               CPU2
    userfaultfd_move
      move_pages_pte()
        entry = pte_to_swp_entry(orig_src_pte);
        // Here it got entry = S1, and S1 is not in swap cache
        folio = filemap_get_folio(S1)
        // Got NULL
        ... < interrupted again> ...
                                       <swapin folio A and free S1>
                                       <swapout folio A re-using S1>
        move_swap_pte
          double_pt_lock
          is_pte_pages_stable
          // Check passed because src_pte == S1
          folio_move_anon_rmap(...)
          // folio A is ignored !!!
    
    Fix this by checking the swap cache again after acquiring the src_pte
    lock.  And to avoid the filemap overhead, we check swap_map directly [2].
    
    The SWP_SYNCHRONOUS_IO path does make the problem more complex, but so far
    we don't need to worry about that, since folios can only be exposed to the
    swap cache in the swap out path, and this is covered in this patch by
    checking the swap cache again after acquiring the src_pte lock.
    
    Testing with a simple C program that allocates and moves several GB of
    memory did not show any observable performance change.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: adef440691ba ("userfaultfd: UFFDIO_MOVE uABI")
    Signed-off-by: Kairui Song <[email protected]>
    Closes: https://lore.kernel.org/linux-mm/CAMgjq7B1K=6OOrK2OUZ0-tqCzi+EJt+2_K97TPGoSt=9+JwP7Q@mail.gmail.com/ [1]
    Link: https://lore.kernel.org/all/CAGsJ_4yJhJBo16XhiC-nUzSheyX-V3-nFE+tAi=8Y560K8eT=A@mail.gmail.com/ [2]
    Reviewed-by: Lokesh Gidra <[email protected]>
    Acked-by: Peter Xu <[email protected]>
    Reviewed-by: Suren Baghdasaryan <[email protected]>
    Reviewed-by: Barry Song <[email protected]>
    Reviewed-by: Chris Li <[email protected]>
    Cc: Andrea Arcangeli <[email protected]>
    Cc: David Hildenbrand <[email protected]>
    Cc: Kairui Song <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
net: enetc: Correct endianness handling in _enetc_rd_reg64 [+ + +]
Author: Simon Horman <[email protected]>
Date:   Tue Jun 24 17:35:12 2025 +0100

    net: enetc: Correct endianness handling in _enetc_rd_reg64
    
    [ Upstream commit 7b515f35a911fdc31fbde6531828dcd6ae9803d3 ]
    
    enetc_hw.h provides two versions of _enetc_rd_reg64.
    One which simply calls ioread64() when available.
    And another that composes the 64-bit result from ioread32() calls.
    
    In the second case the code appears to assume that each ioread32() call
    returns a little-endian value. However both the shift and logical or
    used to compose the return value would not work correctly on big endian
    systems if this were the case. Moreover, this is inconsistent with the
    first case where the return value of ioread64() is assumed to be in host
    byte order.
    
    It appears that the correct approach is for both versions to treat the
    return value of ioread*() functions as being in host byte order. And
    this patch corrects the ioread32()-based version to do so.
    
    This is a bug but would only manifest on big endian systems
    that make use of the ioread32-based implementation of _enetc_rd_reg64.
    While all in-tree users of this driver are little endian and
    make use of the ioread64-based implementation of _enetc_rd_reg64.
    Thus, no in-tree user of this driver is affected by this bug.
    
    Flagged by Sparse.
    Compile tested only.
    
    Fixes: 16eb4c85c964 ("enetc: Add ethtool statistics")
    Closes: https://lore.kernel.org/all/AM9PR04MB850500D3FC24FE23DEFCEA158879A@AM9PR04MB8505.eurprd04.prod.outlook.com/
    Signed-off-by: Simon Horman <[email protected]>
    Reviewed-by: Wei Fang <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: libwx: fix the creation of page_pool [+ + +]
Author: Jiawen Wu <[email protected]>
Date:   Wed Jun 25 10:39:24 2025 +0800

    net: libwx: fix the creation of page_pool
    
    commit 85720e04d9af0b77f8092b12a06661a8d459d4a0 upstream.
    
    'rx_ring->size' means the count of ring descriptors multiplied by the
    size of one descriptor. When increasing the count of ring descriptors,
    it may exceed the limit of pool size.
    
    [ 864.209610] page_pool_create_percpu() gave up with errno -7
    [ 864.209613] txgbe 0000:11:00.0: Page pool creation failed: -7
    
    Fix to set the pool_size to the count of ring descriptors.
    
    Fixes: 850b971110b2 ("net: libwx: Allocate Rx and Tx resources")
    Cc: [email protected]
    Signed-off-by: Jiawen Wu <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Reviewed-by: Mina Almasry <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

net: netpoll: Initialize UDP checksum field before checksumming [+ + +]
Author: Breno Leitao <[email protected]>
Date:   Fri Jun 20 11:48:55 2025 -0700

    net: netpoll: Initialize UDP checksum field before checksumming
    
    [ Upstream commit f5990207026987a353d5a95204c4d9cb725637fd ]
    
    commit f1fce08e63fe ("netpoll: Eliminate redundant assignment") removed
    the initialization of the UDP checksum, which was wrong and broke
    netpoll IPv6 transmission due to bad checksumming.
    
    udph->check needs to be set before calling csum_ipv6_magic().
    
    Fixes: f1fce08e63fe ("netpoll: Eliminate redundant assignment")
    Signed-off-by: Breno Leitao <[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: selftests: fix TCP packet checksum [+ + +]
Author: Jakub Kicinski <[email protected]>
Date:   Tue Jun 24 11:32:58 2025 -0700

    net: selftests: fix TCP packet checksum
    
    [ Upstream commit 8d89661a36dd3bb8c9902cff36dc0c144dce3faf ]
    
    The length in the pseudo header should be the length of the L3 payload
    AKA the L4 header+payload. The selftest code builds the packet from
    the lower layers up, so all the headers are pushed already when it
    constructs L4. We need to subtract the lower layer headers from skb->len.
    
    Fixes: 3e1e58d64c3d ("net: add generic selftest support")
    Signed-off-by: Jakub Kicinski <[email protected]>
    Reviewed-by: Gerhard Engleder <[email protected]>
    Reported-by: Oleksij Rempel <[email protected]>
    Tested-by: Oleksij Rempel <[email protected]>
    Reviewed-by: Oleksij Rempel <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
netlink: specs: tc: replace underscores with dashes in names [+ + +]
Author: Jakub Kicinski <[email protected]>
Date:   Tue Jun 24 14:10:01 2025 -0700

    netlink: specs: tc: replace underscores with dashes in names
    
    [ Upstream commit eef0eaeca7fa8e358a31e89802f564451b797718 ]
    
    We're trying to add a strict regexp for the name format in the spec.
    Underscores will not be allowed, dashes should be used instead.
    This makes no difference to C (codegen, if used, replaces special
    chars in names) but it gives more uniform naming in Python.
    
    Fixes: a1bcfde83669 ("doc/netlink/specs: Add a spec for tc")
    Reviewed-by: Donald Hunter <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
NFSv4.2: fix listxattr to return selinux security label [+ + +]
Author: Olga Kornievskaia <[email protected]>
Date:   Fri Apr 25 14:09:21 2025 -0400

    NFSv4.2: fix listxattr to return selinux security label
    
    [ Upstream commit 243fea134633ba3d64aceb4c16129c59541ea2c6 ]
    
    Currently, when NFS is queried for all the labels present on the
    file via a command example "getfattr -d -m . /mnt/testfile", it
    does not return the security label. Yet when asked specifically for
    the label (getfattr -n security.selinux) it will be returned.
    Include the security label when all attributes are queried.
    
    Signed-off-by: Olga Kornievskaia <[email protected]>
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

NFSv4.2: fix setattr caching of TIME_[MODIFY|ACCESS]_SET when timestamps are delegated [+ + +]
Author: Sagi Grimberg <[email protected]>
Date:   Fri Apr 25 15:49:19 2025 +0300

    NFSv4.2: fix setattr caching of TIME_[MODIFY|ACCESS]_SET when timestamps are delegated
    
    [ Upstream commit aba41e90aadeca8d4656f90639aa5f91ce564f1c ]
    
    nfs_setattr will flush all pending writes before updating a file time
    attributes. However when the client holds delegated timestamps, it can
    update its timestamps locally as it is the authority for the file
    times attributes. The client will later set the file attributes by
    adding a setattr to the delegreturn compound updating the server time
    attributes.
    
    Fix nfs_setattr to avoid flushing pending writes when the file time
    attributes are delegated and the mtime/atime are set to a fixed
    timestamp (ATTR_[MODIFY|ACCESS]_SET. Also, when sending the setattr
    procedure over the wire, we need to clear the correct attribute bits
    from the bitmask.
    
    I was able to measure a noticable speedup when measuring untar performance.
    Test: $ time tar xzf ~/dir.tgz
    Baseline: 1m13.072s
    Patched: 0m49.038s
    
    Which is more than 30% latency improvement.
    
    Signed-off-by: Sagi Grimberg <[email protected]>
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
NFSv4: Always set NLINK even if the server doesn't support it [+ + +]
Author: Han Young <[email protected]>
Date:   Sun May 4 20:57:04 2025 +0800

    NFSv4: Always set NLINK even if the server doesn't support it
    
    [ Upstream commit 3a3065352f73381d3a1aa0ccab44aec3a5a9b365 ]
    
    fattr4_numlinks is a recommended attribute, so the client should emulate
    it even if the server doesn't support it. In decode_attr_nlink function
    in nfs4xdr.c, nlink is initialized to 1. However, this default value
    isn't set to the inode due to the check in nfs_fhget.
    
    So if the server doesn't support numlinks, inode's nlink will be zero,
    the mount will fail with error "Stale file handle". Set the nlink to 1
    if the server doesn't support it.
    
    Signed-off-by: Han Young <[email protected]>
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

NFSv4: xattr handlers should check for absent nfs filehandles [+ + +]
Author: Scott Mayhew <[email protected]>
Date:   Wed Apr 16 11:23:38 2025 -0400

    NFSv4: xattr handlers should check for absent nfs filehandles
    
    [ Upstream commit 6e9a2f8dbe93c8004c2af2c0158888628b7ca034 ]
    
    The nfs inodes for referral anchors that have not yet been followed have
    their filehandles zeroed out.
    
    Attempting to call getxattr() on one of these will cause the nfs client
    to send a GETATTR to the nfs server with the preceding PUTFH sans
    filehandle.  The server will reply NFS4ERR_NOFILEHANDLE, leading to -EIO
    being returned to the application.
    
    For example:
    
    $ strace -e trace=getxattr getfattr -n system.nfs4_acl /mnt/t/ref
    getxattr("/mnt/t/ref", "system.nfs4_acl", NULL, 0) = -1 EIO (Input/output error)
    /mnt/t/ref: system.nfs4_acl: Input/output error
    +++ exited with 1 +++
    
    Have the xattr handlers return -ENODATA instead.
    
    Signed-off-by: Scott Mayhew <[email protected]>
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nvme-tcp: fix I/O stalls on congested sockets [+ + +]
Author: Hannes Reinecke <[email protected]>
Date:   Wed May 28 08:45:34 2025 +0200

    nvme-tcp: fix I/O stalls on congested sockets
    
    [ Upstream commit f42d4796ee100fade86086d1cf98537fb4d326c8 ]
    
    When the socket is busy processing nvme_tcp_try_recv() might return
    -EAGAIN, but this doesn't automatically imply that the sending side is
    blocked, too.  So check if there are pending requests once
    nvme_tcp_try_recv() returns -EAGAIN and continue with the sending loop
    to avoid I/O stalls.
    
    Signed-off-by: Hannes Reinecke <[email protected]>
    Acked-by: Chris Leech <[email protected]>
    Reviewed-by: Sagi Grimberg <[email protected]>
    Signed-off-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

nvme-tcp: sanitize request list handling [+ + +]
Author: Hannes Reinecke <[email protected]>
Date:   Wed May 28 08:45:33 2025 +0200

    nvme-tcp: sanitize request list handling
    
    [ Upstream commit 0bf04c874fcb1ae46a863034296e4b33d8fbd66c ]
    
    Validate the request in nvme_tcp_handle_r2t() to ensure it's not part of
    any list, otherwise a malicious R2T PDU might inject a loop in request
    list processing.
    
    Signed-off-by: Hannes Reinecke <[email protected]>
    Reviewed-by: Sagi Grimberg <[email protected]>
    Signed-off-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nvme: fix atomic write size validation [+ + +]
Author: Christoph Hellwig <[email protected]>
Date:   Wed Jun 11 06:54:56 2025 +0200

    nvme: fix atomic write size validation
    
    [ Upstream commit f46d273449ba65afd53f3dd8fe0182c9df877e08 ]
    
    Don't mix the namespace and controller values, and validate the
    per-controller limit when probing the controller.  This avoid spurious
    failures for controllers with namespaces that have different namespaces
    with different logical block sizes, or report the per-namespace values
    only for some namespaces.
    
    It also fixes a missing queue_limits_cancel_update in an error path by
    removing that error path.
    
    Fixes: 8695f060a029 ("nvme: all namespaces in a subsystem must adhere to a common atomic write size")
    Reported-by: Yi Zhang <[email protected]>
    Signed-off-by: Christoph Hellwig <[email protected]>
    Reviewed-by: Luis Chamberlain <[email protected]>
    Reviewed-by: John Garry <[email protected]>
    Tested-by: Yi Zhang <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

nvme: refactor the atomic write unit detection [+ + +]
Author: Christoph Hellwig <[email protected]>
Date:   Wed Jun 11 07:09:21 2025 +0200

    nvme: refactor the atomic write unit detection
    
    [ Upstream commit b2e607fecac15e07f50269c080e2e71b5049dfa2 ]
    
    Move all the code out of nvme_update_disk_info into the helper, and
    rename the helper to have a somewhat less clumsy name.
    
    Signed-off-by: Christoph Hellwig <[email protected]>
    Reviewed-by: Luis Chamberlain <[email protected]>
    Reviewed-by: John Garry <[email protected]>
    Stable-dep-of: f46d273449ba ("nvme: fix atomic write size validation")
    Signed-off-by: Sasha Levin <[email protected]>

 
ovl: Check for NULL d_inode() in ovl_dentry_upper() [+ + +]
Author: Kees Cook <[email protected]>
Date:   Mon Apr 21 16:15:19 2025 -0700

    ovl: Check for NULL d_inode() in ovl_dentry_upper()
    
    [ Upstream commit 8a39f1c870e9d6fbac5638f3a42a6a6363829c49 ]
    
    In ovl_path_type() and ovl_is_metacopy_dentry() GCC notices that it is
    possible for OVL_E() to return NULL (which implies that d_inode(dentry)
    may be NULL). This would result in out of bounds reads via container_of(),
    seen with GCC 15's -Warray-bounds -fdiagnostics-details. For example:
    
    In file included from arch/x86/include/generated/asm/rwonce.h:1,
                     from include/linux/compiler.h:339,
                     from include/linux/export.h:5,
                     from include/linux/linkage.h:7,
                     from include/linux/fs.h:5,
                     from fs/overlayfs/util.c:7:
    In function 'ovl_upperdentry_dereference',
        inlined from 'ovl_dentry_upper' at ../fs/overlayfs/util.c:305:9,
        inlined from 'ovl_path_type' at ../fs/overlayfs/util.c:216:6:
    include/asm-generic/rwonce.h:44:26: error: array subscript 0 is outside array bounds of 'struct inode[7486503276667837]' [-Werror=array-bounds=]
       44 | #define __READ_ONCE(x)  (*(const volatile __unqual_scalar_typeof(x) *)&(x))
          |                         ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    include/asm-generic/rwonce.h:50:9: note: in expansion of macro '__READ_ONCE'
       50 |         __READ_ONCE(x);                                                 \
          |         ^~~~~~~~~~~
    fs/overlayfs/ovl_entry.h:195:16: note: in expansion of macro 'READ_ONCE'
      195 |         return READ_ONCE(oi->__upperdentry);
          |                ^~~~~~~~~
      'ovl_path_type': event 1
      185 |         return inode ? OVL_I(inode)->oe : NULL;
      'ovl_path_type': event 2
    
    Avoid this by allowing ovl_dentry_upper() to return NULL if d_inode() is
    NULL, as that means the problematic dereferencing can never be reached.
    Note that this fixes the over-eager compiler warning in an effort to
    being able to enable -Warray-bounds globally. There is no known
    behavioral bug here.
    
    Suggested-by: Amir Goldstein <[email protected]>
    Signed-off-by: Kees Cook <[email protected]>
    Signed-off-by: Miklos Szeredi <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
PCI: apple: Fix missing OF node reference in apple_pcie_setup_port [+ + +]
Author: Hector Martin <[email protected]>
Date:   Tue Apr 1 10:17:08 2025 +0100

    PCI: apple: Fix missing OF node reference in apple_pcie_setup_port
    
    [ Upstream commit 7fa9fbf39116b061f8a41cd84f1884c545f322c4 ]
    
    In the success path, we hang onto a reference to the node, so make sure
    to grab one. The caller iterator puts our borrowed reference when we
    return.
    
    Signed-off-by: Hector Martin <[email protected]>
    Signed-off-by: Alyssa Rosenzweig <[email protected]>
    Signed-off-by: Marc Zyngier <[email protected]>
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Tested-by: Janne Grunau <[email protected]>
    Reviewed-by: Rob Herring (Arm) <[email protected]>
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Acked-by: Alyssa Rosenzweig <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

PCI: dwc: Make link training more robust by setting PORT_LOGIC_LINK_WIDTH to one lane [+ + +]
Author: Wenbin Yao <[email protected]>
Date:   Tue Apr 22 18:36:23 2025 +0800

    PCI: dwc: Make link training more robust by setting PORT_LOGIC_LINK_WIDTH to one lane
    
    [ Upstream commit af3c6eacce0c464f28fe0e3d365b3860aba07931 ]
    
    As per DWC PCIe registers description 4.30a, section 1.13.43, NUM_OF_LANES
    named as PORT_LOGIC_LINK_WIDTH in PCIe DWC driver, is referred to as the
    "Predetermined Number of Lanes" in PCIe r6.0, sec 4.2.7.2.1, which explains
    the conditions required to enter Polling.Configuration:
    
      Next state is Polling.Configuration after at least 1024 TS1 Ordered Sets
      were transmitted, and all Lanes that detected a Receiver during Detect
      receive eight consecutive training sequences ...
    
      Otherwise, after a 24 ms timeout the next state is:
    
        Polling.Configuration if,
    
          (i) Any Lane, which detected a Receiver during Detect, received eight
          consecutive training sequences ... and a minimum of 1024 TS1 Ordered
          Sets are transmitted after receiving one TS1 or TS2 Ordered Set.
    
          And
    
          (ii) At least a predetermined set of Lanes that detected a Receiver
          during Detect have detected an exit from Electrical Idle at least
          once since entering Polling.Active.
    
            Note: This may prevent one or more bad Receivers or Transmitters
            from holding up a valid Link from being configured, and allow for
            additional training in Polling.Configuration. The exact set of
            predetermined Lanes is implementation specific.
    
            Note: Any Lane that receives eight consecutive TS1 or TS2 Ordered
            Sets should have detected an exit from Electrical Idle at least
            once since entering Polling.Active.
    
    In a PCIe link supporting multiple lanes, if PORT_LOGIC_LINK_WIDTH is set
    to lane width the hardware supports, all lanes that detect a receiver
    during the Detect phase must receive eight consecutive training sequences.
    Otherwise, LTSSM will not enter Polling.Configuration and link training
    will fail.
    
    Therefore, always set PORT_LOGIC_LINK_WIDTH to 1, regardless of the number
    of lanes the port actually supports, to make link up more robust. This
    setting will not affect the intended link width if all lanes are
    functional. Additionally, the link can still be established with at least
    one lane if other lanes are faulty.
    
    Co-developed-by: Qiang Yu <[email protected]>
    Signed-off-by: Qiang Yu <[email protected]>
    Signed-off-by: Wenbin Yao <[email protected]>
    [mani: subject change]
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    [bhelgaas: update PCIe spec citation, format quote]
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Tested-by: Niklas Cassel <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

PCI: imx6: Add workaround for errata ERR051624 [+ + +]
Author: Richard Zhu <[email protected]>
Date:   Wed Apr 16 16:13:11 2025 +0800

    PCI: imx6: Add workaround for errata ERR051624
    
    [ Upstream commit ce0c43e855c7f652b6351110aaaabf9b521debd7 ]
    
    ERR051624: The Controller Without Vaux Cannot Exit L23 Ready Through Beacon
    or PERST# De-assertion
    
    When the auxiliary power is not available, the controller cannot exit from
    L23 Ready with beacon or PERST# de-assertion when main power is not
    removed. So the workaround is to set SS_RW_REG_1[SYS_AUX_PWR_DET] to 1.
    
    This workaround is required irrespective of whether Vaux is supplied to the
    link partner or not.
    
    Signed-off-by: Richard Zhu <[email protected]>
    [mani: subject and description rewording]
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Reviewed-by: Frank Li <[email protected]>
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
Revert "bcache: remove heap-related macros and switch to generic min_heap" [+ + +]
Author: Kuan-Wei Chiu <[email protected]>
Date:   Sun Jun 15 04:23:52 2025 +0800

    Revert "bcache: remove heap-related macros and switch to generic min_heap"
    
    commit 48fd7ebe00c1cdc782b42576548b25185902f64c upstream.
    
    This reverts commit 866898efbb25bb44fd42848318e46db9e785973a.
    
    The generic bottom-up min_heap implementation causes performance
    regression in invalidate_buckets_lru(), a hot path in bcache.  Before the
    cache is fully populated, new_bucket_prio() often returns zero, leading to
    many equal comparisons.  In such cases, bottom-up sift_down performs up to
    2 * log2(n) comparisons, while the original top-down approach completes
    with just O() comparisons, resulting in a measurable performance gap.
    
    The performance degradation is further worsened by the non-inlined
    min_heap API functions introduced in commit 92a8b224b833 ("lib/min_heap:
    introduce non-inline versions of min heap API functions"), adding function
    call overhead to this critical path.
    
    As reported by Robert, bcache now suffers from latency spikes, with P100
    (max) latency increasing from 600 ms to 2.4 seconds every 5 minutes.
    These regressions degrade bcache's effectiveness as a low-latency cache
    layer and lead to frequent timeouts and application stalls in production
    environments.
    
    This revert aims to restore bcache's original low-latency behavior.
    
    Link: https://lore.kernel.org/lkml/CAJhEC05+0S69z+3+FB2Cd0hD+pCRyWTKLEOsc8BOmH73p1m+KQ@mail.gmail.com
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 866898efbb25 ("bcache: remove heap-related macros and switch to generic min_heap")
    Fixes: 92a8b224b833 ("lib/min_heap: introduce non-inline versions of min heap API functions")
    Signed-off-by: Kuan-Wei Chiu <[email protected]>
    Reported-by: Robert Pang <[email protected]>
    Closes: https://lore.kernel.org/linux-bcache/CAJhEC06F_AtrPgw2-7CvCqZgeStgCtitbD-ryuPpXQA-JG5XXw@mail.gmail.com
    Acked-by: Coly Li <[email protected]>
    Cc: Ching-Chun (Jim) Huang <[email protected]>
    Cc: Kent Overstreet <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Revert "bcache: update min_heap_callbacks to use default builtin swap" [+ + +]
Author: Kuan-Wei Chiu <[email protected]>
Date:   Sun Jun 15 04:23:51 2025 +0800

    Revert "bcache: update min_heap_callbacks to use default builtin swap"
    
    commit 845f1f2d69f3f49b3d8c142265952c8257e3368c upstream.
    
    Patch series "bcache: Revert min_heap migration due to performance
    regression".
    
    This patch series reverts the migration of bcache from its original heap
    implementation to the generic min_heap library.  While the original change
    aimed to simplify the code and improve maintainability, it introduced a
    severe performance regression in real-world scenarios.
    
    As reported by Robert, systems using bcache now suffer from periodic
    latency spikes, with P100 (max) latency increasing from 600 ms to 2.4
    seconds every 5 minutes.  This degrades bcache's value as a low-latency
    caching layer, and leads to frequent timeouts and application stalls in
    production environments.
    
    The primary cause of this regression is the behavior of the generic
    min_heap implementation's bottom-up sift_down, which performs up to 2 *
    log2(n) comparisons when many elements are equal.  The original top-down
    variant used by bcache only required O(1) comparisons in such cases.  The
    issue was further exacerbated by commit 92a8b224b833 ("lib/min_heap:
    introduce non-inline versions of min heap API functions"), which
    introduced non-inlined versions of the min_heap API, adding function call
    overhead to a performance-critical hot path.
    
    
    This patch (of 3):
    
    This reverts commit 3d8a9a1c35227c3f1b0bd132c9f0a80dbda07b65.
    
    Although removing the custom swap function simplified the code, this
    change is part of a broader migration to the generic min_heap API that
    introduced significant performance regressions in bcache.
    
    As reported by Robert, bcache now suffers from latency spikes, with P100
    (max) latency increasing from 600 ms to 2.4 seconds every 5 minutes.
    These regressions degrade bcache's effectiveness as a low-latency cache
    layer and lead to frequent timeouts and application stalls in production
    environments.
    
    This revert is part of a series of changes to restore previous performance
    by undoing the min_heap transition.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Link: https://lore.kernel.org/lkml/CAJhEC05+0S69z+3+FB2Cd0hD+pCRyWTKLEOsc8BOmH73p1m+KQ@mail.gmail.com
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 866898efbb25 ("bcache: remove heap-related macros and switch to generic min_heap")
    Fixes: 92a8b224b833 ("lib/min_heap: introduce non-inline versions of min heap API functions")
    Signed-off-by: Kuan-Wei Chiu <[email protected]>
    Reported-by: Robert Pang <[email protected]>
    Closes: https://lore.kernel.org/linux-bcache/CAJhEC06F_AtrPgw2-7CvCqZgeStgCtitbD-ryuPpXQA-JG5XXw@mail.gmail.com
    Acked-by: Coly Li <[email protected]>
    Cc: Ching-Chun (Jim) Huang <[email protected]>
    Cc: Kent Overstreet <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Revert "drm/i915/gem: Allow EXEC_CAPTURE on recoverable contexts on DG1" [+ + +]
Author: Joonas Lahtinen <[email protected]>
Date:   Thu May 22 09:41:27 2025 +0300

    Revert "drm/i915/gem: Allow EXEC_CAPTURE on recoverable contexts on DG1"
    
    [ Upstream commit ed5915cfce2abb9a553c3737badebd4a11d6c9c7 ]
    
    This reverts commit d6e020819612a4a06207af858e0978be4d3e3140.
    
    The IS_DGFX check was put in place because error capture of buffer
    objects is expected to be broken on devices with VRAM.
    
    Userspace fix[1] to the impacted media driver has been submitted, merged
    and a new driver release is out as 25.2.3 where the capture flag is
    dropped on DG1 thus unblocking the usage of media driver on DG1.
    
    [1] https://github.com/intel/media-driver/commit/93c07d9b4b96a78bab21f6acd4eb863f4313ea4a
    
    Cc: [email protected] # v6.0+
    Cc: Ville Syrjälä <[email protected]>
    Cc: Andi Shyti <[email protected]>
    Cc: Matthew Auld <[email protected]>
    Cc: Thomas Hellström <[email protected]>
    Cc: Tvrtko Ursulin <[email protected]>
    Acked-by: Tvrtko Ursulin <[email protected]>
    Reviewed-by: Andi Shyti <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [Joonas: Update message to point out the merged userspace fix]
    Signed-off-by: Joonas Lahtinen <[email protected]>
    (cherry picked from commit d2dc30e0aa252830f908c8e793d3139d51321370)
    Signed-off-by: Joonas Lahtinen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Revert "riscv: Define TASK_SIZE_MAX for __access_ok()" [+ + +]
Author: Nam Cao <[email protected]>
Date:   Thu Jun 19 17:58:58 2025 +0200

    Revert "riscv: Define TASK_SIZE_MAX for __access_ok()"
    
    commit 890ba5be6335dbbbc99af14ea007befb5f83f174 upstream.
    
    This reverts commit ad5643cf2f69 ("riscv: Define TASK_SIZE_MAX for
    __access_ok()").
    
    This commit changes TASK_SIZE_MAX to be LONG_MAX to optimize access_ok(),
    because the previous TASK_SIZE_MAX (default to TASK_SIZE) requires some
    computation.
    
    The reasoning was that all user addresses are less than LONG_MAX, and all
    kernel addresses are greater than LONG_MAX. Therefore access_ok() can
    filter kernel addresses.
    
    Addresses between TASK_SIZE and LONG_MAX are not valid user addresses, but
    access_ok() let them pass. That was thought to be okay, because they are
    not valid addresses at hardware level.
    
    Unfortunately, one case is missed: get_user_pages_fast() happily accepts
    addresses between TASK_SIZE and LONG_MAX. futex(), for instance, uses
    get_user_pages_fast(). This causes the problem reported by Robert [1].
    
    Therefore, revert this commit. TASK_SIZE_MAX is changed to the default:
    TASK_SIZE.
    
    This unfortunately reduces performance, because TASK_SIZE is more expensive
    to compute compared to LONG_MAX. But correctness first, we can think about
    optimization later, if required.
    
    Reported-by: <[email protected]>
    Closes: https://lore.kernel.org/linux-riscv/77605.1750245028@localhost/
    Signed-off-by: Nam Cao <[email protected]>
    Cc: [email protected]
    Reviewed-by: Alexandre Ghiti <[email protected]>
    Fixes: ad5643cf2f69 ("riscv: Define TASK_SIZE_MAX for __access_ok()")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Palmer Dabbelt <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Revert "riscv: misaligned: fix sleeping function called during misaligned access handling" [+ + +]
Author: Nam Cao <[email protected]>
Date:   Fri Jun 20 13:09:39 2025 +0200

    Revert "riscv: misaligned: fix sleeping function called during misaligned access handling"
    
    commit 2f73c62d4e13df67380ff6faca39eec2bf08dd93 upstream.
    
    This reverts commit 61a74ad25462 ("riscv: misaligned: fix sleeping function
    called during misaligned access handling"). The commit addresses a sleeping
    in atomic context problem, but it is not the correct fix as explained by
    Clément:
    
    "Using nofault would lead to failure to read from user memory that is paged
    out for instance. This is not really acceptable, we should handle user
    misaligned access even at an address that would generate a page fault."
    
    This bug has been properly fixed by commit 453805f0a28f ("riscv:
    misaligned: enable IRQs while handling misaligned accesses").
    
    Revert this improper fix.
    
    Link: https://lore.kernel.org/linux-riscv/[email protected]/
    Signed-off-by: Nam Cao <[email protected]>
    Cc: [email protected]
    Reviewed-by: Clément Léger <[email protected]>
    Reviewed-by: Alexandre Ghiti <[email protected]>
    Fixes: 61a74ad25462 ("riscv: misaligned: fix sleeping function called during misaligned access handling")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Palmer Dabbelt <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
riscv: add a data fence for CMODX in the kernel mode [+ + +]
Author: Andy Chiu <[email protected]>
Date:   Tue Apr 8 02:08:32 2025 +0800

    riscv: add a data fence for CMODX in the kernel mode
    
    [ Upstream commit ca358692de41b273468e625f96926fa53e13bd8c ]
    
    RISC-V spec explicitly calls out that a local fence.i is not enough for
    the code modification to be visble from a remote hart. In fact, it
    states:
    
    To make a store to instruction memory visible to all RISC-V harts, the
    writing hart also has to execute a data FENCE before requesting that all
    remote RISC-V harts execute a FENCE.I.
    
    Although current riscv drivers for IPI use ordered MMIO when sending IPIs
    in order to synchronize the action between previous csd writes, riscv
    does not restrict itself to any particular flavor of IPI. Any driver or
    firmware implementation that does not order data writes before the IPI
    may pose a risk for code-modifying race.
    
    Thus, add a fence here to order data writes before making the IPI.
    
    Signed-off-by: Andy Chiu <[email protected]>
    Reviewed-by: Björn Töpel <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexandre Ghiti <[email protected]>
    Signed-off-by: Palmer Dabbelt <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

riscv: export boot_cpu_hartid [+ + +]
Author: Klara Modin <[email protected]>
Date:   Tue Jun 17 14:58:47 2025 +0200

    riscv: export boot_cpu_hartid
    
    commit c5136add3f9b4c23b8bbe5f4d722c95d4cfb936e upstream.
    
    The mailbox controller driver for the Microchip Inter-processor
    Communication can be built as a module. It uses cpuid_to_hartid_map and
    commit 4783ce32b080 ("riscv: export __cpuid_to_hartid_map") enables that
    to work for SMP. However, cpuid_to_hartid_map uses boot_cpu_hartid on
    non-SMP kernels and this driver can be useful in such configurations[1].
    
    Export boot_cpu_hartid so the driver can be built as a module on non-SMP
    kernels as well.
    
    Link: https://lore.kernel.org/lkml/20250617-confess-reimburse-876101e099cb@spud/ [1]
    Cc: [email protected]
    Fixes: e4b1d67e7141 ("mailbox: add Microchip IPC support")
    Signed-off-by: Klara Modin <[email protected]>
    Acked-by: Conor Dooley <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Palmer Dabbelt <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

riscv: fix runtime constant support for nommu kernels [+ + +]
Author: Charles Mirabile <[email protected]>
Date:   Fri May 30 17:14:22 2025 -0400

    riscv: fix runtime constant support for nommu kernels
    
    [ Upstream commit 8d90d9872edae7e78c3a12b98e239bfaa66f3639 ]
    
    the `__runtime_fixup_32` function does not handle the case where `val` is
    zero correctly (as might occur when patching a nommu kernel and referring
    to a physical address below the 4GiB boundary whose upper 32 bits are all
    zero) because nothing in the existing logic prevents the code from taking
    the `else` branch of both nop-checks and emitting two `nop` instructions.
    
    This leaves random garbage in the register that is supposed to receive the
    upper 32 bits of the pointer instead of zero that when combined with the
    value for the lower 32 bits yields an invalid pointer and causes a kernel
    panic when that pointer is eventually accessed.
    
    The author clearly considered the fact that if the `lui` is converted into
    a `nop` that the second instruction needs to be adjusted to become an `li`
    instead of an `addi`, hence introducing the `addi_insn_mask` variable, but
    didn't follow that logic through fully to the case where the `else` branch
    executes. To fix it just adjust the logic to ensure that the second `else`
    branch is not taken if the first instruction will be patched to a `nop`.
    
    Fixes: a44fb5722199 ("riscv: Add runtime constant support")
    
    Signed-off-by: Charles Mirabile <[email protected]>
    Reviewed-by: Charlie Jenkins <[email protected]>
    Tested-by: Charlie Jenkins <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Palmer Dabbelt <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

riscv: misaligned: declare misaligned_access_speed under CONFIG_RISCV_MISALIGNED [+ + +]
Author: Clément Léger <[email protected]>
Date:   Fri May 23 12:19:25 2025 +0200

    riscv: misaligned: declare misaligned_access_speed under CONFIG_RISCV_MISALIGNED
    
    [ Upstream commit 1317045a7d6f397904d105f6d40dc9787876a34b ]
    
    While misaligned_access_speed was defined in a file compile with
    CONFIG_RISCV_MISALIGNED, its definition was under
    CONFIG_RISCV_SCALAR_MISALIGNED. This resulted in compilation problems
    when using it in a file compiled with CONFIG_RISCV_MISALIGNED.
    
    Move the declaration under CONFIG_RISCV_MISALIGNED so that it can be
    used unconditionnally when compiled with that config and remove the check
    for that variable in traps_misaligned.c.
    
    Signed-off-by: Clément Léger <[email protected]>
    Reviewed-by: Charlie Jenkins <[email protected]>
    Tested-by: Charlie Jenkins <[email protected]>
    Reviewed-by: Andrew Jones <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Palmer Dabbelt <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

riscv: save the SR_SUM status over switches [+ + +]
Author: Ben Dooks <[email protected]>
Date:   Thu Apr 10 07:05:22 2025 +0000

    riscv: save the SR_SUM status over switches
    
    [ Upstream commit 788aa64c01f1262310b4c1fb827a36df170d86ea ]
    
    When threads/tasks are switched we need to ensure the old execution's
    SR_SUM state is saved and the new thread has the old SR_SUM state
    restored.
    
    The issue was seen under heavy load especially with the syz-stress tool
    running, with crashes as follows in schedule_tail:
    
    Unable to handle kernel access to user memory without uaccess routines
    at virtual address 000000002749f0d0
    Oops [#1]
    Modules linked in:
    CPU: 1 PID: 4875 Comm: syz-executor.0 Not tainted
    5.12.0-rc2-syzkaller-00467-g0d7588ab9ef9 #0
    Hardware name: riscv-virtio,qemu (DT)
    epc : schedule_tail+0x72/0xb2 kernel/sched/core.c:4264
     ra : task_pid_vnr include/linux/sched.h:1421 [inline]
     ra : schedule_tail+0x70/0xb2 kernel/sched/core.c:4264
    epc : ffffffe00008c8b0 ra : ffffffe00008c8ae sp : ffffffe025d17ec0
     gp : ffffffe005d25378 tp : ffffffe00f0d0000 t0 : 0000000000000000
     t1 : 0000000000000001 t2 : 00000000000f4240 s0 : ffffffe025d17ee0
     s1 : 000000002749f0d0 a0 : 000000000000002a a1 : 0000000000000003
     a2 : 1ffffffc0cfac500 a3 : ffffffe0000c80cc a4 : 5ae9db91c19bbe00
     a5 : 0000000000000000 a6 : 0000000000f00000 a7 : ffffffe000082eba
     s2 : 0000000000040000 s3 : ffffffe00eef96c0 s4 : ffffffe022c77fe0
     s5 : 0000000000004000 s6 : ffffffe067d74e00 s7 : ffffffe067d74850
     s8 : ffffffe067d73e18 s9 : ffffffe067d74e00 s10: ffffffe00eef96e8
     s11: 000000ae6cdf8368 t3 : 5ae9db91c19bbe00 t4 : ffffffc4043cafb2
     t5 : ffffffc4043cafba t6 : 0000000000040000
    status: 0000000000000120 badaddr: 000000002749f0d0 cause:
    000000000000000f
    Call Trace:
    [<ffffffe00008c8b0>] schedule_tail+0x72/0xb2 kernel/sched/core.c:4264
    [<ffffffe000005570>] ret_from_exception+0x0/0x14
    Dumping ftrace buffer:
       (ftrace buffer empty)
    ---[ end trace b5f8f9231dc87dda ]---
    
    The issue comes from the put_user() in schedule_tail
    (kernel/sched/core.c) doing the following:
    
    asmlinkage __visible void schedule_tail(struct task_struct *prev)
    {
    ...
            if (current->set_child_tid)
                    put_user(task_pid_vnr(current), current->set_child_tid);
    ...
    }
    
    the put_user() macro causes the code sequence to come out as follows:
    
    1:      __enable_user_access()
    2:      reg = task_pid_vnr(current);
    3:      *current->set_child_tid = reg;
    4:      __disable_user_access()
    
    The problem is that we may have a sleeping function as argument which
    could clear SR_SUM causing the panic above. This was fixed by
    evaluating the argument of the put_user() macro outside the user-enabled
    section in commit 285a76bb2cf5 ("riscv: evaluate put_user() arg before
    enabling user access")"
    
    In order for riscv to take advantage of unsafe_get/put_XXX() macros and
    to avoid the same issue we had with put_user() and sleeping functions we
    must ensure code flow can go through switch_to() from within a region of
    code with SR_SUM enabled and come back with SR_SUM still enabled. This
    patch addresses the problem allowing future work to enable full use of
    unsafe_get/put_XXX() macros without needing to take a CSR bit flip cost
    on every access. Make switch_to() save and restore SR_SUM.
    
    Reported-by: [email protected]
    Signed-off-by: Ben Dooks <[email protected]>
    Signed-off-by: Cyril Bur <[email protected]>
    Reviewed-by: Alexandre Ghiti <[email protected]>
    Reviewed-by: Deepak Gupta <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Palmer Dabbelt <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

riscv: uaccess: Only restore the CSR_STATUS SUM bit [+ + +]
Author: Cyril Bur <[email protected]>
Date:   Mon Jun 2 12:15:43 2025 +0000

    riscv: uaccess: Only restore the CSR_STATUS SUM bit
    
    commit 265d6aba165c500389c80d394ac247460c443ef5 upstream.
    
    During switch to csrs will OR the value of the register into the
    corresponding csr. In this case we're only interested in restoring the
    SUM bit not the entire register.
    
    Signed-off-by: Cyril Bur <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Co-developed-by: Alexandre Ghiti <[email protected]>
    Signed-off-by: Alexandre Ghiti <[email protected]>
    Fixes: 788aa64c01f1 ("riscv: save the SR_SUM status over switches")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Palmer Dabbelt <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

riscv: vector: Fix context save/restore with xtheadvector [+ + +]
Author: Han Gao <[email protected]>
Date:   Fri May 23 18:25:56 2025 +0800

    riscv: vector: Fix context save/restore with xtheadvector
    
    commit 4262bd0d9cc704ea1365ac00afc1272400c2cbef upstream.
    
    Previously only v0-v7 were correctly saved/restored,
    and the context of v8-v31 are damanged.
    Correctly save/restore v8-v31 to avoid breaking userspace.
    
    Fixes: d863910eabaf ("riscv: vector: Support xtheadvector save/restore")
    Cc: [email protected]
    Signed-off-by: Han Gao <[email protected]>
    Tested-by: Xiongchuan Tan <[email protected]>
    Reviewed-by: Charlie Jenkins <[email protected]>
    Reviewed-by: Yanteng Si <[email protected]>
    Reviewed-by: Andy Chiu <[email protected]>
    Link: https://lore.kernel.org/r/9b9eb2337f3d5336ce813721f8ebea51e0b2b553.1747994822.git.rabenda.cn@gmail.com
    Signed-off-by: Alexandre Ghiti <[email protected]>
    Signed-off-by: Palmer Dabbelt <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
rust: arm: fix unknown (to Clang) argument '-mno-fdpic' [+ + +]
Author: Rudraksha Gupta <[email protected]>
Date:   Thu May 22 05:02:31 2025 -0700

    rust: arm: fix unknown (to Clang) argument '-mno-fdpic'
    
    [ Upstream commit 977c4308ee4270cf46e2c66b37de8e04670daa0c ]
    
    Currently rust on arm fails to compile due to '-mno-fdpic'. This flag
    disables a GCC feature that we don't want for kernel builds, so let's
    skip it as it doesn't apply to Clang.
    
        UPD     include/generated/asm-offsets.h
        CALL    scripts/checksyscalls.sh
        RUSTC L rust/core.o
        BINDGEN rust/bindings/bindings_generated.rs
        BINDGEN rust/bindings/bindings_helpers_generated.rs
        CC      rust/helpers/helpers.o
        Unable to generate bindings: clang diagnosed error: error: unknown argument: '-mno-fdpic'
        make[2]: *** [rust/Makefile:369: rust/bindings/bindings_helpers_generated.rs] Error 1
        make[2]: *** Deleting file 'rust/bindings/bindings_helpers_generated.rs'
        make[2]: *** Waiting for unfinished jobs....
        Unable to generate bindings: clang diagnosed error: error: unknown argument: '-mno-fdpic'
        make[2]: *** [rust/Makefile:349: rust/bindings/bindings_generated.rs] Error 1
        make[2]: *** Deleting file 'rust/bindings/bindings_generated.rs'
        make[1]: *** [/home/pmos/build/src/linux-next-next-20250521/Makefile:1285: prepare] Error 2
        make: *** [Makefile:248: __sub-make] Error 2
    
    [ Naresh provided the draft diff [1].
    
      Ben explained [2]:
    
        FDPIC is only relevant with no-MMU targets, and then only for userspace.
        When configured for the arm-*-uclinuxfdpiceabi target, GCC enables FDPIC
        by default to facilitate compiling userspace programs. FDPIC is never
        used for the kernel, and we pass -mno-fdpic when building the kernel to
        override the default and make sure FDPIC is disabled.
    
      and [3]:
    
        -mno-fdpic disables a GCC feature that we don't want for kernel builds.
        clang does not support this feature, so it always behaves as though
        -mno-fdpic is passed. Therefore, it should be fine to mix the two, at
        least as far as FDPIC is concerned.
    
      [1] https://lore.kernel.org/rust-for-linux/CA+G9fYt4otQK4pHv8pJBW9e28yHSGCDncKquwuJiJ_1ou0pq0w@mail.gmail.com/
      [2] https://lore.kernel.org/rust-for-linux/aAKrq2InExQk7f_k@dell-precision-5540/
      [3] https://lore.kernel.org/rust-for-linux/aAo_F_UP1Gd4jHlZ@dell-precision-5540/
    
        - Miguel ]
    
    Reported-by: Linux Kernel Functional Testing <[email protected]>
    Closes: https://lore.kernel.org/all/CA+G9fYvOanQBYXKSg7C6EU30k8sTRC0JRPJXYu7wWK51w38QUQ@mail.gmail.com/
    Suggested-by: Miguel Ojeda <[email protected]>
    Acked-by: Naresh Kamboju <[email protected]>
    Signed-off-by: Rudraksha Gupta <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [ Reworded title. - Miguel ]
    Signed-off-by: Miguel Ojeda <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

rust: completion: implement initial abstraction [+ + +]
Author: Danilo Krummrich <[email protected]>
Date:   Thu Jun 12 14:17:13 2025 +0200

    rust: completion: implement initial abstraction
    
    commit 1b56e765bf8990f1f60e124926c11fc4ac63d752 upstream.
    
    Implement a minimal abstraction for the completion synchronization
    primitive.
    
    This initial abstraction only adds complete_all() and
    wait_for_completion(), since that is what is required for the subsequent
    Devres patch.
    
    Cc: Ingo Molnar <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Cc: Juri Lelli <[email protected]>
    Cc: Vincent Guittot <[email protected]>
    Cc: Dietmar Eggemann <[email protected]>
    Cc: Steven Rostedt <[email protected]>
    Cc: Ben Segall <[email protected]>
    Cc: Mel Gorman <[email protected]>
    Cc: Valentin Schneider <[email protected]>
    Reviewed-by: Alice Ryhl <[email protected]>
    Reviewed-by: Boqun Feng <[email protected]>
    Reviewed-by: Benno Lossin <[email protected]>
    Acked-by: Miguel Ojeda <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Danilo Krummrich <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

rust: devres: do not dereference to the internal Revocable [+ + +]
Author: Danilo Krummrich <[email protected]>
Date:   Wed Jun 11 19:48:25 2025 +0200

    rust: devres: do not dereference to the internal Revocable
    
    commit 20c96ed278e362ae4e324ed7d8c69fb48c508d3c upstream.
    
    We can't expose direct access to the internal Revocable, since this
    allows users to directly revoke the internal Revocable without Devres
    having the chance to synchronize with the devres callback -- we have to
    guarantee that the internal Revocable has been fully revoked before
    the device is fully unbound.
    
    Hence, remove the corresponding Deref implementation and, instead,
    provide indirect accessors for the internal Revocable.
    
    Note that we can still support Devres::revoke() by implementing the
    required synchronization (which would be almost identical to the
    synchronization in Devres::drop()).
    
    Fixes: 76c01ded724b ("rust: add devres abstraction")
    Reviewed-by: Benno Lossin <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Danilo Krummrich <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

rust: devres: fix race in Devres::drop() [+ + +]
Author: Danilo Krummrich <[email protected]>
Date:   Thu Jun 12 14:17:15 2025 +0200

    rust: devres: fix race in Devres::drop()
    
    commit f744201c6159fc7323c40936fd079525f7063598 upstream.
    
    In Devres::drop() we first remove the devres action and then drop the
    wrapped device resource.
    
    The design goal is to give the owner of a Devres object control over when
    the device resource is dropped, but limit the overall scope to the
    corresponding device being bound to a driver.
    
    However, there's a race that was introduced with commit 8ff656643d30
    ("rust: devres: remove action in `Devres::drop`"), but also has been
    (partially) present from the initial version on.
    
    In Devres::drop(), the devres action is removed successfully and
    subsequently the destructor of the wrapped device resource runs.
    However, there is no guarantee that the destructor of the wrapped device
    resource completes before the driver core is done unbinding the
    corresponding device.
    
    If in Devres::drop(), the devres action can't be removed, it means that
    the devres callback has been executed already, or is still running
    concurrently. In case of the latter, either Devres::drop() wins revoking
    the Revocable or the devres callback wins revoking the Revocable. If
    Devres::drop() wins, we (again) have no guarantee that the destructor of
    the wrapped device resource completes before the driver core is done
    unbinding the corresponding device.
    
    CPU0                                    CPU1
    ------------------------------------------------------------------------
    Devres::drop() {                        Devres::devres_callback() {
       self.data.revoke() {                    this.data.revoke() {
          is_available.swap() == true
                                                  is_available.swap == false
                                               }
                                            }
    
                                            // [...]
                                            // device fully unbound
          drop_in_place() {
             // release device resource
          }
       }
    }
    
    Depending on the specific device resource, this can potentially lead to
    user-after-free bugs.
    
    In order to fix this, implement the following logic.
    
    In the devres callback, we're always good when we get to revoke the
    device resource ourselves, i.e. Revocable::revoke() returns true.
    
    If Revocable::revoke() returns false, it means that Devres::drop(),
    concurrently, already drops the device resource and we have to wait for
    Devres::drop() to signal that it finished dropping the device resource.
    
    Note that if we hit the case where we need to wait for the completion of
    Devres::drop() in the devres callback, it means that we're actually
    racing with a concurrent Devres::drop() call, which already started
    revoking the device resource for us. This is rather unlikely and means
    that the concurrent Devres::drop() already started doing our work and we
    just need to wait for it to complete it for us. Hence, there should not
    be any additional overhead from that.
    
    (Actually, for now it's even better if Devres::drop() does the work for
    us, since it can bypass the synchronize_rcu() call implied by
    Revocable::revoke(), but this goes away anyways once I get to implement
    the split devres callback approach, which allows us to first flip the
    atomics of all registered Devres objects of a certain device, execute a
    single synchronize_rcu() and then drop all revocable objects.)
    
    In Devres::drop() we try to revoke the device resource. If that is *not*
    successful, it means that the devres callback already did and we're good.
    
    Otherwise, we try to remove the devres action, which, if successful,
    means that we're good, since the device resource has just been revoked
    by us *before* we removed the devres action successfully.
    
    If the devres action could not be removed, it means that the devres
    callback must be running concurrently, hence we signal that the device
    resource has been revoked by us, using the completion.
    
    This makes it safe to drop a Devres object from any task and at any point
    of time, which is one of the design goals.
    
    Fixes: 76c01ded724b ("rust: add devres abstraction")
    Reported-by: Alice Ryhl <[email protected]>
    Closes: https://lore.kernel.org/lkml/[email protected]/
    Reviewed-by: Benno Lossin <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Danilo Krummrich <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

rust: module: place cleanup_module() in .exit.text section [+ + +]
Author: FUJITA Tomonori <[email protected]>
Date:   Sat Mar 8 13:45:06 2025 +0900

    rust: module: place cleanup_module() in .exit.text section
    
    [ Upstream commit 249c3a0e53acefc2b06d3b3e1fc28fb2081f878d ]
    
    Place cleanup_module() in .exit.text section. Currently,
    cleanup_module() is likely placed in the .text section. It's
    inconsistent with the layout of C modules, where cleanup_module() is
    placed in .exit.text.
    
    [ Boqun asked for an example of how the section changed to be
      put in the log. Tomonori provided the following examples:
    
        C module:
    
          $ objdump -t ~/build/x86/drivers/block/loop.o|grep clean
          0000000000000000 l     O .exit.data    0000000000000008 __UNIQUE_ID___addressable_cleanup_module412
          0000000000000000 g     F .exit.text    000000000000009c cleanup_module
    
        Rust module without this patch:
    
          $ objdump -t ~/build/x86/samples/rust/rust_minimal.o|grep clean
          00000000000002b0 g     F .text         00000000000000c6 cleanup_module
          0000000000000000 g     O .exit.data    0000000000000008 _R...___UNIQUE_ID___addressable_cleanup_module
    
        Rust module with this patch:
    
          $ objdump -t ~/build/x86/samples/rust/rust_minimal.o|grep clean
          0000000000000000 g     F .exit.text    00000000000000c6 cleanup_module
          0000000000000000 g     O .exit.data    0000000000000008 _R...___UNIQUE_ID___addressable_cleanup_module
    
      - Miguel ]
    
    Signed-off-by: FUJITA Tomonori <[email protected]>
    Acked-by: Jarkko Sakkinen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Miguel Ojeda <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

rust: revocable: indicate whether `data` has been revoked already [+ + +]
Author: Danilo Krummrich <[email protected]>
Date:   Thu Jun 12 14:17:14 2025 +0200

    rust: revocable: indicate whether `data` has been revoked already
    
    commit 4b76fafb20dd4a2becb94949d78e86bc88006509 upstream.
    
    Return a boolean from Revocable::revoke() and Revocable::revoke_nosync()
    to indicate whether the data has been revoked already.
    
    Return true if the data hasn't been revoked yet (i.e. this call revoked
    the data), false otherwise.
    
    This is required by Devres in order to synchronize the completion of the
    revoke process.
    
    Reviewed-by: Benno Lossin <[email protected]>
    Acked-by: Miguel Ojeda <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Danilo Krummrich <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
s390/mm: Fix in_atomic() handling in do_secure_storage_access() [+ + +]
Author: Heiko Carstens <[email protected]>
Date:   Tue Jun 3 15:49:36 2025 +0200

    s390/mm: Fix in_atomic() handling in do_secure_storage_access()
    
    [ Upstream commit 11709abccf93b08adde95ef313c300b0d4bc28f1 ]
    
    Kernel user spaces accesses to not exported pages in atomic context
    incorrectly try to resolve the page fault.
    With debug options enabled call traces like this can be seen:
    
    BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1523
    in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 419074, name: qemu-system-s39
    preempt_count: 1, expected: 0
    RCU nest depth: 0, expected: 0
    INFO: lockdep is turned off.
    Preemption disabled at:
    [<00000383ea47cfa2>] copy_page_from_iter_atomic+0xa2/0x8a0
    CPU: 12 UID: 0 PID: 419074 Comm: qemu-system-s39
    Tainted: G        W           6.16.0-20250531.rc0.git0.69b3a602feac.63.fc42.s390x+debug #1 PREEMPT
    Tainted: [W]=WARN
    Hardware name: IBM 3931 A01 703 (LPAR)
    Call Trace:
     [<00000383e990d282>] dump_stack_lvl+0xa2/0xe8
     [<00000383e99bf152>] __might_resched+0x292/0x2d0
     [<00000383eaa7c374>] down_read+0x34/0x2d0
     [<00000383e99432f8>] do_secure_storage_access+0x108/0x360
     [<00000383eaa724b0>] __do_pgm_check+0x130/0x220
     [<00000383eaa842e4>] pgm_check_handler+0x114/0x160
     [<00000383ea47d028>] copy_page_from_iter_atomic+0x128/0x8a0
    ([<00000383ea47d016>] copy_page_from_iter_atomic+0x116/0x8a0)
     [<00000383e9c45eae>] generic_perform_write+0x16e/0x310
     [<00000383e9eb87f4>] ext4_buffered_write_iter+0x84/0x160
     [<00000383e9da0de4>] vfs_write+0x1c4/0x460
     [<00000383e9da123c>] ksys_write+0x7c/0x100
     [<00000383eaa7284e>] __do_syscall+0x15e/0x280
     [<00000383eaa8417e>] system_call+0x6e/0x90
    INFO: lockdep is turned off.
    
    It is not allowed to take the mmap_lock while in atomic context. Therefore
    handle such a secure storage access fault as if the accessed page is not
    mapped: the uaccess function will return -EFAULT, and the caller has to
    deal with this. Usually this means that the access is retried in process
    context, which allows to resolve the page fault (or in this case export the
    page).
    
    Reviewed-by: Claudio Imbrenda <[email protected]>
    Acked-by: Alexander Gordeev <[email protected]>
    Acked-by: Christian Borntraeger <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Heiko Carstens <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
s390/pkey: Prevent overflow in size calculation for memdup_user() [+ + +]
Author: Fedor Pchelkin <[email protected]>
Date:   Wed Jun 11 22:20:10 2025 +0300

    s390/pkey: Prevent overflow in size calculation for memdup_user()
    
    commit 7360ee47599af91a1d5f4e74d635d9408a54e489 upstream.
    
    Number of apqn target list entries contained in 'nr_apqns' variable is
    determined by userspace via an ioctl call so the result of the product in
    calculation of size passed to memdup_user() may overflow.
    
    In this case the actual size of the allocated area and the value
    describing it won't be in sync leading to various types of unpredictable
    behaviour later.
    
    Use a proper memdup_array_user() helper which returns an error if an
    overflow is detected. Note that it is different from when nr_apqns is
    initially zero - that case is considered valid and should be handled in
    subsequent pkey_handler implementations.
    
    Found by Linux Verification Center (linuxtesting.org).
    
    Fixes: f2bbc96e7cfa ("s390/pkey: add CCA AES cipher key support")
    Cc: [email protected]
    Signed-off-by: Fedor Pchelkin <[email protected]>
    Reviewed-by: Holger Dengler <[email protected]>
    Reviewed-by: Heiko Carstens <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexander Gordeev <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
s390/ptrace: Fix pointer dereferencing in regs_get_kernel_stack_nth() [+ + +]
Author: Heiko Carstens <[email protected]>
Date:   Fri Jun 13 17:53:04 2025 +0200

    s390/ptrace: Fix pointer dereferencing in regs_get_kernel_stack_nth()
    
    commit 7f8073cfb04a97842fe891ca50dad60afd1e3121 upstream.
    
    The recent change which added READ_ONCE_NOCHECK() to read the nth entry
    from the kernel stack incorrectly dropped dereferencing of the stack
    pointer in order to read the requested entry.
    
    In result the address of the entry is returned instead of its content.
    
    Dereference the pointer again to fix this.
    
    Reported-by: Will Deacon <[email protected]>
    Closes: https://lore.kernel.org/r/20250612163331.GA13384@willie-the-truck
    Fixes: d93a855c31b7 ("s390/ptrace: Avoid KASAN false positives in regs_get_kernel_stack_nth()")
    Cc: [email protected]
    Reviewed-by: Alexander Gordeev <[email protected]>
    Signed-off-by: Heiko Carstens <[email protected]>
    Signed-off-by: Alexander Gordeev <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
sched_ext: Make scx_group_set_weight() always update tg->scx.weight [+ + +]
Author: Sasha Levin <[email protected]>
Date:   Tue Jul 1 21:58:33 2025 -0400

    sched_ext: Make scx_group_set_weight() always update tg->scx.weight
    
    [ Upstream commit c50784e99f0e7199cdb12dbddf02229b102744ef ]
    
    Otherwise, tg->scx.weight can go out of sync while scx_cgroup is not enabled
    and ops.cgroup_init() may be called with a stale weight value.
    
    Signed-off-by: Tejun Heo <[email protected]>
    Fixes: 819513666966 ("sched_ext: Add cgroup support")
    Cc: [email protected] # v6.12+
    Signed-off-by: Sasha Levin <[email protected]>

 
scripts/gdb: fix dentry_name() lookup [+ + +]
Author: Florian Fainelli <[email protected]>
Date:   Thu Jun 19 15:51:05 2025 -0700

    scripts/gdb: fix dentry_name() lookup
    
    commit 79300ac805b672a84b64d80d4cbc374d83411599 upstream.
    
    The "d_iname" member was replaced with "d_shortname.string" in the commit
    referenced in the Fixes tag.  This prevented the GDB script "lx-mount"
    command to properly function:
    
    (gdb) lx-mounts
          mount          super_block     devname pathname fstype options
    0xff11000002d21180 0xff11000002d24800 rootfs / rootfs rw 0 0
    0xff11000002e18a80 0xff11000003713000 /dev/root / ext4 rw,relatime 0 0
    Python Exception <class 'gdb.error'>: There is no member named d_iname.
    Error occurred in Python: There is no member named d_iname.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 58cf9c383c5c ("dcache: back inline names with a struct-wrapped array of unsigned long")
    Signed-off-by: Florian Fainelli <[email protected]>
    Cc: Al Viro <[email protected]>
    Cc: Jan Kara <[email protected]>
    Cc: Jan Kiszka <[email protected]>
    Cc: Jeff Layton <[email protected]>
    Cc: Kieran Bingham <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
scsi: fnic: Fix crash in fnic_wq_cmpl_handler when FDMI times out [+ + +]
Author: Karan Tilak Kumar <[email protected]>
Date:   Tue Jun 17 17:34:28 2025 -0700

    scsi: fnic: Fix crash in fnic_wq_cmpl_handler when FDMI times out
    
    commit a35b29bdedb4d2ae3160d4d6684a6f1ecd9ca7c2 upstream.
    
    When both the RHBA and RPA FDMI requests time out, fnic reuses a frame to
    send ABTS for each of them. On send completion, this causes an attempt to
    free the same frame twice that leads to a crash.
    
    Fix crash by allocating separate frames for RHBA and RPA, and modify ABTS
    logic accordingly.
    
    Tested by checking MDS for FDMI information.
    
    Tested by using instrumented driver to:
    
     - Drop PLOGI response
     - Drop RHBA response
     - Drop RPA response
     - Drop RHBA and RPA response
     - Drop PLOGI response + ABTS response
     - Drop RHBA response + ABTS response
     - Drop RPA response + ABTS response
     - Drop RHBA and RPA response + ABTS response for both of them
    
    Fixes: 09c1e6ab4ab2 ("scsi: fnic: Add and integrate support for FDMI")
    Reviewed-by: Sesidhar Baddela <[email protected]>
    Reviewed-by: Arulprabhu Ponnusamy <[email protected]>
    Reviewed-by: Gian Carlo Boffa <[email protected]>
    Tested-by: Arun Easi <[email protected]>
    Co-developed-by: Arun Easi <[email protected]>
    Signed-off-by: Arun Easi <[email protected]>
    Tested-by: Karan Tilak Kumar <[email protected]>
    Cc: [email protected]
    Signed-off-by: Karan Tilak Kumar <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: John Meneghini <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

scsi: fnic: Fix missing DMA mapping error in fnic_send_frame() [+ + +]
Author: Thomas Fourier <[email protected]>
Date:   Wed Jun 18 08:57:04 2025 +0200

    scsi: fnic: Fix missing DMA mapping error in fnic_send_frame()
    
    [ Upstream commit 85d6fbc47c3087c5d048e6734926b0c36af34fe9 ]
    
    dma_map_XXX() can fail and should be tested for errors with
    dma_mapping_error().
    
    Fixes: a63e78eb2b0f ("scsi: fnic: Add support for fabric based solicited requests and responses")
    Signed-off-by: Thomas Fourier <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Karan Tilak Kumar <[email protected]>
    Reviewed-by: John Menghini <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: fnic: Turn off FDMI ACTIVE flags on link down [+ + +]
Author: Karan Tilak Kumar <[email protected]>
Date:   Tue Jun 17 17:34:29 2025 -0700

    scsi: fnic: Turn off FDMI ACTIVE flags on link down
    
    commit 74f46a0524f8d2f01dc7ca95bb5fc463a8603e72 upstream.
    
    When the link goes down and comes up, FDMI requests are not sent out
    anymore.
    
    Fix bug by turning off FNIC_FDMI_ACTIVE when the link goes down.
    
    Fixes: 09c1e6ab4ab2 ("scsi: fnic: Add and integrate support for FDMI")
    Reviewed-by: Sesidhar Baddela <[email protected]>
    Reviewed-by: Arulprabhu Ponnusamy <[email protected]>
    Reviewed-by: Gian Carlo Boffa <[email protected]>
    Reviewed-by: Arun Easi <[email protected]>
    Tested-by: Karan Tilak Kumar <[email protected]>
    Cc: [email protected]
    Signed-off-by: Karan Tilak Kumar <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: John Meneghini <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

scsi: megaraid_sas: Fix invalid node index [+ + +]
Author: Chen Yu <[email protected]>
Date:   Wed Jun 4 12:25:56 2025 +0800

    scsi: megaraid_sas: Fix invalid node index
    
    commit 752eb816b55adb0673727ba0ed96609a17895654 upstream.
    
    On a system with DRAM interleave enabled, out-of-bound access is
    detected:
    
    megaraid_sas 0000:3f:00.0: requested/available msix 128/128 poll_queue 0
    ------------[ cut here ]------------
    UBSAN: array-index-out-of-bounds in ./arch/x86/include/asm/topology.h:72:28
    index -1 is out of range for type 'cpumask *[1024]'
    dump_stack_lvl+0x5d/0x80
    ubsan_epilogue+0x5/0x2b
    __ubsan_handle_out_of_bounds.cold+0x46/0x4b
    megasas_alloc_irq_vectors+0x149/0x190 [megaraid_sas]
    megasas_probe_one.cold+0xa4d/0x189c [megaraid_sas]
    local_pci_probe+0x42/0x90
    pci_device_probe+0xdc/0x290
    really_probe+0xdb/0x340
    __driver_probe_device+0x78/0x110
    driver_probe_device+0x1f/0xa0
    __driver_attach+0xba/0x1c0
    bus_for_each_dev+0x8b/0xe0
    bus_add_driver+0x142/0x220
    driver_register+0x72/0xd0
    megasas_init+0xdf/0xff0 [megaraid_sas]
    do_one_initcall+0x57/0x310
    do_init_module+0x90/0x250
    init_module_from_file+0x85/0xc0
    idempotent_init_module+0x114/0x310
    __x64_sys_finit_module+0x65/0xc0
    do_syscall_64+0x82/0x170
    entry_SYSCALL_64_after_hwframe+0x76/0x7e
    
    Fix it accordingly.
    
    Signed-off-by: Chen Yu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Fixes: 8049da6f3943 ("scsi: megaraid_sas: Use irq_set_affinity_and_hint()")
    Cc: [email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

scsi: ufs: core: Don't perform UFS clkscaling during host async scan [+ + +]
Author: Ziqi Chen <[email protected]>
Date:   Thu May 22 16:12:28 2025 +0800

    scsi: ufs: core: Don't perform UFS clkscaling during host async scan
    
    [ Upstream commit e97633492f5a3eca7b3ff03b4ef6f993017f7955 ]
    
    When preparing for UFS clock scaling, the UFS driver will quiesce all
    sdevs queues in the UFS SCSI host tagset list and then unquiesce them in
    ufshcd_clock_scaling_unprepare(). If the UFS SCSI host async scan is in
    progress at this time, some LUs may be added to the tagset list between
    UFS clkscale prepare and unprepare. This can cause two issues:
    
    1. During clock scaling, there may be I/O requests issued through new
    added queues that have not been quiesced, leading to task abort issue.
    
    2. These new added queues that have not been quiesced will be unquiesced
    as well when UFS clkscale is unprepared, resulting in warning prints.
    
    Therefore, use the mutex lock scan_mutex in
    ufshcd_clock_scaling_prepare() and ufshcd_clock_scaling_unprepare() to
    protect it.
    
    Co-developed-by: Can Guo <[email protected]>
    Signed-off-by: Can Guo <[email protected]>
    Signed-off-by: Ziqi Chen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Suggested-by: Bart Van Assche <[email protected]>
    Reviewed-by: Bart Van Assche <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: ufs: core: Fix clk scaling to be conditional in reset and restore [+ + +]
Author: anvithdosapati <[email protected]>
Date:   Mon Jun 16 08:57:34 2025 +0000

    scsi: ufs: core: Fix clk scaling to be conditional in reset and restore
    
    commit 2e083cd802294693a5414e4557a183dd7e442e71 upstream.
    
    In ufshcd_host_reset_and_restore(), scale up clocks only when clock
    scaling is supported. Without this change CPU latency is voted for 0
    (ufshcd_pm_qos_update) during resume unconditionally.
    
    Signed-off-by: anvithdosapati <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Fixes: a3cd5ec55f6c ("scsi: ufs: add load based scaling of UFS gear")
    Cc: [email protected]
    Reviewed-by: Bart Van Assche <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
selinux: change security_compute_sid to return the ssid or tsid on match [+ + +]
Author: Stephen Smalley <[email protected]>
Date:   Tue Jun 10 15:48:27 2025 -0400

    selinux: change security_compute_sid to return the ssid or tsid on match
    
    commit fde46f60f6c5138ee422087addbc5bf5b4968bf1 upstream.
    
    If the end result of a security_compute_sid() computation matches the
    ssid or tsid, return that SID rather than looking it up again. This
    avoids the problem of multiple initial SIDs that map to the same
    context.
    
    Cc: [email protected]
    Reported-by: Guido Trentalancia <[email protected]>
    Fixes: ae254858ce07 ("selinux: introduce an initial SID for early boot processes")
    Signed-off-by: Stephen Smalley <[email protected]>
    Tested-by: Guido Trentalancia <[email protected]>
    Signed-off-by: Paul Moore <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
serial: core: restore of_node information in sysfs [+ + +]
Author: Aidan Stewart <[email protected]>
Date:   Tue Jun 17 10:48:19 2025 -0600

    serial: core: restore of_node information in sysfs
    
    commit d36f0e9a0002f04f4d6dd9be908d58fe5bd3a279 upstream.
    
    Since in v6.8-rc1, the of_node symlink under tty devices is
    missing. This breaks any udev rules relying on this information.
    
    Link the of_node information in the serial controller device with the
    parent defined in the device tree. This will also apply to the serial
    device which takes the serial controller as a parent device.
    
    Fixes: b286f4e87e32 ("serial: core: Move tty and serdev to be children of serial core port device")
    Cc: [email protected]
    Signed-off-by: Aidan Stewart <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

serial: imx: Restore original RXTL for console to fix data loss [+ + +]
Author: Fabio Estevam <[email protected]>
Date:   Thu Jun 19 08:46:17 2025 -0300

    serial: imx: Restore original RXTL for console to fix data loss
    
    commit f23c52aafb1675ab1d1f46914556d8e29cbbf7b3 upstream.
    
    Commit 7a637784d517 ("serial: imx: reduce RX interrupt frequency")
    introduced a regression on the i.MX6UL EVK board. The issue can be
    reproduced with the following steps:
    
    - Open vi on the board.
    - Paste a text file (~150 characters).
    - Save the file, then repeat the process.
    - Compare the sha256sum of the saved files.
    
    The checksums do not match due to missing characters or entire lines.
    
    Fix this by restoring the RXTL value to 1 when the UART is used as a
    console.
    
    This ensures timely RX interrupts and reliable data reception in console
    mode.
    
    With this change, pasted content is saved correctly, and checksums are
    always consistent.
    
    Cc: stable <[email protected]>
    Fixes: 7a637784d517 ("serial: imx: reduce RX interrupt frequency")
    Signed-off-by: Fabio Estevam <[email protected]>
    Reviewed-by: Stefan Wahren <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
smb: client: fix potential deadlock when reconnecting channels [+ + +]
Author: Paulo Alcantara <[email protected]>
Date:   Wed Jun 25 12:22:38 2025 -0300

    smb: client: fix potential deadlock when reconnecting channels
    
    [ Upstream commit 711741f94ac3cf9f4e3aa73aa171e76d188c0819 ]
    
    Fix cifs_signal_cifsd_for_reconnect() to take the correct lock order
    and prevent the following deadlock from happening
    
    ======================================================
    WARNING: possible circular locking dependency detected
    6.16.0-rc3-build2+ #1301 Tainted: G S      W
    ------------------------------------------------------
    cifsd/6055 is trying to acquire lock:
    ffff88810ad56038 (&tcp_ses->srv_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x134/0x200
    
    but task is already holding lock:
    ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200
    
    which lock already depends on the new lock.
    
    the existing dependency chain (in reverse order) is:
    
    -> #2 (&ret_buf->chan_lock){+.+.}-{3:3}:
           validate_chain+0x1cf/0x270
           __lock_acquire+0x60e/0x780
           lock_acquire.part.0+0xb4/0x1f0
           _raw_spin_lock+0x2f/0x40
           cifs_setup_session+0x81/0x4b0
           cifs_get_smb_ses+0x771/0x900
           cifs_mount_get_session+0x7e/0x170
           cifs_mount+0x92/0x2d0
           cifs_smb3_do_mount+0x161/0x460
           smb3_get_tree+0x55/0x90
           vfs_get_tree+0x46/0x180
           do_new_mount+0x1b0/0x2e0
           path_mount+0x6ee/0x740
           do_mount+0x98/0xe0
           __do_sys_mount+0x148/0x180
           do_syscall_64+0xa4/0x260
           entry_SYSCALL_64_after_hwframe+0x76/0x7e
    
    -> #1 (&ret_buf->ses_lock){+.+.}-{3:3}:
           validate_chain+0x1cf/0x270
           __lock_acquire+0x60e/0x780
           lock_acquire.part.0+0xb4/0x1f0
           _raw_spin_lock+0x2f/0x40
           cifs_match_super+0x101/0x320
           sget+0xab/0x270
           cifs_smb3_do_mount+0x1e0/0x460
           smb3_get_tree+0x55/0x90
           vfs_get_tree+0x46/0x180
           do_new_mount+0x1b0/0x2e0
           path_mount+0x6ee/0x740
           do_mount+0x98/0xe0
           __do_sys_mount+0x148/0x180
           do_syscall_64+0xa4/0x260
           entry_SYSCALL_64_after_hwframe+0x76/0x7e
    
    -> #0 (&tcp_ses->srv_lock){+.+.}-{3:3}:
           check_noncircular+0x95/0xc0
           check_prev_add+0x115/0x2f0
           validate_chain+0x1cf/0x270
           __lock_acquire+0x60e/0x780
           lock_acquire.part.0+0xb4/0x1f0
           _raw_spin_lock+0x2f/0x40
           cifs_signal_cifsd_for_reconnect+0x134/0x200
           __cifs_reconnect+0x8f/0x500
           cifs_handle_standard+0x112/0x280
           cifs_demultiplex_thread+0x64d/0xbc0
           kthread+0x2f7/0x310
           ret_from_fork+0x2a/0x230
           ret_from_fork_asm+0x1a/0x30
    
    other info that might help us debug this:
    
    Chain exists of:
      &tcp_ses->srv_lock --> &ret_buf->ses_lock --> &ret_buf->chan_lock
    
     Possible unsafe locking scenario:
    
           CPU0                    CPU1
           ----                    ----
      lock(&ret_buf->chan_lock);
                                   lock(&ret_buf->ses_lock);
                                   lock(&ret_buf->chan_lock);
      lock(&tcp_ses->srv_lock);
    
     *** DEADLOCK ***
    
    3 locks held by cifsd/6055:
     #0: ffffffff857de398 (&cifs_tcp_ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x7b/0x200
     #1: ffff888119c64060 (&ret_buf->ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x9c/0x200
     #2: ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200
    
    Cc: [email protected]
    Reported-by: David Howells <[email protected]>
    Fixes: d7d7a66aacd6 ("cifs: avoid use of global locks for high contention data")
    Reviewed-by: David Howells <[email protected]>
    Tested-by: David Howells <[email protected]>
    Signed-off-by: Paulo Alcantara (Red Hat) <[email protected]>
    Signed-off-by: David Howells <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

smb: client: fix regression with native SMB symlinks [+ + +]
Author: Paulo Alcantara <[email protected]>
Date:   Sun Jun 22 14:13:40 2025 -0300

    smb: client: fix regression with native SMB symlinks
    
    commit ff8abbd248c1f52df0c321690b88454b13ff54b2 upstream.
    
    Some users and customers reported that their backup/copy tools started
    to fail when the directory being copied contained symlink targets that
    the client couldn't parse - even when those symlinks weren't followed.
    
    Fix this by allowing lstat(2) and readlink(2) to succeed even when the
    client can't resolve the symlink target, restoring old behavior.
    
    Cc: [email protected]
    Cc: [email protected]
    Reported-by: Remy Monsen <[email protected]>
    Closes: https://lore.kernel.org/r/CAN+tdP7y=jqw3pBndZAGjQv0ObFq8Q=+PUDHgB36HdEz9QA6FQ@mail.gmail.com
    Reported-by: Pierguido Lambri <[email protected]>
    Fixes: 12b466eb52d9 ("cifs: Fix creating and resolving absolute NT-style symlinks")
    Signed-off-by: Paulo Alcantara (Red Hat) <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

smb: client: remove \t from TP_printk statements [+ + +]
Author: Stefan Metzmacher <[email protected]>
Date:   Wed Jun 25 10:13:04 2025 +0200

    smb: client: remove \t from TP_printk statements
    
    commit e97f9540ce001503a4539f337da742c1dfa7d86a upstream.
    
    The generate '[FAILED TO PARSE]' strings in trace-cmd report output like this:
    
      rm-5298  [001]  6084.533748493: smb3_exit_err:        [FAILED TO PARSE] xid=972 func_name=cifs_rmdir rc=-39
      rm-5298  [001]  6084.533959234: smb3_enter:           [FAILED TO PARSE] xid=973 func_name=cifs_closedir
      rm-5298  [001]  6084.533967630: smb3_close_enter:     [FAILED TO PARSE] xid=973 fid=94489281833 tid=1 sesid=96758029877361
      rm-5298  [001]  6084.534004008: smb3_cmd_enter:       [FAILED TO PARSE] tid=1 sesid=96758029877361 cmd=6 mid=566
      rm-5298  [001]  6084.552248232: smb3_cmd_done:        [FAILED TO PARSE] tid=1 sesid=96758029877361 cmd=6 mid=566
      rm-5298  [001]  6084.552280542: smb3_close_done:      [FAILED TO PARSE] xid=973 fid=94489281833 tid=1 sesid=96758029877361
      rm-5298  [001]  6084.552316034: smb3_exit_done:       [FAILED TO PARSE] xid=973 func_name=cifs_closedir
    
    Cc: [email protected]
    Signed-off-by: Stefan Metzmacher <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
spi: spi-cadence-quadspi: Fix pm runtime unbalance [+ + +]
Author: Khairul Anuar Romli <[email protected]>
Date:   Mon Jun 16 09:13:53 2025 +0800

    spi: spi-cadence-quadspi: Fix pm runtime unbalance
    
    commit b07f349d1864abe29436f45e3047da2bdd476462 upstream.
    
    Having PM put sync in remove function is causing PM underflow during
    remove operation. This is caused by the function, runtime_pm_get_sync,
    not being called anywhere during the op. Ensure that calls to
    pm_runtime_enable()/pm_runtime_disable() and
    pm_runtime_get_sync()/pm_runtime_put_sync() match.
    
    echo 108d2000.spi > /sys/bus/platform/drivers/cadence-qspi/unbind
    [   49.644256] Deleting MTD partitions on "108d2000.spi.0":
    [   49.649575] Deleting u-boot MTD partition
    [   49.684087] Deleting root MTD partition
    [   49.724188] cadence-qspi 108d2000.spi: Runtime PM usage count underflow!
    
    Continuous bind/unbind will result in an "Unbalanced pm_runtime_enable" error.
    Subsequent unbind attempts will return a "No such device" error, while bind
    attempts will return a "Resource temporarily unavailable" error.
    
    [   47.592434] cadence-qspi 108d2000.spi: Runtime PM usage count underflow!
    [   49.592233] cadence-qspi 108d2000.spi: detected FIFO depth (1024) different from config (128)
    [   53.232309] cadence-qspi 108d2000.spi: Runtime PM usage count underflow!
    [   55.828550] cadence-qspi 108d2000.spi: detected FIFO depth (1024) different from config (128)
    [   57.940627] cadence-qspi 108d2000.spi: Runtime PM usage count underflow!
    [   59.912490] cadence-qspi 108d2000.spi: detected FIFO depth (1024) different from config (128)
    [   61.876243] cadence-qspi 108d2000.spi: Runtime PM usage count underflow!
    [   61.883000] platform 108d2000.spi: Unbalanced pm_runtime_enable!
    [  532.012270] cadence-qspi 108d2000.spi: probe with driver cadence-qspi failed1
    
    Also, change clk_disable_unprepare() to clk_disable() since continuous
    bind and unbind operations will trigger a warning indicating that the clock is
    already unprepared.
    
    Fixes: 4892b374c9b7 ("mtd: spi-nor: cadence-quadspi: Add runtime PM support")
    cc: [email protected] # 6.6+
    Signed-off-by: Khairul Anuar Romli <[email protected]>
    Reviewed-by: Matthew Gerlach <[email protected]>
    Link: https://patch.msgid.link/4e7a4b8aba300e629b45a04f90bddf665fbdb335.1749601877.git.khairul.anuar.romli@altera.com
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
staging: rtl8723bs: Avoid memset() in aes_cipher() and aes_decipher() [+ + +]
Author: Nathan Chancellor <[email protected]>
Date:   Mon Jun 9 14:13:14 2025 -0700

    staging: rtl8723bs: Avoid memset() in aes_cipher() and aes_decipher()
    
    commit a55bc4ffc06d8c965a7d6f0a01ed0ed41380df28 upstream.
    
    After commit 6f110a5e4f99 ("Disable SLUB_TINY for build testing"), which
    causes CONFIG_KASAN to be enabled in allmodconfig again, arm64
    allmodconfig builds with older versions of clang (15 through 17) show an
    instance of -Wframe-larger-than (which breaks the build with
    CONFIG_WERROR=y):
    
      drivers/staging/rtl8723bs/core/rtw_security.c:1287:5: error: stack frame size (2208) exceeds limit (2048) in 'rtw_aes_decrypt' [-Werror,-Wframe-larger-than]
       1287 | u32 rtw_aes_decrypt(struct adapter *padapter, u8 *precvframe)
            |     ^
    
    This comes from aes_decipher() being inlined in rtw_aes_decrypt().
    Running the same build with CONFIG_FRAME_WARN=128 shows aes_cipher()
    also uses a decent amount of stack, just under the limit of 2048:
    
      drivers/staging/rtl8723bs/core/rtw_security.c:864:19: warning: stack frame size (1952) exceeds limit (128) in 'aes_cipher' [-Wframe-larger-than]
        864 | static signed int aes_cipher(u8 *key, uint      hdrlen,
            |                   ^
    
    -Rpass-analysis=stack-frame-layout only shows one large structure on the
    stack, which is the ctx variable inlined from aes128k128d(). A good
    number of the other variables come from the additional checks of
    fortified string routines, which are present in memset(), which both
    aes_cipher() and aes_decipher() use to initialize some temporary
    buffers. In this case, since the size is known at compile time, these
    additional checks should not result in any code generation changes but
    allmodconfig has several sanitizers enabled, which may make it harder
    for the compiler to eliminate the compile time checks and the variables
    that come about from them.
    
    The memset() calls are just initializing these buffers to zero, so use
    '= {}' instead, which is used all over the kernel and does the exact
    same thing as memset() without the fortify checks, which drops the stack
    usage of these functions by a few hundred kilobytes.
    
      drivers/staging/rtl8723bs/core/rtw_security.c:864:19: warning: stack frame size (1584) exceeds limit (128) in 'aes_cipher' [-Wframe-larger-than]
        864 | static signed int aes_cipher(u8 *key, uint      hdrlen,
            |                   ^
      drivers/staging/rtl8723bs/core/rtw_security.c:1271:5: warning: stack frame size (1456) exceeds limit (128) in 'rtw_aes_decrypt' [-Wframe-larger-than]
       1271 | u32 rtw_aes_decrypt(struct adapter *padapter, u8 *precvframe)
            |     ^
    
    Cc: [email protected]
    Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
    Signed-off-by: Nathan Chancellor <[email protected]>
    Reviewed-by: Dan Carpenter <[email protected]>
    Link: https://lore.kernel.org/r/20250609-rtl8723bs-fix-clang-arm64-wflt-v1-1-e2accba43def@kernel.org
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
sunrpc: don't immediately retransmit on seqno miss [+ + +]
Author: Nikhil Jha <[email protected]>
Date:   Wed Mar 19 13:02:40 2025 -0400

    sunrpc: don't immediately retransmit on seqno miss
    
    [ Upstream commit fadc0f3bb2de8c570ced6d9c1f97222213d93140 ]
    
    RFC2203 requires that retransmitted messages use a new gss sequence
    number, but the same XID. This means that if the server is just slow
    (e.x. overloaded), the client might receive a response using an older
    seqno than the one it has recorded.
    
    Currently, Linux's client immediately retransmits in this case. However,
    this leads to a lot of wasted retransmits until the server eventually
    responds faster than the client can resend.
    
    Client -> SEQ 1 -> Server
    Client -> SEQ 2 -> Server
    Client <- SEQ 1 <- Server (misses, expecting seqno = 2)
    Client -> SEQ 3 -> Server (immediate retransmission on miss)
    Client <- SEQ 2 <- Server (misses, expecting seqno = 3)
    Client -> SEQ 4 -> Server (immediate retransmission on miss)
    ... and so on ...
    
    This commit makes it so that we ignore messages with bad checksums
    due to seqnum mismatch, and rely on the usual timeout behavior for
    retransmission instead of doing so immediately.
    
    Signed-off-by: Nikhil Jha <[email protected]>
    Acked-by: Chuck Lever <[email protected]>
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
tty: serial: uartlite: register uart driver in init [+ + +]
Author: Jakub Lewalski <[email protected]>
Date:   Mon Mar 31 18:06:19 2025 +0200

    tty: serial: uartlite: register uart driver in init
    
    [ Upstream commit 6bd697b5fc39fd24e2aa418c7b7d14469f550a93 ]
    
    When two instances of uart devices are probing, a concurrency race can
    occur. If one thread calls uart_register_driver function, which first
    allocates and assigns memory to 'uart_state' member of uart_driver
    structure, the other instance can bypass uart driver registration and
    call ulite_assign. This calls uart_add_one_port, which expects the uart
    driver to be fully initialized. This leads to a kernel panic due to a
    null pointer dereference:
    
    [    8.143581] BUG: kernel NULL pointer dereference, address: 00000000000002b8
    [    8.156982] #PF: supervisor write access in kernel mode
    [    8.156984] #PF: error_code(0x0002) - not-present page
    [    8.156986] PGD 0 P4D 0
    ...
    [    8.180668] RIP: 0010:mutex_lock+0x19/0x30
    [    8.188624] Call Trace:
    [    8.188629]  ? __die_body.cold+0x1a/0x1f
    [    8.195260]  ? page_fault_oops+0x15c/0x290
    [    8.209183]  ? __irq_resolve_mapping+0x47/0x80
    [    8.209187]  ? exc_page_fault+0x64/0x140
    [    8.209190]  ? asm_exc_page_fault+0x22/0x30
    [    8.209196]  ? mutex_lock+0x19/0x30
    [    8.223116]  uart_add_one_port+0x60/0x440
    [    8.223122]  ? proc_tty_register_driver+0x43/0x50
    [    8.223126]  ? tty_register_driver+0x1ca/0x1e0
    [    8.246250]  ulite_probe+0x357/0x4b0 [uartlite]
    
    To prevent it, move uart driver registration in to init function. This
    will ensure that uart_driver is always registered when probe function
    is called.
    
    Signed-off-by: Jakub Lewalski <[email protected]>
    Signed-off-by: Elodie Decerle <[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]>

 
um: Add cmpxchg8b_emu and checksum functions to asm-prototypes.h [+ + +]
Author: Sami Tolvanen <[email protected]>
Date:   Wed Mar 26 19:05:00 2025 +0000

    um: Add cmpxchg8b_emu and checksum functions to asm-prototypes.h
    
    [ Upstream commit 674d03f6bd6b0f8327f1a4920ff5893557facfbd ]
    
    With CONFIG_GENDWARFKSYMS, um builds fail due to missing prototypes
    in asm/asm-prototypes.h. Add declarations for cmpxchg8b_emu and the
    exported checksum functions, including csum_partial_copy_generic as
    it's also exported.
    
    Cc: Masahiro Yamada <[email protected]>
    Cc: [email protected]
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
    Signed-off-by: Sami Tolvanen <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

um: ubd: Add missing error check in start_io_thread() [+ + +]
Author: Tiwei Bie <[email protected]>
Date:   Fri Jun 6 20:44:25 2025 +0800

    um: ubd: Add missing error check in start_io_thread()
    
    [ Upstream commit c55c7a85e02a7bfee20a3ffebdff7cbeb41613ef ]
    
    The subsequent call to os_set_fd_block() overwrites the previous
    return value. OR the two return values together to fix it.
    
    Fixes: f88f0bdfc32f ("um: UBD Improvements")
    Signed-off-by: Tiwei Bie <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

um: use proper care when taking mmap lock during segfault [+ + +]
Author: Benjamin Berg <[email protected]>
Date:   Tue Apr 8 09:45:24 2025 +0200

    um: use proper care when taking mmap lock during segfault
    
    [ Upstream commit 6767e8784cd2e8b386a62330ea6864949d983a3e ]
    
    Segfaults can occur at times where the mmap lock cannot be taken. If
    that happens the segfault handler may not be able to take the mmap lock.
    
    Fix the code to use the same approach as most other architectures.
    Unfortunately, this requires copying code from mm/memory.c and modifying
    it slightly as UML does not have exception tables.
    
    Signed-off-by: Benjamin Berg <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
usb: Add checks for snprintf() calls in usb_alloc_dev() [+ + +]
Author: Andy Shevchenko <[email protected]>
Date:   Fri Mar 21 18:49:49 2025 +0200

    usb: Add checks for snprintf() calls in usb_alloc_dev()
    
    [ Upstream commit 82fe5107fa3d21d6c3fba091c9dbc50495588630 ]
    
    When creating a device path in the driver the snprintf() takes
    up to 16 characters long argument along with the additional up to
    12 characters for the signed integer (as it can't see the actual limits)
    and tries to pack this into 16 bytes array. GCC complains about that
    when build with `make W=1`:
    
      drivers/usb/core/usb.c:705:25: note: ‘snprintf’ output between 3 and 28 bytes into a destination of size 16
    
    Since everything works until now, let's just check for the potential
    buffer overflow and bail out. It is most likely a never happen situation,
    but at least it makes GCC happy.
    
    Signed-off-by: Andy Shevchenko <[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]>

usb: cdc-wdm: avoid setting WDM_READ for ZLP-s [+ + +]
Author: Robert Hodaszi <[email protected]>
Date:   Thu Apr 3 16:40:04 2025 +0200

    usb: cdc-wdm: avoid setting WDM_READ for ZLP-s
    
    [ Upstream commit 387602d8a75574fafb451b7a8215e78dfd67ee63 ]
    
    Don't set WDM_READ flag in wdm_in_callback() for ZLP-s, otherwise when
    userspace tries to poll for available data, it might - incorrectly -
    believe there is something available, and when it tries to non-blocking
    read it, it might get stuck in the read loop.
    
    For example this is what glib does for non-blocking read (briefly):
    
      1. poll()
      2. if poll returns with non-zero, starts a read data loop:
        a. loop on poll() (EINTR disabled)
        b. if revents was set, reads data
          I. if read returns with EINTR or EAGAIN, goto 2.a.
          II. otherwise return with data
    
    So if ZLP sets WDM_READ (#1), we expect data, and try to read it (#2).
    But as that was a ZLP, and we are doing non-blocking read, wdm_read()
    returns with EAGAIN (#2.b.I), so loop again, and try to read again
    (#2.a.).
    
    With glib, we might stuck in this loop forever, as EINTR is disabled
    (#2.a).
    
    Signed-off-by: Robert Hodaszi <[email protected]>
    Acked-by: Oliver Neukum <[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]>

usb: common: usb-conn-gpio: use a unique name for usb connector device [+ + +]
Author: Chance Yang <[email protected]>
Date:   Fri Apr 11 16:33:26 2025 +0800

    usb: common: usb-conn-gpio: use a unique name for usb connector device
    
    [ Upstream commit d4e5b10c55627e2f3fc9e5b337a28b4e2f02a55e ]
    
    The current implementation of the usb-conn-gpio driver uses a fixed
    "usb-charger" name for all USB connector devices. This causes conflicts
    in the power supply subsystem when multiple USB connectors are present,
    as duplicate names are not allowed.
    
    Use IDA to manage unique IDs for naming usb connectors (e.g.,
    usb-charger-0, usb-charger-1).
    
    Signed-off-by: Chance Yang <[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]>

usb: dwc2: also exit clock_gating when stopping udc while suspended [+ + +]
Author: Michael Grzeschik <[email protected]>
Date:   Thu Apr 17 19:40:17 2025 +0200

    usb: dwc2: also exit clock_gating when stopping udc while suspended
    
    [ Upstream commit af076a41f8a28faf9ceb9dd2d88aef2c202ef39a ]
    
    It is possible that the gadget will be disabled, while the udc is
    suspended. When enabling the udc in that case, the clock gating
    will not be enabled again. Leaving the phy unclocked. Even when the
    udc is not enabled, connecting this powered but not clocked phy leads
    to enumeration errors on the host side.
    
    To ensure that the clock gating will be in an valid state, we ensure
    that the clock gating will be enabled before stopping the udc.
    
    Signed-off-by: Michael Grzeschik <[email protected]>
    Acked-by: Minas Harutyunyan <[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]>

usb: gadget: f_hid: wake up readers on disable/unbind [+ + +]
Author: Peter Korsgaard <[email protected]>
Date:   Tue Mar 18 16:22:07 2025 +0100

    usb: gadget: f_hid: wake up readers on disable/unbind
    
    [ Upstream commit 937a8a3a8d46a3377b4195cd8f2aa656666ebc8b ]
    
    Similar to how it is done in the write path.
    
    Add a disabled flag to track the function state and use it to exit the read
    loops to ensure no readers get stuck when the function is disabled/unbound,
    protecting against corruption when the waitq and spinlocks are reinitialized
    in hidg_bind().
    
    Signed-off-by: Peter Korsgaard <[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]>

usb: potential integer overflow in usbg_make_tpg() [+ + +]
Author: Chen Yufeng <[email protected]>
Date:   Tue Apr 15 14:58:57 2025 +0800

    usb: potential integer overflow in usbg_make_tpg()
    
    [ Upstream commit 153874010354d050f62f8ae25cbb960c17633dc5 ]
    
    The variable tpgt in usbg_make_tpg() is defined as unsigned long and is
    assigned to tpgt->tport_tpgt, which is defined as u16. This may cause an
    integer overflow when tpgt is greater than USHRT_MAX (65535). I
    haven't tried to trigger it myself, but it is possible to trigger it
    by calling usbg_make_tpg() with a large value for tpgt.
    
    I modified the type of tpgt to match tpgt->tport_tpgt and adjusted the
    relevant code accordingly.
    
    This patch is similar to commit 59c816c1f24d ("vhost/scsi: potential
    memory corruption").
    
    Signed-off-by: Chen Yufeng <[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]>

usb: typec: displayport: Receive DP Status Update NAK request exit dp altmode [+ + +]
Author: Jos Wang <[email protected]>
Date:   Sun Feb 9 15:19:26 2025 +0800

    usb: typec: displayport: Receive DP Status Update NAK request exit dp altmode
    
    [ Upstream commit b4b38ffb38c91afd4dc387608db26f6fc34ed40b ]
    
    Although some Type-C DRD devices that do not support the DP Sink
    function (such as Huawei Mate 40Pro), the Source Port initiates
    Enter Mode CMD, but the device responds to Enter Mode ACK, the
    Source port then initiates DP Status Update CMD, and the device
    responds to DP Status Update NAK.
    
    As PD2.0 spec ("6.4.4.3.4 Enter Mode Command"),A DR_Swap Message
    Shall Not be sent during Modal Operation between the Port Partners.
    At this time, the source port initiates DR_Swap message through the
    "echo device > /sys/class/typec/port0/data_role" command to switch
    the data role from host to device. The device will initiate a Hard
    Reset for recovery, resulting in the failure of data role swap.
    
    Therefore, when DP Status Update NAK is received, Exit Mode CMD is
    initiated to exit the currently entered DP altmode.
    
    Signed-off-by: Jos Wang <[email protected]>
    Reviewed-by: Heikki Krogerus <[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]>

usb: typec: mux: do not return on EOPNOTSUPP in {mux, switch}_set [+ + +]
Author: Michael Grzeschik <[email protected]>
Date:   Fri Apr 4 00:21:01 2025 +0200

    usb: typec: mux: do not return on EOPNOTSUPP in {mux, switch}_set
    
    [ Upstream commit 0f7bbef1794dc87141897f804e5871a293aa174b ]
    
    Since the typec connectors can have many muxes or switches for different
    lanes (sbu, usb2, usb3) going into different modal states (usb2, usb3,
    audio, debug) all of them will be called on typec_switch_set and
    typec_mux_set. But not all of them will be handling the expected mode.
    
    If one of the mux or switch will come back with EOPTNOSUPP this is no
    reason to stop running through the next ones. Therefor we skip this
    particular error value and continue calling the next.
    
    Signed-off-by: Michael Grzeschik <[email protected]>
    Reviewed-by: Heikki Krogerus <[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]>

usb: typec: tcpci: Fix wakeup source leaks on device unbind [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Sun Apr 6 22:40:50 2025 +0200

    usb: typec: tcpci: Fix wakeup source leaks on device unbind
    
    [ Upstream commit 9fc5986fbcd7e1e63afb04be94cd4e8a536a4b04 ]
    
    Device can be unbound, so driver must also release memory for the wakeup
    source.
    
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Reviewed-by: Heikki Krogerus <[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]>

usb: typec: tipd: Fix wakeup source leaks on device unbind [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Sun Apr 6 22:40:51 2025 +0200

    usb: typec: tipd: Fix wakeup source leaks on device unbind
    
    [ Upstream commit aaa8f2e959341fd4a3ccf111500eb1e6176678e0 ]
    
    Device can be unbound, so driver must also release memory for the wakeup
    source.
    
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Reviewed-by: Heikki Krogerus <[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]>

 
Linux: userns and mnt_idmap leak in open_tree_attr(2) [+ + +]
Author: Al Viro <[email protected]>
Date:   Tue Jun 24 10:25:04 2025 -0400

    userns and mnt_idmap leak in open_tree_attr(2)
    
    [ Upstream commit 0748e553df0225754c316a92af3a77fdc057b358 ]
    
    Once want_mount_setattr() has returned a positive, it does require
    finish_mount_kattr() to release ->mnt_userns.  Failing do_mount_setattr()
    does not change that.
    
    As the result, we can end up leaking userns and possibly mnt_idmap as
    well.
    
    Fixes: c4a16820d901 ("fs: add open_tree_attr()")
    Reviewed-by: Christian Brauner <[email protected]>
    Signed-off-by: Al Viro <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
vsock/uapi: fix linux/vm_sockets.h userspace compilation errors [+ + +]
Author: Stefano Garzarella <[email protected]>
Date:   Mon Jun 23 12:00:53 2025 +0200

    vsock/uapi: fix linux/vm_sockets.h userspace compilation errors
    
    [ Upstream commit 22bbc1dcd0d6785fb390c41f0dd5b5e218d23bdd ]
    
    If a userspace application just include <linux/vm_sockets.h> will fail
    to build with the following errors:
    
        /usr/include/linux/vm_sockets.h:182:39: error: invalid application of ‘sizeof’ to incomplete type ‘struct sockaddr’
          182 |         unsigned char svm_zero[sizeof(struct sockaddr) -
              |                                       ^~~~~~
        /usr/include/linux/vm_sockets.h:183:39: error: ‘sa_family_t’ undeclared here (not in a function)
          183 |                                sizeof(sa_family_t) -
              |
    
    Include <sys/socket.h> for userspace (guarded by ifndef __KERNEL__)
    where `struct sockaddr` and `sa_family_t` are defined.
    We already do something similar in <linux/mptcp.h> and <linux/if.h>.
    
    Fixes: d021c344051a ("VSOCK: Introduce VM Sockets")
    Reported-by: Daan De Meyer <[email protected]>
    Signed-off-by: Stefano Garzarella <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
wifi: iwlwifi: mld: Move regulatory domain initialization [+ + +]
Author: Ilan Peer <[email protected]>
Date:   Wed Jun 4 06:13:21 2025 +0300

    wifi: iwlwifi: mld: Move regulatory domain initialization
    
    [ Upstream commit f81aa834bfa91c827f290b62a245e23c5ad2813c ]
    
    The regulatory domain information was initialized every time the
    FW was loaded and the device was restarted. This was unnecessary
    and useless as at this stage the wiphy channels information was
    not setup yet so while the regulatory domain was set to the wiphy,
    the channel information was not updated.
    
    In case that a specific MCC was configured during FW initialization
    then following updates with this MCC are ignored, and thus the
    wiphy channels information is left with information not matching
    the regulatory domain.
    
    This commit moves the regulatory domain initialization to after the
    operational firmware is started, i.e., after the wiphy channels were
    configured and the regulatory information is needed.
    
    Signed-off-by: Ilan Peer <[email protected]>
    Reviewed-by: Johannes Berg <[email protected]>
    Signed-off-by: Miri Korenblit <[email protected]>
    Link: https://patch.msgid.link/20250604061200.f138a7382093.I2fd8b3e99be13c2687da483e2cb1311ffb4fbfce@changeid
    Signed-off-by: Miri Korenblit <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mac80211: Add link iteration macro for link data [+ + +]
Author: Muna Sinada <[email protected]>
Date:   Tue Mar 25 14:31:23 2025 -0700

    wifi: mac80211: Add link iteration macro for link data
    
    [ Upstream commit f61c7b3d442bef91dd432d468d08f72eadcc3209 ]
    
    Currently before iterating through valid links we are utilizing
    open-coding when checking if vif valid_links is a non-zero value.
    
    Add new macro, for_each_link_data(), which iterates through link_id
    and checks if it is set on vif valid_links. If it is a valid link then
    access link data for that link id.
    
    Signed-off-by: Muna Sinada <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Johannes Berg <[email protected]>
    Stable-dep-of: d87c3ca0f8f1 ("wifi: mac80211: finish link init before RCU publish")
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mac80211: Create separate links for VLAN interfaces [+ + +]
Author: Muna Sinada <[email protected]>
Date:   Tue Mar 25 14:31:24 2025 -0700

    wifi: mac80211: Create separate links for VLAN interfaces
    
    [ Upstream commit 90233b0ad215efc9ea56a7c0b09021bcd4eea4ac ]
    
    Currently, MLD links for an AP_VLAN interface type is not fully
    supported.
    
    Add allocation of separate links for each VLAN interface and copy
    chanctx and chandef of AP bss to VLAN where necessary. Separate
    links are created because for Dynamic VLAN each link will have its own
    default_multicast_key.
    
    Signed-off-by: Muna Sinada <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Johannes Berg <[email protected]>
    Stable-dep-of: d87c3ca0f8f1 ("wifi: mac80211: finish link init before RCU publish")
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mac80211: finish link init before RCU publish [+ + +]
Author: Johannes Berg <[email protected]>
Date:   Tue Jun 24 13:07:49 2025 +0200

    wifi: mac80211: finish link init before RCU publish
    
    [ Upstream commit d87c3ca0f8f1ca4c25f2ed819e954952f4d8d709 ]
    
    Since the link/conf pointers can be accessed without any
    protection other than RCU, make sure the data is actually
    set up before publishing the structures.
    
    Fixes: b2e8434f1829 ("wifi: mac80211: set up/tear down client vif links properly")
    Link: https://patch.msgid.link/20250624130749.9a308b713c74.I4a80f5eead112a38730939ea591d2e275c721256@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mac80211: fix beacon interval calculation overflow [+ + +]
Author: Lachlan Hodges <[email protected]>
Date:   Sat Jun 21 22:32:09 2025 +1000

    wifi: mac80211: fix beacon interval calculation overflow
    
    [ Upstream commit 7a3750ff0f2e8fee338a9c168f429f6c37f0e820 ]
    
    As we are converting from TU to usecs, a beacon interval of
    100*1024 usecs will lead to integer wrapping. To fix change
    to use a u32.
    
    Fixes: 057d5f4ba1e4 ("mac80211: sync dtim_count to TSF")
    Signed-off-by: Lachlan Hodges <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
x86/fpu: Refactor xfeature bitmask update code for sigframe XSAVE [+ + +]
Author: Chang S. Bae <[email protected]>
Date:   Tue Apr 15 19:16:57 2025 -0700

    x86/fpu: Refactor xfeature bitmask update code for sigframe XSAVE
    
    commit 64e54461ab6e8524a8de4e63b7d1a3e4481b5cf3 upstream.
    
    Currently, saving register states in the signal frame, the legacy feature
    bits are always set in xregs_state->header->xfeatures. This code sequence
    can be generalized for reuse in similar cases.
    
    Refactor the logic to ensure a consistent approach across similar usages.
    
    Signed-off-by: Chang S. Bae <[email protected]>
    Signed-off-by: Ingo Molnar <[email protected]>
    Cc: Andy Lutomirski <[email protected]>
    Cc: H. Peter Anvin <[email protected]>
    Cc: Linus Torvalds <[email protected]>
    Cc: Oleg Nesterov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Cc: Ben Hutchings <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
x86/pkeys: Simplify PKRU update in signal frame [+ + +]
Author: Chang S. Bae <[email protected]>
Date:   Tue Apr 15 19:16:58 2025 -0700

    x86/pkeys: Simplify PKRU update in signal frame
    
    commit d1e420772cd1eb0afe5858619c73ce36f3e781a1 upstream.
    
    The signal delivery logic was modified to always set the PKRU bit in
    xregs_state->header->xfeatures by this commit:
    
        ae6012d72fa6 ("x86/pkeys: Ensure updated PKRU value is XRSTOR'd")
    
    However, the change derives the bitmask value using XGETBV(1), rather
    than simply updating the buffer that already holds the value. Thus, this
    approach induces an unnecessary dependency on XGETBV1 for PKRU handling.
    
    Eliminate the dependency by using the established helper function.
    Subsequently, remove the now-unused 'mask' argument.
    
    Signed-off-by: Chang S. Bae <[email protected]>
    Signed-off-by: Ingo Molnar <[email protected]>
    Cc: Andy Lutomirski <[email protected]>
    Cc: Aruna Ramakrishna <[email protected]>
    Cc: H. Peter Anvin <[email protected]>
    Cc: Linus Torvalds <[email protected]>
    Cc: Oleg Nesterov <[email protected]>
    Cc: Tony W Wang-oc <[email protected]>
    Cc: Dave Hansen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Cc: Ben Hutchings <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

    x86/traps: Initialize DR6 by writing its architectural reset value
    
    commit 5f465c148c61e876b6d6eacd8e8e365f2d47758f upstream.
    
    Initialize DR6 by writing its architectural reset value to avoid
    incorrectly zeroing DR6 to clear DR6.BLD at boot time, which leads
    to a false bus lock detected warning.
    
    The Intel SDM says:
    
      1) Certain debug exceptions may clear bits 0-3 of DR6.
    
      2) BLD induced #DB clears DR6.BLD and any other debug exception
         doesn't modify DR6.BLD.
    
      3) RTM induced #DB clears DR6.RTM and any other debug exception
         sets DR6.RTM.
    
      To avoid confusion in identifying debug exceptions, debug handlers
      should set DR6.BLD and DR6.RTM, and clear other DR6 bits before
      returning.
    
    The DR6 architectural reset value 0xFFFF0FF0, already defined as
    macro DR6_RESERVED, satisfies these requirements, so just use it to
    reinitialize DR6 whenever needed.
    
    Since clear_all_debug_regs() no longer zeros all debug registers,
    rename it to initialize_debug_regs() to better reflect its current
    behavior.
    
    Since debug_read_clear_dr6() no longer clears DR6, rename it to
    debug_read_reset_dr6() to better reflect its current behavior.
    
    Fixes: ebb1064e7c2e9 ("x86/traps: Handle #DB for bus lock")
    Reported-by: Sohil Mehta <[email protected]>
    Suggested-by: H. Peter Anvin (Intel) <[email protected]>
    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]>
    Tested-by: Sohil Mehta <[email protected]>
    Link: https://lore.kernel.org/lkml/[email protected]/
    Cc:[email protected]
    Link: https://lore.kernel.org/all/20250620231504.2676902-2-xin%40zytor.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>