- Linux-stable-mirror - lists.linaro.org

[syzbot ci] Re: Fix stale IOTLB entries for kernel address space

by syzbot ci

syzbot ci has tested the following series [v6] Fix stale IOTLB entries for kernel address space https://lore.kernel.org/all/20251014130437.1090448-1-baolu.lu@linux.intel.c… * [PATCH v6 1/7] mm: Add a ptdesc flag to mark kernel page tables * [PATCH v6 2/7] mm: Actually mark kernel page table pages * [PATCH v6 3/7] x86/mm: Use 'ptdesc' when freeing PMD pages * [PATCH v6 4/7] mm: Introduce pure page table freeing function * [PATCH v6 5/7] x86/mm: Use pagetable_free() * [PATCH v6 6/7] mm: Introduce deferred freeing for kernel page tables * [PATCH v6 7/7] iommu/sva: Invalidate stale IOTLB entries for kernel address space and found the following issues: * KASAN: use-after-free Read in pmd_set_huge * KASAN: use-after-free Read in vmap_range_noflush * PANIC: double fault in search_extable Full report is available here: https://ci.syzbot.org/series/9d75a765-d6b2-4839-8db9-2f2e64e78cdd *** KASAN: use-after-free Read in pmd_set_huge tree: torvalds URL: https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux base: 0d97f2067c166eb495771fede9f7b73999c67f66 arch: amd64 compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8 config: https://ci.syzbot.org/builds/68e38247-432a-45b2-b187-a533b7040841/config syz repro: https://ci.syzbot.org/findings/ce54ec93-1f21-4deb-b2f8-d34917bd1be2/syz_rep… ================================================================== BUG: KASAN: use-after-free in pmd_set_huge+0xd8/0x340 arch/x86/mm/pgtable.c:676 Read of size 8 at addr ffff888100efa960 by task syz.0.20/5965 CPU: 1 UID: 0 PID: 5965 Comm: syz.0.20 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 pmd_set_huge+0xd8/0x340 arch/x86/mm/pgtable.c:676 vmap_try_huge_pmd mm/vmalloc.c:161 [inline] vmap_pmd_range mm/vmalloc.c:177 [inline] vmap_pud_range mm/vmalloc.c:233 [inline] vmap_p4d_range mm/vmalloc.c:284 [inline] vmap_range_noflush+0x7b3/0xf80 mm/vmalloc.c:308 __vmap_pages_range_noflush+0xd31/0xf30 mm/vmalloc.c:661 vmap_pages_range_noflush mm/vmalloc.c:681 [inline] vmap_pages_range mm/vmalloc.c:701 [inline] __vmalloc_area_node mm/vmalloc.c:3766 [inline] __vmalloc_node_range_noprof+0xe8c/0x12d0 mm/vmalloc.c:3897 __kvmalloc_node_noprof+0x674/0x910 mm/slub.c:7058 nf_tables_newset+0x1330/0x2540 net/netfilter/nf_tables_api.c:5548 nfnetlink_rcv_batch net/netfilter/nfnetlink.c:526 [inline] nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:649 [inline] nfnetlink_rcv+0x11d9/0x2590 net/netfilter/nfnetlink.c:667 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0x82f/0x9e0 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 ____sys_sendmsg+0x505/0x830 net/socket.c:2630 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2684 __sys_sendmsg net/socket.c:2716 [inline] __do_sys_sendmsg net/socket.c:2721 [inline] __se_sys_sendmsg net/socket.c:2719 [inline] __x64_sys_sendmsg+0x19b/0x260 net/socket.c:2719 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fc5fff8eec9 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:00007fc600ecb038 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007fc6001e5fa0 RCX: 00007fc5fff8eec9 RDX: 0000000004008100 RSI: 00002000000000c0 RDI: 0000000000000003 RBP: 00007fc600011f91 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fc6001e6038 R14: 00007fc6001e5fa0 R15: 00007ffed63a0428 </TASK> The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x100efa flags: 0x17ff00000000000(node=0|zone=2|lastcpupid=0x7ff) raw: 017ff00000000000 ffffea0004772f88 ffff88823c6403a0 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as freed page last allocated via order 0, migratetype Unmovable, gfp_mask 0x40100(__GFP_ZERO|__GFP_COMP), pid 0, tgid 0 (swapper/0), ts 1659724794, free_ts 71235002142 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x240/0x2a0 mm/page_alloc.c:1850 prep_new_page mm/page_alloc.c:1858 [inline] get_page_from_freelist+0x2365/0x2440 mm/page_alloc.c:3884 __alloc_frozen_pages_noprof+0x181/0x370 mm/page_alloc.c:5183 alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2416 alloc_frozen_pages_noprof mm/mempolicy.c:2487 [inline] alloc_pages_noprof+0xa9/0x190 mm/mempolicy.c:2507 pagetable_alloc_noprof include/linux/mm.h:3016 [inline] pmd_alloc_one_noprof include/asm-generic/pgalloc.h:144 [inline] __pmd_alloc+0x3a/0x5d0 mm/memory.c:6573 pmd_alloc_track mm/pgalloc-track.h:37 [inline] vmap_pages_pmd_range mm/vmalloc.c:564 [inline] vmap_pages_pud_range mm/vmalloc.c:587 [inline] vmap_pages_p4d_range mm/vmalloc.c:605 [inline] vmap_small_pages_range_noflush mm/vmalloc.c:627 [inline] __vmap_pages_range_noflush+0x9cc/0xf30 mm/vmalloc.c:656 vmap_pages_range_noflush mm/vmalloc.c:681 [inline] vmap_pages_range mm/vmalloc.c:701 [inline] vmap+0x1ca/0x310 mm/vmalloc.c:3521 map_irq_stack arch/x86/kernel/irq_64.c:49 [inline] irq_init_percpu_irqstack+0x342/0x4a0 arch/x86/kernel/irq_64.c:76 init_IRQ+0x15c/0x1c0 arch/x86/kernel/irqinit.c:90 start_kernel+0x1cd/0x410 init/main.c:1016 x86_64_start_reservations+0x24/0x30 arch/x86/kernel/head64.c:310 x86_64_start_kernel+0x143/0x1c0 arch/x86/kernel/head64.c:291 common_startup_64+0x13e/0x147 page last free pid 5965 tgid 5964 stack trace: reset_page_owner include/linux/page_owner.h:25 [inline] free_pages_prepare mm/page_alloc.c:1394 [inline] __free_frozen_pages+0xbc4/0xd30 mm/page_alloc.c:2906 pmd_free_pte_page+0xa1/0xc0 arch/x86/mm/pgtable.c:783 vmap_try_huge_pmd mm/vmalloc.c:158 [inline] vmap_pmd_range mm/vmalloc.c:177 [inline] vmap_pud_range mm/vmalloc.c:233 [inline] vmap_p4d_range mm/vmalloc.c:284 [inline] vmap_range_noflush+0x774/0xf80 mm/vmalloc.c:308 __vmap_pages_range_noflush+0xd31/0xf30 mm/vmalloc.c:661 vmap_pages_range_noflush mm/vmalloc.c:681 [inline] vmap_pages_range mm/vmalloc.c:701 [inline] __vmalloc_area_node mm/vmalloc.c:3766 [inline] __vmalloc_node_range_noprof+0xe8c/0x12d0 mm/vmalloc.c:3897 __kvmalloc_node_noprof+0x674/0x910 mm/slub.c:7058 nf_tables_newset+0x1330/0x2540 net/netfilter/nf_tables_api.c:5548 nfnetlink_rcv_batch net/netfilter/nfnetlink.c:526 [inline] nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:649 [inline] nfnetlink_rcv+0x11d9/0x2590 net/netfilter/nfnetlink.c:667 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0x82f/0x9e0 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 ____sys_sendmsg+0x505/0x830 net/socket.c:2630 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2684 __sys_sendmsg net/socket.c:2716 [inline] __do_sys_sendmsg net/socket.c:2721 [inline] __se_sys_sendmsg net/socket.c:2719 [inline] __x64_sys_sendmsg+0x19b/0x260 net/socket.c:2719 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Memory state around the buggy address: ffff888100efa800: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888100efa880: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff888100efa900: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff888100efa980: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888100efaa00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== *** KASAN: use-after-free Read in vmap_range_noflush tree: torvalds URL: https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux base: 0d97f2067c166eb495771fede9f7b73999c67f66 arch: amd64 compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8 config: https://ci.syzbot.org/builds/68e38247-432a-45b2-b187-a533b7040841/config C repro: https://ci.syzbot.org/findings/b676cfe4-8c9a-435c-aa8f-7315912fa378/c_repro syz repro: https://ci.syzbot.org/findings/b676cfe4-8c9a-435c-aa8f-7315912fa378/syz_rep… ================================================================== BUG: KASAN: use-after-free in vmap_try_huge_pmd mm/vmalloc.c:158 [inline] BUG: KASAN: use-after-free in vmap_pmd_range mm/vmalloc.c:177 [inline] BUG: KASAN: use-after-free in vmap_pud_range mm/vmalloc.c:233 [inline] BUG: KASAN: use-after-free in vmap_p4d_range mm/vmalloc.c:284 [inline] BUG: KASAN: use-after-free in vmap_range_noflush+0x743/0xf80 mm/vmalloc.c:308 Read of size 8 at addr ffff888100efa128 by task syz.0.17/5955 CPU: 1 UID: 0 PID: 5955 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 vmap_try_huge_pmd mm/vmalloc.c:158 [inline] vmap_pmd_range mm/vmalloc.c:177 [inline] vmap_pud_range mm/vmalloc.c:233 [inline] vmap_p4d_range mm/vmalloc.c:284 [inline] vmap_range_noflush+0x743/0xf80 mm/vmalloc.c:308 __vmap_pages_range_noflush+0xd31/0xf30 mm/vmalloc.c:661 vmap_pages_range_noflush mm/vmalloc.c:681 [inline] vmap_pages_range mm/vmalloc.c:701 [inline] __vmalloc_area_node mm/vmalloc.c:3766 [inline] __vmalloc_node_range_noprof+0xe8c/0x12d0 mm/vmalloc.c:3897 __kvmalloc_node_noprof+0x674/0x910 mm/slub.c:7058 kvmalloc_array_node_noprof include/linux/slab.h:1122 [inline] bpf_uprobe_multi_link_attach+0x54b/0xee0 kernel/trace/bpf_trace.c:3228 link_create+0x673/0x850 kernel/bpf/syscall.c:5721 __sys_bpf+0x6be/0x860 kernel/bpf/syscall.c:6204 __do_sys_bpf kernel/bpf/syscall.c:6244 [inline] __se_sys_bpf kernel/bpf/syscall.c:6242 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:6242 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f3d8e78eec9 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:00007f3d8f64c038 EFLAGS: 00000246 ORIG_RAX: 0000000000000141 RAX: ffffffffffffffda RBX: 00007f3d8e9e5fa0 RCX: 00007f3d8e78eec9 RDX: 0000000000000040 RSI: 00002000000005c0 RDI: 000000000000001c RBP: 00007f3d8e811f91 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f3d8e9e6038 R14: 00007f3d8e9e5fa0 R15: 00007ffe8caa72c8 </TASK> The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x100efa flags: 0x17ff00000000000(node=0|zone=2|lastcpupid=0x7ff) raw: 017ff00000000000 ffffea00044109c8 ffff88823c6403a0 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as freed page last allocated via order 0, migratetype Unmovable, gfp_mask 0x40100(__GFP_ZERO|__GFP_COMP), pid 0, tgid 0 (swapper/0), ts 1684936790, free_ts 91274246476 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x240/0x2a0 mm/page_alloc.c:1850 prep_new_page mm/page_alloc.c:1858 [inline] get_page_from_freelist+0x2365/0x2440 mm/page_alloc.c:3884 __alloc_frozen_pages_noprof+0x181/0x370 mm/page_alloc.c:5183 alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2416 alloc_frozen_pages_noprof mm/mempolicy.c:2487 [inline] alloc_pages_noprof+0xa9/0x190 mm/mempolicy.c:2507 pagetable_alloc_noprof include/linux/mm.h:3016 [inline] pmd_alloc_one_noprof include/asm-generic/pgalloc.h:144 [inline] __pmd_alloc+0x3a/0x5d0 mm/memory.c:6573 pmd_alloc_track mm/pgalloc-track.h:37 [inline] vmap_pages_pmd_range mm/vmalloc.c:564 [inline] vmap_pages_pud_range mm/vmalloc.c:587 [inline] vmap_pages_p4d_range mm/vmalloc.c:605 [inline] vmap_small_pages_range_noflush mm/vmalloc.c:627 [inline] __vmap_pages_range_noflush+0x9cc/0xf30 mm/vmalloc.c:656 vmap_pages_range_noflush mm/vmalloc.c:681 [inline] vmap_pages_range mm/vmalloc.c:701 [inline] vmap+0x1ca/0x310 mm/vmalloc.c:3521 map_irq_stack arch/x86/kernel/irq_64.c:49 [inline] irq_init_percpu_irqstack+0x342/0x4a0 arch/x86/kernel/irq_64.c:76 init_IRQ+0x15c/0x1c0 arch/x86/kernel/irqinit.c:90 start_kernel+0x1cd/0x410 init/main.c:1016 x86_64_start_reservations+0x24/0x30 arch/x86/kernel/head64.c:310 x86_64_start_kernel+0x143/0x1c0 arch/x86/kernel/head64.c:291 common_startup_64+0x13e/0x147 page last free pid 5892 tgid 5892 stack trace: reset_page_owner include/linux/page_owner.h:25 [inline] free_pages_prepare mm/page_alloc.c:1394 [inline] __free_frozen_pages+0xbc4/0xd30 mm/page_alloc.c:2906 __pagetable_free include/linux/mm.h:3026 [inline] kernel_pgtable_work_func+0x276/0x2e0 mm/pgtable-generic.c:436 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Memory state around the buggy address: ffff888100efa000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888100efa080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff888100efa100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff888100efa180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888100efa200: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== *** PANIC: double fault in search_extable tree: torvalds URL: https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux base: 0d97f2067c166eb495771fede9f7b73999c67f66 arch: amd64 compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8 config: https://ci.syzbot.org/builds/68e38247-432a-45b2-b187-a533b7040841/config syz repro: https://ci.syzbot.org/findings/967ed946-aab2-484a-8267-954586f5962b/syz_rep… traps: PANIC: double fault, error_code: 0x0 Oops: double fault: 0000 [#1] SMP KASAN PTI CPU: 1 UID: 0 PID: 5921 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:search_extable+0x69/0xd0 lib/extable.c:115 Code: 8d 48 c7 44 24 10 20 50 40 8b 49 89 e5 49 c1 ed 03 48 b8 f1 f1 f1 f1 00 f3 f3 f3 49 bc 00 00 00 00 00 fc ff df 4b 89 44 25 00 <e8> 12 45 7f f6 48 89 5c 24 20 b9 0c 00 00 00 48 8d 7c 24 20 4c 89 RSP: 0018:ffffc90003e5f000 EFLAGS: 00010806 RAX: f3f3f300f1f1f1f1 RBX: ffffffff8b4b123e RCX: 0000000000001c56 RDX: ffffffff8b4b123e RSI: 0000000000000972 RDI: ffffffff8dc137d0 RBP: ffffc90003e5f0a0 R08: 0000000000000001 R09: 0000000000000002 R10: 0000000000000011 R11: 0000000000000000 R12: dffffc0000000000 R13: 1ffff920007cbe00 R14: 0000000000000972 R15: ffffffff8dc137d0 FS: 000055558b2ef500(0000) GS:ffff8882a9d0f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc90003e5eff8 CR3: 00000001ba5ea000 CR4: 00000000000006f0 Call Trace: <TASK> search_kernel_exception_table kernel/extable.c:49 [inline] search_exception_tables+0x3a/0x60 kernel/extable.c:58 fixup_exception+0xb1/0x20b0 arch/x86/mm/extable.c:319 kernelmode_fixup_or_oops+0x68/0xf0 arch/x86/mm/fault.c:726 __bad_area_nosemaphore+0x11a/0x780 arch/x86/mm/fault.c:783 handle_page_fault arch/x86/mm/fault.c:1474 [inline] exc_page_fault+0xcf/0x100 arch/x86/mm/fault.c:1532 asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:623 RIP: 0010:in_irq_stack arch/x86/kernel/dumpstack_64.c:165 [inline] RIP: 0010:get_stack_info_noinstr+0xee/0x130 arch/x86/kernel/dumpstack_64.c:182 Code: 08 48 8d 90 08 80 ff ff 49 39 d7 40 0f 92 c6 49 39 cf 40 0f 93 c7 40 08 f7 75 27 41 c7 06 02 00 00 00 49 89 56 08 49 89 4e 10 <48> 8b 00 49 89 46 18 89 d8 5b 41 5c 41 5d 41 5e 41 5f e9 8b 12 03 RSP: 0018:ffffc90003e5f470 EFLAGS: 00010046 RAX: ffffc90000a08ff8 RBX: ffff88816ac1ba01 RCX: ffffc90000a09000 RDX: ffffc90000a01000 RSI: ffffffff8d837700 RDI: ffffffff8bc07500 RBP: ffffc90003e5f630 R08: ffffc90003e5f500 R09: 0000000000000000 R10: ffffc90003e5f5a0 R11: fffff520007cbeb8 R12: ffff88816ac1ba00 R13: fffffe000004f000 R14: ffffc90003e5f5a0 R15: ffffc90000a08ff8 get_stack_guard_info arch/x86/include/asm/stacktrace.h:45 [inline] page_fault_oops+0x12a/0xa10 arch/x86/mm/fault.c:663 __bad_area_nosemaphore+0x11a/0x780 arch/x86/mm/fault.c:783 handle_page_fault arch/x86/mm/fault.c:1474 [inline] exc_page_fault+0xcf/0x100 arch/x86/mm/fault.c:1532 asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:623 RIP: 0010:instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1052 [inline] RIP: 0010:sysvec_apic_timer_interrupt+0x8e/0xc0 arch/x86/kernel/apic/apic.c:1052 Code: 00 00 48 c7 c7 c0 b4 67 8b e8 ae 23 00 00 65 c6 05 50 d7 45 07 01 48 c7 c7 a0 b4 67 8b e8 9a 23 00 00 65 4c 8b 1d 02 d7 45 07 <49> 89 23 4c 89 dc e8 77 23 39 f6 48 89 df e8 4f 2f 25 f6 e8 8a 24 RSP: 0018:ffffc90003e5f830 EFLAGS: 00010082 RAX: 0000000000000001 RBX: ffffc90003e5f848 RCX: 4d01a0d08cb75600 RDX: 0000000000000000 RSI: ffffffff8b67b4a0 RDI: ffffffff8bc07560 RBP: 0000000000000000 R08: ffffffff8f9e1177 R09: 1ffffffff1f3c22e R10: dffffc0000000000 R11: ffffc90000a08ff8 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702 RIP: 0010:check_preemption_disabled+0x0/0x120 lib/smp_processor_id.c:13 Code: c7 00 75 c0 8b 48 c7 c6 40 75 c0 8b eb 1c 66 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 <55> 41 57 41 56 53 48 83 ec 10 65 48 8b 05 ae b4 45 07 48 89 44 24 RSP: 0018:ffffc90003e5f8f0 EFLAGS: 00000282 RAX: 0000000000000000 RBX: 00007f5f1858e627 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: ffffffff8bc07540 RDI: ffffffff8bc07500 RBP: 0000000000000001 R08: 0000000000000022 R09: ffffffff81731d25 R10: ffffc90003e5f9b8 R11: ffffffff81abbe80 R12: ffff88816ac1ba00 R13: dffffc0000000000 R14: dffffc0000000000 R15: 1ffff920007cbf36 rcu_is_watching_curr_cpu include/linux/context_tracking.h:128 [inline] rcu_is_watching+0x15/0xb0 kernel/rcu/tree.c:751 kernel_text_address+0x80/0xe0 kernel/extable.c:113 __kernel_text_address+0xd/0x40 kernel/extable.c:79 unwind_get_return_address+0x4d/0x90 arch/x86/kernel/unwind_orc.c:369 arch_stack_walk+0xfc/0x150 arch/x86/kernel/stacktrace.c:26 stack_trace_save+0x9c/0xe0 kernel/stacktrace.c:122 ref_tracker_free+0xef/0x7d0 lib/ref_tracker.c:307 __netns_tracker_free include/net/net_namespace.h:379 [inline] put_net_track include/net/net_namespace.h:394 [inline] __sk_destruct+0x3c3/0x660 net/core/sock.c:2368 sock_put include/net/sock.h:1972 [inline] unix_release_sock+0xa7b/0xd50 net/unix/af_unix.c:732 unix_release+0x92/0xd0 net/unix/af_unix.c:1196 __sock_release net/socket.c:662 [inline] sock_close+0xc3/0x240 net/socket.c:1455 __fput+0x44c/0xa70 fs/file_table.c:468 fput_close_sync+0x119/0x200 fs/file_table.c:573 __do_sys_close fs/open.c:1589 [inline] __se_sys_close fs/open.c:1574 [inline] __x64_sys_close+0x7f/0x110 fs/open.c:1574 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f5f1858e627 Code: 44 00 00 48 c7 c2 a8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb bc 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 01 c3 48 c7 c2 a8 ff ff ff f7 d8 64 89 02 b8 RSP: 002b:00007ffec60e5be8 EFLAGS: 00000246 ORIG_RAX: 0000000000000003 RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007f5f1858e627 RDX: 0000000000000000 RSI: 0000000000008933 RDI: 0000000000000005 RBP: 00007ffec60e5bf0 R08: 000000000000000a R09: 0000000000000001 R10: 000000000000000f R11: 0000000000000246 R12: 0000000000000024 R13: 000000000000002d R14: 00007f5f19314620 R15: 0000000000000024 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:search_extable+0x69/0xd0 lib/extable.c:115 Code: 8d 48 c7 44 24 10 20 50 40 8b 49 89 e5 49 c1 ed 03 48 b8 f1 f1 f1 f1 00 f3 f3 f3 49 bc 00 00 00 00 00 fc ff df 4b 89 44 25 00 <e8> 12 45 7f f6 48 89 5c 24 20 b9 0c 00 00 00 48 8d 7c 24 20 4c 89 RSP: 0018:ffffc90003e5f000 EFLAGS: 00010806 RAX: f3f3f300f1f1f1f1 RBX: ffffffff8b4b123e RCX: 0000000000001c56 RDX: ffffffff8b4b123e RSI: 0000000000000972 RDI: ffffffff8dc137d0 RBP: ffffc90003e5f0a0 R08: 0000000000000001 R09: 0000000000000002 R10: 0000000000000011 R11: 0000000000000000 R12: dffffc0000000000 R13: 1ffff920007cbe00 R14: 0000000000000972 R15: ffffffff8dc137d0 FS: 000055558b2ef500(0000) GS:ffff8882a9d0f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc90003e5eff8 CR3: 00000001ba5ea000 CR4: 00000000000006f0 ---------------- Code disassembly (best guess): 0: 8d 48 c7 lea -0x39(%rax),%ecx 3: 44 24 10 rex.R and $0x10,%al 6: 20 50 40 and %dl,0x40(%rax) 9: 8b 49 89 mov -0x77(%rcx),%ecx c: e5 49 in $0x49,%eax e: c1 ed 03 shr $0x3,%ebp 11: 48 b8 f1 f1 f1 f1 00 movabs $0xf3f3f300f1f1f1f1,%rax 18: f3 f3 f3 1b: 49 bc 00 00 00 00 00 movabs $0xdffffc0000000000,%r12 22: fc ff df 25: 4b 89 44 25 00 mov %rax,0x0(%r13,%r12,1) * 2a: e8 12 45 7f f6 call 0xf67f4541 <-- trapping instruction 2f: 48 89 5c 24 20 mov %rbx,0x20(%rsp) 34: b9 0c 00 00 00 mov $0xc,%ecx 39: 48 8d 7c 24 20 lea 0x20(%rsp),%rdi 3e: 4c rex.WR 3f: 89 .byte 0x89 *** If these findings have caused you to resend the series or submit a separate fix, please add the following tag to your commit message: Tested-by: syzbot(a)syzkaller.appspotmail.com --- This report is generated by a bot. It may contain errors. syzbot ci engineers can be reached at syzkaller(a)googlegroups.com.

