kernel/scripts, branch linux-rolling-stable

kbuild: rpm-pkg: Disable automatic requires for manual debuginfo package

2026-03-04T12:21:44Z

[ Upstream commit f94711255a73d8938cf3bb405a0af3a4d2700ed1 ] Stefano reports that after commit 62089b804895 ("kbuild: rpm-pkg: Generate debuginfo package manually"), building with an rpm package using rpm 4.20.0 fails with: RPM build errors: Dependency tokens must begin with alpha-numeric, '_' or '/': #�) = 0x0d000002 Dependency tokens must begin with alpha-numeric, '_' or '/': �) = 0x0d000000 Dependency tokens must begin with alpha-numeric, '_' or '/': ) = 0x7c0e000000 Unknown rich dependency op 'Hat': (Red Hat 15.2.1-7)) = 0x3130363230322000 Unknown rich dependency op 'Hat': (Red Hat 15.2.1-7)) = 0x4728203a43434800 Unknown rich dependency op 'Hat': (Red Hat 15.2.1-7)) = 0x3130363230322000 Unknown rich dependency op 'Hat': (Red Hat 15.2.1-7)) = 0x4728203a43434800 This error comes from the automatic requirements feature of rpm. The -debuginfo subpackage has no dependencies, so disable this feature with 'AutoReq: 0' for this subpackage, avoiding the error. This matches the official %_debug_template macro that rpm provides. While automatic provides should be default enabled, be explicit like %_debug_template does. Additionally, while in the area, add the manual debug information package to the Development/Debug group, further aligning with %_debug_template. Cc: stable@vger.kernel.org Fixes: 62089b804895 ("kbuild: rpm-pkg: Generate debuginfo package manually") Reported-by: Stefano Garzarella Closes: https://lore.kernel.org/CAGxU2F7FFNgb781_A7a1oL63n9Oy8wsyWceKhUpeZ6mLk=focw@mail.gmail.com/ Tested-by: Stefano Garzarella Link: https://patch.msgid.link/20260216-improve-manual-debuginfo-template-v1-1-e584b3f8d3be@kernel.org Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin

kbuild: rpm-pkg: Fix manual debuginfo generation when using .src.rpm

2026-03-04T12:21:42Z

[ Upstream commit afdfb71c018e9a0aa2e51fb8186d3fb1acdd3f0e ] Commit 62089b804895 ("kbuild: rpm-pkg: Generate debuginfo package manually") added uses of OBJCOPY and READELF, variables from Kbuild. These variables are defined and work properly when using the binrpm-pkg target because rpmbuild is run within Kbuild. However, these variables are not defined when building from a source RPM package generated with the srcrpm-pkg target, breaking the build when generating the debug info subpackage. Define a default value for these variables so that these commands respect the value from Kbuild but continue to work when built from a source RPM package. Cc: stable@vger.kernel.org Fixes: 62089b804895 ("kbuild: rpm-pkg: Generate debuginfo package manually") Reported-by: Lukas Herbolt Closes: https://lore.kernel.org/20260212135855.147906-2-lukas@herbolt.com/ Tested-by: Lukas Herbolt Link: https://patch.msgid.link/20260213-fix-debuginfo-srcrpm-pkg-v1-1-45cd0c0501b9@kernel.org Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin

kernel: rpm-pkg: Restore find-debuginfo.sh approach to -debuginfo package

2026-03-04T12:21:41Z

[ Upstream commit ffe9ac1ad56df8f915896b97bd7645f522c47ce9 ] Commit 62089b804895 ("kbuild: rpm-pkg: Generate debuginfo package manually") effectively reverted commit a7c699d090a1 ("kbuild: rpm-pkg: build a debuginfo RPM") but the approach it took is not safe for older RPM releases. Restore commit a7c699d090a1 ("kbuild: rpm-pkg: build a debuginfo RPM") for the !CONFIG_MODULE_SIG case to allow more environments and configurations to take advantage of the separate debug information package process. Cc: stable@vger.kernel.org Fixes: 62089b804895 ("kbuild: rpm-pkg: Generate debuginfo package manually") Tested-by: Stefano Garzarella Tested-by: Steve French Tested-by: Juergen Gross Acked-by: Nicolas Schier Link: https://patch.msgid.link/20260210-kbuild-fix-debuginfo-rpm-v1-2-0730b92b14bc@kernel.org Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin

kbuild: rpm-pkg: Restrict manual debug package creation

2026-03-04T12:21:41Z

[ Upstream commit 6d6b8b0e28c468263d7fcb071e5cb284ae343df2 ] Commit 62089b804895 ("kbuild: rpm-pkg: Generate debuginfo package manually") moved away from the built-in RPM machinery for generating -debuginfo packages to a more manual way to be compatible with module signing, as the built-in machinery strips the modules after the installation process, breaking the signatures. Unfortunately, prior to rpm 4.20.0, there is a bug where a custom %files directive is ignored for a -debuginfo subpackage [1], meaning builds using older versions of RPM (such as on RHEL9 or RHEL10) fail with: Checking for unpackaged file(s): /usr/lib/rpm/check-files .../rpmbuild/BUILDROOT/kernel-6.19.0_dirty-1.x86_64 error: Installed (but unpackaged) file(s) found: /debuginfo.list /usr/lib/debug/.build-id/09/748c214974bfba1522d434a7e0a02e2fd7f29b.debug /usr/lib/debug/.build-id/0b/b96dd9c7d3689d82e56d2e73b46f53103cc6c7.debug /usr/lib/debug/.build-id/0e/979a2f34967c7437fd30aabb41de1f0c8b6a66.debug ... To workaround this, restrict the manual debug info package creation process to when it is necessary (CONFIG_MODULE_SIG=y) and possible (when using RPM >= 4.20.0). A follow up change will restore the RPM debuginfo creation process using a separate internal flag to allow the package to be built in more situations, as RPM 4.20.0 is a fairly recent version and the built-in -debuginfo generation works fine when module signing is disabled. Cc: stable@vger.kernel.org Fixes: 62089b804895 ("kbuild: rpm-pkg: Generate debuginfo package manually") Link: https://github.com/rpm-software-management/rpm/commit/49f906998f3cf1f4152162ca61ac0869251c380f [1] Reported-by: Steve French Closes: https://lore.kernel.org/CAH2r5mugbrHTwnaQwQiYEUVwbtqmvFYf0WZiLrrJWpgT8iwftw@mail.gmail.com/ Tested-by: Stefano Garzarella Tested-by: Steve French Tested-by: Juergen Gross Acked-by: Nicolas Schier Link: https://patch.msgid.link/20260210-kbuild-fix-debuginfo-rpm-v1-1-0730b92b14bc@kernel.org Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin

kbuild: Fix CC_CAN_LINK detection

2026-03-04T12:21:41Z

[ Upstream commit be55899b71630c79ad01df54c92e467e47644f87 ] Most samples cannot be build on some environments because they depend on CC_CAN_LINK, which is set according to the result of scripts/cc-can-link.sh called by cc_can_link_user. Because cc-can-link.sh must now build without warning, it may fail because it is calling printf() with an empty string: + cat + gcc -m32 -Werror -Wl,--fatal-warnings -x c - -o /dev/null : In function ‘main’: :4:9: error: zero-length gnu_printf format string [-Werror=format-zero-length] cc1: all warnings being treated as errors Fix this warning and the samples build by actually printing something. Cc: stable@vger.kernel.org Fixes: d81d9d389b9b ("kbuild: don't enable CC_CAN_LINK if the dummy program generates warnings") Signed-off-by: Mickaël Salaün Reviewed-by: Nicolas Schier Reviewed-by: Thomas Weißschuh Link: https://patch.msgid.link/20260212133544.1331437-1-mic@digikod.net Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin

docs: kdoc: avoid error_count overflows

2026-03-04T12:21:19Z

[ Upstream commit 802774d8539fa73487190ec45438777a3c38d424 ] The glibc library limits the return code to 8 bits. We need to stick to this limit when using sys.exit(error_count). Signed-off-by: Mauro Carvalho Chehab Cc: stable@vger.kernel.org Signed-off-by: Jonathan Corbet Message-ID: <233d1674db99ed8feb405a2f781de350f0fba0ac.1768823489.git.mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin

modpost: Amend ppc64 save/restfpr symnames for -Os build

2026-03-04T12:20:14Z

[ Upstream commit 3cd9763ce4ad999d015cf0734e6b968cead95077 ] Building a size optimized ppc64 kernel (-Os), gcc emits more FP save/restore symbols, that the linker generates on demand into the .sfpr section. Explicitly allow-list those in scripts/mod/modpost.c, too. They are needed for the amdgpu in-kernel floating point support. MODPOST Module.symvers ERROR: modpost: "_restfpr_20" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_restfpr_26" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_restfpr_22" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_savegpr1_27" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_savegpr1_25" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_restfpr_28" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_savegpr1_29" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_savefpr_20" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_savefpr_22" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_restfpr_15" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! WARNING: modpost: suppressed 56 unresolved symbol warnings because there were too many) Signed-off-by: René Rebe Link: https://patch.msgid.link/20251123.131330.407910684435629198.rene@exactco.de Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin

gendwarfksyms: Fix build on 32-bit hosts

2026-03-04T12:19:43Z

[ Upstream commit ddc54f912a551f6eb0bbcfc3880f45fe27a252cb ] We have interchangeably used unsigned long for some of the types defined in elfutils, assuming they're always 64-bit. This obviously fails when building gendwarfksyms on 32-bit hosts. Fix the types. Reported-by: Michal Suchánek Closes: https://lore.kernel.org/linux-modules/aRcxzPxtJblVSh1y@kitsune.suse.cz/ Tested-by: Michal Suchánek Signed-off-by: Sami Tolvanen Signed-off-by: Sasha Levin

Merge tag 'objtool-urgent-2026-02-07' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2026-02-07T16:21:21Z

Pull objtool fixes from Ingo Molnar:: - Bump up the Clang minimum version requirements for livepatch builds, due to Clang assembler section handling bugs causing silent miscompilations - Strip livepatching symbol artifacts from non-livepatch modules - Fix livepatch build warnings when certain Clang LTO options are enabled - Fix livepatch build error when CONFIG_MEM_ALLOC_PROFILING_DEBUG=y * tag 'objtool-urgent-2026-02-07' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: objtool/klp: Fix unexported static call key access for manually built livepatch modules objtool/klp: Fix symbol correlation for orphaned local symbols livepatch: Free klp_{object,func}_ext data after initialization livepatch: Fix having __klp_objects relics in non-livepatch modules livepatch/klp-build: Require Clang assembler >= 20

livepatch: Free klp_{object,func}_ext data after initialization

2026-02-05T16:00:45Z

The klp_object_ext and klp_func_ext data, which are stored in the __klp_objects and __klp_funcs sections, respectively, are not needed after they are used to create the actual klp_object and klp_func instances. This operation is implemented by the init function in scripts/livepatch/init.c. Prefix the two sections with ".init" so they are freed after the module is initializated. Signed-off-by: Petr Pavlu Acked-by: Joe Lawrence Acked-by: Miroslav Benes Reviewed-by: Aaron Tomlin Link: https://patch.msgid.link/20260123102825.3521961-3-petr.pavlu@suse.com Signed-off-by: Josh Poimboeuf