summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-08-12KVM: s390: Fix potential tiny kernel stack leakClaudio Imbrenda
In some circumstances, one bit of kernel stack could have been leaked from dat_cond_set_storage_key(). Fix by clearing prev before use. Fixes: 8e03e8316eb2 ("KVM: s390: KVM page table management functions: storage keys") Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-ID: <20260812104436.109741-9-imbrenda@linux.ibm.com>
2026-08-12KVM: s390: Fix kvm_s390_clear_pv_state()Claudio Imbrenda
kvm_s390_clear_pv_state() needs to also clear the dumping flag, to allow the protected VM to be started again (as non-protected, with all protected state safely destroyed) after a forced reboot while a protected dump was ongoing and not completed. Fixes: e40df9efd68a ("KVM: s390: pv: clear the state without memset") Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-ID: <20260812104436.109741-8-imbrenda@linux.ibm.com>
2026-08-12KVM: s390: Fix IRQ injection with SIGP Stop and Store StatusClaudio Imbrenda
When __inject_sigp_stop() is called for a Stop and Store Status operation, if the vCPU is running, the interrupt is marked as pending and the status is stored by the thread performing the KVM_RUN IOCTL. If the vCPU is already stopped, the status is stored immediately. Storing the status means writing into userspace, which might fault, and __inject_sigp_stop() is called from do_inject_vcpu() which in turn is always called holding a spinlock, which is obviously an issue. Fix this by returning -EWOULDBLOCK from __inject_sigp_stop(), and adding a bool flag to indicate whether a store status is needed. The callers of do_inject_vcpu() are modified to pass the pointer to the bool flag; whenever a Store Status operation is needed, the callers can now perform it outside the spinlock. Opportunistically refactor kvm_s390_set_irq_state() to use scoped_guard() and __free(). Fixes: 6cddd432e3da ("KVM: s390: handle stop irqs without action_bits") Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> [ Added Fixes tag while picking -- Claudio ] Message-ID: <20260812104436.109741-7-imbrenda@linux.ibm.com>
2026-08-12RDMA/rxe: Fix OOB in free_rd_atomic_resources()Peiyang He
free_rd_atomic_resources() iterates using qp->attr.max_dest_rd_atomic. Updating max_dest_rd_atomic before freeing the old array can make the free path walk past the old allocation and trigger a slab out-of-bounds write catched by KASAN: ================================================================== BUG: KASAN: slab-out-of-bounds in free_rd_atomic_resource drivers/infiniband/sw/rxe/rxe_qp.c:180 [inline] BUG: KASAN: slab-out-of-bounds in free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:171 [inline] BUG: KASAN: slab-out-of-bounds in free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:163 [inline] BUG: KASAN: slab-out-of-bounds in rxe_qp_from_attr+0x1e88/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c:712 Write of size 4 at addr ffff88802b8dddb8 by task syz.3.451/11063 CPU: 0 UID: 0 PID: 11063 Comm: syz.3.451 Not tainted 7.1.0 #2 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x10e/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xf7/0x600 mm/kasan/report.c:482 kasan_report+0xe4/0x120 mm/kasan/report.c:595 free_rd_atomic_resource drivers/infiniband/sw/rxe/rxe_qp.c:180 [inline] free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:171 [inline] free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:163 [inline] rxe_qp_from_attr+0x1e88/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c:712 rxe_modify_qp+0x1e2/0x530 drivers/infiniband/sw/rxe/rxe_verbs.c:623 ib_security_modify_qp+0x223/0xfa0 drivers/infiniband/core/security.c:625 _ib_modify_qp+0x333/0xec0 drivers/infiniband/core/verbs.c:1915 modify_qp+0x13ca/0x1940 drivers/infiniband/core/uverbs_cmd.c:1932 ib_uverbs_modify_qp+0xcb/0x120 drivers/infiniband/core/uverbs_cmd.c:1958 ib_uverbs_write+0xb86/0x1030 drivers/infiniband/core/uverbs_main.c:680 vfs_write+0x2aa/0x1070 fs/read_write.c:686 ksys_write+0x1f8/0x250 fs/read_write.c:740 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x116/0x800 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fefc75a70cd Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 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:00007fefc8495018 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fefc7835fa0 RCX: 00007fefc75a70cd RDX: 0000000000000078 RSI: 0000200000000240 RDI: 0000000000000007 RBP: 00007fefc764f10f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fefc7836038 R14: 00007fefc7835fa0 R15: 00007ffcf0586aa0 </TASK> Allocated by task 11063: kasan_save_stack+0x33/0x60 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 [inline] __do_kmalloc_node mm/slub.c:5296 [inline] __kmalloc_noprof+0x32a/0x850 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 [inline] kzalloc_noprof include/linux/slab.h:1188 [inline] alloc_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:155 [inline] rxe_qp_from_attr+0x3f8/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c:714 rxe_modify_qp+0x1e2/0x530 drivers/infiniband/sw/rxe/rxe_verbs.c:623 ib_security_modify_qp+0x223/0xfa0 drivers/infiniband/core/security.c:625 _ib_modify_qp+0x333/0xec0 drivers/infiniband/core/verbs.c:1915 modify_qp+0x13ca/0x1940 drivers/infiniband/core/uverbs_cmd.c:1932 ib_uverbs_modify_qp+0xcb/0x120 drivers/infiniband/core/uverbs_cmd.c:1958 ib_uverbs_write+0xb86/0x1030 drivers/infiniband/core/uverbs_main.c:680 vfs_write+0x2aa/0x1070 fs/read_write.c:686 ksys_write+0x1f8/0x250 fs/read_write.c:740 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x116/0x800 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f The buggy address belongs to the object at ffff88802b8ddd80 which belongs to the cache kmalloc-64 of size 64 The buggy address is located 0 bytes to the right of allocated 56-byte region [ffff88802b8ddd80, ffff88802b8dddb8) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x2b8dd flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff) page_type: f5(slab) raw: 00fff00000000000 ffff888015c418c0 dead000000000100 dead000000000122 raw: 0000000000000000 0000000800200020 00000000f5000000 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0xd2c40(GFP_NOFS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 4651, tgid 4651 ((udev-worker)), ts 123427165316, free_ts 123425874255 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0xfc/0x120 mm/page_alloc.c:1853 prep_new_page mm/page_alloc.c:1861 [inline] get_page_from_freelist+0x75b/0x3220 mm/page_alloc.c:3941 __alloc_frozen_pages_noprof+0x27e/0x2b00 mm/page_alloc.c:5221 alloc_slab_page mm/slub.c:3278 [inline] allocate_slab mm/slub.c:3467 [inline] new_slab+0xa6/0x670 mm/slub.c:3525 refill_objects+0x278/0x420 mm/slub.c:7272 refill_sheaf mm/slub.c:2816 [inline] __pcs_replace_empty_main+0x2ed/0x640 mm/slub.c:4652 alloc_from_pcs mm/slub.c:4750 [inline] slab_alloc_node mm/slub.c:4884 [inline] __do_kmalloc_node mm/slub.c:5295 [inline] __kmalloc_noprof+0x68d/0x850 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 [inline] kzalloc_noprof include/linux/slab.h:1188 [inline] tomoyo_encode2+0x100/0x3e0 security/tomoyo/realpath.c:45 tomoyo_encode+0x29/0x50 security/tomoyo/realpath.c:80 tomoyo_realpath_from_path+0x18c/0x690 security/tomoyo/realpath.c:283 tomoyo_get_realpath security/tomoyo/file.c:151 [inline] tomoyo_check_open_permission+0x2ab/0x3c0 security/tomoyo/file.c:776 tomoyo_file_open+0x6b/0x90 security/tomoyo/tomoyo.c:334 security_file_open+0x7a/0x1b0 security/security.c:2739 do_dentry_open+0x57e/0x1690 fs/open.c:924 vfs_open+0x82/0x3f0 fs/open.c:1079 do_open fs/namei.c:4699 [inline] path_openat+0x218a/0x3190 fs/namei.c:4858 page last free pid 1 tgid 1 stack trace: reset_page_owner include/linux/page_owner.h:25 [inline] __free_pages_prepare mm/page_alloc.c:1397 [inline] __free_frozen_pages+0x763/0xfc0 mm/page_alloc.c:2938 selinux_genfs_get_sid security/selinux/hooks.c:1364 [inline] inode_doinit_with_dentry+0x903/0x1320 security/selinux/hooks.c:1563 selinux_d_instantiate+0x26/0x30 security/selinux/hooks.c:6658 security_d_instantiate+0x123/0x190 security/security.c:3704 d_splice_alias_ops+0x92/0x850 fs/dcache.c:3141 kernfs_iop_lookup+0x23f/0x2d0 fs/kernfs/dir.c:1289 lookup_open.isra.0+0x659/0x1080 fs/namei.c:4484 open_last_lookups fs/namei.c:4611 [inline] path_openat+0x17dd/0x3190 fs/namei.c:4855 do_file_open+0x20c/0x430 fs/namei.c:4887 do_sys_openat2+0x101/0x1d0 fs/open.c:1364 do_sys_open fs/open.c:1370 [inline] __do_sys_openat fs/open.c:1386 [inline] __se_sys_openat fs/open.c:1381 [inline] __x64_sys_openat+0x141/0x200 fs/open.c:1381 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x116/0x800 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Memory state around the buggy address: ffff88802b8ddc80: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc ffff88802b8ddd00: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc >ffff88802b8ddd80: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc ^ ffff88802b8dde00: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc ffff88802b8dde80: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc Fix the OOB by moving the assignment after free_rd_atomic_resources() so the old array is freed using the old bound. This matches the original ordering in commit 8700e3e7c485 ("Soft RoCE driver"). Closes: https://lore.kernel.org/all/365C68B4923F8214+30195a67-0b90-4b92-ab96-2ce41517793c@smail.nju.edu.cn/ Fixes: b6bbee0d2438 ("IB/rxe: Properly honor max IRD value for rd/atomic.") Cc: stable@vger.kernel.org Signed-off-by: Peiyang He <peiyang_he@smail.nju.edu.cn> Reviewed-by: Zhu Yanjun <yanjun.zhu@linux.dev> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
2026-08-12m68k: Define NR_CPUS to 1Uwe Kleine-König
This fixes a Kconfig warning fs/erofs/Kconfig:137:warning: range is invalid which originates from EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS using NR_CPUS which up to now didn't exist for ARCH=m68k. All other architectures define this symbol, so fix the outlier. [geert] This also fixes: - CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS being set to the literal NR_CPUS instead of a number by automatic configs like "make allmodconfig" or "make olddefconfig", - An infinite loop in manual configs like "make oldconfig" when CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS is not present or has an invalid value in your existing .config. Fixes: c9b47e6b2311 ("erofs: cap LZMA stream pool size") Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Link: https://patch.msgid.link/20260731094950.1988084-2-ukleinek@kernel.org Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2026-08-12leds: is31fl319x: Modernize registrationAndreas Kemnade
Use _ext version to have properties parsed to avoid needing to parse them in the driver itself. More modern properties are recognized and the LEDs can be referenced via phandle. Due to the maximum current mechanics, LEDs are not registered right in the first iteration over the nodes. Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Link: https://patch.msgid.link/20260806-led-modern-v4-1-eed715baab2e@kemnade.info Signed-off-by: Lee Jones <lee@kernel.org>
2026-08-12KVM: s390: Fix pgste_get_trylock_multiple()Claudio Imbrenda
In case of failure, pgste_get_trylock_multiple() will attempt to unlock the locked PGSTEs based on whether the PCL is set. In some circumstances this can lead to unlocking PGSTEs that were locked by other threads. Fix by unlocking the amount of PGSTEs that were actually locked, ignoring the PCL bit in the array. Fixes: 94fd9b16cc67 ("KVM: s390: KVM page table management functions: lifecycle management") Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by: Christoph Schlameuss <schlameuss@linux.ibm.com> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-ID: <20260812104436.109741-6-imbrenda@linux.ibm.com>
2026-08-12KVM: s390: Fix get_all_floating_irqs()Claudio Imbrenda
When attempting to report all pending floating interrupt to userspace, the GISA IPM bits are atomically tested and cleared, and the corresponding interrupt description is written in the output buffer. If the output buffer is too small, an error is returned to userspace, but the GISA IPM bits are now lost. Moreover, the contract of KVM_DEV_FLIC_GET_ALL_IRQS, which is the only path to get_all_floating_irqs(), states that: > All interrupts remain pending, i.e. are not deleted from the list of > currently pending interrupts. Fix by non-destructively testing for the GISA IPM bits. Fixes: 24160af6cb28 ("KVM: s390: add GISA interrupts to FLIC ioctl interface") Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-ID: <20260812104436.109741-4-imbrenda@linux.ibm.com>
2026-08-12KVM: s390: Use srcu in kvm_arch_vcpu_unlocked_ioctl()Claudio Imbrenda
kvm_arch_vcpu_unlocked_ioctl() is called without further locks held, but kvm_s390_inject_vcpu(), which is called from there, needs either the kvm->srcu or the slots lock. Fix by taking the kvm->srcu in kvm_arch_vcpu_unlocked_ioctl(). Fixes: ba5c1e9b6cee ("KVM: s390: interrupt subsystem, cpu timer, waitpsw") Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by: Christoph Schlameuss <schlameuss@linux.ibm.com> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-ID: <20260812104436.109741-3-imbrenda@linux.ibm.com>
2026-08-12KVM: s390: Properly handle NULL pointer in dat_cond_set_storage_key()Claudio Imbrenda
Some callers pass NULL as oldkey. Calling page_cond_set_storage_key() will cause that NULL pointer to get dereferenced. Fix by checking for NULL and assigning the pointer to a dummy local variable to avoid crashes. Fixes: 8e03e8316eb2 ("KVM: s390: KVM page table management functions: storage keys") Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by: Christoph Schlameuss <schlameuss@linux.ibm.com> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-ID: <20260812104436.109741-2-imbrenda@linux.ibm.com>
2026-08-12KVM: s390: Restore sigset on error pathChristian Borntraeger
kvm_sigset_activate() installs vcpu->sigset via sigprocmask() and stashes the caller's mask in current->real_blocked; only kvm_sigset_deactivate() restores it. For KVM_RUN on a STOPPED vcpu the error path will not restore the userspace mask. Re-arrange the error handling to also restore the signal mask. Fixes: 6352e4d2dd9a3 ("KVM: s390: implement KVM_(S|G)ET_MP_STATE for user space state control") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-ID: <20260811153738.206885-5-borntraeger@linux.ibm.com>
2026-08-12KVM: s390: pv: Fix rc/rrc offset for PVM_DUMPChristian Borntraeger
The rc/rrc value is copied to the cmd location of the cmd in the kvm_pv_cmd structure. Fix the offset. Fixes: 8aba09588d2a ("KVM: s390: Add CPU dump functionality") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-ID: <20260811153738.206885-4-borntraeger@linux.ibm.com>
2026-08-12KVM: s390: vsie: zero stale crypto bitsChristian Borntraeger
When shadowing crypto access bits from a format0 apcb (crycb 0 or 1), the bits 64..255 are unchanged from whatever is in the vsie page in the crycb and thus in the apcb. This gives a nested guest potential access to a device no longer available. Zero out the remaining bits. Fixes: 6b79de4b056e ("KVM: s390: vsie: allow guest FORMAT-1 CRYCB on host FORMAT-2") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-ID: <20260811153738.206885-3-borntraeger@linux.ibm.com>
2026-08-12KVM: s390: keyop: use mmu_lock to read gmap->asceChristian Borntraeger
Every other dat_* consumer in this file (kvm_s390_get_skeys, set_skeys, get_cmma_bits, set_cmma_bits, MEM_CLR_CMMA, kvm_s390_fixup_prefix, kvm_test_age_gfn, kvm_age_gfn) reads kvm->arch.gmap->asce *inside* the mmu_lock read-side. keyop is the only outlier. gmap->asce is mutated under write_lock(mmu_lock) by gmap_set_limit() and keyop might use a stale asce value for walking as KVM_S390_KEYOP and KVM_S390_VM_MEM_LIMIT_SIZE can run concurrently. This can result in memory corruption. Fixes: 0ee4ddc1647b ("KVM: s390: Storage key manipulation IOCTL") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-ID: <20260811153738.206885-2-borntraeger@linux.ibm.com>
2026-08-12mfd: cs42l43: Fix regmap defaults orderingCharles Keepax
The regmap defaults should be ordered as binary search is done on the array. A few registers were added in the wrong places, move these to be in register address order. Fixes: a6fe20d67dc7 ("mfd: cs42l43: Add support for the B variant") Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260805120109.4024451-1-ckeepax@opensource.cirrus.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-08-12dt-bindings: mfd: syscon: Allow syscon compatible for Loongson-2K0300 chip idBinbin Zhou
The Loongson-2K0300 SoC exposes its chip ID registers through a syscon interface. Add the specific compatible `loongson,ls2k0300-chipid-syscon` to the allowed list of syscon bindings so that it can be referenced from the thermal node via a phandle. Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/b76405a88b0cded91ba370139d7223fe2d6953df.1785829933.git.zhoubinbin@loongson.cn Signed-off-by: Lee Jones <lee@kernel.org>
2026-08-12pid: reject allocations through dead ancestor pid namespacesJérémy Jean
alloc_pid() checks PIDNS_ADDING only on the leaf pid namespace before making a new struct pid visible in every ancestor namespace. That is insufficient when an unborn descendant pid namespace outlives an ancestor whose init task has already exited. The descendant can still be initialized later through setns(), and the new pid is then published into the dead ancestor as well. Keep the existing ENOMEM behavior, but require PIDNS_ADDING to be set in every namespace that will receive the new pid before publishing any of them. This preserves the invariant that free_pid() never decrements pid_allocated in a namespace whose child_reaper is no longer live. Fixes: a3bdc23ba8ea ("pid_namespace: allow opening pid_for_children before init was created") Signed-off-by: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr> Reviewed-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-08-12ASoC: es8316: Add regulator supportMark Brown
Hongyang Zhao <hongyang.zhao@thundersoft.com> says: Add regulator support for the four ES8316 power domains so board descriptions can model and control the codec supplies. The binding patch documents AVDD, CPVDD, DVDD and PVDD as optional supplies for ES8316, preserving compatibility with existing device-tree descriptions. The driver patch enables the supplies before initializing the regmap and keeps them enabled for the lifetime of the I2C device. The missing supply model was identified while reviewing the RubikPi 3 audio support: https://lore.kernel.org/linux-arm-msm/c293d9c7-bdb7-4303-80c8-404228c434d7@oss.qualcomm.com/ Link: https://patch.msgid.link/20260812-es8316-regulator-next-20260722-v2-0-e7078bc9bc9c@thundersoft.com
2026-08-12ASoC: codecs: es8316: Add regulator supportHongyang Zhao
ES8316 has separate AVDD, CPVDD, DVDD and PVDD supply inputs. Request and enable the supplies during I2C probe, before initializing the regmap. Keep them enabled for the lifetime of the I2C device so the regmap cannot access an unpowered device and its cache remains synchronized if the ASoC component is unbound and rebound. Signed-off-by: Hongyang Zhao <hongyang.zhao@thundersoft.com> Link: https://patch.msgid.link/20260812-es8316-regulator-next-20260722-v2-2-e7078bc9bc9c@thundersoft.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-12ASoC: dt-bindings: es8316: Add regulator suppliesHongyang Zhao
The ES8316 has separate AVDD, CPVDD, DVDD and PVDD supply inputs for its analog, charge pump, digital core and digital I/O domains. Describe all four inputs so boards can model the codec power topology. The binding also covers ES8311 and ES8323, whose supply inputs differ, so restrict these properties to the ES8316 compatible. Keep them optional for compatibility with existing descriptions. Signed-off-by: Hongyang Zhao <hongyang.zhao@thundersoft.com> Link: https://patch.msgid.link/20260812-es8316-regulator-next-20260722-v2-1-e7078bc9bc9c@thundersoft.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-12arm64/efi: Avoid voluntary preemption with efi_mm installedWill Deacon
Gus reports a bad kernel memory access when using software PAN (CONFIG_ARM64_SW_TTBR0_PAN=y) on a machine with support for EFI runtime services: Unable to handle kernel access to user memory outside uaccess routines at virtual address 00000000f322ff30 Mem abort info: ESR = 0x0000000096000004 FSC = 0x04: level 0 translation fault Internal error: Oops: 0000000096000004 [#1] SMP Workqueue: efi_rts_wq efi_call_rts pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : efi_call_rts+0xd8/0x288 Call trace: efi_call_rts+0xd8/0x288 (P) process_one_work+0x178/0x4f8 worker_thread+0x194/0x328 This is because the fpsimd context management code called from __efi_fpsimd_begin() can preempt voluntarily, returning later to the EFI code with an incorrect value for TTBR0_EL1 thanks to the deferred mm switching used by the software PAN implementation. Since EFI runtime services cannot preempt voluntarily and because the fpsimd switching code does not rely on the TTBR0_EL1 mappings, simply reorder the fpsimd switch so that it occurs before we change the page-table. Cc: Ard Biesheuvel <ardb@kernel.org> Reported-by: Gus Bourg <gus@bourg.net> Tested-by: Gus Bourg <gus@bourg.net> Fixes: a5baf582f4c0 ("arm64/efi: Call EFI runtime services without disabling preemption") Link: https://lore.kernel.org/all/20260806000144.3388823-1-gus@bourg.net/ Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2026-08-12rust: fmt: route {:p} through HashedPtr to prevent address leaksKe Sun
Define a custom `kernel::fmt::Pointer` trait and `HashedPtr` wrapper so that `{:p}` formatting uses the kernel's `%p` hashed format instead of printing raw pointer values, preventing kernel address space leaks. Signed-off-by: Ke Sun <sunke@kylinos.cn> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260810-hashedptr-v15-2-eafd27d36476@kylinos.cn [ Fixed KUnit failure when the CRNG is not ready. Then, as suggested, replaced the `scnprintf` comment (with v16's), changed width to 100, replaced cast with `without_provenance`. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-08-12rust: fmt: fix {:p} printing stack addressesKe Sun
The `impl_fmt_adapter_forward!` macro forwards `Pointer` for `Adapter<T>` by destructuring `self` into a local `t`, causing `{:p}` to print the address of that temporary stack variable rather than the actual pointer. Remove `Pointer` from the macro and provide a manual impl for `Adapter<&T>` that passes `self.0` directly. Signed-off-by: Ke Sun <sunke@kylinos.cn> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Tested-by: Link Mauve <linkmauve@linkmauve.fr> Cc: stable@vger.kernel.org Fixes: c5cf01ba8dfe ("rust: support formatting of foreign types") Link: https://patch.msgid.link/20260810-hashedptr-v15-1-eafd27d36476@kylinos.cn Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-08-12ovl: fix double end_creating() on the casefold-mismatch pathVivek Parikh
ovl_create_real() releases the new dentry twice when the casefold consistency check fails. The S_IFDIR branch calls end_creating() and sets err, then falls through to the common out: label which calls end_creating() on the same dentry again: case S_IFDIR: newdentry = ovl_do_mkdir(ofs, dir, newdentry, attr->mode); err = PTR_ERR_OR_ZERO(newdentry); if (!err && ofs->casefold != ovl_dentry_casefolded(newdentry)) { pr_warn_ratelimited(...); end_creating(newdentry); /* first */ err = -EINVAL; } break; ... if (err) goto out; ... out: if (err) { end_creating(newdentry); /* second, same dentry */ return ERR_PTR(err); } end_creating() is end_dirop(), which does inode_unlock() on the parent and dput() on the dentry, so the parent directory's i_rwsem is unlocked twice and the dentry is put twice. The second unlock releases a lock that is not held, which is what wedges every later creation under that parent, and the second dput() drops a reference that was never taken. The branch was added by commit dfc7da402ccc ("ovl: Check for casefold consistency when creating new dentries") as a bare dput(), which already released the reference twice; commit fe497f0759e0 ("VFS: change vfs_mkdir() to unlock on failure.") converted both sites to end_creating(), adding the double unlock. This is reachable by an unprivileged user. The casefold consistency of the layers is validated at mount time in ovl_parse_layer(), and again on every lookup in ovl_lookup_single(), but ofs->workdir is the internal "work" subdirectory created inside the user-supplied workdir, and that subdirectory is not re-checked. Marking it casefolded after the mount therefore makes every ovl_create_temp() inherit the wrong state - and that path reaches ovl_create_real() through ovl_start_creating_temp(), which uses start_creating() with a generated name and so never runs the lookup-time check. unshare -Urm mount -t tmpfs -o casefold=utf8-12.1.0 tmpfs mnt mkdir -p mnt/lower/d mnt/upper mnt/work mnt/merged mount -t overlay ovl -o lowerdir=mnt/lower,\ upperdir=mnt/upper,workdir=mnt/work mnt/merged chattr +F mnt/work/work mkdir mnt/merged/d/sub # directory copy-up overlayfs: wrong inherited casefold (work/#5) and the next copy-up blocks forever on the parent's i_rwsem: mkdir D start_creating+0x65/0xb0 ovl_start_creating_temp+0xb0/0xe0 [overlay] ovl_create_temp+0xa3/0x1d0 [overlay] ovl_copy_up_one+0x1f1c/0x21c0 [overlay] ovl_copy_up_flags+0xf5/0x140 [overlay] ovl_create_object+0xb7/0x220 [overlay] ovl_mkdir+0x23/0x40 [overlay] Drop the end_creating() from the branch and let out: own the cleanup, which is what every other error path in this function already does. Fixes: dfc7da402ccc ("ovl: Check for casefold consistency when creating new dentries") Cc: stable@vger.kernel.org Signed-off-by: Vivek Parikh <vivek.parikh@breachx.ai> Reviewed-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-08-12pipe: only enable the extra wake_up(rd_wait) for EPOLLET consumersOleg Nesterov
pipe_poll() unconditionally sets ->poll_usage on the first call, forcing anon_pipe_write() to wake up readers on every write even if the pipe was not empty. The reason is that some legacy epoll(EPOLLET) users depend on historical per-write wakeups, see commit 3a34b13a88ca ("pipe: make pipe writes always wake up readers"). Test-case: #include <unistd.h> #include <sys/epoll.h> #include <assert.h> int main(void) { int pfd[2], efd; struct epoll_event evt = { .events = EPOLLIN | EPOLLET }; pipe(pfd); efd = epoll_create1(0); epoll_ctl(efd, EPOLL_CTL_ADD, pfd[0], &evt); for (int i = 0; i < 2; ++i) { write(pfd[1], "", 1); assert(epoll_wait(efd, &evt, 1, 0) == 1); } return 0; } it fails if WRITE_ONCE(poll_usage, true) is removed from pipe_poll(). However, without EPOLLET in .events, it does not need the extra wakeup and succeeds even if write() is called only once before the main loop. Currently io_uring without (unsupported) IORING_POLL_ADD_LEVEL always sets EPOLLET, and in IORING_POLL_ADD_MULTI mode it depends on per-write wakeups the same way: #include <unistd.h> #include <sys/mman.h> #include <sys/epoll.h> #include <sys/syscall.h> #include <linux/io_uring.h> #include <assert.h> int main(void) { struct io_uring_params p = {}; int fd, pfd[2]; pipe(pfd); fd = syscall(SYS_io_uring_setup, 2, &p); assert(fd >= 0); void *ring = mmap(0, p.cq_off.cqes + p.cq_entries * sizeof(struct io_uring_cqe), PROT_READ | PROT_WRITE, MAP_SHARED, fd, IORING_OFF_SQ_RING); assert(ring != MAP_FAILED); *(unsigned *)(ring + p.sq_off.tail) = 1; struct io_uring_sqe *sqes = mmap(0, p.sq_entries * sizeof(*sqes), PROT_READ | PROT_WRITE, MAP_SHARED, fd, IORING_OFF_SQES); assert(sqes != MAP_FAILED); sqes[0].opcode = IORING_OP_POLL_ADD; sqes[0].fd = pfd[0]; sqes[0].len = IORING_POLL_ADD_MULTI; sqes[0].poll32_events = EPOLLIN; syscall(SYS_io_uring_enter, fd, 1, 0, 0, 0, 0); unsigned *cq_head = ring + p.cq_off.head; unsigned *cq_tail = ring + p.cq_off.tail; for (int i = 0; i < 2; ++i) { write(pfd[1], "", 1); syscall(SYS_io_uring_enter, fd, 0, 0, IORING_ENTER_GETEVENTS, 0, 0); assert(*cq_tail == ++*cq_head); } return 0; } the 2nd assert() in the main loop fails without ->poll_usage == true. Rename ->poll_usage to ->pseudo_edgetrigger to make the purpose clearer, update the comments, and change pipe_poll() to set ->pseudo_edgetrigger only if wait->_key & EPOLLET is true. This check should catch both users, and this way poll/select and epoll without EPOLLET users will not pay for the extra wakeup. Signed-off-by: Oleg Nesterov <oleg@redhat.com> Link: https://patch.msgid.link/anCNoW-x0bcB2ggg@redhat.com Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-08-12pidfd: hold exec_update_lock around namespace ioctlChen Linxuan
The PIDFD_GET_*_NAMESPACE ioctls in pidfd_ioctl() perform a filesystem credentials ptrace access check before handing out a namespace file descriptor. The accompanying comment states that the code "mirrors nsfs behavior", but, unlike the corresponding procfs paths, it does so without holding the target task's exec_update_lock. proc_ns_get_link() and proc_ns_readlink() both take exec_update_lock for reading around the ptrace check and the namespace lookup, so that the credentials used for the access decision match those of the task when its namespace is read. Without it, a caller can pass the check against the target's old credentials and then read the namespace after the target has execve()'d a setuid binary and committed new credentials -- accessing namespace information it should have been denied. Hold exec_update_lock for reading around the ptrace check and the namespace lookup so that pidfd truly mirrors nsfs behavior, as the comment already claims. open_namespace() itself runs outside the lock: once a namespace reference is obtained it carries its own refcount and is opened with the caller's own credentials, so a concurrent execve() on the target can no longer affect the outcome. Fixes: 5b08bd408534 ("pidfs: allow retrieval of namespace file descriptors") Cc: stable@vger.kernel.org Signed-off-by: Chen Linxuan <me@black-desk.cn> Link: https://patch.msgid.link/20260731-pidfd-exec-update-lock-v1-1-b388f2f3a8b0@black-desk.cn Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-08-12fs: fix user path of nested backing filesBaokun Li
backing_file_open() derives the path to be stored in the new backing file from user_file->f_path. This is incorrect when user_file itself is a backing file, which is the case for nested stacking filesystems, e.g. overlayfs mounts where the lowerdir of one overlayfs is the merged directory of another. Since commit def3ae83da02 ("fs: store real path instead of fake path in backing file f_path") the f_path of a backing file holds the real path of the intermediate layer, not the path that the user opened. Commit 924577e4f6ca ("ovl: Fix nested backing file paths") fixed this for such configurations by passing file_user_path() from ovl_open_realfile(). However, commit 6af36aeb147a ("lsm: add backing_file LSM hooks") changed the first argument of backing_file_open() from the user path back to the user file and derived the path from user_file->f_path again, silently re-introducing the problem. As a result, files mapped through a nested overlayfs show the wrong path in /proc/<pid>/maps and in perf/ftrace mmap records. For example, with two nested overlayfs mounts: mkdir -p /ovl/{lower,upper,work,merged} /ovl/nested echo hello > /ovl/lower/foo mount -t overlay overlay \ -o lowerdir=/ovl/lower,upperdir=/ovl/upper,workdir=/ovl/work \ /ovl/merged # at least two lowerdirs are needed when upperdir is nonexistent mount -t overlay overlay \ -o lowerdir=/ovl/merged:/ovl/lower /ovl/nested mapping /ovl/nested/foo shows a disconnected path instead of the user path: # readlink /proc/self/fd/3 /ovl/nested/foo # grep foo /proc/self/maps 7f6e2c100000-7f6e2c101000 r--s 00000000 00:24 15813027 /foo The bogus path is derived from the f_path of the intermediate backing file, whose mount is a private clone that d_path() cannot resolve. Fix this by using file_user_path(), which returns the outermost user-visible path for backing files and falls back to &user_file->f_path for regular files. This restores the behavior of commit 924577e4f6ca ("ovl: Fix nested backing file paths") for overlayfs and also fixes the same problem for the other backing_file_open() callers, fuse passthrough and erofs ishare, when their user file is itself a backing file. backing_tmpfile_open() has the same pattern but is not affected: it is only called by ovl_create_tmpfile() for the upper layer, and another overlayfs is rejected as upperdir by the DCACHE_OP_REAL check in ovl_mount_dir_check(), so its user_file can never be a backing file. Fixes: 6af36aeb147a ("lsm: add backing_file LSM hooks") Cc: stable@vger.kernel.org Signed-off-by: Baokun Li <libaokun@linux.alibaba.com> Link: https://patch.msgid.link/20260804034204.3487077-1-libaokun@linux.alibaba.com Tested-by: Paul Moore <paul@paul-moore.com> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-08-12fs: remove stale inode_insert5() kernel-doc parameterYichong Chen
inode_insert5() no longer has an isnew argument, but its kernel-doc still documents one. This triggers a W=1 kernel-doc warning. Remove the stale parameter description. Signed-off-by: Yichong Chen <chenyichong@uniontech.com> Link: https://patch.msgid.link/20260805024149.935769-1-chenyichong@uniontech.com Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-08-12fs: fix switch/case indentation in sysfs() syscallManush Prajwal
The case labels in the sysfs(2) syscall implementation are indented one level deeper than the switch statement itself, which does not match the kernel coding style (switch and case should be at the same indentation level). Fix the indentation; no functional change. Signed-off-by: Manush Prajwal <manushprajwal555@gmail.com> Link: https://patch.msgid.link/20260808182816.2399-1-manushprajwal555@gmail.com Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-08-12fs: document semantics of kstat::{uid,gid} fieldsJann Horn
The uid stored in struct kstat is logically a vfsuid; file systems initialize it by converting a kuid (filesystem perspective) to a vfsuid (mount perspective), then use vfsuid_into_kuid(), which essentially just typecasts from vfsuid to kuid. For now, just add a comment to note this mismatch between C type and semantic type. Below are some notes for anyone who wants to refactor this in the future. There are probably two options to refactor this away: 1. Change the type of kstat::uid to vfsuid_t, and perform the conversion from vfsuid to userspace-uid in the VFS layer. This wouldn't change machine code, just be more semantically correct. 2. Change the semantics of kstat::uid to really be a kuid_t, and let the VFS layer take care of doing the translation from kuid to vfsuid that is currently done in filesystem code (or in generic_fillattr, on behalf of the filesystem code). Option 2 is probably neater since it moves more logic into the generic VFS layer, and this is something that is expected to work the same way in all file systems? The following coccinelle script: ``` virtual context @@ struct kstat *stat; @@ * stat->uid @@ struct kstat *stat; @@ * stat->gid @@ struct kstat stat; @@ * stat.uid @@ struct kstat stat; @@ * stat.gid ``` detects 43 field accesses to these uid/gid fields. Signed-off-by: Jann Horn <jannh@google.com> Link: https://patch.msgid.link/20260803-vfs-comment-stat-uid-v1-1-162d062b737c@google.com Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-08-12pmdomain: Merge branch fixes into nextUlf Hansson
Merge the pmdomain fixes for v7.2-rc[n] into the next branch, to allow them to get tested together with the pmdomain changes that are targeted for the next release. Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-08-12pmdomain: mediatek: mfg: initialize prev_o in mtk_mfg_attach_dev()Karl Mehltretter
mtk_mfg_attach_dev() reads prev_o on the first iteration of its loop, in "if (prev_o && prev_o->freq == o->freq)", before prev_o is assigned at the end of the loop body. On that first iteration, evaluating prev_o reads an indeterminate value. If it is non-NULL, the condition dereferences a stale or invalid pointer, potentially faulting or incorrectly skipping the first OPP. Initialize prev_o to NULL. This matches the intent as well: there is no previous OPP to compare against on the first iteration. Found with Clang's -Wconditional-uninitialized. Fixes: f08e7a4e8d6ac ("pmdomain: mediatek: Add support for MFlexGraphics") Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-08-12pmdomain: renesas: Add R-Car X5H MDLC driverGeert Uytterhoeven
Add a minimal Module Controller driver for the R-Car X5H (R8A78000) SoC. For now this just supports the always-on power domains, and dummy module clocks and resets for the serial console (which is enabled by the boot loader). Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-08-12dt-bindings: mfd: syscon: Add ESWIN EIC7700 compatiblePinkesh Vaghela
Document ESWIN EIC7700 SoC compatible for syscon registers. Signed-off-by: Pinkesh Vaghela <pinkesh.vaghela@einfochips.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/20260804104431.1391839-5-pinkesh.vaghela@einfochips.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-08-12mfd: qnap-mcu: keep the reply buffer alive past a command timeoutAli Ahmet Memis
qnap_mcu_exec() publishes an on-stack buffer to the receive path: unsigned char rx[QNAP_MCU_RX_BUFFER_SIZE]; ... reply->data = rx; reply->length = length; and qnap_mcu_receive_buf() writes into it from the serdev receive path, which runs out of flush_to_ldisc() and is not serialized against qnap_mcu_exec() at all. bus_lock cannot cover it, because qnap_mcu_exec() holds that mutex across wait_for_completion_timeout(). On a timeout qnap_mcu_exec() returns with reply->data still pointing at its own frame. A reply that arrives late, or an unsolicited message from the MCU, is then written into a stack frame that has been left, corrupting whatever runs next on that stack. The same applies when qnap_mcu_write() fails, since that path returns without touching the reply state either. Move the receive buffer into struct qnap_mcu. It is 37 bytes and the structure is devm_kzalloc()ed, so it lives as long as the driver, and a late write lands in memory that is still valid and is reinitialized by the next command. bus_lock keeps commands from sharing it. This deliberately does not clear reply->data or reply->length on the timeout path. Doing so races with qnap_mcu_receive_buf(), which reads both after its if (!reply->length) return size; check: clearing reply->data gives a NULL dereference, and clearing reply->length alone removes the reply->received == reply->length exit condition, so the copy loop runs until the uart chunk is consumed and overruns the buffer. Leaving both set keeps the write bounded by reply->length, which qnap_mcu_exec() has already checked against sizeof(mcu->rx). Fixes: 998f70d1806b ("mfd: Add base driver for qnap-mcu devices") Cc: stable@vger.kernel.org Signed-off-by: Ali Ahmet Memis <ali@iusegentoo.com> Link: https://lore.kernel.org/all/20260802132012.537B81F000E9@smtp.kernel.org/ Link: https://patch.msgid.link/20260802135307.31380-1-ali@iusegentoo.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-08-12rust: module: update MAINTAINERS to cover module.rsAlvin Sun
Module types now live in `rust/kernel/module.rs` alongside `rust/kernel/module_param.rs`. Update the MODULE SUPPORT file pattern from `rust/kernel/module_param.rs` to `rust/kernel/module*.rs` so both files are covered. Assisted-by: opencode:glm-5.2 Link: https://lore.kernel.org/rust-for-linux/8ea21b29-9baf-4926-a16f-7d21c5a1a1b8@suse.com Reviewed-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Petr Pavlu <petr.pavlu@suse.com> Signed-off-by: Alvin Sun <alvin.sun@linux.dev> Link: https://patch.msgid.link/20260811-fix-fops-owner-v10-10-7e71776f9dbe@linux.dev [ Removed Acked-by and Cc. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-08-12rust: macros: remove `THIS_MODULE` static from `module!`Alvin Sun
All users have been migrated to `ModuleMetadata::THIS_MODULE` const or `this_module::<LocalModule>()` helper. The `static THIS_MODULE` generated by the `module!` macro is no longer referenced anywhere, so remove it to avoid having two sources of the same `ThisModule` pointer. Assisted-by: opencode:glm-5.2 Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Acked-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Petr Pavlu <petr.pavlu@suse.com> Signed-off-by: Alvin Sun <alvin.sun@linux.dev> Link: https://patch.msgid.link/20260811-fix-fops-owner-v10-9-7e71776f9dbe@linux.dev Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-08-12rust_binder: use `LocalModule` for `THIS_MODULE`Alvin Sun
Replace the `THIS_MODULE` static reference in the binder fops with `this_module::<LocalModule>()`, consistent with the move of `THIS_MODULE` into the `ModuleMetadata` trait. Assisted-by: opencode:glm-5.2 Reviewed-by: Gary Guo <gary@garyguo.net> Acked-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Alvin Sun <alvin.sun@linux.dev> Link: https://patch.msgid.link/20260811-fix-fops-owner-v10-8-7e71776f9dbe@linux.dev Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-08-12rust: configfs: use `LocalModule` for `THIS_MODULE`Alvin Sun
Replace the `THIS_MODULE` static reference in the `configfs_attrs!` macro with `this_module::<LocalModule>()`, and update rnull to import `LocalModule` instead of `THIS_MODULE`, consistent with the move of `THIS_MODULE` into the `ModuleMetadata` trait. Assisted-by: opencode:glm-5.2 Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Acked-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Acked-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Alvin Sun <alvin.sun@linux.dev> Link: https://patch.msgid.link/20260811-fix-fops-owner-v10-7-7e71776f9dbe@linux.dev [ Rebased to avoid the imports cleanup patch. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-08-12rust: miscdevice: set fops.owner from driver module pointerAlvin Sun
Set the miscdevice fops owner field from the driver module pointer via the `this_module::<T::OwnerModule>()` helper, instead of defaulting to null. Assisted-by: opencode:glm-5.2 Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Acked-by: Danilo Krummrich <dakr@kernel.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Alvin Sun <alvin.sun@linux.dev> Link: https://patch.msgid.link/20260811-fix-fops-owner-v10-6-7e71776f9dbe@linux.dev Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-08-12rust: drm: set fops.owner from driver module pointerAlvin Sun
Change `create_fops()` to accept an owner module pointer instead of hardcoding `null_mut()`, ensuring the kernel correctly tracks the module owning the DRM device's file operations. Assisted-by: opencode:glm-5.2 Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Acked-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Alvin Sun <alvin.sun@linux.dev> Link: https://patch.msgid.link/20260811-fix-fops-owner-v10-5-7e71776f9dbe@linux.dev Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-08-12rust: macros: auto-insert OwnerModule in #[vtable]Alvin Sun
Auto-add `type OwnerModule: ::kernel::ModuleMetadata;` as a required associated type on the trait side if not already defined, and auto-insert `type OwnerModule = crate::LocalModule;` on the impl side if not explicitly provided, eliminating the need to manually declare and implement `OwnerModule` in every vtable trait and impl. Assisted-by: opencode:glm-5.2 Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Suggested-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/all/DIMMWHUOLPSH.13JFRHDKDQJGO@garyguo.net Reviewed-by: Gary Guo <gary@garyguo.net> Acked-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Alvin Sun <alvin.sun@linux.dev> Link: https://patch.msgid.link/20260811-fix-fops-owner-v10-4-7e71776f9dbe@linux.dev [ Fixed `rusttest` by adding a dummy `LocalModule`. Removed interim `#[allow(dead_code)]`. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-08-12rust: doctest: add LocalModule fallback for #[vtable] ThisModuleAlvin Sun
Add a `LocalModule` struct with a null-pointer `ModuleMetadata` impl in the doctest harness, so that `crate::LocalModule` (auto-inserted by `#[vtable]`) resolves correctly when there is no `module!` macro. Assisted-by: opencode:glm-5.2 Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Acked-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Alvin Sun <alvin.sun@linux.dev> Link: https://patch.msgid.link/20260811-fix-fops-owner-v10-3-7e71776f9dbe@linux.dev [ Fixed `clippy::undocumented_unsafe_blocks` lint by wrapping with a block. Added interim `#[allow(dead_code)]`. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-08-12rust: module: add `THIS_MODULE` const to `ModuleMetadata` traitAlvin Sun
Since `const_refs_to_static` has been stable as of the MSRV bump, a `ThisModule` pointer can now be used in const contexts. Add a `THIS_MODULE` const to the `ModuleMetadata` trait so that modules can provide their `ThisModule` pointer in const contexts such as static `file_operations`. Add a `this_module()` helper to retrieve the `THIS_MODULE` pointer of a given module type, and update `__init` to use it instead of the `THIS_MODULE` static generated by the `module!` macro. The `static THIS_MODULE` generated by the `module!` macro is retained for backwards compatibility with existing users and removed in a later patch once all references have been migrated. Assisted-by: opencode:glm-5.2 Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Acked-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Petr Pavlu <petr.pavlu@suse.com> Signed-off-by: Alvin Sun <alvin.sun@linux.dev> Link: https://patch.msgid.link/20260811-fix-fops-owner-v10-2-7e71776f9dbe@linux.dev Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-08-12rust: module: move module types into `module.rs`Alvin Sun
Move `Module`, `InPlaceModule`, `ModuleMetadata` and `ThisModule` from `lib.rs` into a new `rust/kernel/module.rs`. Re-export them from `lib.rs` to avoid tree-wide changes. Switch six bus driver registrations from `module.0` to the public `ThisModule::as_ptr()` accessor, since the field is no longer visible outside the new `module` submodule. No functional change. Assisted-by: opencode:glm-5.2 Suggested-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/all/DJFIQPLOVO4T.1K8T0VZM30LDA@garyguo.net/ Reviewed-by: Gary Guo <gary@garyguo.net> Acked-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Petr Pavlu <petr.pavlu@suse.com> Signed-off-by: Alvin Sun <alvin.sun@linux.dev> Link: https://patch.msgid.link/20260811-fix-fops-owner-v10-1-7e71776f9dbe@linux.dev Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-08-12Merge patch series "fixes for iomap_bio_read_folio_range_sync"Christian Brauner
Christoph Hellwig <hch@lst.de> says: Two fixes for iomap_bio_read_folio_range_sync, a potential kernel crash when tweaking the device integrity behvavior using sysfs, and a missing bio_uninit that the Sashiko review of the first fix found. * patches from https://patch.msgid.link/20260804124404.737145-1-hch@lst.de: iomap: iomap_bio_read_folio_range_sync is missing a call to bio_uninit iomap: don't free integrity payload that doesn't exist Link: https://patch.msgid.link/20260804124404.737145-1-hch@lst.de Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-08-12iomap: iomap_bio_read_folio_range_sync is missing a call to bio_uninitChristoph Hellwig
Which could leak blkg references. Fixes: c03cea42149d ("iomap: add initial support for writes without buffer heads") Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://patch.msgid.link/20260804124404.737145-3-hch@lst.de Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Anuj Gupta <anuj20.g@samsung.com> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-08-12iomap: don't free integrity payload that doesn't existChristoph Hellwig
fs_bio_integrity_alloc might not allocate a bio integrity payload if PI verification is disabled on the block device. Check for that case before calling fs_bio_integrity_free in iomap_bio_read_folio_range_sync to avoid a NULL pointer dereferences. Make the branch cover the PI verification as well - while fs_bio_integrity_verify works without an integrity payload, it requires one to actually do useful work. Fixes: 0b10a370529c ("iomap: support T10 protection information") Cc: stable@vger.kernel.org # v7.1 Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Anuj Gupta <anuj20.g@samsung.com> Reviewed-by: Kanchan Joshi <joshi.k@samsung.com> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Link: https://patch.msgid.link/20260804124404.737145-2-hch@lst.de Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-08-12super: fix dying superblock warning messagesKarl Mehltretter
WARN_ON_ONCE() takes a condition, not a message. The string literals are always true, so the warnings still trigger but the messages are never printed. Use WARN_ONCE(1, ...) instead to print the messages and keep the once-only behavior. Found with a Coccinelle script. Clang's -Wstring-conversion also flags such calls but is not enabled in kernel builds. Fixes: f0cd988016f6 ("fs: massage locking helpers") Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Link: https://patch.msgid.link/20260808123802.73687-1-kmehltretter@gmail.com Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-08-12docs: fix grammatical error in iomap docsBenjamin Wu
Change "This origins" -> "The origins" Signed-off-by: Benjamin Wu <benjamin.wu37@gmail.com> Link: https://patch.msgid.link/20260810063704.355933-1-benjamin.wu37@gmail.com Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>