2 months

4
6
0 0

[DISCUSSION] Fixing bad pmd due to a race condition between change_prot_numa() and THP migration in pre-6.5 kernels.

by Harry Yoo

Hi. This is supposed to be a patch, but I think it's worth discussing how it should be backported to -stable, so I've labeled it as [DISCUSSION]. The bug described below was unintentionally fixed in v6.5 and not backported to -stable. So technically I would need to use "Option 3" [A], but since the original patch [B] did not intend to fix a bug (and it's also part of a larger patch series), it looks quite different from the patch below, and I'm not sure what the backport should look like. I think there are probably two options: 1. Provide the description of the original patch along with a very long, detailed explanation of why the patch deviates from the upstream version, or 2. Post the patch below with a clarification that it was fixed upstream by commit 670ddd8cdcbd1. Any thoughts? [A] https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html#opt… [B] https://lkml.kernel.org/r/725a42a9-91e9-c868-925-e3a5fd40bb4f@google.com (Upstream commit 670ddd8cdcbd1) In any case, no matter how we backport this, it needs some review and feedback would be appreciated. The patch applies to v6.1 and v5.15, and v5.10 but not v5.4. From cf45867ab8e48b42160b7253390db7bdecef1455 Mon Sep 17 00:00:00 2001 From: Harry Yoo <harry.yoo(a)oracle.com> Date: Thu, 11 Sep 2025 20:05:40 +0900 Subject: [PATCH] mm, numa: fix bad pmd by atomically checking is_swap_pmd() in change_prot_numa() It was observed that a bad pmd is seen when automatic NUMA balancing is marking page table entries as prot_numa: [2437548.196018] mm/pgtable-generic.c:50: bad pmd 00000000af22fc02(dffffffe71fbfe02) With some kernel modification, the call stack was dumped: [2437548.235022] Call Trace: [2437548.238234] <TASK> [2437548.241060] dump_stack_lvl+0x46/0x61 [2437548.245689] panic+0x106/0x2e5 [2437548.249497] pmd_clear_bad+0x3c/0x3c [2437548.253967] change_pmd_range.isra.0+0x34d/0x3a7 [2437548.259537] change_p4d_range+0x156/0x20e [2437548.264392] change_protection_range+0x116/0x1a9 [2437548.269976] change_prot_numa+0x15/0x37 [2437548.274774] task_numa_work+0x1b8/0x302 [2437548.279512] task_work_run+0x62/0x95 [2437548.283882] exit_to_user_mode_loop+0x1a4/0x1a9 [2437548.289277] exit_to_user_mode_prepare+0xf4/0xfc [2437548.294751] ? sysvec_apic_timer_interrupt+0x34/0x81 [2437548.300677] irqentry_exit_to_user_mode+0x5/0x25 [2437548.306153] asm_sysvec_apic_timer_interrupt+0x16/0x1b This is due to a race condition between change_prot_numa() and THP migration because the kernel doesn't check is_swap_pmd() and pmd_trans_huge() atomically: change_prot_numa() THP migration ====================================================================== - change_pmd_range() -> is_swap_pmd() returns false, meaning it's not a PMD migration entry. - do_huge_pmd_numa_page() -> migrate_misplaced_page() sets migration entries for the THP. - change_pmd_range() -> pmd_none_or_clear_bad_unless_trans_huge() -> pmd_none() and pmd_trans_huge() returns false - pmd_none_or_clear_bad_unless_trans_huge() -> pmd_bad() returns true for the migration entry! For the race condition described above to occur: 1) AutoNUMA must be unmapping a range of pages, with at least part of the range already unmapped by AutoNUMA. 2) While AutoNUMA is in the process of unmapping, a NUMA hinting fault occurs within that range, specifically when we are about to unmap the PMD entry, between the is_swap_pmd() and pmd_trans_huge() checks. So this is a really rare race condition and it's observed that it takes usually a few days of autonuma-intensive testing to trigger. A bit of history on a similar race condition in the past: In fact, a similar race condition caused by not checking pmd_trans_huge() atomically was reported [1] in 2017. However, instead of the patch [1], another patch series [3] fixed the problem [2] by not clearing the pmd entry but invaliding it instead (so that pmd_trans_huge() would still return true). Despite patch series [3], the bad pmd error continued to be reported in mainline. As a result, [1] was resurrected [4] and it landed mainline in 2020 in a hope that it would resolve the issue. However, now it turns out that [3] was not sufficient. Fix this race condition by checking is_swap_pmd() and pmd_trans_huge() atomically. With that, the kernel should see either pmd_trans_huge() == true, or is_swap_pmd() == true when another task is migrating the page concurrently. This bug was introduced when THP migration support was added. More specifically, by commit 84c3fc4e9c56 ("mm: thp: check pmd migration entry in common path")). It is unintentionally fixed since v6.5 by commit 670ddd8cdcbd1 ("mm/mprotect: delete pmd_none_or_clear_bad_unless_trans_huge()") while removing pmd_none_or_clear_bad_unless_trans_huge() function. But it's not backported to -stable because it was fixed unintentionally. Link: https://lore.kernel.org/linux-mm/20170410094825.2yfo5zehn7pchg6a@techsingul… [1] Link: https://lore.kernel.org/linux-mm/8A6309F4-DB76-48FA-BE7F-BF9536A4C4E5@cs.ru… [2] Link: https://lore.kernel.org/linux-mm/20170302151034.27829-1-kirill.shutemov@lin… [3] Link: https://lore.kernel.org/linux-mm/20200216191800.22423-1-aquini@redhat.com [4] Fixes: 84c3fc4e9c56 ("mm: thp: check pmd migration entry in common path") Signed-off-by: Harry Yoo <harry.yoo(a)oracle.com> --- mm/mprotect.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mm/mprotect.c b/mm/mprotect.c index 668bfaa6ed2a..c0e796c0f9b0 100644 --- a/mm/mprotect.c +++ b/mm/mprotect.c @@ -303,7 +303,7 @@ static inline int pmd_none_or_clear_bad_unless_trans_huge(pmd_t *pmd) if (pmd_none(pmdval)) return 1; - if (pmd_trans_huge(pmdval)) + if (is_swap_pmd(pmdval) || pmd_trans_huge(pmdval)) return 0; if (unlikely(pmd_bad(pmdval))) { pmd_clear_bad(pmd); @@ -373,7 +373,7 @@ static inline unsigned long change_pmd_range(struct mmu_gather *tlb, * Hence, it's necessary to atomically read the PMD value * for all the checks. */ - if (!is_swap_pmd(*pmd) && !pmd_devmap(*pmd) && + if (!pmd_devmap(*pmd) && pmd_none_or_clear_bad_unless_trans_huge(pmd)) goto next; -- 2.43.0

2 months

2
9
0 0

[PATCH 6.12.y] drm/amd/display: fix dmub access race condition

by Timothy Pearson

From: Aurabindo Pillai <aurabindo.pillai(a)amd.com> Justificiation: This fixes DisplayPort lockups on Polaris GPUs during DPMS transitions, which have been a major headache on our POWER9 platforms. Backport to Debian stable kernel version. [ Upstream commit c210b757b400959577a5a17b783b5959b82baed8 ] Accessing DC from amdgpu_dm is usually preceded by acquisition of dc_lock mutex. Most of the DC API that DM calls are under a DC lock. However, there are a few that are not. Some DC API called from interrupt context end up sending DMUB commands via a DC API, while other threads were using DMUB. This was apparent from a race between calls for setting idle optimization enable/disable and the DC API to set vmin/vmax. Offload the call to dc_stream_adjust_vmin_vmax() to a thread instead of directly calling them from the interrupt handler such that it waits for dc_lock. [Timothy Pearson] Modified header file patch to apply to 6.12 Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas(a)amd.com> Signed-off-by: Aurabindo Pillai <aurabindo.pillai(a)amd.com> Signed-off-by: Roman Li <roman.li(a)amd.com> Tested-by: Daniel Wheeler <daniel.wheeler(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Timothy Pearson <tpearson(a)raptorengineering.com> --- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 55 +++++++++++++++++-- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 14 +++++ 2 files changed, 63 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index b02ff92bae0b..fd6d66832ccf 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -533,6 +533,50 @@ static void dm_pflip_high_irq(void *interrupt_params) amdgpu_crtc->crtc_id, amdgpu_crtc, vrr_active, (int)!e); } +static void dm_handle_vmin_vmax_update(struct work_struct *offload_work) +{ + struct vupdate_offload_work *work = container_of(offload_work, struct vupdate_offload_work, work); + struct amdgpu_device *adev = work->adev; + struct dc_stream_state *stream = work->stream; + struct dc_crtc_timing_adjust *adjust = work->adjust; + + mutex_lock(&adev->dm.dc_lock); + dc_stream_adjust_vmin_vmax(adev->dm.dc, stream, adjust); + mutex_unlock(&adev->dm.dc_lock); + + dc_stream_release(stream); + kfree(work->adjust); + kfree(work); +} + +static void schedule_dc_vmin_vmax(struct amdgpu_device *adev, + struct dc_stream_state *stream, + struct dc_crtc_timing_adjust *adjust) +{ + struct vupdate_offload_work *offload_work = kzalloc(sizeof(*offload_work), GFP_KERNEL); + if (!offload_work) { + drm_dbg_driver(adev_to_drm(adev), "Failed to allocate vupdate_offload_work\n"); + return; + } + + struct dc_crtc_timing_adjust *adjust_copy = kzalloc(sizeof(*adjust_copy), GFP_KERNEL); + if (!adjust_copy) { + drm_dbg_driver(adev_to_drm(adev), "Failed to allocate adjust_copy\n"); + kfree(offload_work); + return; + } + + dc_stream_retain(stream); + memcpy(adjust_copy, adjust, sizeof(*adjust_copy)); + + INIT_WORK(&offload_work->work, dm_handle_vmin_vmax_update); + offload_work->adev = adev; + offload_work->stream = stream; + offload_work->adjust = adjust_copy; + + queue_work(system_wq, &offload_work->work); +} + static void dm_vupdate_high_irq(void *interrupt_params) { struct common_irq_params *irq_params = interrupt_params; @@ -582,10 +626,9 @@ static void dm_vupdate_high_irq(void *interrupt_params) acrtc->dm_irq_params.stream, &acrtc->dm_irq_params.vrr_params); - dc_stream_adjust_vmin_vmax( - adev->dm.dc, - acrtc->dm_irq_params.stream, - &acrtc->dm_irq_params.vrr_params.adjust); + schedule_dc_vmin_vmax(adev, + acrtc->dm_irq_params.stream, + &acrtc->dm_irq_params.vrr_params.adjust); spin_unlock_irqrestore(&adev_to_drm(adev)->event_lock, flags); } } @@ -675,8 +718,8 @@ static void dm_crtc_high_irq(void *interrupt_params) acrtc->dm_irq_params.stream, &acrtc->dm_irq_params.vrr_params); - dc_stream_adjust_vmin_vmax(adev->dm.dc, acrtc->dm_irq_params.stream, - &acrtc->dm_irq_params.vrr_params.adjust); + schedule_dc_vmin_vmax(adev, acrtc->dm_irq_params.stream, + &acrtc->dm_irq_params.vrr_params.adjust); } /* diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h index 9603352ee094..aa99e226a381 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h @@ -1012,4 +1012,18 @@ void dm_free_gpu_mem(struct amdgpu_device *adev, bool amdgpu_dm_is_headless(struct amdgpu_device *adev); +/** + * struct dm_vupdate_work - Work data for periodic action in idle + * @work: Kernel work data for the work event + * @adev: amdgpu_device back pointer + * @stream: DC stream associated with the crtc + * @adjust: DC CRTC timing adjust to be applied to the crtc + */ +struct vupdate_offload_work { + struct work_struct work; + struct amdgpu_device *adev; + struct dc_stream_state *stream; + struct dc_crtc_timing_adjust *adjust; +}; + #endif /* __AMDGPU_DM_H__ */ -- 2.47.2

