kernel/git/next/linux-next.git/init, branch master

Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git

2026-07-07T12:10:11+00:00

Merge branch 'fs-next' of linux-next

2026-07-07T11:54:18+00:00

init/main.c: use bootconfig_cmdline_requested() for the runtime opt-in

2026-07-02T12:15:46+00:00

setup_boot_config() open-coded the same "is bootconfig requested on the kernel command line?" check that setup_arch() performs via the shared bootconfig_cmdline_requested() helper. Switch it to the helper so the early (setup_arch) and late (setup_boot_config) paths use one parser and cannot disagree on what counts as opt-in. The helper also reports the offset of the init arguments following a "--" separator, which is exactly what initargs_offs needs, so the local parse_args() call, its bootconfig_params() callback and the tmp_cmdline copy are removed. No functional change intended. Link: https://lore.kernel.org/all/20260626-bootconfig_using_tools-v7-9-24ab72139c29@debian.org/ Suggested-by: Masami Hiramatsu (Google) Signed-off-by: Breno Leitao Signed-off-by: Masami Hiramatsu (Google)

bootconfig: skip runtime kernel.* render once prepended early

2026-07-02T12:15:46+00:00

setup_boot_config() folds the embedded bootconfig "kernel" subtree into the command line via xbc_make_cmdline("kernel"). A subsequent patch lets an architecture prepend the build-time-rendered embedded "kernel" keys to boot_command_line early in setup_arch(); rendering them again here would then duplicate every key in saved_command_line and make accumulating handlers (console=, earlycon=, ...) re-register the same value. Track whether the bootconfig data came from the embedded source (from_embedded) and skip the runtime render only when the early prepend actually happened, as reported by xbc_embedded_cmdline_applied(). On architectures that do not select ARCH_SUPPORTS_CMDLINE_FROM_BOOTCONFIG that helper is a stub returning false, so this path is unchanged and the embedded "kernel" keys still reach the cmdline via the runtime parser exactly as before. Link: https://lore.kernel.org/all/20260626-bootconfig_using_tools-v7-8-24ab72139c29@debian.org/ Signed-off-by: Breno Leitao Signed-off-by: Masami Hiramatsu (Google)

bootconfig: render embedded bootconfig as a kernel cmdline at build time

2026-07-02T12:15:45+00:00

Add the build-time pipeline that renders the "kernel" subtree of CONFIG_BOOT_CONFIG_EMBED_FILE into a flat cmdline string and stashes it in .init.rodata as embedded_kernel_cmdline[]. A follow-up patch adds the runtime helper that prepends this string to boot_command_line during early architecture setup so parse_early_param() sees the values. The build wires up: tools/bootconfig -C kernel - userspace tool already shared with lib/bootconfig.c, used here in -C mode to render a bootconfig file to a cmdline lib/embedded-cmdline.S - .incbin's the rendered text plus a NUL (listed under the EXTRA BOOT CONFIG MAINTAINERS entry) lib/Makefile rule - runs tools/bootconfig at build time Makefile prepare dep - ensures tools/bootconfig is built first, same pattern as tools/objtool and tools/bpf/resolve_btfids Drop the test target from tools/bootconfig/Makefile's default 'all' recipe so that hooking the binary into the kernel build does not run test-bootconfig.sh on every prepare. The tests stay available as 'make -C tools/bootconfig test', matching the convention of tools/objtool and tools/bpf/resolve_btfids whose 'all' targets only build the binary. Require BOOT_CONFIG_EMBED_FILE to be non-empty before the new option can be enabled, otherwise tools/bootconfig -C runs against an empty file and prints a parse error on every kernel build. The feature gates on CONFIG_ARCH_SUPPORTS_CMDLINE_FROM_BOOTCONFIG, a silent symbol arches select once they've wired the prepend call into setup_arch(). No arch selects it in this patch, so the user-visible CONFIG_CMDLINE_FROM_BOOTCONFIG is not yet enableable; when an arch later opts in, the runtime behavior is added by the follow-up patches. tools/bootconfig also installs on target systems, so its own Makefile keeps $(CC) and stays cross-buildable as a standalone tool. The kernel build, which runs the tool on the build host during prepare, instead forces CC=$(HOSTCC) from a dedicated tools/bootconfig rule and clears CROSS_COMPILE= in the sub-make. Without that clear, an LLVM=1 cross build would inherit CROSS_COMPILE and tools/scripts/Makefile.include would inject --target=/--sysroot= flags into the host clang invocation, producing a target binary that fails to exec ("Exec format error"). embedded-cmdline.S places the rendered string in its own .init.rodata subsection (.init.rodata.embed_cmdline) with the "a" (allocatable, read-only) flag and %progbits. lib/bootconfig-data.S already places the embedded bootconfig blob in .init.rodata with the "aw" flag (xbc_init() rewrites separators in place, so that data must be writable). Using a distinct subsection name avoids the ld.lld section- type mismatch that would otherwise arise from mixing "a" and "aw" under the same name; the linker's "*(.init.rodata .init.rodata.*)" glob still folds both into the init image and frees them after boot. A follow-up patch wires the build-time tools/bootconfig into the top-level clean target. Link: https://lore.kernel.org/all/20260626-bootconfig_using_tools-v7-3-24ab72139c29@debian.org/ Reviewed-by: Nicolas Schier Signed-off-by: Breno Leitao Signed-off-by: Masami Hiramatsu (Google)

