summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-10-10Input: st-keyscan - disable interrupt while clock is gatedDmitry Torokhov
The driver gates off its peripheral clock when the input device is not open and during system suspend without wakeup. However, the interrupt is requested without IRQF_NO_AUTOEN and remains unmasked when the device is stopped. If a pending or spurious interrupt fires while the clock is disabled, keyscan_isr() will attempt to read the matrix state register with the clock gated off, triggering a bus fault (synchronous external abort) and panicking the system. Request the interrupt with IRQF_NO_AUTOEN, enable it in keyscan_start(), and disable it in keyscan_stop() prior to gating the clock. Drop the pointless clock enable/stop sequence in keyscan_probe(), leaving the clock gated and hardware untouched until the device is opened. Fixes: 062589b13991 ("Input: add st-keyscan driver") Reported-by: sashiko-bot@kernel.org Assisted-by: LLM Link: https://patch.msgid.link/apK-PZ5c97mCxBSC@google.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-10-11usb: core: don't set drvdata to NULL in usb_unbind_interface()Danilo Krummrich
usb_unbind_interface() serves as the remove() callback of struct usb_driver and calls usb_set_intfdata(intf, NULL) to clear the bus device private data pointer. However, the driver core code already sets the bus device private data pointer to NULL in device_unbind_cleanup() *after* devres_release_all(), which makes the call redundant. In addition, it can create unexpected NULL pointer dereference scenarios when drivers use managed APIs. int probe(struct usb_interface *intf, const struct usb_device_id *id) { struct data *data; int ret; data = devm_kzalloc(&intf->dev, sizeof(*data), GFP_KERNEL); if (!data) return -ENOMEM; ret = devm_device_add_group(&intf->dev, &foo_attr_group); if (ret) return ret; ... } ssize_t foo_value_show(struct device *dev, struct device_attribute *attr, char *buf) { struct usb_interface *intf = to_usb_interface(dev); struct data *data = usb_get_intfdata(intf); /* Potential NULL pointer dereference */ return sysfs_emit(buf, "%u\n", data->value); } Nothing prevents usb_unbind_interface() to race with foo_value_show() and set usb_set_intfdata(intf, NULL). The same applies to the unwind path of usb_probe_interface(), which also calls usb_set_intfdata(intf, NULL). Besides that, the Rust driver core code manages a driver's bus device private data and destroys it in device_unbind_cleanup(). If usb_unbind_interface() sets the pointer to NULL prematurely, the Rust driver core code sees NULL, and hence skips the destructor of the bus device private data, which leaks all its resources. Thus, drop usb_set_intfdata(intf, NULL) from usb_probe_interface() and usb_unbind_interface(), and move it to usb_driver_release_interface(), which manually calls the remove() callback of struct usb_driver and hence can't rely on the driver core. Cc: stable@kernel.org Fixes: a995fe1a3aa7 ("rust: driver: drop device private data post unbind") Reviewed-by: Johan Hovold <johan@kernel.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20261010135131.286498-1-dakr@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-10-10bootconfig: reject unexpected data after null characterMasami Hiramatsu (Google)
Patch series "bootconfig: Reject unexpected data after null character and cleanups", v2. Make bootconfig reject unexpected config data after null character and implement other cleanups including tools/bootconfig to consolidate bootconfig initialization with errors, and to skip internal tree sanity checks in kernel. This patch (of 4): If a bootconfig buffer contains an intermediate null character in the middle of the configuration, xbc_parse_tree() stops at the null character because string delimiter searches (e.g. strpbrk()) stop at '\0', and cleanly breaks out of the loop without error. As a result, any configuration data following the intermediate null character is silently ignored, allowing unparsed or potentially malicious data to be hidden after an early termination. Fix this in xbc_parse_tree() by checking that no non-null data remains between the parser termination point and the end of the input buffer. Trailing null characters (such as alignment padding in initrd) continue to be accepted as valid. Also update apply_xbc() in tools/bootconfig/main.c to calculate the buffer size based on the loaded file size rather than strlen(), so that files with intermediate null characters are not truncated before validation. Link: https://lore.kernel.org/178913597653.248794.1237187523153227751.stgit@devnote2 Link: https://lore.kernel.org/178913598628.248794.1048773774471250986.stgit@devnote2 Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Sang-Heon Jeon <ekffu200098@gmail.com> Assisted-by: Antigravity:gemini-3.8-flash
2026-10-10bootconfig: remove redundant assignment in xbc_parse_array()Sang-Heon Jeon
After the loop, node is the last array value that xbc_add_child() added, and xbc_parse_array() sets node->child to 0. xbc_init_node() already set node->child to 0 when the value was added, and node->child is not modified after that, so the assignment is redundant. So remove the assignment. No functional change. Link: https://lore.kernel.org/20260910163051.1973775-1-ekffu200098@gmail.com Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
2026-10-10checkpatch: skip kernel specific checks for userspacePetr Vorel
These check are kernel specific, do not warn about it when testing userspace code: * BIT_MACRO * LONG_UDELAY * MSLEEP * PREFER_KERNEL_TYPES * USLEEP_RANGE This is a follow-up to 99b70ece33d8 ("checkpatch: suppress strscpy warnings for userspace tools"). Link: https://lore.kernel.org/20260904110230.1219037-5-pvorel@suse.cz Signed-off-by: Petr Vorel <pvorel@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Cc: Andy Whitcroft <apw@canonical.com> Cc: Dwaipayan Ray <dwaipayanray1@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com>
2026-10-10checkpatch: add --userspace to force userspace rulesPetr Vorel
Also allow to use --no-userspace for userspace projects which vendored checkpatch.pl and use --userspace globally to be able switch it off for files with kernel code. Link: https://lore.kernel.org/20260904110230.1219037-4-pvorel@suse.cz Signed-off-by: Petr Vorel <pvorel@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Cc: Andy Whitcroft <apw@canonical.com> Cc: Dwaipayan Ray <dwaipayanray1@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com>
2026-10-10checkpatch: ignore <inttypes.h> format macros for userspace toolsPetr Vorel
Constants from <inttypes.h> are used only in userspace tools, they are from ISO C99, let's don't report it: arch/mips/boot/tools/relocs.c:572: CHECK: Avoid CamelCase: <PRIx32> arch/s390/tools/relocs.c:52: CHECK: Avoid CamelCase: <PRIu64> tools/testing/selftests/mm/vm_util.c:244: CHECK: Avoid CamelCase: <SCNu64> Link: https://lore.kernel.org/20260904110230.1219037-3-pvorel@suse.cz Signed-off-by: Petr Vorel <pvorel@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Cc: Andy Whitcroft <apw@canonical.com> Cc: Dwaipayan Ray <dwaipayanray1@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com>
2026-10-10checkpatch: add more userspace directories to is_userspace()Petr Vorel
Patch series "checkpatch: userspace improvements", v6. Few improvements for user space code + --userspace option for projects which vendored checkpatch.pl. There could be probably more checks which are kernel space only. This patch (of 4): arch/ directory contains subdirectories with userspace tools (at least arch/*/tools/ and arch/*/boot/tools/). Add check to consider any arch/.*/tools/ subdirectory as userspace tools directory. This helps not only to strscpy() checks but also to CamelCase checks in the next commit to be more precise. This is a follow-up to 99b70ece33d8 ("checkpatch: suppress strscpy warnings for userspace tools"). Link: https://lore.kernel.org/20260904110230.1219037-1-pvorel@suse.cz Link: https://lore.kernel.org/20260904110230.1219037-2-pvorel@suse.cz Signed-off-by: Petr Vorel <pvorel@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Cc: Andy Whitcroft <apw@canonical.com> Cc: Dwaipayan Ray <dwaipayanray1@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com>
2026-10-10ocfs2: validate dl_blkno and dl_fs_generation of dir index leaf blocksJoseph Qi
ocfs2_validate_dx_leaf() checks the checksum, the signature and the entry list counts, but it never checks dl_blkno or dl_fs_generation. The inode, extent block, xattr block, refcount block and dir index root validators all check the on-disk block number against bh->b_blocknr and the generation against the superblock, and both dir index leaf fields are documented as "Must match super block". Without the checks, a stale dir index leaf block left on the device from a previously formatted filesystem at the same physical block number can pass validation as long as its signature, entry counts and checksum match. Its index entries would then be used in the new filesystem context. Both fields are written unconditionally when a leaf block is formatted in ocfs2_dx_dir_format_cluster(), from the live superblock generation and the real block number, so a correctly formatted filesystem cannot trip the new checks. The leaf block number read back here comes from on-disk dir index root extent records. Reject dir index leaf blocks whose dl_blkno or dl_fs_generation does not match, like the dir index root validator does. Link: https://lore.kernel.org/20260905142144.2869105-2-joseph.qi@linux.alibaba.com Signed-off-by: Joseph Qi <joseph.qi@linux.alibaba.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Heming Zhao <heming.zhao@suse.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>
2026-10-10ocfs2: validate dr_fs_generation of dir index root blocksJoseph Qi
ocfs2_validate_dx_root() does not verify dr_fs_generation against the superblock generation, unlike the extent and xattr block validators which check h_fs_generation and xb_fs_generation respectively. The field is documented as "Must match super block". Without the check, a stale dir index root block left on the device from a previously formatted filesystem at the same physical block number can pass validation as long as its signature, dr_blkno and checksum match. Its index entries and suballocator information would then be used in the new filesystem context. Reject dir index root blocks whose dr_fs_generation does not match the mounted filesystem, like the extent and xattr block validators do. Link: https://lore.kernel.org/20260905142144.2869105-1-joseph.qi@linux.alibaba.com Signed-off-by: Joseph Qi <joseph.qi@linux.alibaba.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Heming Zhao <heming.zhao@suse.com> Cc: Changwei Ge <gechangwei@live.cn> Cc: Joel Becker <jlbec@evilplan.org> Cc: Jun Piao <piaojun@huawei.com> Cc: Junxiao Bi <junxiao.bi@oracle.com> Cc: Mark Fasheh <mark@fasheh.com>
2026-10-10mailmap: update email address for Ali Ahmet MemişAli Ahmet Memiş
I'm switching to my disroot address for kernel contributions. Map the address my earlier patches were sent from to it, so that get_maintainer.pl stops offering the old one as a recipient. Also switch to the proper spelling of my name with diacritics, which is what I use with the new address. Link: https://lore.kernel.org/20260905195000.556185-1-aliamemis@disroot.org Signed-off-by: Ali Ahmet Memiş <aliamemis@disroot.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-10-10lib/plist: fix plist_requeue() corrupting order in the last bucketAdam Harshbarger
plist_requeue() is meant to move a node to the end of its own priority run. When the node heads the *last* priority bucket it is instead placed at the head of the whole list, leaving the plist unsorted: built: A(prio 0) B(prio 1) C(prio 1) requeue(B): B(prio 1) A(prio 0) C(prio 1) expected: A(prio 0) C(prio 1) B(prio 1) prio_list is a *headless* circular ring of the nodes that lead each priority bucket. The shortcut added by commit 95d4b3450ebe ("lib/plist.c: add shortcut for plist_requeue()") takes iter = list_entry(iter->prio_list.next, struct plist_node, prio_list); node_next = &iter->node_list; which from the last bucket wraps round to the *first* bucket, so node_next ends up pointing at the head of the list rather than at its end. The plist_for_each_continue() loop immediately below it computes the correct answer (&head->node_list) for that case. With any bucket after it the shortcut is correct, which is why this went unnoticed: the benchmark in that commit measured elapsed time and never checked the resulting order. Keep the shortcut -- it is a real win -- but exclude the case where iter's bucket is the last one, which is exactly when its ring successor is the first bucket again. Reachable from mm/swapfile.c, which rotates swap_avail_heads[] with plist_requeue(). It takes three or more swap devices: at least two distinct priorities, so that a later bucket exists for the ring to wrap round from, and two or more devices sharing the lowest priority, so that plist_requeue() does not return early. One device per priority returns early at the node->prio != iter->prio test. A single priority is also safe, but for a different reason worth stating: with one bucket no node is ever linked onto prio_list at all -- plist_add() skips it for the first node and for every node whose predecessor shares its priority -- so list_empty(&iter->prio_list) holds and the shortcut is never entered. Tested by driving three implementations -- the pre-95d4b3450ebe code, current mainline, and this patch -- through 1,084,492 identical random add/del/requeue operations over 24 nodes and 1..5 distinct priorities, comparing the resulting node_list node for node after every operation: variant differs from pre-95d4b3450ebe left list unsorted pre-95d4b3450ebe -- (reference) 0 mainline 289,297 276,660 this patch 0 0 Link: https://lore.kernel.org/20260903222456.1881786-1-handyhandyman.adam@gmail.com Fixes: 95d4b3450ebe ("lib/plist.c: add shortcut for plist_requeue()") Signed-off-by: Adam Harshbarger <handyhandyman.adam@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Nickolai Zeldovich <nickolai@csail.mit.edu> Assisted-by: Claude:claude-opus-5 Cc: I Hsin Cheng <richard120310@gmail.com> Cc: <stable@vger.kernel.org> # v6.15+
2026-10-11bootconfig: Move BOOTCONFIG_FOOTER_SIZE to include/linux/bootconfig.hMasami Hiramatsu (Google)
BOOTCONFIG_FOOTER_SIZE was defined locally in tools/bootconfig/main.c. Move it to include/linux/bootconfig.h so that it can be shared with the kernel and user-space tools. Also, use it in init/main.c instead of the hardcoded (BOOTCONFIG_MAGIC_LEN + 8) expression when checking the initrd size. Link: https://lore.kernel.org/all/178913601321.248794.4786502771058559887.stgit@devnote2/ Suggested-by: Sang-Heon Jeon <ekffu200098@gmail.com> Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Reviewed-by: Sang-Heon Jeon <ekffu200098@gmail.com>
2026-10-11bootconfig: Skip internal tree sanity checks in kernelMasami Hiramatsu (Google)
In xbc_verify_tree(), the loop iterating through all nodes to check that xbc_nodes[i].next < xbc_node_num and xbc_nodes[i].child < xbc_node_num is a defensive sanity check against implementation regressions (such an out-of-bounds index cannot be produced by malformed input). Running this check in the kernel adds unnecessary boot-time overhead. Split this check out into xbc_sanity_check_tree() for userspace, so that it continues to run during userspace bootconfig validation (e.g. when applying or testing bootconfig with tools/bootconfig), but is omitted in the kernel to speed up initialization. Link: https://lore.kernel.org/all/178913600409.248794.12941798680046327623.stgit@devnote2/ Reported-by: Sang-Heon Jeon <ekffu200098@gmail.com> Closes: https://lore.kernel.org/all/20260905141637.1547429-1-ekffu200098@gmail.com/ Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Reviewed-by: Sang-Heon Jeon <ekffu200098@gmail.com>
2026-10-11tools/bootconfig: Consolidate xbc_init() to error message wrapperMasami Hiramatsu (Google)
Use init_xbc_with_error() for all bootconfig initialization in the bootconfig tool instead of showing errors in different way. This simplifies the code logic and make it easy to maintain. Link: https://lore.kernel.org/all/178913599508.248794.10388592925402087434.stgit@devnote2/ Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
2026-10-11bootconfig: Reject unexpected data after null characterMasami Hiramatsu (Google)
If a bootconfig buffer contains an intermediate null character in the middle of the configuration, xbc_parse_tree() stops at the null character because string delimiter searches (e.g. strpbrk()) stop at '\0', and cleanly breaks out of the loop without error. As a result, any configuration data following the intermediate null character is silently ignored, allowing unparsed or potentially malicious data to be hidden after an early termination. Fix this in xbc_parse_tree() by checking that no non-null data remains between the parser termination point and the end of the input buffer. Trailing null characters (such as alignment padding in initrd) continue to be accepted as valid. Also update apply_xbc() in tools/bootconfig/main.c to calculate the buffer size based on the loaded file size rather than strlen(), so that files with intermediate null characters are not truncated before validation. Link: https://lore.kernel.org/all/178913598628.248794.1048773774471250986.stgit@devnote2/ Assisted-by: LLM Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Reviewed-by: Sang-Heon Jeon <ekffu200098@gmail.com>
2026-10-11kbuild: Mark the initcall ordering recipe as recursiveKees Cook
generate_initcall_order.pl, which orders initcalls for Clang LTO, forks a child per input file, up to the job count scripts/jobserver-exec passes it in PARALLELISM. It used to run from link-vmlinux.sh, which the top-level Makefile invokes as a recursive recipe, but commit 5d45950dfbb15 ("kbuild: move vmlinux.o link to scripts/Makefile.vmlinux_o") moved it into a recipe without "+". GNU Make passes the jobserver pipe only to recipes it treats as recursive, and the make 4.3 in CentOS Stream 9 also hides it in sub-makes (a backport of the fix for GNU Make bug 58232), so jobserver-exec cannot open it and prints: WARNING: Unable to reopen jobserver read-side pipe: FileNotFoundError(2, 'No such file or directory') PARALLELISM is then left unset, and the script caps its children at the number of online CPUs instead of the free job slots. Mark the recipe as recursive again (this makes "make -n" runs the script again too, as it did from link-vmlinux.sh). Masahiro posted the same change and withdrew it because the script was given only vmlinux.a, and so never ran more than one child [1]. But on arm64, LoongArch, and RISC-V with CONFIG_EFI_STUB, KBUILD_VMLINUX_LIBS also gives it the EFI stub's lib.a. Either way, the warning is silenced. Tested ARCH=x86_64 defconfig with CONFIG_LTO_CLANG_THIN=y, LLVM=1 (Clang 24.0.0git), and GNU Make 4.3 plus CentOS Stream 9's make-4.3-cloexec.patch. Fixes: 5d45950dfbb15 ("kbuild: move vmlinux.o link to scripts/Makefile.vmlinux_o") Link: https://lore.kernel.org/all/CAK7LNARCM=rUm8mA8GRQ7ufeyfneGf4OEvHmESKt=zuxs2KrHw@mail.gmail.com/ [1] Assisted-by: LLM Reviewed-by: Nicolas Schier <n.schier@fritz.com> Signed-off-by: Kees Cook <kees@kernel.org> Tested-by: Paul E. McKenney <paulmck@kernel.org> Link: https://patch.msgid.link/20261010081914.540611-2-kees@kernel.org Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-10-11kbuild: Mark the gzip recipes as recursiveKees Cook
Since commit 48ebe1cbbeb51 ("kbuild: compress the kernel with pigz if available"), cmd_gzip runs pigz through scripts/jobserver-exec, which takes the job slots make has free. GNU Make passes the jobserver pipe only to recipes it treats as recursive, but leaves --jobserver-auth in MAKEFLAGS for all of them. The make 4.3 in CentOS Stream 9 also hides the pipe in sub-makes (a backport of the fix for GNU Make bug 58232), so jobserver-exec cannot open it, runs pigz on one thread, and prints: WARNING: Unable to reopen jobserver read-side pipe: FileNotFoundError(2, 'No such file or directory') Mark every recipe that can run cmd_gzip as recursive with "+", as commit ecab4115c44cc ("kbuild: mark `rustc` (and others) invocations as recursive") did for rustc. Besides the $(call if_changed,gzip) rules, this covers those that choose gzip through a variable: the built-in initramfs in usr/Makefile (which rcutorture's kvm.sh builds), the EFI zboot image, and the arm, csky, and mips compressed images. As with rustc, "make -n" now runs these recipes, including those that choose through a variable when they select another compressor. Also update the gzip entry in Documentation/kbuild/makefiles.rst, as suggested in review. Tested with GNU Make 4.3 plus CentOS Stream 9's make-4.3-cloexec.patch, GCC 16.2.0, and -j64, on ARCH=x86_64, arm64, and arm defconfig, and ARCH=x86_64 defconfig with a built-in initramfs: none of them prints the warning, and pigz gets the free job slots (-p 54, 64, and 50 for the kernel image). Without this change, the x86_64 builds print it for the kernel image and for the initramfs. Reported-by: Paul E. McKenney <paulmck@kernel.org> Closes: https://lore.kernel.org/all/0ddb5e5e-f801-444c-aa98-0cfe814a3026@paulmck-laptop/ Fixes: 48ebe1cbbeb51 ("kbuild: compress the kernel with pigz if available") Assisted-by: LLM Reviewed-by: Nicolas Schier <n.schier@fritz.com> Acked-by: Lorenzo Stoakes (ARM) <ljs@kernel.org> Signed-off-by: Kees Cook <kees@kernel.org> Tested-by: Paul E. McKenney <paulmck@kernel.org> Link: https://patch.msgid.link/20261010081914.540611-1-kees@kernel.org Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-10-11localmodconfig: Explicitly report boolean configs during integrity checkAaron Tomlin
When running make localmodconfig, streamline_config.pl reads loaded modules and maps each module object to its corresponding Kconfig symbol(s) using repository Makefiles. In several instances, a loaded module corresponds to an object controlled by a boolean symbol (e.g. config FOO declared as bool), or is a composite module that depends on a boolean configuration. Because boolean options only accept "=y" or disabled, they cannot be configured as loadable modules ("=m"). Previously, if such a symbol was not already built-in ("=y") in the baseline configuration, the final integrity check emitted an ambiguous diagnostic. For example foo did not have configs CONFIG_FOO Further investigation is required by developers to determine whether the module was out-of-tree, its dependencies were unmet, or it failed due to a type constraint. Address this by: 1. Tracking symbol types in a %types hash during Kconfig parsing. 2. Enhancing the final integrity check when running localmodconfig (!$localyesconfig) to explicitly annotate boolean symbols. For example: module cec did not have configs CONFIG_CEC_CORE (tristate) CONFIG_RAS_CEC (boolean, not supported with =m) Signed-off-by: Aaron Tomlin <atomlin@atomlin.com> Acked-by: Steven Rostedt <rostedt@goodmis.org> Link: https://patch.msgid.link/20260925181230.130525-1-atomlin@atomlin.com Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-10-11bootconfig: Skip printing early params to cmdline from bootconfigMasami Hiramatsu (Google)
If user configures `kernel.key` in bootconfig, the 'key' is shown in kernel cmdline (/proc/cmdline) and kernel boot parameter handler associated with 'key' is invoked. However, since the bootconfig does not support the parameter defined with early_param, those keys are shown in '/proc/cmdline' but not handled by kernel. This could easily mislead users who expected to be able to specify early parameters via the boot configuration, leading them to wonder why it doesn't work. Let's skip printing out early params to cmdline buffer, and warn if there is such parameters in bootconfig. Link: https://lore.kernel.org/all/178844899530.263905.7707547252181797215.stgit@devnote2/ Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
2026-10-10Merge tag 'edac_urgent_for_v7.3_rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras Pull EDAC fix from Borislav Petkov: - amd64_edac: Shorten the ErrorInformation field read from the MCA_SYND MSR to only two bits. It is perfectly fine to do so because no system ever supported more than 2 bits of information (the Chip Selects used were only 4 maximum) and newer hardware will use only 2 bits anyway * tag 'edac_urgent_for_v7.3_rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras: EDAC/amd64: Mask UMC chip select to the four implemented selects
2026-10-10Merge tag 'drm-fixes-2026-10-11' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds
Pull drm fixes from Dave Ailie: "Live from Dublin Airport, it's Saturday Night drm fixes. This week has the missing misc fixes from last week which I tracked down and seemed to be a race/bug in my lei setup somehow, once I asked lei to ignore it's cache I got the missing email. But there are more misc fixes this week and amd and intel ones. The main ones in this are amdgpu and xe, with vc4, vmwgfx, nouveau and imagination in the middle, with a bunch of small single fixes. Bit busier than I'd like, but the missing misc might explain it, anyways time for me to fly home. fb: - defer setup when fbdev_probe() fails, not just on -EAGAIN bridge: - Fix unlocked list_del in drm_bridge_add() - Fix unlocked list access in drm_bridge_attach() - th1520-dw-hdmi: - Fix error check on dw_hdmi_probe() return value - Fix remove() callback aspeed: - Balance the display clock enable on teardown i915: - Fix a GT park race that could trigger spurious RPM wakelock warnings - Fix execbuffer relocation cleanup to avoid out-of-bounds free xe: - i2c removal - system Controller Maibox header handling - two bo pin/unpin accounting bugs - not emitting a w/a twice - xe_mmio_wait32() to honor delay/sleep maximums amdgpu: - Fix direct scanout alpha on some DRM_FORMATs - UserQ fixes - Fix tearing flips with PSR - GPU reset vblank fix - Debugfs register interface fix - Fix display mode patching - Expand Mac reserved memory workaround amdkfd: - SDMA doorbell fix - Fix dma-buf reference leak in error path imagination: - fix reference and vm_bo handling in remap() - size page table preallocation by device address gud: - don't keep a connector without a CRTC as connector_state panthor: - validate userspace queue count against initialized firmware slot count nouveau: - fix null ptr regression - skip turing CE workaround for non-GR vmwgfx: - validate pitch value - add blend mode property vc4: - drain hangcheck timer on unbind - free BO cache on teardown - use kvmalloc_objs for bo cache size list - disable V3D interrupt across runtime suspend - fix binner slot allocation - fix fw refcount leak" * tag 'drm-fixes-2026-10-11' of https://gitlab.freedesktop.org/drm/kernel: (39 commits) drm/nouveau: Skip the Turing CE workaround object for non-GR channels drm/vc4: Fix binner slot allocation failing on an idle GPU drm/vc4: Disable the V3D interrupt across runtime suspend drm/imagination: Size page table preallocation by device address drm/imagination: Fix reference and vm_bo handling in remap() drm/amdgpu: make Mac FB workaround generic drm/amdkfd: fix dma_buf reference leak in get_dmabuf_info drm/amd/display: Don't replace a sink mode that shares the native totals drm/amdkfd: align SDMA doorbell base for shader doorbell writes drm/amdgpu: copy debugfs register data outside the GRBM/SRBM locks drm/amdgpu: serialize vblank counter reads against GPU reset drm/amd/display: disable self-refresh on tearing flips drm/amdgpu/userq: return the memdup_user() error for the user MQD drm/amdgpu/userq: only accept doorbell BOs as queue doorbell drm/amd/display: Fix direct scanout alpha on some DRM_FORMATs drm/xe/i2c: cancel the client work on remove drm/xe/sysctrl: Fix mailbox header handling drm/i915/gt: Unmask interrupts only when ACTIVE is true drm/i915/gem: Prevent overstepping exec array boundary drm/gud: don't keep a connector without a CRTC as connector_state ...
2026-10-10Merge tag 'i2c-fixes-7.3-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux Pull i2c fix from Andi Shyti: "Just one qcom-geni fix for a runtime PM reference leak during transfer setup" * tag 'i2c-fixes-7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux: i2c: qcom-geni: release runtime PM reference when set_rate fails
2026-10-10drm/msm/a6xx: Split out a7xx/a8xx device tablesRob Clark
This way we can start including generated tables for a8xx GPU snapshot in the device table (without having conflicts with earlier gens if we eventually try to retrofit this approach, or later gens in the future). Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/759096/ Message-ID: <20261010154125.726149-3-robin.clark@oss.qualcomm.com>
2026-10-10drm/msm/a6xx: Move a702/a704 to a6xx listRob Clark
It is a bit more a6xx than a7xx, and this simplifies the next patch. Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/759094/ Message-ID: <20261010154125.726149-2-robin.clark@oss.qualcomm.com>
2026-10-10drm/msm/a8xx: report the GMEM size of the active slicesRahul Pon
A8xx GPUs split GMEM evenly between their slices, and parts can have slices fused off: a8xx_gpu_get_slice_info() reads the active slice mask and folds the slice count into the chip ID. The GMEM size reported to userspace (MSM_PARAM_GMEM_SIZE) is still the catalog value for all slices, so on a part with fused-off slices userspace would size its tiles and place its CCU caches past the end of the GMEM that exists. Qualcomm's downstream driver reports GMEM for the active slices: gen8_get_gmem_size() in KGSL divides the GMEM size by the number of physical slices and multiplies it by the number of active ones. Do the same when reading the slice mask. The GMEM protection and UCHE setup still cover the full range, as in KGSL. Fixes: 288a93200892 ("drm/msm/adreno: Introduce A8x GPU Support") Signed-off-by: Rahul Pon <theflyingrahul@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/757560/ Message-ID: <20260930183840.1171-1-theflyingrahul@gmail.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-10-11MAINTAINERS: erofs: add dev branch to git tree entryChao Yu
The EROFS entry lists the git tree without a branch, so tools that derive a baseline from MAINTAINERS, e.g. sashiko, fall back to the remote HEAD, which points to master. master only moves at -rc1, so series developed against the dev branch fail to apply there. Name the dev branch explicitly, where erofs patches are queued. Signed-off-by: Chao Yu <chao@kernel.org> Acked-by: Gao Xiang <xiang@kernel.org> Signed-off-by: Gao Xiang <xiang@kernel.org>
2026-10-11erofs: fix xattrs handling when metadata compression is usedBinglei Wang
erofs_bread() reuses a cached folio on page index match without checking folio->mapping. xattr.c calls erofs_init_metabuf() twice on the same buffer without erofs_put_metabuf(); the two in_metabox sources differ, so buf->mapping can switch while buf->page still belongs to the old address_space. The next erofs_bread() then reads the wrong mapping, dropping shared xattrs with METABOX. We require folio->mapping == buf->mapping in the reuse check; otherwise drop the cached folio and re-read via the slow path. Fixes: 414091322c63 ("erofs: implement metadata compression") Cc: Bo Liu (OpenAnolis) <liubo03@inspur.com> Signed-off-by: Binglei Wang <l3b2w1@gmail.com> Reviewed-by: Gao Xiang <xiang@kernel.org> Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Gao Xiang <xiang@kernel.org>
2026-10-10rust: drm: Remove unused flags argument from Registration::new()Danilo Krummrich
The flags argument to drm_dev_register() is only passed to the deprecated .load() callback. Rust DRM drivers always set this callback to NULL, so the argument has no effect. Remove the argument from drm::Registration::new(), pass zero to drm_dev_register(), and update the Nova and Tyr callers. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260929190024.2248099-2-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-10-10rust: drm: Return impl PinInit from drm::Registration::new()Danilo Krummrich
Convert drm::Registration to return an impl PinInit<Self, Error> rather than creating a separate allocation. This removes an otherwise unnecessary allocation. Update both in-tree callers (nova, tyr) to construct their bus device private data using try_pin_init!(). Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260929190024.2248099-1-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-10-11Merge tag 'amd-drm-next-7.4-2026-10-08' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/amdgpu/kernel into drm-next amd-drm-next-7.4-2026-10-08: amdgpu: - Fix direct scanout alpha on some DRM_FORMATs - UserQ fixes - Fix for PSR with tearing flips - GPU reset vblank fix - Debugfs register interface fix - Fix mode patching - Expand Mac reserved memory workaround - GC 12.1 fixes - Clean up MES/HWS vmid mask handling - Make runtime pm more fine grained - A+A SPM fixes - SR-IOV fixes - 3D LUT fixes - HDMI fixes - DCN 4.2 fixes - HDMI VRR fixes - DC tracing fixes - UALink fixes amdkfd: - SDMA doorbell fix - Fix dma-buf reference leak in error path Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20261008212310.2508510-1-alexander.deucher@amd.com
2026-10-11Merge tag 'drm-misc-fixes-2026-10-09' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes A pointer assignment fix for gud, a reference fix and a preallocation size fix for imagination, a suspend fix and an allocation fix when idle for vc4, and a hardware variant fix for nouveau. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <self@mripard.dev> Link: https://patch.msgid.link/asjkbknTHg2t8JGy@houat
2026-10-11Merge tag 'amd-drm-fixes-7.3-2026-10-08' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/amdgpu/kernel into drm-fixes amd-drm-fixes-7.3-2026-10-08: amdgpu: - Fix direct scanout alpha on some DRM_FORMATs - UserQ fixes - Fix tearing flips with PSR - GPU reset vblank fix - Debugfs register interface fix - Fix display mode patching - Expand Mac reserved memory workaround amdkfd: - SDMA doorbell fix - Fix dma-buf reference leak in error path Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20261008174658.2506431-1-alexander.deucher@amd.com
2026-10-11Merge tag 'drm-xe-fixes-2026-10-08' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes Fixes on: - i2c removal (Fan) - system Controller Maibox header handling (Mallesh) - two bo pin/unpin accounting bugs (Thomas) - not emitting a w/a twice (Tvrtko) - xe_mmio_wait32() to honor delay/sleep maximums (Alan) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/asfEfgbIjs0GJ-RF@intel.com
2026-10-10vfio/pci: Remove the core dependency on driver dataSimon Song
vfio-pci-core currently has runtime functions that interpret pci driver_data as a pointer to vfio_pci_core_device, and enforce vfio variant drivers must set vfio_pci_core_device to their pci driver_data. This constrains variant drivers' private-data layout, including the typed driver data used by the Rust PCI infrastructure. Add VFIO_PCI_CORE_DEFINE_CALLBACKS macro to generate wrapper code for each vfio variant driver, update vfio variant drivers to store their private structures in driver_data and use generated wrapper to pass the vfio core device to helpers. Assisted-by: LLM Suggested-by: Jason Gunthorpe <jgg@nvidia.com> Suggested-by: Alex Williamson <alex.williamson@nvidia.com> Suggested-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/all/DLFD2ZDSK9YQ.3A4R66G8UJMD8@kernel.org/ Signed-off-by: Simon Song <xinmengs@nvidia.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20261005184236.1946167-2-xinmengs@nvidia.com [VGA chunks and commit log reference dropped with rebase to commit 93d41424caf7 ("PCI/VGA: pass a data pointer to be used in the decode callback (v2)")] Signed-off-by: Alex Williamson <alex@shazbot.org>
2026-10-10Merge tag 'topic/pci-vgaarb-rework-2026-10-01' of ↵Alex Williamson
https://gitlab.freedesktop.org/drm/kernel into v7.4/vfio/next pci/vgaarb rework for drm/vfio This reworks the vgaarb API to be a bit more sane. Signed-off-by: Alex Williamson <alex@shazbot.org>
2026-10-10Merge branch 'bpf-add-bpf_tcp_ops-hooks-for-tcp-autolowat'Alexei Starovoitov
Kuniyuki Iwashima says: ==================== bpf: Add bpf_tcp_ops hooks for TCP AutoLOWAT. This series introduces two callbacks for bpf_tcp_ops: .enqueue_rcvq(): invoked when TCP stack enqueues skb to sk->sk_receive_queue .dequeue_rcvq(): invoked in tcp_cleanup_rbuf() after data is dequeued from sk->sk_receive_queue Those callbacks can be enabled on a per-socket basis by a new kfunc bpf_tcp_ops_set_flags(): bpf_tcp_ops_set_flags((struct tcp_sock *)sk, BPF_TCP_OPS_FLAG_RCVQ, 0); This allows the BPF prog to dynamically adjust sk->sk_rcvlowat, suppressing unnecessary EPOLLIN wakeups until sufficient data is available in the receive queue. This functionality, which we call "TCP AutoLOWAT", was originally developed in 2020 by Tenzin Ukyab with the help of Soheil Hassas Yeganeh, Arjun Roy, and Eric Dumazet. It has served Google RPC workloads for more than 5 years. Combined with TCP RX zerocopy, this typically allows us to read an entire RPC frame with just a single wakeup and a single system call. While the original implementation was specialised for our internal RPC format, this series introduces a more flexible version by leveraging BPF. The bpf prog in the last selftest patch closely mirrors the core logic of the original implementation to provide a real-world example. Note that the new callbacks are not supported on legacy SOCK_OPS. Changes: v5: * Patch 4 & 5 * Always inline bpf_tcp_ops_hdr_opt_len() and bpf_skops_hdr_opt_len() to tcp_established_options(). v4: https://lore.kernel.org/bpf/20261006192601.1875100-1-kuniyu@google.com/ * Patch 2 * Allow-listed BPF_PROG_TYPE_CGROUP_SOCKOPT and _SKB in bpf_tcp_ops_set_flags_kfunc_filter() * Add doc for flag enum and bpf_tcp_ops members * Patch 4 * Check static key first and then flags * Patch 5 (new) * Bubble up static key check for SOCK_OPS similar to bpf_tcp_ops * Patch 6 * Use bpf_tcp_ops_call_flag() v3: https://lore.kernel.org/bpf/20261005154533.4147685-1-kuniyu@google.com/ * Add patch 2 ~ 4 (guard bpf_tcp_ops w/ a new flag) * Patch 5 & 9 : Adapt to a new flag and kfunc v2: https://lore.kernel.org/netdev/20260923213719.224838-1-kuniyu@google.com/ * Add patch 1 not to allow setsockopt() from new callbacks * Patch 8 (selftest) * Avoid address comparison for a specific version of gcc. * Make rpc_test_cases[] static. * Update comment in rpc_test_case[]. v1: https://lore.kernel.org/bpf/20260920195633.3033620-1-kuniyu@google.com/ Legacy SOCK_OPS version: v3: https://lore.kernel.org/bpf/20260523083001.2911931-1-kuniyu@google.com/ v2: https://lore.kernel.org/bpf/20260522074601.1658705-1-kuniyu@google.com/ v1: https://lore.kernel.org/bpf/20260508073355.3916746-1-kuniyu@google.com/ ==================== Link: https://patch.msgid.link/20261008031604.256498-1-kuniyu@google.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-10-10selftest: bpf: Add test for bpf_tcp_ops.{enqueue,dequeue}_rcvq().Kuniyuki Iwashima
The test is roughly divided into two stages, and the sequence is as follows: I) Setup 1. Attach two BPF programs to a cgroup 2. Establish a TCP connection (@client <-> @child) within the cgroup 3. Enable BPF_TCP_OPS_FLAG_RCVQ on @child via setsockopt() II) RPC frame exchange in various patterns 4. Send a partial RPC descriptor from @client to @child 5. Verify that epoll does NOT wake up @child 6. Send the remaining data of the RPC frame 7. Verify that epoll finally wakes up @child During setup, two BPF programs are attached to simulate a real-world scenario; one is bpf_tcp_ops and the other is CGROUP_SOCKOPT. While the bpf_tcp_ops prog handles the dynamic adjustment of sk->sk_rcvlowat, the CGROUP_SOCKOPT prog is used to enable the TCP AutoLOWAT feature via userspace setsockopt() using pseudo options: #define SOL_BPF 0xdeadbeef #define BPF_TCP_AUTOLOWAT 0x8badf00d setsockopt(fd, SOL_BPF, BPF_TCP_AUTOLOWAT, &(int){1}, sizeof(int)); This reflects a common production use case where an application decides to start parsing RPC frames only at a certain point in the stream (e.g., after HTTP Upgrade), rather than immediately after TCP 3WHS (->passive_established(), etc). When BPF_TCP_AUTOLOWAT is enabled, the BPF prog sets BPF_TCP_OPS_FLAG_RCVQ and initializes sk_local_storage for two sequence numbers to manage its state. Then, for the RPC frame exchange, this test uses a simple format defined as follows: 0 8 16 24 32 +--------+--------+-------+--------+ `. | header size | | +--------+--------+-------+--------+ > RPC descriptor (8 bytes) | payload size | | +--------+--------+-------+--------+ .' ~ header ~ +--------+--------+-------+--------+ ~ payload ~ +--------+--------+-------+--------+ Every time a new skb is enqueued to sk->sk_receive_queue, the bpf_tcp_ops prog parses it and updates these sequence numbers: rpc_desc_seq : the SEQ # of the start of the RPC descriptor rpc_end_seq : the SEQ # of the end of the RPC frame => rpc_desc_seq + 8 + header size + payload size Assume we receive two RPC descriptors in the following pattern: 1. When we receive skb-1, only part of the RPC descriptor is parsed. rpc_desc_seq is set to the first byte while rpc_end_seq is unknown. Thus, sk->sk_rcvlowat is set to the size of the RPC descriptor (8 bytes). <- skb-1 -> <---- skb-2 ----> <------ skb-3 -----> +-----------+.................+....................+...... | RPC desc 1 | header + payload | RPC desc 2 | ... +-----------+.................+....................+...... ^ ^-. `- rpc_desc_seq `- sk->sk_rcvlowat 2. Next, we receive skb-2, which completes the first RPC descriptor. Now rpc_end_seq is known, so sk->sk_rcvlowat is advanced to it. <- skb-1 -> <---- skb-2 ----> <------ skb-3 -----> +-----------+-----------------+....................+...... | RPC desc 1 | header + payload | RPC desc 2 | ... +-----------+-----------------+....................+...... ^ ^ '- rpc_desc_seq '- rpc_end_seq & sk->sk_rcvlowat 3. Once we receive skb-3, which contains the next full RPC descriptor, rpc_desc_seq is advanced and rpc_end_seq is updated according to the size of RPC frame 2. Note that sk->sk_rcvlowat is NOT updated to the new rpc_end_seq yet. This ensures that the application is woken up to read the already complete RPC frame 1. <- skb-1 -> <---- skb-2 ----> <------ skb-3 -----> +-----------+-----------------+--------------------+...... | RPC desc 1 | header + payload | RPC desc 2 | ... | +-----------+-----------------+--------------------+...... ^ ^ rpc_desc_seq -----------' rpc_end_seq ----...-' & sk->sk_rcvlowat This sequence corresponds to the 4th test case in rpc_test_cases[], and we can see helpful output if we "#define DEBUG": # cat /sys/kernel/tracing/trace_pipe | \ awk '{ if ($0 ~ /AF_/) sub(/^.*AF_/, "AF_"); print $0 }' & \ BGPID=$!; ./test_progs -t tcp_autolowat; kill -9 -$BGPID ... AF_INET6 rpc_test_cases[3]: Start parsing skb: seq: 0, end_seq: 1, len: 1, rpc_desc_seq: 0, rpc_end_seq: 0, rpc_buff_len: 0 AF_INET6 rpc_test_cases[3]: Copied 1 bytes: rpc_desc_buff_len: 1 AF_INET6 rpc_test_cases[3]: Setting rcvlowat: tp->copied_seq: 0, rpc_desc_seq: 0, rpc_end_seq: 0, rpc_desc_buff_len: 1 AF_INET6 rpc_test_cases[3]: Set rcvlowat: expected: 8, actual: 8 AF_INET6 rpc_test_cases[3]: Start parsing skb: seq: 1, end_seq: 8, len: 7, rpc_desc_seq: 0, rpc_end_seq: 0, rpc_buff_len: 1 AF_INET6 rpc_test_cases[3]: Copied full descriptor: rpc_desc_seq: 0, rpc_end_seq: 258, header_len: 100, payload_len: 150 AF_INET6 rpc_test_cases[3]: No more descriptor: rpc_end_seq: 258, end_seq: 8 AF_INET6 rpc_test_cases[3]: Setting rcvlowat: tp->copied_seq: 0, rpc_desc_seq: 0, rpc_end_seq: 258, rpc_desc_buff_len: 8 AF_INET6 rpc_test_cases[3]: Set rcvlowat: expected: 258, actual: 258 ... Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Reviewed-by: Amery Hung <ameryhung@gmail.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://patch.msgid.link/20261008031604.256498-11-kuniyu@google.com
2026-10-10bpf: tcp: Add kfunc to adjust sk->sk_rcvlowat.Kuniyuki Iwashima
bpf_tcp_ops.{enqueue,dequeue}_rcvq() were added to parse skb and adjust sk->sk_rcvlowat dynamically to suppress unnecessary wakeups. Let's add a new kfunc to set sk->sk_rcvlowat. Negative values are clamped to INT_MAX, consistent with SO_RCVLOWAT. For enqueue_rcvq(), wakeup is set to false because: * tcp_data_ready() is always called after the hooks in tcp_queue_rcv() and tcp_ofo_queue(). * when tcp_fastopen_add_skb() is called for TFO SYN, the socket is not yet accept()ed, and when called for TFO SYN+ACK, the socket is woken up by sk->sk_state_change() anyway. For dequeue_rcvq(), wakeup is set to true because tcp_data_ready() is not called in that path. An alternative would be to support bpf_setsockopt() for these hooks. However, that approach involves excessive conditionals and an unnecessary memcpy(), costs we do not want to pay for every skb in the TCP fast path. Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Tested-by: Clément Léger <cleger@meta.com> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Reviewed-by: Amery Hung <ameryhung@gmail.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://patch.msgid.link/20261008031604.256498-10-kuniyu@google.com
2026-10-10bpf: mptcp: Don't support BPF_TCP_OPS_FLAG_RCVQ.Kuniyuki Iwashima
The next patch exposes a new kfunc calling __tcp_set_rcvlowat() to bpf_tcp_ops. MPTCP has its own sock->ops->set_rcvlowat() / mptcp_set_rcvlowat(), so we should not allow calling __tcp_set_rcvlowat() on MPTCP subflows. Let's disable BPF_TCP_OPS_FLAG_RCVQ for MPTCP for now. If needed in the future, bpf_tcp_ops_set_rcvlowat() could be extended to properly support MPTCP. Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Reviewed-by: Amery Hung <ameryhung@gmail.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://patch.msgid.link/20261008031604.256498-9-kuniyu@google.com
2026-10-10tcp: Split out __tcp_set_rcvlowat().Kuniyuki Iwashima
We will add a kfunc for bpf_tcp_ops.{enqueue,dequeue}_rcvq() to adjust sk->sk_rcvlowat. These hooks are triggered * when the TCP stack enqueues an skb to sk->sk_receive_queue * after data is dequeued from sk->sk_receive_queue In the enqueue path, tcp_data_ready() is always called after the hooks in tcp_queue_rcv() and tcp_ofo_queue(). If tcp_set_rcvlowat() were used as is, tcp_data_ready() could be called twice for the same skb, which is redundant and also confusing. Let's split out __tcp_set_rcvlowat() and add a flag to control wakeup behaviour. Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Reviewed-by: Amery Hung <ameryhung@gmail.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://patch.msgid.link/20261008031604.256498-8-kuniyu@google.com
2026-10-10bpf: tcp: Introduce bpf_tcp_ops.{enqueue,dequeue}_rcvq().Kuniyuki Iwashima
Waking up a thread per packet is expensive when an application processes variable-length frames (e.g., RPC) that span multiple packets. SO_RCVLOWAT can defer wakeups, but because the frame size is encoded in a fixed-size descriptor at the start of each frame, the application has to: 1. wake up and recv() the descriptor, 2. raise SO_RCVLOWAT to the payload size via setsockopt(), 3. wake up and recv() the payload, and 4. reset SO_RCVLOWAT back to the descriptor size via setsockopt() for the next frame. This requires an extra wakeup and two setsockopt() syscalls for every single RPC frame. With SOCKMAP, we can parse skb and suppress wakeups in kernel, but SOCKMAP adds overhead and also kills zerocopy. Let's add lighter-weight opt-in callbacks to bpf_tcp_ops to replace that. .enqueue_rcvq(): invoked when TCP stack enqueues skb to sk->sk_receive_queue .dequeue_rcvq(): invoked in tcp_cleanup_rbuf() after data is dequeued from sk->sk_receive_queue Those callbacks can be enabled on a per-socket basis by bpf_tcp_ops_set_flags(): bpf_tcp_ops_set_flags((struct tcp_sock *)sk, BPF_TCP_OPS_FLAG_RCVQ, 0); Later, we will add a new kfunc to adjust sk->sk_rcvlowat from these callbacks. This will allow the bpf_tcp_ops prog to parse each skb and dynamically adjust sk->sk_rcvlowat to suppress unnecessary EPOLLIN wakeups until sufficient data is available in the receive queue. The placement of bpf_tcp_ops_call() in tcp_ofo_queue() and tcp_fastopen_add_skb() is chosen to provide the same snapshot as tcp_queue_rcv(). For example, if bpf_tcp_ops_call() were called before updating TCP_SKB_CB(skb)->seq in tcp_fastopen_add_skb(), BPF prog would need an extra branch for the unlikely TFO case to strip SYN. In addition, the TCP stack can queue overlapping skbs into recvq. Once rcv_nxt is updated with a new skb, BPF prog can no longer infer the previous rcv_nxt from skb->len. Lastly, dequeue_rcvq() is placed in tcp_cleanup_rbuf() rather than __tcp_cleanup_rbuf() so that it is not called for sockets in SOCKMAP, where calling sk->sk_data_ready() from the new kfunc would otherwise trigger infinite recursion. Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Reviewed-by: Amery Hung <ameryhung@gmail.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://patch.msgid.link/20261008031604.256498-7-kuniyu@google.com
2026-10-10bpf: tcp: Check BPF_SOCK_OPS_TEST_FLAG() after ↵Kuniyuki Iwashima
cgroup_bpf_enabled(CGROUP_SOCK_OPS). BPF_CGROUP_RUN_PROG_XXX() macros guard __cgroup_bpf_run_filter_XXX() with cgroup_bpf_enabled(). However, even when no SOCK_OPS prog is attached, callers still initialise struct bpf_sock_ops_kern (memset(), etc.) or evaluate BPF_SOCK_OPS_TEST_FLAG(), which loads tp->bpf_sock_ops_cb_flags from a cold cacheline near the end of struct tcp_sock. Similar to bpf_tcp_ops, let's check cgroup_bpf_enabled() before BPF_SOCK_OPS_TEST_FLAG() and struct bpf_sock_ops_kern setup, and rename BPF_CGROUP_RUN_PROG_SOCK_OPS{,_SK}() with __ prefix. Since all direct callers of tcp_call_bpf() pass 0 and NULL for nargs and args, they can be folded into the new tcp_call_bpf() macro. All callers of tcp_call_bpf_{2,3}arg() check BPF_SOCK_OPS_TEST_FLAG() and do not need the return value. These are replaced with the new tcp_call_bpf_flag() macro. Now, bpf_skops_hdr_opt_len() and bpf_tcp_ops_hdr_opt_len() are just NOPs without bpf prog attached. $ llvm-objdump -S -D --disassemble=tcp_established_options vmlinux ... ; asm goto(ARCH_STATIC_BRANCH_ASM("%c0 + %c1", "%l[l_yes]") ; size = MAX_TCP_OPTION_SPACE - remaining; ffffffff825127ea: b9 28 00 00 00 movl $0x28, %ecx ffffffff825127ef: 29 c1 subl %eax, %ecx ; return size; ffffffff825127f1: 89 c8 movl %ecx, %eax ... ffffffff825127fb: 2e e9 6f 02 43 00 jmp 0xffffffff82942a70 <__x86_return_thunk> Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Reviewed-by: Amery Hung <ameryhung@gmail.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://patch.msgid.link/20261008031604.256498-6-kuniyu@google.com
2026-10-10bpf: tcp: Guard fast-path bpf_tcp_ops_call() under per-socket flag.Kuniyuki Iwashima
bpf_tcp_ops.{parse_hdr,hdr_opt_len} are called for every incoming / outgoing skb. bpf_tcp_ops.rtt is called once per RTT, which is every incoming skb in ping-pong workloads like tcp_rr. Even attaching NULL callbacks in the fast path hurts performance. Let's guard them (and write_hdr_opt) with the new per-socket flags. __bpf_tcp_ops_call() and bpf_tcp_ops_call_flag() are added to check cgroup_bpf_enabled(CGROUP_TCP_SOCK_OPS) first and avoid accessing tp->bpf_tcp_ops_flags when no bpf_tcp_ops is attached. Note that bpf_tcp_ops_hdr_opt_len() has 3 callers and previously checked the static key both in tcp_established_options() and inside bpf_tcp_ops_call(). Now the static key is checked once at the beginning of bpf_tcp_ops_hdr_opt_len(), and the redundant check in tcp_established_options() is removed. tcp_bpf_hdr_opt_len() must use __always_inline, not just inline, otherwise Clang inlines bpf_tcp_ops_hdr_opt_len() to tcp_bpf_hdr_opt_len() instead. $ llvm-objdump -S -D --disassemble=tcp_established_options vmlinux ... ; if (unlikely(BPF_SOCK_OPS_TEST_FLAG(tp, ffffffff8251270e: 41 f6 87 20 0c 00 00 40 testb $0x40, 0xc20(%r15) ffffffff82512716: 75 47 jne 0xffffffff8251275f <tcp_established_options+0x1ff> ; asm goto(ARCH_STATIC_BRANCH_ASM("%c0 + %c1", "%l[l_yes]") ffffffff82512718: 0f 1f 44 00 00 nopl (%rax,%rax) ; return size; ffffffff8251271d: 44 89 e0 movl %r12d, %eax ffffffff82512720: 5b popq %rbx ffffffff82512721: 41 5c popq %r12 ffffffff82512723: 41 5e popq %r14 ffffffff82512725: 41 5f popq %r15 ffffffff82512727: 5d popq %rbp ffffffff82512728: 2e e9 42 03 43 00 jmp 0xffffffff82942a70 <__x86_return_thunk> bpf_skops_write_hdr_opt() is still not free, but it can be optimised later if needed. Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://patch.msgid.link/20261008031604.256498-5-kuniyu@google.com
2026-10-10selftest: bpf: Use bpf_tcp_ops_set_flags() in bpf_tcp_ops_hdr.c.Kuniyuki Iwashima
The next patch guards bpf_tcp_ops callbacks in the fast path with per-socket flags. Let's use bpf_tcp_ops_set_flags() to enable flags for parse_hdr, write_hdr_opt, and hdr_opt_len. Note that BPF_TCP_OPS_FLAG_PARSE_HDR_OPT_ALL and BPF_TCP_OPS_FLAG_PARSE_HDR_OPT_UNKNOWN are used on the server and client, respectively, for better coverage. Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Reviewed-by: Amery Hung <ameryhung@gmail.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://patch.msgid.link/20261008031604.256498-4-kuniyu@google.com
2026-10-10bpf: tcp: Add a new per-socket flag and kfunc for bpf_tcp_ops.Kuniyuki Iwashima
The legacy SOCK_OPS guards some hooks with a per-socket flag, tp->bpf_sock_ops_cb_flags. In contrast, bpf_tcp_ops was initially designed without per-socket flags so that users can simply define only the callbacks they need. However, it turned out that even attaching a bpf_tcp_ops with a NULL callback incurs measurable overhead in the fast path. [0] We could reuse tp->bpf_sock_ops_cb_flags, but it is u8 and has only 1 bit left for a new opt-in callback, while not all of the 7 existing opt-in hooks are in the fast path and really need a flag guard. Moreover, tp->bpf_sock_ops_cb_flags has two bpf helper functions to update it, both of which require sock_owned_by_me(sk): * bpf_sock_ops_cb_flags_set() * bpf_setsockopt(TCP_BPF_SOCK_OPS_CB_FLAGS) Both helpers only overwrite the field, which leads to reading and modifying the flags in the BPF prog and then writing them back via the helper. This prevents use from the fast path (tc or cgroup_skb) hooks where bh_lock_sock() alone cannot prevent races with process context. Let's add a new u32 field, tp->bpf_tcp_ops_flags, at the end of the tcp_sock_read_txrx cacheline group, along with a new kfunc, bpf_tcp_ops_set_flags(). bpf_tcp_ops_set_flags() takes bitmasks of flags to enable and disable and updates tp->bpf_tcp_ops_flags atomically via try_cmpxchg() without relying on lock_sock(). The kfunc is exposed to bpf_tcp_ops, BPF_PROG_TYPE_CGROUP_SOCKOPT, and BPF_PROG_TYPE_CGROUP_SKB. The first argument is struct tcp_sock * so that bpf_tcp_sock() etc is required for cgroup hooks, but not for bpf_tcp_ops where struct sock * is promoted to struct tcp_sock * automatically. The fast-path callbacks will be guarded by the new flags in a later patch after updating the existing selftest to avoid breaking bisection. Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Reviewed-by: Amery Hung <ameryhung@gmail.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://lore.kernel.org/netdev/CAMB2axMwBuz3X4Uwn5uzZUqm91EbiMnbQX832wUFOQ44fOwDnQ@mail.gmail.com/ #[0] Link: https://patch.msgid.link/20261008031604.256498-3-kuniyu@google.com
2026-10-10bpf: tcp: Convert deny-list for bpf_{get,set}sockopt() to allow-list.Kuniyuki Iwashima
Currently, four bpf_tcp_ops callbacks are not allowed to call bpf_setsockopt() and bpf_getsockopt(). However, the deny-list is fragile, and when a new callback is added, we might re-open a can of worms. [0][1] Let's convert it to allow-list. Note that it can be written as offsetof(,X) <= moff <= offsetof(,Y) but clang can optimise to similar code anyway. Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Reviewed-by: Amery Hung <ameryhung@gmail.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://lore.kernel.org/r/20220929070407.965581-5-martin.lau@linux.dev/ #[0] Link: https://lore.kernel.org/bpf/20260421155804.135786-1-kafai.wan@linux.dev/ #[1] Link: https://patch.msgid.link/20261008031604.256498-2-kuniyu@google.com
2026-10-10bpf, arm64: Fix racy plt target update in bpf_arch_text_poke()Matthew Wood
When a long-jump trampoline is attached to or detached from a bpf prog, bpf_arch_text_poke() updates the plt target at the end of the prog by temporarily making the page writable: set_memory_rw(page); WRITE_ONCE(plt->target, plt_target); set_memory_ro(page); Since commit 1dad391daef1 ("bpf, arm64: use bpf_prog_pack for memory management"), bpf progs are allocated from the bpf prog pack, so unrelated progs and their plts commonly share a page. The sequence above is not serialized against other pokers, it runs before text_mutex is taken and callers only hold the lock of the trampoline being updated. Two CPUs attaching to or detaching from different target progs in the same page can therefore race: CPU A CPU B set_memory_rw(page) set_memory_rw(page) WRITE_ONCE(plt_B->target, ...) set_memory_ro(page) WRITE_ONCE(plt_A->target, ...) <- permission fault This was hit on an arm64 server with 64K pages while attaching fentry programs to bpf progs: Unable to handle kernel write to read-only memory at virtual address ffff80008f46d5f8 ESR = 0x000000009600004f FSC = 0x0f: level 3 permission fault pte=00c00200ea5a0783 Internal error: Oops: 000000009600004f [#1] SMP pc : bpf_arch_text_poke+0x214/0x238 lr : bpf_arch_text_poke+0x200/0x238 Call trace: bpf_arch_text_poke+0x214/0x238 (P) __bpf_trampoline_link_prog+0x1c8/0x470 bpf_trampoline_link_prog+0x64/0x90 bpf_tracing_prog_attach+0x318/0x4a8 bpf_raw_tp_link_attach+0x104/0x258 bpf_raw_tracepoint_open+0x6c/0x90 __sys_bpf+0x134c/0x3e10 Rather than serializing the permission changes, stop changing page permissions altogether and write the plt target with aarch64_insn_write_literal_u64(). It writes through the text patching fixmap under patch_lock, the same way the rest of the prog pack is written, and performs a single-copy atomic 64-bit store. The plt target is naturally aligned (see build_plt()), so CPUs concurrently executing the plt still observe either the old or the new target. This is the same helper ftrace and static calls use to update 64-bit literals that are loaded concurrently. Fixes: 1dad391daef1 ("bpf, arm64: use bpf_prog_pack for memory management") Signed-off-by: Matthew Wood <thepacketgeek@gmail.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://patch.msgid.link/20261009173802.1248441-1-thepacketgeek@gmail.com
2026-10-10Merge branch ↵Alexei Starovoitov
'bpf-test_run-fix-false-ebadmsg-with-bpf_f_test_skb_checksum_complete' Maxim Skokov says: ==================== bpf: test_run: Fix false -EBADMSG with BPF_F_TEST_SKB_CHECKSUM_COMPLETE BPF_PROG_TEST_RUN with BPF_F_TEST_SKB_CHECKSUM_COMPLETE returns -EBADMSG for correct tc programs that call bpf_skb_change_tail(). The helper moves the skb to CHECKSUM_NONE and leaves skb->csum stale, but the post-run check added by commit a3cfe84cca28 ("bpf: Add CHECKSUM_COMPLETE to bpf test progs") still compares against it. Patch 1 only does the check while the skb is still CHECKSUM_COMPLETE. Patch 2 adds selftests for a trim, a grow followed by a write, and a negative case that keeps the skb CHECKSUM_COMPLETE with a stale skb->csum. Tested in a VM on bpf, with two kernels that differ only by patch 1 (subtest results): without patch 1 with patch 1 change_tail_trim FAIL (-EBADMSG) OK change_tail_grow_write FAIL (-EBADMSG) OK store_no_recompute OK OK test_skb_pkt_end OK OK Changes in v2: - Put the opening /* of multi-line comments on its own line (bpf-ci, Sashiko). v1: https://lore.kernel.org/bpf/20261007181249.352831-1-skokovmaksimevg@gmail.com/ ==================== Link: https://patch.msgid.link/20261009174755.22026-1-skokovmaksimevg@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-10-10selftests/bpf: Cover test_run csum validation after bpf_skb_change_tail()Maxim Skokov
Add BPF_F_TEST_SKB_CHECKSUM_COMPLETE tests for tc programs that move the skb out of CHECKSUM_COMPLETE with bpf_skb_change_tail(): - change_tail_trim trims the last 4 bytes of pkt_v4. They hold the non-zero tcp.urg_ptr, so the stale skb->csum no longer matches the packet. - change_tail_grow_write appends 4 zero bytes, which on their own do not change the sum, and then writes a byte with BPF_F_RECOMPUTE_CSUM. That write can no longer update skb->csum. Both return -EBADMSG without the preceding test_run fix and pass with it. Also add store_no_recompute as a negative test. It writes a byte without BPF_F_RECOMPUTE_CSUM, so the skb stays CHECKSUM_COMPLETE with a stale skb->csum, and test_run must keep returning -EBADMSG. This checks that the validation still runs for CHECKSUM_COMPLETE skbs. The passing case, a CHECKSUM_COMPLETE skb whose checksum is updated correctly, is already covered by test_skb_pkt_end. Signed-off-by: Maxim Skokov <skokovmaksimevg@gmail.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://patch.msgid.link/20261009174755.22026-3-skokovmaksimevg@gmail.com