2 months

2
2
0 0

[PATCH 0/3] gpio: idio-16: Fix regmap initialization errors

by William Breathitt Gray

The migration of IDIO-16 GPIO drivers to the regmap API resulted in some regressions to the gpio-104-idio-16, gpio-pci-idio-16, and gpio-idio-16 modules. Specifically, the 104-idio-16 and pci-idio-16 GPIO drivers utilize regmap caching and thus must set max_register for their regmap_config, while gpio-idio-16 requires fixed_direction_output to represent the fixed direction of the IDIO-16 GPIO lines. Fixes for these regressions are provided by this series. Link: https://lore.kernel.org/r/cover.1680618405.git.william.gray@linaro.org Link: https://lore.kernel.org/r/9b0375fd-235f-4ee1-a7fa-daca296ef6bf@nutanix.com Signed-off-by: William Breathitt Gray <wbg(a)kernel.org> --- William Breathitt Gray (3): gpio: 104-idio-16: Define maximum valid register address offset gpio: pci-idio-16: Define maximum valid register address offset gpio: idio-16: Define fixed direction of the GPIO lines drivers/gpio/gpio-104-idio-16.c | 1 + drivers/gpio/gpio-idio-16.c | 5 +++++ drivers/gpio/gpio-pci-idio-16.c | 1 + 3 files changed, 7 insertions(+) --- base-commit: eba11116f39533d2e38cc5898014f2c95f32d23a change-id: 20251017-fix-gpio-idio-16-regmap-1282cdc56a19 Best regards, -- William Breathitt Gray <wbg(a)kernel.org>