kunit: use scoped_with_init_fs() in tests that resolve paths

2026-07-02T06:53:32+00:00

KUnit runs each test in a kthread (kunit_generic_run_threadfn_adapter()). Since commit 32750c77e811 ("fs: start all kthreads in nullfs") every kthread starts out with its fs_struct root and pwd pointing at an empty, immutable nullfs and can no longer resolve paths. Two test suites resolve paths from test context and now fail. The misc minor tests create a device node and open it: # miscdev_test_static_basic: EXPECTATION FAILED at drivers/char/misc_minor_kunit.c:166 failed to create node # miscdev_test_static_basic: EXPECTATION FAILED at drivers/char/misc_minor_kunit.c:170 failed to open misc device: -2 init_mknod("/dev/...") resolves relative to current->fs, which is now nullfs with no /dev, so node creation returns -ENOENT and the following filp_open() fails with -ENOENT (-2). The initramfs tests hit the same wall: they call unpack_to_rootfs() (init_mkdir()/init_mknod() under the hood) and then verify with relative-name init_stat()/init_unlink()/ filp_open(), all of which resolve against the nullfs root and pwd. Wrap the path-resolving regions of both suites in scoped_with_init_fs(), which borrows the userspace init fs_struct (set up by init_userspace_fs() before kunit_run_all_tests()) for the duration. This is the same opt-in the rest of the tree uses for kthread path resolution. Doing it per test rather than blanket-wrapping the KUnit runner keeps the nullfs isolation in place for the many tests that should never touch the filesystem. Link: https://patch.msgid.link/20260701-work-kunit-nullfs-v1-1-dfa60270434f@kernel.org Fixes: 32750c77e811 ("fs: start all kthreads in nullfs") Reported-by: Mark Brown Closes: https://lore.kernel.org/r/akOrbOsKUqgZarGw@sirena.org.uk Signed-off-by: Christian Brauner (Amutable)

rust: allow `suspicious_runtime_symbol_definitions` lint for Rust >= 1.98

2026-06-29T11:02:15+00:00

