summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-08-13selftests/bpf: Fix for veristat file/prog filters processingEduard Zingerman
At the moment veristat filtering behaves unexpectedly for the following filter expression: -f !file/prog The expression rejects all programs with name 'prog', and all programs in a file with name 'file'. This commit fixes the expression to exclude only a program 'prog' from a file 'file'. Additionally, the commit makes empty filters like '-f ""' or '-f "/"' and error. Here is the filtering behaviour compared old versus new: | filter | file | prog | old verdict | new verdict | |----------+------+------+-------------+-------------| | !foo | foo | bar | skipped | skipped | | !foo | bar | foo | skipped | skipped | | !foo | bar | bar | processed | processed | | !foo/bar | foo | bar | skipped | skipped | | !foo/bar | foo | buz | skipped | processed | (!) | !foo/bar | bar | bar | skipped | processed | (!) | !foo/ | foo | bar | skipped | skipped | | !foo/ | bar | bar | processed | processed | | !/bar | foo | bar | skipped | skipped | | !/bar | foo | foo | processed | processed | | !/ | foo | bar | processed | error | (!) | ! | foo | bar | processed | error | (!) |----------+------+------+-------------+-------------| | foo | foo | bar | processed | processed | | foo | bar | foo | processed | processed | | foo | bar | bar | skipped | skipped | | foo/bar | foo | bar | processed | processed | | foo/bar | foo | buz | skipped | skipped | | foo/bar | bar | bar | skipped | skipped | | foo/ | foo | bar | processed | processed | | foo/ | bar | bar | skipped | skipped | | /bar | foo | bar | processed | processed | | /bar | foo | foo | skipped | skipped | | / | foo | bar | processed | error | (!) | | foo | bar | skipped | error | (!) Fixes: 10b1b3f3e56a ("selftests/bpf: consolidate and improve file/prog filtering in veristat") Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20260811-veristat-filter-fix-v2-1-6c234c4cd6ef@gmail.com
2026-08-13checkpatch: add NOKPROBE_SYMBOL to the whitelist of lines that can occur ↵Paul Walmsley
immediately after functions It's customary for NOKPROBE_SYMBOL() macro usage to appear immediately after a function's final closing brace, but checkpatch doesn't know that yet. As a result, checkpatch --strict incorrectly flags this common kernel pattern, e.g., CHECK: Please use a blank line after function/struct/union/enum declarations 33: FILE: arch/riscv/kernel/traps.c:273: } +NOKPROBE_SYMBOL(probe_single_step_handler); Fix by adding NOKPROBE_SYMBOL to the whitelist of patterns that are cleared to appear immediately after functions. Link: https://lore.kernel.org/130be7db-6098-86a4-60fe-0c1a5d9e30ba@kernel.org Signed-off-by: Paul Walmsley <pjw@kernel.org> Acked-by: Joe Perches <joe@perches.com> Cc: Nam Cao <namcao@linutronix.de> Cc: Jisheng Zhang <jszhang@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-13Squashfs: check block offset is not negativePhillip Lougher
If a negative offset is read off disk (for example the offset into the decompressed fragment block), this will cause squashfs_copy_data() to perform an out of bounds access. Fix by checking if offset is negative, and returning 0. This matches existing behaviour where an offset beyond the block returns 0 bytes copied. To trigger this out of bounds access requires a crafted Squashfs filesystem and CAP_SYS_ADMIN to mount it. Unprivileged users will not be able to mount such a filesystem, but once mounted, an unprivileged user can trigger the out of bounds access by reading the crafted file with the negative offset. Link: https://lore.kernel.org/20260807162951.672510-1-phillip@squashfs.org.uk Fixes: f400e12656ab ("Squashfs: cache operations") Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk> Reported-by: Yuejie Shi <syjcnss@gmail.com> Closes: https://lore.kernel.org/all/20260803032735.81785-1-syjcnss@gmail.com/ Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-13signal: factor out the kernel reserved si_code checkBradley Morgan
The check that prevents userspace from sending siginfo with si_code values reserved to the kernel is duplicated across do_rt_sigqueueinfo(), do_rt_tgsigqueueinfo() and do_pidfd_send_signal(). Move the check into a helper so the rule lives in one place. Link: https://lore.kernel.org/20260806133013.4341-1-include@grrlz.net Signed-off-by: Bradley Morgan <include@grrlz.net> Reviewed-by: Andrew Morton <akpm@linux-foundation.org> Acked-by: Oleg Nesterov <oleg@redhat.com> Cc: Christian Brauner <brauner@kernel.org> Cc: Thomas Gleixner <tglx@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-13ocfs2: fix readdir position truncation on 32-bit kernelsZhan Xusheng
In ocfs2_dir_foreach_blk_el(), the directory cookie position is rebuilt with ctx->pos = (ctx->pos & ~(sb->s_blocksize - 1)) | offset; `ctx->pos` is loff_t (signed 64-bit), while `sb->s_blocksize` is unsigned long. On 32-bit kernels unsigned long is 32-bit, so the mask ~(sb->s_blocksize - 1) is computed as a 32-bit unsigned value (e.g. 0xfffff000 for a 4 KiB block size). In the AND expression with the 64-bit `ctx->pos`, that unsigned operand is zero-extended to 64 bits per the usual arithmetic conversions, yielding 0x00000000fffff000. The high 32 bits of `ctx->pos` are silently cleared, even though directory size is allowed to exceed 4 GiB. When readdir() crosses the 4 GiB boundary on a 32-bit kernel the position is reset back into the first 4 GiB block, making the re-validation path re-enumerate already-returned dirents indefinitely. This is ocfs2_dir_foreach_blk_el(), the extent-list readdir path taken for all non-inline directories, so a directory large enough to cross 4 GiB reaches it. This is the same class of bug that commit 3dce5bb82c97 ("exfat: Fix bitwise operation having different size") fixed in exfat, and the fix mirrors the equivalent ext4 fix in this series. Cast the operand to loff_t so the mask is 64-bit before the AND: ctx->pos = (ctx->pos & ~((loff_t)sb->s_blocksize - 1)) | offset; 64-bit kernels are unaffected. Link: https://lore.kernel.org/20260806022044.167962-3-zhanxusheng@xiaomi.com Fixes: ccd979bdbce9 ("[PATCH] OCFS2: The Second Oracle Cluster Filesystem") Signed-off-by: Zhan Xusheng <zhanxusheng@xiaomi.com> Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com> Cc: Mark Fasheh <mark@fasheh.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Junxiao Bi <junxiao.bi@oracle.com> Cc: Changwei Ge <gechangwei@live.cn> Cc: Jun Piao <piaojun@huawei.com> Cc: Heming Zhao <heming.zhao@suse.com> Cc: Andreas Dilger <adilger.kernel@dilger.ca> Cc: Jan Kara <jack@suse.cz> Cc: Ojaswin Mujoo <ojaswin@linux.ibm.com> Cc: "Ritesh Harjani (IBM)" <ritesh.list@gmail.com> Cc: Ted Ts'o <tytso@mit.edu> Cc: "zhangyi (F)" <yi.zhang@huawei.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-13ocfs2: fix cached cluster count after suballocator reclaimMatthias Goergens
When reclaiming a suballocator block group, first reduce the on-disk cluster count by cl_cpg. The current code then subtracts that new count (fe->i_clusters) from the old cached count (OCFS2_I(alloc_inode)->ip_clusters). For an allocator with N block groups, that leaves the cache at N * cl_cpg - (N * cl_cpg - cl_cpg) = cl_cpg i.e. ip_clusters -= (fe->i_clusters - cl_cpg) leaves ip_clusters equal to cl_cpg regardless of N. This happens to be correct when reclaiming from two block groups, but undercounts the clusters from three block groups onwards. The incorrect cache value is also used immediately to update i_blocks. Assign the updated on-disk count to the cache, matching the allocation and inode refresh paths. In a QEMU test using a clean 256 MiB OCFS2 image and a 10,000-file create/delete workload, the first buggy reclaim left the on-disk (fe->i_clusters) and cached (ip_clusters) counts at 2048 and 512 clusters respectively; later reclaims underflowed the cache. With this change, the cache matched the on-disk count across all four reclaims: 2048, 1536, 1024, and 512 clusters. Link: https://lore.kernel.org/20260805113920.385959-1-matthias.goergens@gmail.com Fixes: 4a54331616b3 ("ocfs2: give ocfs2 the ability to reclaim suballocator free bg") Signed-off-by: Matthias Goergens <matthias.goergens@gmail.com> Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com> Cc: Mark Fasheh <mark@fasheh.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Junxiao Bi <junxiao.bi@oracle.com> Cc: Changwei Ge <gechangwei@live.cn> Cc: Jun Piao <piaojun@huawei.com> Cc: Heming Zhao <heming.zhao@suse.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-13ocfs2: fix circular locking dependency in ocfs2_init_acl()Krystian Kaniewski
A lockdep warning indicates a circular locking dependency between `&oi->ip_xattr_sem` and `&journal->j_trans_barrier`: WARNING: possible circular locking dependency detected is trying to acquire lock: (&oi->ip_xattr_sem){++++}-{4:4}, at: ocfs2_init_acl+0x2fd/0x7e0 fs/ocfs2/acl.c:367 but task is already holding lock: (&journal->j_trans_barrier){.+.+}-{4:4}, at: ocfs2_start_trans+0x3ab/0x700 fs/ocfs2/journal.c:369 The deadlock involves two code paths: Path 1 (setxattr) where `ocfs2_xattr_set()` acquires `ip_xattr_sem` (write) and then starts a transaction, which acquires `j_trans_barrier` (read); and Path 2 (mkdir/mknod) where `ocfs2_mknod()` starts a transaction (`j_trans_barrier` read) and then calls `ocfs2_init_acl()`, which attempts to acquire `ip_xattr_sem` (read) on the parent directory to retrieve the default ACL. Because rw_semaphores are subject to writer priority, a pending writer on `j_trans_barrier` (e.g., the journal commit thread) can cause Path 1 to block, while Path 2 is blocked waiting for Path 1 to release `ip_xattr_sem`. The patch fixes the lock ordering by precomputing the ACL state before starting the OCFS2 transaction, while preserving POSIX ACL storage semantics and the existing inode/security initialization order. By reading the parent directory's default ACL and preparing the new inode's ACLs outside the transaction, `ip_xattr_sem` is always acquired before `j_trans_barrier`. `struct ocfs2_acl_state` encapsulates the prepared ACL state, while `ocfs2_acl_init_prepare()` and `ocfs2_acl_init_release()` avoid code duplication between `ocfs2_mknod()` and `ocfs2_init_security_and_acl()`. `ocfs2_calc_xattr_init()` and `ocfs2_init_acl()` use this precomputed state, removing internal `ip_xattr_sem` acquisition and redundant disk reads. Additionally, remove the `ip_xattr_sem` acquisition from `ocfs2_xattr_set_handle()`. This function is only used while initializing a new inode that has not yet been inserted into the inode hash or attached to a dentry, meaning there is no risk of concurrent access and the lock is unnecessary. Link: https://lore.kernel.org/4094de06-9b69-4174-b2ee-08126dffc693@mail.kernel.org Fixes: 16c8d569f570 ("ocfs2/acl: use 'ip_xattr_sem' to protect getting extended attribute") Signed-off-by: Krystian Kaniewski <krystianmkaniewski@gmail.com> Assisted-by: Gemini:gemini-3.5-flash Gemini:gemini-3.1-pro-preview syzbot Reported-by: syzbot+4007ab5229e732466d9f@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=4007ab5229e732466d9f Link: https://syzkaller.appspot.com/ai_job?id=cc75363d-c672-499e-8fc5-44bcdc1cee39 Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com> Cc: Mark Fasheh <mark@fasheh.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Junxiao Bi <junxiao.bi@oracle.com> Cc: Changwei Ge <gechangwei@live.cn> Cc: Jun Piao <piaojun@huawei.com> Cc: Heming Zhao <heming.zhao@suse.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-13ocfs2: validate DIO orphan slot during inode readZhengYuan Huang
[BUG] A corrupted append-DIO dinode (high byte at offset 0xa1 corrupted from 0 to 1) can carry an i_dio_orphaned_slot outside the mounted filesystem slot range and trigger a use-after-free error: BUG: KASAN: slab-use-after-free in ocfs2_get_system_file_inode+0x780/0x820 fs/ocfs2/sysfile.c:102 Read of size 8 at addr ffff88800b767c00 by task kworker/u8:3/85 Call Trace: ... ocfs2_get_system_file_inode+0x780/0x820 fs/ocfs2/sysfile.c:102 ocfs2_wipe_inode+0x292/0xf70 fs/ocfs2/inode.c:840 ocfs2_delete_inode fs/ocfs2/inode.c:1155 [inline] ocfs2_evict_inode+0x6c9/0x1170 fs/ocfs2/inode.c:1295 evict+0x38e/0x8f0 fs/inode.c:810 iput_final fs/inode.c:1914 [inline] iput fs/inode.c:1966 [inline] iput+0x55b/0x8b0 fs/inode.c:1926 ocfs2_recover_orphans+0x610/0xe40 fs/ocfs2/journal.c:2374 ocfs2_complete_recovery+0x5af/0xd00 fs/ocfs2/journal.c:1373 ... [CAUSE] ocfs2_del_inode_from_orphan() uses i_dio_orphaned_slot to index the slot-local system inode cache. The dinode validator does not check this active slot, so an out-of-range value produces an invalid cache entry pointer that is dereferenced as an inode pointer. [FIX] Reject an active i_dio_orphaned_slot outside the slot range during dinode validation, before DIO orphan recovery can consume it. Link: https://lore.kernel.org/20260803030007.3993199-3-gality369@gmail.com Fixes: 06ee5c75b575 ("ocfs2: add functions to add and remove inode in orphan dir") Signed-off-by: ZhengYuan Huang <gality369@gmail.com> Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com> Cc: Mark Fasheh <mark@fasheh.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Junxiao Bi <junxiao.bi@oracle.com> Cc: Changwei Ge <gechangwei@live.cn> Cc: Jun Piao <piaojun@huawei.com> Cc: Heming Zhao <heming.zhao@suse.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-13ocfs2: validate orphan slot during inode readZhengYuan Huang
Patch series "ocfs2: validate active orphan slots during inode read". OCFS2 trusts active ordinary and append-DIO orphan slots read from dinodes. A corrupted slot can therefore index osb_orphan_wipes or the slot-local system-inode cache outside their allocations before the corruption is reported. Patch 1 validates the ordinary orphan slot used by inode wipe processing. Patch 2 validates the append-DIO orphan slot used by DIO completion and orphan recovery. Both checks reject corrupt metadata at the existing inode validation boundary. This patch (of 2): [BUG] A corrupted dinode with OCFS2_ORPHANED_FL can carry an i_orphaned_slot outside the mounted filesystem slot range. ocfs2_wipe_inode() uses it to index osb_orphan_wipes before looking up the orphan directory, causing an out-of-bounds memory access. BUG: KASAN: slab-use-after-free in ocfs2_get_system_file_inode+0x780/0x820 fs/ocfs2/sysfile.c:102 Read of size 8 at addr ffff88800b767c00 by task kworker/u8:3/85 Call Trace: ... ocfs2_get_system_file_inode+0x780/0x820 fs/ocfs2/sysfile.c:102 ocfs2_wipe_inode+0x292/0xf70 fs/ocfs2/inode.c:840 ocfs2_delete_inode fs/ocfs2/inode.c:1155 [inline] ocfs2_evict_inode+0x6c9/0x1170 fs/ocfs2/inode.c:1295 evict+0x38e/0x8f0 fs/inode.c:810 iput_final fs/inode.c:1914 [inline] iput fs/inode.c:1966 [inline] iput+0x55b/0x8b0 fs/inode.c:1926 ocfs2_recover_orphans+0x610/0xe40 fs/ocfs2/journal.c:2374 ocfs2_complete_recovery+0x5af/0xd00 fs/ocfs2/journal.c:1373 ... [CAUSE] ocfs2_validate_inode_block() validates i_suballoc_slot but leaves the active ordinary orphan slot unchecked. Downstream consumers assume that the value is smaller than osb->max_slots. [FIX] Reject an active i_orphaned_slot outside the slot range during dinode validation, before the inode reaches orphan wipe processing. Link: https://lore.kernel.org/20260803030007.3993199-1-gality369@gmail.com Link: https://lore.kernel.org/20260803030007.3993199-2-gality369@gmail.com Fixes: b4df6ed8db0c ("[PATCH] ocfs2: fix orphan recovery deadlock") Signed-off-by: ZhengYuan Huang <gality369@gmail.com> Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com> Cc: Mark Fasheh <mark@fasheh.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Junxiao Bi <junxiao.bi@oracle.com> Cc: Changwei Ge <gechangwei@live.cn> Cc: Jun Piao <piaojun@huawei.com> Cc: Heming Zhao <heming.zhao@suse.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-13selftests/prctl: fix non-anonymous VMA mapping in set-anon-vma-name testHongfu Li
The test creates a non-anonymous VMA (ptr_not_anon) via mmap() with MAP_PRIVATE but without MAP_ANONYMOUS, using fd=0 (stdin) as the file descriptor. This always fails because fd=0 is not a regular file, and the failure was hidden because ASSERT_NE() incorrectly checked for NULL instead of MAP_FAILED. Fix by using mkstemp() + ftruncate() to create a real temporary file, then mapping it with MAP_PRIVATE to obtain a genuine file-backed VMA. Also fix the mmap() error checks to use MAP_FAILED instead of NULL, and pass fd=-1 for the anonymous mapping for clarity. The temp file is unlinked immediately so it does not persist on disk. Link: https://lore.kernel.org/20260803103046.14324-1-hongfu.li@linux.dev Signed-off-by: Hongfu Li <lihongfu@kylinos.cn> Cc: Shuah Khan <shuah@kernel.org> Cc: Wei Yang <richard.weiyang@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-13MAINTAINERS: add IRC and patchwork for LTPPetr Vorel
LTP project recently switched to patchwork.kernel.org, document it. Add also IRC channel. Link: https://github.com/linux-test-project/ltp/commit/3590f66120d1c875bef5d573c66c4c0d340c1612 Link: https://lore.kernel.org/ltp/20260731054548.133241-1-pvorel@suse.cz/ Link: https://lore.kernel.org/20260803115821.238704-1-pvorel@suse.cz Signed-off-by: Petr Vorel <pvorel@suse.cz> Suggested-by: Cyril Hrubis <chrubis@suse.cz> Reviewed-by: Cyril Hrubis <chrubis@suse.cz> Reviewed-by: Li Wang <li.wang@linux.dev> Reviewed-by: Andrea Cervesato <andrea.cervesato@suse.com> Cc: Anders Roxell <anders.roxell@linaro.org> Cc: Ben Copeland <ben.copeland@linaro.org> Cc: Jan Stancek <jstancek@redhat.com> Cc: Tim Bird <tim.bird@sony.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-13include/linux/list.h: mark list_add and __list_add as __always_inlineJordan R Abrahams-Whitehead
This commit resolves an issue where modpost section verification fails due to section mismatches between list_add and its callers. At present, list_add (and its internal __list_add) are called from both .text and .init code sections. Since inlining can vary per call site, list_add can be 4 different states: list_add in text with arguments to non-.init.data values list_add in init with arguments to static .init.data values list_add in init with arguments to non-.init.data values list_add in text with arguments to static .init.data values It is last instance that ends up causing the section mismatch caused by constant propagation of the address of static libs inside the `dir_add` as seen below (with the dir_list being defined statically in initramfs.c, resting in .init.data). WARNING: modpost: vmlinux.o: section mismatch in reference: __list_add (section: .text.unlikely.) -> dir_list (section: .init.data) Because of these section matching requirements, semantically, __list_add and list_add MUST be inlined. This will then ensure callers inside .init will receive a list_add that exists and refers to only .init data, and list_add code in .text sections will only refer to non-init data. This issue manifests predominently in AutoFDO with clang, which is very hesitant to inline cold functions such as list_add even when marked `inline`. Marking them as `__always_inline` therefore matches the existing semantic constraints imposed by modpost's section mismatch checks. Link: https://lore.kernel.org/20260731-always-inline-list-add-v1-1-d29f54ce5477@google.com Link: https://lore.kernel.org/all/CANn89iJVQe=wedLheJmjZjOTJsWHijT0jZs=iRxKssJZbjAxHw@mail.gmail.com/ Signed-off-by: Jordan R Abrahams-Whitehead <ajordanr@google.com> Suggested-by: Nathan Chancellor <nathan@kernel.org> Suggested-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Reported-by: Giuliano Procida <gprocida@google.com> Reported-by: Yabin Cui <yabinc@google.com> Closes: https://github.com/ClangBuiltLinux/linux/issues/2173 Cc: Bill Wendling <morbo@google.com> Cc: Justin Stitt <justinstitt@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-13tools/mm: prevent page_owner_sort from truncating inputWarren Xiong
page_owner_sort opens the output file with "w" before reading the input. If both paths refer to the same file, this truncates the input and the tool silently processes zero records before returning success. Delay opening the output file until all input records have been loaded into memory. This allows the tool to sort a file in place without truncating data before it has been consumed. Link: https://lore.kernel.org/20260730015809.3819606-1-warren.xiong@ugreen.com Signed-off-by: Warren Xiong <warren.xiong@ugreen.com> Reviewed-by: Andrew Morton <akpm@linux-foundation.org> Cc: Vishal Moola <vishal.moola@gmail.com> Cc: Ye Liu <ye.liu@linux.dev> Cc: Zhen Ni <zhen.ni@easystack.cn> Cc: Zi Yan <ziy@nvidia.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-13hung_task: update DETECT_HUNG_TASK_BLOCKER Kconfig helpXibo Wang
The help text still says the feature only covers mutexes, but blocker tracking has since been extended to semaphores and rwsems. Update the description to match the supported lock types. Link: https://lore.kernel.org/20260730061854.176547-1-wangxb12@chinatelecom.cn Cc: Petr Mladek <pmladek@suse.com> Signed-off-by: Xibo Wang <wangxb12@chinatelecom.cn> Suggested-by: Lance Yang <lance.yang@linux.dev> Reviewed-by: Lance Yang <lance.yang@linux.dev> Cc: "Masami Hiramatsu (Google)" <mhiramat@kernel.org> Cc: Petr Mladek <pmladek@suse.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-13taskstats: fold the two cpumask handlers into oneBradley Morgan
cmd_attr_register_cpumask() and cmd_attr_deregister_cpumask() differed only in which attribute they parsed and which action they passed on, so take both as arguments. __free(free_cpumask_var) then removes the goto. No functional change. Link: https://lore.kernel.org/20260728202104.17839-3-include@grrlz.net Signed-off-by: Bradley Morgan <include@grrlz.net> Cc: Balbir Singh <bsingharora@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-13taskstats: drop the dead NULL attribute check in parse()Bradley Morgan
Patch series "taskstats: tidy up the cpumask command path". Two small cleanups from reading kernel/taskstats.c. No functional change in either one. This patch (of 2): taskstats_user_cmd() only calls the cpumask handlers after checking the same info->attrs[] entry, so parse() never sees a NULL attribute. Drop the check and its odd "return 1", which no caller tested for anyway. No functional change. Link: https://lore.kernel.org/20260728202104.17839-1-include@grrlz.net Link: https://lore.kernel.org/20260728202104.17839-2-include@grrlz.net Signed-off-by: Bradley Morgan <include@grrlz.net> Cc: Balbir Singh <bsingharora@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-13lib/xz: fix commentsLasse Collin
Link: https://lore.kernel.org/20260614160521.924710-2-lasse.collin@tukaani.org Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Cc: David Laight <david.laight.linux@gmail.com> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-13lib/xz: use size_t instead of uint32_t in a few placesLasse Collin
Reduce the number of uint32_t <-> size_t conversions a little. Eliminating such conversions entirely would require changing almost all uint32_t to size_t, which would look confusing and increase the sizes of the structs even more. Going the other way, converting everything to uint32_t, isn't possible because the input and output buffers use size_t in struct xz_buf. Now both arguments to min() have the same type. This is required to for compatibility with PowerPC boot code[1] whose min() is strict like include/linux/minmax.h was before the commit d03eba99f5bf ("minmax: allow min()/max()/clamp() if the arguments have the same signedness."). Swap the order of the "state" and "len" in struct lzma_dec to avoid padding in the middle of the struct when size_t is 64 bits. The reordering doesn't change the size of the struct; the padding just appears at the end instead. dict_flush() used to truncate size_t to uint32_t when returning. This wasn't a bug; the value is always small enough. Link: https://lore.kernel.org/20260614160521.924710-1-lasse.collin@tukaani.org Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Reported-by: Nathan Chancellor <nathan@kernel.org> Closes: https://lore.kernel.org/lkml/20260610232323.GA1071374@ax162/ [1] Reviewed-by: Thorsten Blum <thorsten.blum@linux.dev> Cc: David Laight <david.laight.linux@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-13ipc: only destroy orphaned shm segments on sysctl writeJianlin Shi
proc_ipc_dointvec_minmax_orphans() currently calls shm_destroy_orphaned() whenever shm_rmid_forced is set, including on sysctl reads. Reading /proc/sys/kernel/shm_rmid_forced should not take shm_ids rwsem for write and walk all segments. Only run the cleanup when the sysctl is written and the forced RMID policy is enabled. When shm_rmid_forced=1, monitoring tools that read /proc/sys/kernel/shm_rmid_forced trigger the cleanup on every read. Link: https://lore.kernel.org/all/?q=only+destroy+orphaned+shm+segments+on+sysctl+write Link: https://lore.kernel.org/tencent_738A8BC6E9EA205F555E4B0DAA154D4F8E0A@qq.com Signed-off-by: Jianlin Shi <shijianlin11@foxmail.com> Acked-by: Davidlohr Bueso <dave@stgolabs.net> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-13lib/xz: replace min_t with minThorsten Blum
Use the simpler min() macro since the values are unsigned and compatible. Link: https://lore.kernel.org/20260609150030.634570-1-lasse.collin@tukaani.org Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Reviewed-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-13bpftool: Fix double close in map dumpYuan Chen
map_dump() closes the map fd in its error path, and do_dump() then closes the same fd again after a successful dump. Closing an already closed fd leaves errno set to EBADF, which poisons later errno checks such as the batch file read check in do_batch(). Let do_dump() own the fd and remove the close from map_dump(). The same double-close pattern exists in do_show_subset(): both show_map_close_json() and show_map_close_plain() already close the fd, so drop the extra close() there as well. Also propagate the error when bpf_map_get_info_by_fd() fails on a subsequent map in do_dump(): set err = -1 before breaking out of the loop, so a later failure is not silently hidden after an earlier iteration succeeded. Fixes: 99f9863a0c45f ("bpftool: Match maps by name") Signed-off-by: Yuan Chen <chenyuan@kylinos.cn> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20260810142224.2907373-2-chenyuan_fl@163.com
2026-08-13bpf: Fix func_info_aux desync after dead code eliminationKumar Kartikeya Dwivedi
The verifier keeps per-subprogram metadata in three parallel arrays: subprog_info, func_info, and func_info_aux. Dead code elimination can remove whole subprograms, and adjust_subprog_starts_after_remove() shifts subprog_info and func_info to close the gap, but leaves func_info_aux in place. From that point on, func_info_aux[i] no longer describes subprogram i. Shift func_info_aux together with func_info so the three arrays stay aligned after subprogram removal. Reported-by: Sashiko <sashiko-bot@kernel.org> Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20260808064523.DE3E71F000E9@smtp.kernel.org Link: https://lore.kernel.org/bpf/20260812231506.3558128-1-memxor@gmail.com
2026-08-13tracing: Fix race between update_event_fields and, event_define_fieldsMichael Wu
The following sequence may leads race between event_define_fields() and update_event_fields(): CPU0 (loads module A) CPU1 (loads module B) =============================== =============================== load_module(A) load_module(B) notifier_call_chain notifier_call_chain trace_module_notify trace_module_notify mutex_lock(&event_mutex) trace_event_update_all() trace_module_add_events(A) down_write(&trace_event_sem) __register_event(call_A) __add_event_to_tracers(call_A) event_define_fields(call_A) for each f: list_for_each_entry(field, list_add(&f->link, &class->fields, link) &class->fields) field = class->fields->next; Where access to the class->fields is not protected by the event_mutex in trace_event_update_all(). This produces the following panic: Unable to handle kernel access ... at virtual address 0000000000000018 pc : update_event_fields+0xf8/0x368 Call trace: update_event_fields+0xf8/0x368 trace_event_update_all+0x7c/0x2b4 trace_module_notify+0x4c/0x1dc notifier_call_chain+0x84/0x168 blocking_notifier_call_chain_robust+0x64/0xd4 load_module+0x10c8/0x123c __arm64_sys_finit_module+0x230/0x31c Fix by taking event_mutex in trace_event_update_all() before trace_event_sem. Cc: stable@vger.kernel.org Fixes: b3bc8547d3be ("tracing: Have TRACE_DEFINE_ENUM affect trace event types as well") Link: https://patch.msgid.link/2e5730d2-c631-da41-3a3a-ae35bb4895f3@allwinnertech.com Signed-off-by: Michael Wu <michael@allwinnertech.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-08-13tracing: Fix NULL pointer dereference in module event cache removalHui Su
A module-only event filter such as ":mod:foo" is cached with a NULL event_mod->match when foo has not been loaded. If a later write tries to remove a specific match from the same module, remove_cache_mod() passes the NULL cached match to strcmp(), causing a NULL pointer dereference. The issue can be reproduced from userspace: echo ':mod:trace_events_kunit_missing' > /sys/kernel/tracing/set_event echo '!foo_bar:mod:trace_events_kunit_missing' >> /sys/kernel/tracing/set_event The second write must be a concatenation (">>") to not include O_TRUNC as that would cause ftrace_clear_events() to clear the cached modules lines. The crash was reproduced on x86_64 QEMU while KUnit workers contended on the event tracing path: BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode RIP: 0010:strcmp+0x10/0x30 Call Trace: __ftrace_set_clr_event_nolock+0x373/0x4a0 ftrace_set_clr_event+0xf0/0x180 ftrace_event_write+0xdf/0x110 vfs_write+0xf6/0x440 ksys_write+0x68/0xe0 do_syscall_64+0xf9/0x540 entry_SYSCALL_64_after_hwframe+0x77/0x7f Check event_mod->match before comparing it, consistent with the existing NULL checks for the cached system and event fields. The mismatched removal continues to return -EINVAL; a broad cached module filter is removed with "!:mod:<module>". Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260811173902.1927376-2-sh_def@163.com Fixes: b355247df104 ("tracing: Cache \":mod:\" events for modules not loaded yet") Reported-by: syzbot+4d3143c8e28f6266c636@syzkaller.appspotmail.com Closes: https://lore.kernel.org/lkml/6a7a6b7f.9c11d2ce.289b96.00f8.GAE@google.com/ Signed-off-by: Hui Su <sh_def@163.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-08-13Input: rmi4 - use platform data instead of query, when availableDavid Heidelberg
Platform data may define touchscreen-x-mm and touchscreen-y-mm, but these were quietly overridden by data provided by sensor. Signed-off-by: David Heidelberg <david@ixit.cz> Link: https://patch.msgid.link/20260731-respect-x-y-mm-v1-0-3e85a4bec745@ixit.cz Link: https://patch.msgid.link/20260806-respect-x-y-mm-v2-1-e0681ed3d63c@ixit.cz Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-08-13ASoC: tas2781: Refactor calibration start kcontrol creation to separate helperShenghao Ding
Move the tas2781-specific calibration start kcontrol initialization logic out of tasdevice_create_cali_ctrls() into a new dedicated helper function create_tas2781_cali_start_ktrl(). This change eliminates duplicate inline code in the main calibration control registration routine, improves code readability, and makes further extension for custom calibration parameters much easier. No functional behavior changes. Signed-off-by: Shenghao Ding <shenghao-ding@ti.com> Link: https://patch.msgid.link/20260813080540.1030-1-shenghao-ding@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-13Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Cross-merge networking fixes after downstream PR (net-7.2-rc8). No conflicts. Adjacent changes: drivers/net/ethernet/wangxun/ngbe/ngbe_main.c 5f3a13e0bb5e ("net: ngbe: fix NULL pointer dereference in non-MSI-X interrupt enabling") d661abdc30c2 ("net: ngbe: correct misleading interrupt comment") drivers/net/ipvlan/ipvlan_main.c e16e960d55a4 ("ipvlan: inherit needed_headroom and needed_tailroom from phy_dev") 00a40d809207 ("ipvlan: Support per-netns netdev unregistration.") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-13vfio/pci: Remove the pcie check for VFIO_PCI_ERR_IRQ_INDEXFarhan Ali
The error signaling is configured for the vast majority of devices and it's extremely rare that it fires anyway. Removing the pcie check will allow userspace to be notified on errors for legacy PCI devices. The Internal Shared Memory (ISM) device on s390 is one such device. For PCI devices on IBM s390 error recovery involves platform firmware and notification to operating system is done by architecture specific way. So the ISM device can still be recovered when notified of an error. Reviewed-by: Julian Ruess <julianr@linux.ibm.com> Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com> Reviewed-by: Alex Williamson <alex@shazbot.org> Signed-off-by: Farhan Ali <alifm@linux.ibm.com> Link: https://lore.kernel.org/r/20260630165553.725-4-alifm@linux.ibm.com Signed-off-by: Alex Williamson <alex@shazbot.org>
2026-08-13vfio-pci/zdev: Add a device feature for error informationFarhan Ali
For zPCI devices, we have platform specific error information. The platform firmware provides this error information to the operating system in an architecture specific mechanism. To enable recovery from userspace for these devices, we want to expose this error information to userspace. Add a new device feature to expose this information. Userspace needs to be provide a buffer of fixed size. This size is provided to userspace via the VFIO_DEVICE_INFO_CAP_ZPCI_BASE capability. Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Farhan Ali <alifm@linux.ibm.com> Link: https://lore.kernel.org/r/20260630165553.725-3-alifm@linux.ibm.com Signed-off-by: Alex Williamson <alex@shazbot.org>
2026-08-13iommufd: Fix UAF in selftest IOPF reportingPeiyang He
IOMMUFD selftest TRIGGER_IOPF borrows an attach handle from group->pasid_array without synchronizing against PASID detach, then a concurrent iommu_report_device_fault() can dereference that borrowed handle's domain pointer after the detach erases the handle and frees the backing struct iommufd_attach_handle. TRIGGER_IOPF then dereferences the freed handle, causing a UAF. Fix by adding a iopf_rwsem in mock_dev to follow the expected design of a real driver. Hold its read side across the whole iommu_report_device_fault() call, and its write side around every path that attaches, detaches, or replaces a device domain. This can block new reports and drains in-flight reports before an old attach handle or the IOPF fault parameter can be removed. Also take the write side while registering a mock device, since it can invoke the mock driver's default-domain attach callback. Closes: https://lore.kernel.org/all/D5E3AA41600B2056+f4e15662-bd2b-43ea-91cb-518de429e72c@smail.nju.edu.cn/ Fixes: ddee19971081 ("iommufd/selftest: Add IOPF support for mock device") Cc: stable@vger.kernel.org Suggested-by: Jason Gunthorpe <jgg@ziepe.ca> Assisted-by: Codex:gpt-5.6-terra Signed-off-by: Peiyang He <peiyang_he@smail.nju.edu.cn> Link: https://patch.msgid.link/38C8DF0A118B7176+20260811095551.2756745-1-peiyang_he@smail.nju.edu.cn Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-08-13Merge branch 'bpf-introduce-global-percpu-data'Andrii Nakryiko
Leon Hwang says: ==================== bpf: Introduce global percpu data This patch set introduces global percpu data, similar to commit 6316f78306c1 ("Merge branch 'support-global-data'"), to reduce restrictions in C for BPF programs. With this enhancement, it becomes possible to define and use global percpu variables, like the DEFINE_PER_CPU() macro in the kernel include/linux/percpu-defs.h. The section name for global peurcpu data is ".percpu". Even though, a one-byte percpu variable (e.g., char run SEC(".percpu") = 0;) can trigger a crash with Clang 17 [1], users are expected to use such small variables as global percpu data with newer Clang versions, which don't have the issue. The idea stems from the bpfsnoop [2], which itself was inspired by retsnoop [3]. During testing of bpfsnoop on the v6.6 kernel, two LBR (Last Branch Record) entries were observed related to the bpf_get_smp_processor_id() helper. Since commit 1ae6921009e5 ("bpf: inline bpf_get_smp_processor_id() helper"), the bpf_get_smp_processor_id() helper has been inlined on x86_64, reducing the overhead and consequently minimizing these two LBR records. However, the introduction of global percpu data offers a more robust solution. By leveraging the percpu_array map and percpu instruction, global percpu data can be implemented intrinsically. This feature also facilitates sharing percpu information between tail callers and callees or between freplace callers and callees through a shared global percpu variable. Previously, this was achieved using a 1-entry percpu_array map, which this patch set aims to improve upon. Links: [1] https://lore.kernel.org/bpf/fd1b3f58-c27f-403d-ad99-644b7d06ecb3@linux.dev/ [2] https://github.com/bpfsnoop/bpfsnoop [3] https://github.com/anakryiko/retsnoop Changes: v11 -> v12: * Improve feature check in bpf_object__create_maps() in libbpf. * Add percpu_array map support in bpf_map__set_value_size() in libbpf. * Exercise bpf_map__set_value_size() in selftest. * Drop dead warning in bpf_object__populate_internal_map() in libbpf. (Sashiko) * v11: https://lore.kernel.org/bpf/20260806163125.11172-1-leon.hwang@linux.dev/ v10 -> v11: * Drop env->prog->jit_requested check when inlining insns for global percpu data. * Do not autocreate percpu_array map when kernel does not have global percpu data support in libbpf. * Check map->btf_value_type_id in bpftool's is_skel_data(). * Exercise bpf_map__lookup_elem() in selftest. * Collect Reviewed-by tags from Emil, thanks. * Drop all duplicate blank lines in kernel/bpf/*.c. (Emil) * Factor out check_map_mem_read() helper. (Emil) * Check bpf_jit_supports_percpu_insn() first in percpu_array_map_direct_value_addr/meta(). (Emil) * Add comment for 'map->libbpf_type == LIBBPF_MAP_PERCPU' in libbpf's map_is_mmapable(). (Emil) * Init update_flags as a const var in libbpf's bpf_object__populate_internal_map(). (Emil) * Keep is_mmapable_map() beyond is_skel_data() in bpftool. (Emil) * Add 'run' and 'cpu_id' in selftest. (Emil) * Drop subskel test. Verify the generated subskel manually. (Emil) * Add comment to the raw insns in selftest. (Emil) * v10: https://lore.kernel.org/bpf/20260715153254.92010-1-leon.hwang@linux.dev/ v9 -> v10: * Rebase latest bpf-next tree to resolve code conflict in verifier in patch #1. * v9: https://lore.kernel.org/bpf/20260713154024.30851-1-leon.hwang@linux.dev/ v8 -> v9: * Use real name for percpu data maps in libbpf in patch #4. * Add long map name test in patch #6. * Move parse_cpu_mask_file() to test_percpu_data_on_cpus() in test in patch #6. * Validate map type in get_map_ident() for percpu data maps in patch #5. * Update code comment in verifier in patch #2. (per Andrii) * Pass 'type' to internal_map_name in libbpf in patch #4. (per Andrii) * Factor out the helper is_skel_data() in bpftool in patch #5. (per Quentin and Andrii) * v8: https://lore.kernel.org/bpf/20260629152406.52582-1-leon.hwang@linux.dev/ v7 -> v8: * Send patch #1 and #2 separately that fix interpreter fallback issues. (Andrii) * Use 'array->elem_size' to avoid 'range' local variable in percpu_array_map_direct_value_meta(). (Andrii) * Keep original map name for percpu data's map in libbpf. (Andrii) * Factor out helper bpf_map_is_skel_data() in bpftool. (Andrii) * Update commit message of direct access read-only percpu_array map. (Andrii) * Add test to verify that it is disallowed to directly write data of read-only percpu_array map. (Andrii) * Drop unused 'num_cpus' in test. (bot+bpf-ci) * Factor out helper test_percpu_data_on_cpus() in test. (bot+bpf-ci) * v7: https://lore.kernel.org/bpf/20260622143557.22955-1-leon.hwang@linux.dev/ v6 -> v7: * Use tgt_endian() in bpf_gen__map_update_elem() in patch #6. (Sashiko) * Use sizeof(args) in verifier_snprintf test in patch #10. (Sashiko) * Drop xlated test of v6. (Alexei) * v6: https://lore.kernel.org/bpf/20260615152646.27639-1-leon.hwang@linux.dev/ v5 -> v6: * Prevent running user addr_space_cast and addr_percpu insns in interpreter. (Sashiko) * Cast __percpu pointer to u64 with (__force unsigned long). (lkp) * Exclude BPF_MAP_TYPE_PERCPU_ARRAY in check_mem_access() before calling bpf_map_direct_read(), and add a test to verify it. (Sashiko, bot+bpf-ci) * Skip percpu data variables for subskeleton in bpftool. (Sashiko) * Protect skel->percpu using mprotect(..., PROT_READ) in light skeleton. (Sashiko, bot+bpf-ci) * Drop roundup() in tests. (Sashiko) * Call test_global_percpu_data_verifier_log() without test__start_subtest(). (Sashiko) * Cast insn->imm to __u64 with (__u32) in xlated test. (Sashiko) * Check cnt using the new idx in xlated test. (Sashiko) * v5: https://lore.kernel.org/bpf/20260608145113.65857-1-leon.hwang@linux.dev/ v4 -> v5: * Add prog->jit_requested check to prevent running percpu data in interpreter in patch #1. * Factor out verifier log tests using its own patch. * Address comments from Alexei: * Move map_type check from check_mem_access() to bpf_map_direct_read() in patch #2. * Move BPF_MAP_TYPE_INSN_ARRAY map_type check from const_reg_xfer() to bpf_map_direct_read() in patch #2. * Add a test to verify that the off of xlated ldimm64 insn matches the off encoded in the ELF ldimm64 insn. * Drop patch #5 of v4. * Address reviews from Sashiko: * Update commit message of patch #6 to indicate that maps.percpu->mmaped has been marked as read-only in libbpf. * Lookup elem on specified CPU using BPF_F_CPU in tests. * Drop unnecessary err == -EOPNOTSUPP in test. * Locate target field using its offset in the iter test. * v4: https://lore.kernel.org/bpf/20260414132421.63409-1-leon.hwang@linux.dev/ v3 -> v4: * Drop duplicate blank lines in verifier. * Add percpu data feature probe in libbpf. * Update percpu_array map using BPF_F_ALL_CPUS flag for lskel, if no cpu flag is set. * Add two tests to verify verifier log. * Add a test to verify mov64_percpu_reg instruction. * Add a test to verify bpf_iter for percpu data map. * Update percpu_array map using BPF_F_ALL_CPUS flag in libbpf (per Alexei and Andrii). * Address comments from Andrii: * Use .percpu as section identifier. * Use bpf_jit_supports_percpu_insn() instead of CONFIG_SMP. * Drop bpf_map__is_internal_percpu() API. * Drop unnecessary __aligned(8) in libbpf, verified by selftest. * Make mmap data read-only after loading prog. v3: https://lore.kernel.org/bpf/20250526162146.24429-1-leon.hwang@linux.dev/ v2 -> v3: * Use ".data..percpu" as PERCPU_DATA_SEC. * Address comment from Alexei: * Add u8, array of ints and struct { .. } vars to selftest. v2: https://lore.kernel.org/bpf/20250213161931.46399-1-leon.hwang@linux.dev/ v1 -> v2: * Address comments from Andrii: * Use LIBBPF_MAP_PERCPU and SEC_PERCPU. * Reuse mmaped of libbpf's struct bpf_map for .percpu map data. * Set .percpu struct pointer to NULL after loading skeleton. * Make sure value size of .percpu map is __aligned(8). * Use raw_tp and opts.cpu to test global percpu variables on all CPUs. * Address comments from Alexei: * Test non-zero offset of global percpu variable. * Test case about BPF_PSEUDO_MAP_IDX_VALUE. v1: https://lore.kernel.org/bpf/20250127162158.84906-1-leon.hwang@linux.dev/ rfc -> v1: * Address comments from Andrii: * Keep one image of global percpu variable for all CPUs. * Reject non-ARRAY map in bpf_map_direct_read(), check_reg_const_str(), and check_bpf_snprintf_call() in verifier. * Split out libbpf changes from kernel-side changes. * Use ".percpu" as PERCPU_DATA_SEC. * Use enum libbpf_map_type to distinguish BSS, DATA, RODATA and PERCPU_DATA. * Avoid using errno for checking err from libbpf_num_possible_cpus(). * Use "map '%s': " prefix for error message. rfc: https://lore.kernel.org/bpf/20250113152437.67196-1-leon.hwang@linux.dev/ ==================== Link: https://patch.msgid.link/20260813152324.97937-1-leon.hwang@linux.dev Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
2026-08-13selftests/bpf: Verify bpf_iter for global percpu dataLeon Hwang
Add a test to verify that it is OK to iter the percpu_array map used for global percpu data. Signed-off-by: Leon Hwang <leon.hwang@linux.dev> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Link: https://lore.kernel.org/bpf/20260813152324.97937-11-leon.hwang@linux.dev
2026-08-13selftests/bpf: Test verifier log for global percpu dataLeon Hwang
Add two tests to verify the verifier log "R%d points to percpu_array map which cannot be used as const string\n". Signed-off-by: Leon Hwang <leon.hwang@linux.dev> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Link: https://lore.kernel.org/bpf/20260813152324.97937-10-leon.hwang@linux.dev
2026-08-13selftests/bpf: Test direct reading/writing read-only percpu_array mapLeon Hwang
Verify these two cases: 1. Direct reading the data of read-only percpu data's percpu_array map is allowed. 2. Direct writing the data of read-only percpu data's percpu_array map is disallowed. Assisted-by: Codex:gpt-5.5-xhigh Signed-off-by: Leon Hwang <leon.hwang@linux.dev> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20260813152324.97937-9-leon.hwang@linux.dev
2026-08-13selftests/bpf: Add tests to verify global percpu dataLeon Hwang
If the arch, like s390x, does not support percpu insn, these cases won't test global percpu data by checking FEAT_PERCPU_DATA support. The following APIs have been tested for global percpu data: 1. bpf_map__set_initial_value() 2. bpf_map__initial_value() 3. bpf_map__set_value_size() 4. generated percpu struct pointer pointing to internal map's mmaped data 5. bpf_map__lookup_elem() for global percpu data map 6. bpf_map_lookup_elem_flags() for global percpu data map At the same time, the case is also tested with 'bpftool gen skeleton -L'. Assisted-by: Codex:gpt-5.5-xhigh Signed-off-by: Leon Hwang <leon.hwang@linux.dev> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20260813152324.97937-8-leon.hwang@linux.dev
2026-08-13bpftool: Generate skeleton for global percpu dataLeon Hwang
Enhance bpftool to generate skeletons that properly handle global percpu variables. The generated skeleton now includes a dedicated structure for percpu data, allowing users to initialize and access percpu variables more efficiently. For global percpu variables, the skeleton now includes a nested structure, e.g.: struct test_global_percpu_data { struct bpf_object_skeleton *skeleton; struct bpf_object *obj; struct { struct bpf_map *percpu; } maps; // ... struct test_global_percpu_data__percpu { int data; char run; struct { char set; int i; int nums[7]; } struct_data; int nums[7]; } *percpu; // ... }; * The "struct test_global_percpu_data__percpu *percpu" points to initialized data, which is actually "maps.percpu->mmaped". * Before loading the skeleton, updating the "struct test_global_percpu_data__percpu *percpu" modifies the initial value of the corresponding global percpu variables. * After loading the skeleton, "maps.percpu->mmaped" has been marked as read-only in libbpf. If users want to update the global percpu variables, they have to update the "maps.percpu" map instead. * For lightweight skeleton, "lskel->percpu" will be protected by "mprotect(p, sz, PROT_READ)". * For subskeleton, those variables of global percpu data will be skipped. Assisted-by: Codex:gpt-5.5-xhigh Signed-off-by: Leon Hwang <leon.hwang@linux.dev> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Quentin Monnet <qmo@kernel.org> Link: https://lore.kernel.org/bpf/20260813152324.97937-7-leon.hwang@linux.dev
2026-08-13libbpf: Add support for global percpu dataLeon Hwang
Add support for global percpu data in libbpf by adding a new ".percpu" section, similar to ".data". It enables efficient handling of percpu global variables in bpf programs. When generating loader for lightweight skeleton, update the percpu_array map used for global percpu data using BPF_F_ALL_CPUS, in order to update values across all CPUs using one value slot. Unlike global data, the mmaped data for global percpu data will be marked as read-only after populating the percpu_array map. Thereafter, users can read those initialized percpu data after loading prog. If they want to update the percpu data after loading prog, they have to update the percpu_array map using key=0 instead. Signed-off-by: Leon Hwang <leon.hwang@linux.dev> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20260813152324.97937-6-leon.hwang@linux.dev
2026-08-13libbpf: Probe percpu data featureLeon Hwang
libbpf needs a reliable way to distinguish kernels that can support global percpu data from those that cannot. Add a dedicated feature probe, so libbpf can make capability decisions early and fail predictably when global percpu data is unavailable. Signed-off-by: Leon Hwang <leon.hwang@linux.dev> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Acked-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20260813152324.97937-5-leon.hwang@linux.dev
2026-08-13bpf: Introduce global percpu dataLeon Hwang
Introduce global percpu data, inspired by the commit 6316f78306c1 ("Merge branch 'support-global-data'"). It enables the definition of global percpu variables in BPF, similar to the include/linux/percpu-defs.h::DEFINE_PER_CPU() macro. For example, in BPF, it is able to define a global percpu variable like: int data SEC(".percpu"); With this patch, tools like retsnoop [1] and bpfsnoop [2] can simplify their BPF code for handling LBRs. The code can be updated from static struct perf_branch_entry lbrs[1][MAX_LBR_ENTRIES] SEC(".data.lbrs"); to static struct perf_branch_entry lbrs[MAX_LBR_ENTRIES] SEC(".percpu.lbrs"); This eliminates the need to retrieve the CPU ID using the bpf_get_smp_processor_id() helper. Additionally, by reusing global percpu data map, sharing information between tail callers and callees or freplace callers and callees becomes simpler compared to reusing percpu_array maps. Links: [1] https://github.com/anakryiko/retsnoop [2] https://github.com/bpfsnoop/bpfsnoop Signed-off-by: Leon Hwang <leon.hwang@linux.dev> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/bpf/20260813152324.97937-4-leon.hwang@linux.dev
2026-08-13bpf: Factor out check_map_mem_read helper in verifierLeon Hwang
In the next commit, percpu_array map will add map_direct_value_addr support. IOW, it will add a map_type check in the iff condition of the bpf_map_direct_read() code block, which will reduce the code block readability. Hence, factor out check_map_mem_read helper to improve the readability, and the maintainability for the percpu_array map case. Signed-off-by: Leon Hwang <leon.hwang@linux.dev> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/bpf/20260813152324.97937-3-leon.hwang@linux.dev
2026-08-13bpf: Drop duplicate blank lines in kernel/bpf/Leon Hwang
There are many adjacent blank lines in kernel/bpf/ that have accumulated over time. Drop them for cleanup. No functional changes intended. Signed-off-by: Leon Hwang <leon.hwang@linux.dev> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Link: https://lore.kernel.org/bpf/20260813152324.97937-2-leon.hwang@linux.dev
2026-08-13x86/pkeys: Fix pkey_alloc() return value when pkeys are not supportedBijan Tabatabai
The man page for pkey_alloc(2) specifies that it should return -1 with the errno set to ENOSPC when pkeys are not supported [1]. However, on x86 pkey_alloc() sets errno to EINVAL when called for the first time on a CPU that does not support pkeys. The root cause of this is the x86 implementation of mm_pkey_alloc() not directly checking if pkeys are supported. It only checks if all the pkeys have been allocated by comparing the allocation map against all_pkeys_mask. When OSPKE is not enabled, init_new_context() skips the initialization of the allocation map, leaving it as 0, while all_pkeys_mask is 1. mm_pkey_alloc() interprets this as there being a pkey available and it returns pkey 0. Then, pkey_alloc() fails with -EINVAL from arch_set_user_pkey_access() instead of returning -ENOSPC. Subsequent calls to pkey_alloc() do return -ENOSPC because pkey 0 is left marked as allocated. Change mm_pkey_alloc() to directly check if OSPKE is enabled, and return -1 if it is not, which causes pkey_alloc() to return -ENOSPC. The arm64 and powerpc implementations of mm_pkey_alloc() already do this check. [1] https://man7.org/linux/man-pages/man2/pkey_alloc.2.html [ dhansen: use arch_pkeys_enabled() to follow arm ] Fixes: e8c24d3a23a4 ("x86/pkeys: Allocation/free syscalls") Signed-off-by: Bijan Tabatabai <btabatabai@wisc.edu> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Link: https://patch.msgid.link/20260716220604.26452-1-bijan311@gmail.com
2026-08-13selftests/cgroup: Preserve CPU hotplug write errorsRui Qi
The cpuset partition root state selftest checks several CPU hotplug transitions. If writing to a CPU online file fails, the helper still runs pause afterwards and returns the status of pause instead of the failed write. This hides the real hotplug failure and can make later checks run against expectations for a transition that never happened. Move the write before the bookkeeping and return when it fails, so callers can observe the hotplug error and the test does not record a CPU as offline unless the offline operation actually succeeded. Also change the O* command handler in set_ctrl_state() to use "eval $COMM $REDIRECT" like all other handlers. The previous version set COMM but still called write_cpu_online directly, bypassing the redirect that captures stderr for error reporting. Changes since v1: - Use eval $COMM $REDIRECT in the O* handler instead of calling write_cpu_online directly (Waiman Long) Fixes: a8c52eba880a ("kselftest/cgroup: Add cpuset v2 partition root state test") Signed-off-by: Rui Qi <qirui.001@bytedance.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2026-08-13workqueue: annotate racy p->wake_cpu accesses in kick_pool_pick()Breno Leitao
kick_pool_pick() reads and writes p->wake_cpu while the scheduler can update it concurrently. KCSAN reports: BUG: KCSAN: data-race in kick_pool_pick+0xf8/0x2d8 race at unknown origin, with read to 0xffff000663229da4 of 4 bytes by task 1817002 on cpu 40: kick_pool_pick+0xf8/0x2d8 process_scheduled_works+0x2bc/0x888 worker_thread+0x394/0x548 kthread+0x1b8/0x1f0 ret_from_fork+0x10/0x20 value changed: 0x0000002b -> 0x0000002f The race is harmless. wake_cpu is a best-effort placement hint: every writer stores a valid CPU id and the wakeup path validates it through select_task_rq(), so a stale value only affects which CPU the worker wakes up on. Mark both accesses with READ_ONCE() and WRITE_ONCE() to document that they are intentionally racy and to stop the compiler from reloading or tearing them. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Bradley Morgan <include@grrlz.net> Signed-off-by: Tejun Heo <tj@kernel.org>
2026-08-13PCI: Fix 32-bit config write in Intel PCH Root Port MPC ACS quirkMohamad Raizudeen
pci_quirk_enable_intel_rp_mpc_acs() reads a 32-bit DWORD from the MPC register, sets bit 26 (INTEL_MPC_REG_IRBNCE), but it writes it back using pci_write_config_word(). Because bit 26 resides in the upper 16 bits of the 32-bit register, a 16-bit write drops the newly set bit. The quirk logs that it is enabling IRBNCE, but the hardware never actually receives the command. Use pci_write_config_dword() to ensure the full 32-bit value is written back to the hardware. Fixes: d99321b63b1f ("PCI: Enable quirks for PCIe ACS on Intel PCH root ports") Signed-off-by: Mohamad Raizudeen <raizudeen.kerneldev@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260723171203.4892-1-raizudeen.kerneldev@gmail.com
2026-08-13ASoC: dt-bindings: es8316: Fix supply property constraintsHongyang Zhao
The DT meta-schema requires a `then` clause when an `if` condition has an `else` clause. Invert the compatible check and move the supply property restrictions to `then` so they remain allowed only for ES8316. Fixes: e9966d450b46 ("ASoC: dt-bindings: es8316: Add regulator supplies") Reported-by: Rob Herring <robh@kernel.org> Closes: https://lore.kernel.org/r/20260812194234.GA693895-robh@kernel.org Signed-off-by: Hongyang Zhao <hongyang.zhao@thundersoft.com> Link: https://patch.msgid.link/20260813-b4-es8316-binding-conditional-fix-v1-1-6cd56aa1370c@thundersoft.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-13s390/pci: Store PCI error information for passthrough devicesFarhan Ali
For a passthrough device we need co-operation from user space to recover the device. This would require to bubble up any error information to user space. Let's store this error information for passthrough devices, so it can be retrieved later. We can now have userspace drivers (vfio-pci based) on s390x. The userspace drivers will not have any KVM fd and so no kzdev associated with them. So we need to update the logic for detecting passthrough devices to not depend on struct kvm_zdev. Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Farhan Ali <alifm@linux.ibm.com> Link: https://lore.kernel.org/r/20260630165553.725-2-alifm@linux.ibm.com Signed-off-by: Alex Williamson <alex@shazbot.org>
2026-08-13Merge branch 'slot' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci ↵Alex Williamson
into v7.3/vfio/s390x-pci-error-recovery PCI dependencies from shared branch supporting vfio-pci error recovery on s390x. Signed-off-by: Alex Williamson <alex@shazbot.org>
2026-08-13spi: virtio: mark device ready before registering the controllerJasper Wise
virtio_spi_probe() registers the SPI controller with devm_spi_register_controller(). spi_register_controller() binds a child inline unless its driver has asked for asynchronous probing, so a peripheral that performs a transfer during its own probe reaches virtio_spi_transfer_one(), which kicks the virtqueue before probe has returned. The driver never calls virtio_device_ready(), so DRIVER_OK is set on its behalf by virtio_dev_probe(), only once probe has returned. The virtio spec is explicit about that ordering in 3.1 Device Initialization: | The driver MUST NOT send any buffer available notifications to the | device before setting DRIVER_OK. A device that waits for DRIVER_OK before servicing the queue therefore leaves the transfer unanswered, and virtio_spi_transfer_one() waits for its completion with no timeout, so probe never returns. Mark the device ready before registering the controller, as done for the same reason in commit f5866db64f34 ("virtio_console: enable VQs early") and commit 1d774589f924 ("i2c: virtio: mark device ready before registering the adapter"). Fixes: f98cabe3f6cf ("SPI: Add virtio SPI driver") Signed-off-by: Jasper Wise <jaspwise@amazon.co.uk> Link: https://patch.msgid.link/20260813084618.613172-1-jaspwise@amazon.co.uk Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-13nvmet: fix max_qid race between configfs and controller allocationMaurizio Lombardi
The function nvmet_subsys_attr_qid_max_store() can race against nvmet_alloc_ctrl() when a subsystem's max_qid limit is modified. Suppose max_qid is currently 64. If nvmet_alloc_ctrl() executes: ctrl->sqs = kzalloc_objs(struct nvmet_sq *, subsys->max_qid + 1); and at this exact point, a userspace process changes max_qid to 128, nvmet_subsys_attr_qid_max_store() will set the new max_qid value. It attempts to delete active controllers to force a reconnect, but the new controller won't be deleted because it hasn't been added to the subsys->ctrls list yet. nvmet_alloc_ctrl() then proceeds and adds the new controller to the subsys->ctrls list. Later, when nvmet_install_queue() is called, it will see max_qid set to 128, but the memory allocated for sqs is only sized for 64 entries. This results in a KASAN out-of-bounds warning and potential memory corruptions. Fix this by protecting the queue allocations and list insertion in nvmet_alloc_ctrl() with down_read(&nvmet_config_sem). Because nvmet_subsys_attr_qid_max_store() acquires down_write(&nvmet_config_sem) to modify the attribute, this safely prevents the configfs writer from modifying max_qid during controller creation. Copy the max_qid from the subsystem to the controller's structure during the allocation; ctrl->max_qid never changes as long as the controller remains in LIVE state, so this will prevent similar race conditions. Fixes: 3e980f5995e0 ("nvmet: expose max queues to configfs") Reported-by: syzbot+2626e846cd2585c9aa67@syzkaller.appspotmail.com Signed-off-by: Maurizio Lombardi <mlombard@redhat.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-17 02:09:35 +0000