2 months

4
10
0 0

FAILED: patch "[PATCH] HID: multitouch: fix sticky fingers" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y git checkout FETCH_HEAD git cherry-pick -x 46f781e0d151844589dc2125c8cce3300546f92a # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102008-likewise-rubbing-d48b@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 46f781e0d151844589dc2125c8cce3300546f92a Mon Sep 17 00:00:00 2001 From: Benjamin Tissoires <bentiss(a)kernel.org> Date: Wed, 8 Oct 2025 16:06:58 +0200 Subject: [PATCH] HID: multitouch: fix sticky fingers The sticky fingers quirk (MT_QUIRK_STICKY_FINGERS) was only considering the case when slots were not released during the last report. This can be problematic if the firmware forgets to release a finger while others are still present. This was observed on the Synaptics DLL0945 touchpad found on the Dell XPS 9310 and the Dell Inspiron 5406. Fixes: 4f4001bc76fd ("HID: multitouch: fix rare Win 8 cases when the touch up event gets missing") Cc: stable(a)vger.kernel.org Signed-off-by: Benjamin Tissoires <bentiss(a)kernel.org> Signed-off-by: Jiri Kosina <jkosina(a)suse.com> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c index 513b8673ad8d..179dc316b4b5 100644 --- a/drivers/hid/hid-multitouch.c +++ b/drivers/hid/hid-multitouch.c @@ -94,9 +94,8 @@ enum report_mode { TOUCHPAD_REPORT_ALL = TOUCHPAD_REPORT_BUTTONS | TOUCHPAD_REPORT_CONTACTS, }; -#define MT_IO_FLAGS_RUNNING 0 -#define MT_IO_FLAGS_ACTIVE_SLOTS 1 -#define MT_IO_FLAGS_PENDING_SLOTS 2 +#define MT_IO_SLOTS_MASK GENMASK(7, 0) /* reserve first 8 bits for slot tracking */ +#define MT_IO_FLAGS_RUNNING 32 static const bool mtrue = true; /* default for true */ static const bool mfalse; /* default for false */ @@ -172,7 +171,11 @@ struct mt_device { struct timer_list release_timer; /* to release sticky fingers */ struct hid_haptic_device *haptic; /* haptic related configuration */ struct hid_device *hdev; /* hid_device we're attached to */ - unsigned long mt_io_flags; /* mt flags (MT_IO_FLAGS_*) */ + unsigned long mt_io_flags; /* mt flags (MT_IO_FLAGS_RUNNING) + * first 8 bits are reserved for keeping the slot + * states, this is fine because we only support up + * to 250 slots (MT_MAX_MAXCONTACT) + */ __u8 inputmode_value; /* InputMode HID feature value */ __u8 maxcontacts; bool is_buttonpad; /* is this device a button pad? */ @@ -986,6 +989,7 @@ static void mt_release_pending_palms(struct mt_device *td, for_each_set_bit(slotnum, app->pending_palm_slots, td->maxcontacts) { clear_bit(slotnum, app->pending_palm_slots); + clear_bit(slotnum, &td->mt_io_flags); input_mt_slot(input, slotnum); input_mt_report_slot_inactive(input); @@ -1019,12 +1023,6 @@ static void mt_sync_frame(struct mt_device *td, struct mt_application *app, app->left_button_state = 0; if (td->is_haptic_touchpad) hid_haptic_pressure_reset(td->haptic); - - if (test_bit(MT_IO_FLAGS_ACTIVE_SLOTS, &td->mt_io_flags)) - set_bit(MT_IO_FLAGS_PENDING_SLOTS, &td->mt_io_flags); - else - clear_bit(MT_IO_FLAGS_PENDING_SLOTS, &td->mt_io_flags); - clear_bit(MT_IO_FLAGS_ACTIVE_SLOTS, &td->mt_io_flags); } static int mt_compute_timestamp(struct mt_application *app, __s32 value) @@ -1202,7 +1200,9 @@ static int mt_process_slot(struct mt_device *td, struct input_dev *input, input_event(input, EV_ABS, ABS_MT_TOUCH_MAJOR, major); input_event(input, EV_ABS, ABS_MT_TOUCH_MINOR, minor); - set_bit(MT_IO_FLAGS_ACTIVE_SLOTS, &td->mt_io_flags); + set_bit(slotnum, &td->mt_io_flags); + } else { + clear_bit(slotnum, &td->mt_io_flags); } return 0; @@ -1337,7 +1337,7 @@ static void mt_touch_report(struct hid_device *hid, * defect. */ if (app->quirks & MT_QUIRK_STICKY_FINGERS) { - if (test_bit(MT_IO_FLAGS_PENDING_SLOTS, &td->mt_io_flags)) + if (td->mt_io_flags & MT_IO_SLOTS_MASK) mod_timer(&td->release_timer, jiffies + msecs_to_jiffies(100)); else @@ -1814,6 +1814,7 @@ static void mt_release_contacts(struct hid_device *hid) for (i = 0; i < mt->num_slots; i++) { input_mt_slot(input_dev, i); input_mt_report_slot_inactive(input_dev); + clear_bit(i, &td->mt_io_flags); } input_mt_sync_frame(input_dev); input_sync(input_dev); @@ -1836,7 +1837,7 @@ static void mt_expired_timeout(struct timer_list *t) */ if (test_and_set_bit_lock(MT_IO_FLAGS_RUNNING, &td->mt_io_flags)) return; - if (test_bit(MT_IO_FLAGS_PENDING_SLOTS, &td->mt_io_flags)) + if (td->mt_io_flags & MT_IO_SLOTS_MASK) mt_release_contacts(hdev); clear_bit_unlock(MT_IO_FLAGS_RUNNING, &td->mt_io_flags); }