Starting with Rust 1.98.0 (expected 2026-08-20), Rust is introducing a couple new lints, `invalid_runtime_symbol_definitions` (deny-by-default) and `suspicious_runtime_symbol_definitions` (warn-by-default), which check the signature of items whose symbol name is a runtime symbol expected by `core`. Our build hits the second one, i.e. the warning: error: suspicious definition of the runtime `strlen` symbol used by the standard library --> rust/bindings/bindings_generated.rs:20018:5 | 20018 | pub fn strlen(s: *const ffi::c_char) -> usize; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: expected `unsafe extern "C" fn(*const i8) -> usize` found `unsafe extern "C" fn(*const u8) -> usize` = help: either fix the signature or remove any attributes like `#[unsafe(no_mangle)]`, `#[unsafe(export_name = "strlen")]`, or `#[link_name = "strlen"]` = help: allow this lint if the signature is compatible = note: `-D suspicious-runtime-symbol-definitions` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(suspicious_runtime_symbol_definitions)]` error: suspicious definition of the runtime `strlen` symbol used by the standard library --> rust/uapi/uapi_generated.rs:14236:5 | 14236 | pub fn strlen(s: *const ffi::c_char) -> usize; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: expected `unsafe extern "C" fn(*const i8) -> usize` found `unsafe extern "C" fn(*const u8) -> usize` = help: either fix the signature or remove any attributes like `#[unsafe(no_mangle)]`, `#[unsafe(export_name = "strlen")]`, or `#[link_name = "strlen"]` = help: allow this lint if the signature is compatible = note: `-D suspicious-runtime-symbol-definitions` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(suspicious_runtime_symbol_definitions)]` Thus `allow` the lint in `bindings` and `uapi`. A more targeted alternative to avoid `allow`ing it would be to pass `--blocklist-function strlen` to `bindgen`, but we would perhaps need to adjust if other C headers end up adding more (or Rust checking more). Since it is just the less critical one that we hit, and since eventually this should be properly fixed by getting upstream Rust to provide a flag like GCC/Clang's `-funsigned-char` [2][3], just `allow` it for now. Cc: Urgau Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://github.com/rust-lang/rust/pull/155521 [1] Link: https://github.com/rust-lang/rust/issues/138446 [2] Link: https://github.com/Rust-for-Linux/linux/issues/355 [3] Reviewed-by: Gary Guo Reviewed-by: Alice Ryhl Reviewed-by: Tamir Duberstein Link: https://patch.msgid.link/20260615143225.471756-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda

fs: stop sharing fs_struct between init_task and pid 1

2026-06-29T08:53:32+00:00

Spawn kernel_init (PID 1) via kernel_clone() directly instead of user_mode_thread(), without CLONE_FS. This gives PID 1 its own private copy of init_task's fs_struct rather than sharing it. This is a prerequisite for isolating kthreads in nullfs: when init_task's fs is later pointed at nullfs, PID 1 must not share it or init_userspace_fs() would modify init_task's fs as well, defeating the isolation. At this stage PID 1 still gets rootfs (a private copy rather than a shared reference), so there is no functional change. Link: https://patch.msgid.link/20260601-work-kthread-nullfs-v4-19-77ee053060e0@kernel.org Signed-off-by: Christian Brauner (Amutable)

initramfs: use scoped_with_init_fs() for rootfs unpacking

2026-06-29T08:53:31+00:00

Extract the initramfs unpacking code into a separate unpack_initramfs() function and wrap its invocation from do_populate_rootfs() with scoped_with_init_fs(). This ensures all file operations during initramfs unpacking (including filp_open() calls in do_name() and populate_initrd_image()) happen in init's filesystem context. Note that security_initramfs_populated() needs the scope as well since it does use current->fs to derive the initramfs superblock. do_populate_rootfs() ← async_schedule_domain() ← kworker (async workqueue) May also run synchronously from PID 1 in case async workqueue is considered full. Overriding in that case is fine as well. Link: https://patch.msgid.link/20260601-work-kthread-nullfs-v4-17-77ee053060e0@kernel.org Signed-off-by: Christian Brauner (Amutable)

fs: make userspace_init_fs a dynamically-initialized pointer

2026-06-29T08:44:05+00:00

Change userspace_init_fs from a declared-but-unused extern struct to a dynamically initialized pointer. Add init_userspace_fs() which is called early in kernel_init() (PID 1) to record PID 1's fs_struct as the canonical userspace filesystem state. Wire up __override_init_fs() and __revert_init_fs() to actually swap current->fs to/from userspace_init_fs. Previously these were no-ops that stored current->fs back to itself. Fix nullfs_userspace_init() to compare against userspace_init_fs instead of &init_fs. When PID 1 unshares its filesystem state, revert userspace_init_fs to init_fs's root (nullfs) so that stale filesystem state is not silently inherited by kworkers and usermodehelpers. At this stage PID 1's fs still points to rootfs (set by init_mount_tree), so userspace_init_fs points to rootfs and scoped_with_init_fs() is functionally equivalent to its previous no-op behavior. Link: https://patch.msgid.link/20260601-work-kthread-nullfs-v4-5-77ee053060e0@kernel.org Signed-off-by: Christian Brauner (Amutable)