2 months

4
3
0 0

FAILED: patch "[PATCH] iio: imu: inv_icm42600: Avoid configuring if already" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x 466f7a2fef2a4e426f809f79845a1ec1aeb558f4 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025101624-legacy-gab-3e94@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 466f7a2fef2a4e426f809f79845a1ec1aeb558f4 Mon Sep 17 00:00:00 2001 From: Sean Nyekjaer <sean(a)geanix.com> Date: Mon, 1 Sep 2025 09:49:15 +0200 Subject: [PATCH] iio: imu: inv_icm42600: Avoid configuring if already pm_runtime suspended Do as in suspend, skip resume configuration steps if the device is already pm_runtime suspended. This avoids reconfiguring a device that is already in the correct low-power state and ensures that pm_runtime handles the power state transitions properly. Fixes: 31c24c1e93c3 ("iio: imu: inv_icm42600: add core of new inv_icm42600 driver") Signed-off-by: Sean Nyekjaer <sean(a)geanix.com> Link: https://patch.msgid.link/20250901-icm42pmreg-v3-3-ef1336246960@geanix.com Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c b/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c index 41b275ecc7e2..ee780f530dc8 100644 --- a/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c +++ b/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c @@ -837,17 +837,15 @@ static int inv_icm42600_suspend(struct device *dev) struct device *accel_dev; bool wakeup; int accel_conf; - int ret; + int ret = 0; mutex_lock(&st->lock); st->suspended.gyro = st->conf.gyro.mode; st->suspended.accel = st->conf.accel.mode; st->suspended.temp = st->conf.temp_en; - if (pm_runtime_suspended(dev)) { - ret = 0; + if (pm_runtime_suspended(dev)) goto out_unlock; - } /* disable FIFO data streaming */ if (st->fifo.on) { @@ -900,10 +898,13 @@ static int inv_icm42600_resume(struct device *dev) struct inv_icm42600_sensor_state *accel_st = iio_priv(st->indio_accel); struct device *accel_dev; bool wakeup; - int ret; + int ret = 0; mutex_lock(&st->lock); + if (pm_runtime_suspended(dev)) + goto out_unlock; + /* check wakeup capability */ accel_dev = &st->indio_accel->dev; wakeup = st->apex.on && device_may_wakeup(accel_dev);

2 months

2
2
0 0

FAILED: patch "[PATCH] iio: imu: inv_icm42600: Avoid configuring if already" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 466f7a2fef2a4e426f809f79845a1ec1aeb558f4 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025101624-blazing-sharpener-111d@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 466f7a2fef2a4e426f809f79845a1ec1aeb558f4 Mon Sep 17 00:00:00 2001 From: Sean Nyekjaer <sean(a)geanix.com> Date: Mon, 1 Sep 2025 09:49:15 +0200 Subject: [PATCH] iio: imu: inv_icm42600: Avoid configuring if already pm_runtime suspended Do as in suspend, skip resume configuration steps if the device is already pm_runtime suspended. This avoids reconfiguring a device that is already in the correct low-power state and ensures that pm_runtime handles the power state transitions properly. Fixes: 31c24c1e93c3 ("iio: imu: inv_icm42600: add core of new inv_icm42600 driver") Signed-off-by: Sean Nyekjaer <sean(a)geanix.com> Link: https://patch.msgid.link/20250901-icm42pmreg-v3-3-ef1336246960@geanix.com Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c b/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c index 41b275ecc7e2..ee780f530dc8 100644 --- a/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c +++ b/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c @@ -837,17 +837,15 @@ static int inv_icm42600_suspend(struct device *dev) struct device *accel_dev; bool wakeup; int accel_conf; - int ret; + int ret = 0; mutex_lock(&st->lock); st->suspended.gyro = st->conf.gyro.mode; st->suspended.accel = st->conf.accel.mode; st->suspended.temp = st->conf.temp_en; - if (pm_runtime_suspended(dev)) { - ret = 0; + if (pm_runtime_suspended(dev)) goto out_unlock; - } /* disable FIFO data streaming */ if (st->fifo.on) { @@ -900,10 +898,13 @@ static int inv_icm42600_resume(struct device *dev) struct inv_icm42600_sensor_state *accel_st = iio_priv(st->indio_accel); struct device *accel_dev; bool wakeup; - int ret; + int ret = 0; mutex_lock(&st->lock); + if (pm_runtime_suspended(dev)) + goto out_unlock; + /* check wakeup capability */ accel_dev = &st->indio_accel->dev; wakeup = st->apex.on && device_may_wakeup(accel_dev);

2 months

2
2
0 0

FAILED: patch "[PATCH] iio: imu: inv_icm42600: Avoid configuring if already" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x 466f7a2fef2a4e426f809f79845a1ec1aeb558f4 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025101623-clarify-manhood-adaa@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 466f7a2fef2a4e426f809f79845a1ec1aeb558f4 Mon Sep 17 00:00:00 2001 From: Sean Nyekjaer <sean(a)geanix.com> Date: Mon, 1 Sep 2025 09:49:15 +0200 Subject: [PATCH] iio: imu: inv_icm42600: Avoid configuring if already pm_runtime suspended Do as in suspend, skip resume configuration steps if the device is already pm_runtime suspended. This avoids reconfiguring a device that is already in the correct low-power state and ensures that pm_runtime handles the power state transitions properly. Fixes: 31c24c1e93c3 ("iio: imu: inv_icm42600: add core of new inv_icm42600 driver") Signed-off-by: Sean Nyekjaer <sean(a)geanix.com> Link: https://patch.msgid.link/20250901-icm42pmreg-v3-3-ef1336246960@geanix.com Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c b/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c index 41b275ecc7e2..ee780f530dc8 100644 --- a/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c +++ b/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c @@ -837,17 +837,15 @@ static int inv_icm42600_suspend(struct device *dev) struct device *accel_dev; bool wakeup; int accel_conf; - int ret; + int ret = 0; mutex_lock(&st->lock); st->suspended.gyro = st->conf.gyro.mode; st->suspended.accel = st->conf.accel.mode; st->suspended.temp = st->conf.temp_en; - if (pm_runtime_suspended(dev)) { - ret = 0; + if (pm_runtime_suspended(dev)) goto out_unlock; - } /* disable FIFO data streaming */ if (st->fifo.on) { @@ -900,10 +898,13 @@ static int inv_icm42600_resume(struct device *dev) struct inv_icm42600_sensor_state *accel_st = iio_priv(st->indio_accel); struct device *accel_dev; bool wakeup; - int ret; + int ret = 0; mutex_lock(&st->lock); + if (pm_runtime_suspended(dev)) + goto out_unlock; + /* check wakeup capability */ accel_dev = &st->indio_accel->dev; wakeup = st->apex.on && device_may_wakeup(accel_dev);

2 months

2
2
0 0

FAILED: patch "[PATCH] iio: imu: inv_icm42600: Avoid configuring if already" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.6-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.6.y git checkout FETCH_HEAD git cherry-pick -x 466f7a2fef2a4e426f809f79845a1ec1aeb558f4 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025101623-dry-crummiest-15b3@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 466f7a2fef2a4e426f809f79845a1ec1aeb558f4 Mon Sep 17 00:00:00 2001 From: Sean Nyekjaer <sean(a)geanix.com> Date: Mon, 1 Sep 2025 09:49:15 +0200 Subject: [PATCH] iio: imu: inv_icm42600: Avoid configuring if already pm_runtime suspended Do as in suspend, skip resume configuration steps if the device is already pm_runtime suspended. This avoids reconfiguring a device that is already in the correct low-power state and ensures that pm_runtime handles the power state transitions properly. Fixes: 31c24c1e93c3 ("iio: imu: inv_icm42600: add core of new inv_icm42600 driver") Signed-off-by: Sean Nyekjaer <sean(a)geanix.com> Link: https://patch.msgid.link/20250901-icm42pmreg-v3-3-ef1336246960@geanix.com Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c b/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c index 41b275ecc7e2..ee780f530dc8 100644 --- a/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c +++ b/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c @@ -837,17 +837,15 @@ static int inv_icm42600_suspend(struct device *dev) struct device *accel_dev; bool wakeup; int accel_conf; - int ret; + int ret = 0; mutex_lock(&st->lock); st->suspended.gyro = st->conf.gyro.mode; st->suspended.accel = st->conf.accel.mode; st->suspended.temp = st->conf.temp_en; - if (pm_runtime_suspended(dev)) { - ret = 0; + if (pm_runtime_suspended(dev)) goto out_unlock; - } /* disable FIFO data streaming */ if (st->fifo.on) { @@ -900,10 +898,13 @@ static int inv_icm42600_resume(struct device *dev) struct inv_icm42600_sensor_state *accel_st = iio_priv(st->indio_accel); struct device *accel_dev; bool wakeup; - int ret; + int ret = 0; mutex_lock(&st->lock); + if (pm_runtime_suspended(dev)) + goto out_unlock; + /* check wakeup capability */ accel_dev = &st->indio_accel->dev; wakeup = st->apex.on && device_may_wakeup(accel_dev);

2 months

2
2
0 0

FAILED: patch "[PATCH] iio: imu: inv_icm42600: Avoid configuring if already" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y git checkout FETCH_HEAD git cherry-pick -x 466f7a2fef2a4e426f809f79845a1ec1aeb558f4 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025101623-attractor-shopper-b67e@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 466f7a2fef2a4e426f809f79845a1ec1aeb558f4 Mon Sep 17 00:00:00 2001 From: Sean Nyekjaer <sean(a)geanix.com> Date: Mon, 1 Sep 2025 09:49:15 +0200 Subject: [PATCH] iio: imu: inv_icm42600: Avoid configuring if already pm_runtime suspended Do as in suspend, skip resume configuration steps if the device is already pm_runtime suspended. This avoids reconfiguring a device that is already in the correct low-power state and ensures that pm_runtime handles the power state transitions properly. Fixes: 31c24c1e93c3 ("iio: imu: inv_icm42600: add core of new inv_icm42600 driver") Signed-off-by: Sean Nyekjaer <sean(a)geanix.com> Link: https://patch.msgid.link/20250901-icm42pmreg-v3-3-ef1336246960@geanix.com Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c b/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c index 41b275ecc7e2..ee780f530dc8 100644 --- a/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c +++ b/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c @@ -837,17 +837,15 @@ static int inv_icm42600_suspend(struct device *dev) struct device *accel_dev; bool wakeup; int accel_conf; - int ret; + int ret = 0; mutex_lock(&st->lock); st->suspended.gyro = st->conf.gyro.mode; st->suspended.accel = st->conf.accel.mode; st->suspended.temp = st->conf.temp_en; - if (pm_runtime_suspended(dev)) { - ret = 0; + if (pm_runtime_suspended(dev)) goto out_unlock; - } /* disable FIFO data streaming */ if (st->fifo.on) { @@ -900,10 +898,13 @@ static int inv_icm42600_resume(struct device *dev) struct inv_icm42600_sensor_state *accel_st = iio_priv(st->indio_accel); struct device *accel_dev; bool wakeup; - int ret; + int ret = 0; mutex_lock(&st->lock); + if (pm_runtime_suspended(dev)) + goto out_unlock; + /* check wakeup capability */ accel_dev = &st->indio_accel->dev; wakeup = st->apex.on && device_may_wakeup(accel_dev);

2 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror