summaryrefslogtreecommitdiff
path: root/scripts
AgeCommit message (Collapse)Author
2025-03-24Merge tag 'hardening-v6.15-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux Pull hardening updates from Kees Cook: "As usual, it's scattered changes all over. Patches touching things outside of our traditional areas in the tree have been Acked by maintainers or were trivial changes: - loadpin: remove unsupported MODULE_COMPRESS_NONE (Arulpandiyan Vadivel) - samples/check-exec: Fix script name (Mickaël Salaün) - yama: remove needless locking in yama_task_prctl() (Oleg Nesterov) - lib/string_choices: Sort by function name (R Sundar) - hardening: Allow default HARDENED_USERCOPY to be set at compile time (Mel Gorman) - uaccess: Split out compile-time checks into ucopysize.h - kbuild: clang: Support building UM with SUBARCH=i386 - x86: Enable i386 FORTIFY_SOURCE on Clang 16+ - ubsan/overflow: Rework integer overflow sanitizer option - Add missing __nonstring annotations for callers of memtostr*()/strtomem*() - Add __must_be_noncstr() and have memtostr*()/strtomem*() check for it - Introduce __nonstring_array for silencing future GCC 15 warnings" * tag 'hardening-v6.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: (26 commits) compiler_types: Introduce __nonstring_array hardening: Enable i386 FORTIFY_SOURCE on Clang 16+ x86/build: Remove -ffreestanding on i386 with GCC ubsan/overflow: Enable ignorelist parsing and add type filter ubsan/overflow: Enable pattern exclusions ubsan/overflow: Rework integer overflow sanitizer option to turn on everything samples/check-exec: Fix script name yama: don't abuse rcu_read_lock/get_task_struct in yama_task_prctl() kbuild: clang: Support building UM with SUBARCH=i386 loadpin: remove MODULE_COMPRESS_NONE as it is no longer supported lib/string_choices: Rearrange functions in sorted order string.h: Validate memtostr*()/strtomem*() arguments more carefully compiler.h: Introduce __must_be_noncstr() nilfs2: Mark on-disk strings as nonstring uapi: stddef.h: Introduce __kernel_nonstring x86/tdx: Mark message.bytes as nonstring string: kunit: Mark nonstring test strings as __nonstring scsi: qla2xxx: Mark device strings as nonstring scsi: mpt3sas: Mark device strings as nonstring scsi: mpi3mr: Mark device strings as nonstring ...
2025-03-24Merge tag 'vfs-6.15-rc1.mount' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs Pull vfs mount updates from Christian Brauner: - Mount notifications The day has come where we finally provide a new api to listen for mount topology changes outside of /proc/<pid>/mountinfo. A mount namespace file descriptor can be supplied and registered with fanotify to listen for mount topology changes. Currently notifications for mount, umount and moving mounts are generated. The generated notification record contains the unique mount id of the mount. The listmount() and statmount() api can be used to query detailed information about the mount using the received unique mount id. This allows userspace to figure out exactly how the mount topology changed without having to generating diffs of /proc/<pid>/mountinfo in userspace. - Support O_PATH file descriptors with FSCONFIG_SET_FD in the new mount api - Support detached mounts in overlayfs Since last cycle we support specifying overlayfs layers via file descriptors. However, we don't allow detached mounts which means userspace cannot user file descriptors received via open_tree(OPEN_TREE_CLONE) and fsmount() directly. They have to attach them to a mount namespace via move_mount() first. This is cumbersome and means they have to undo mounts via umount(). Allow them to directly use detached mounts. - Allow to retrieve idmappings with statmount Currently it isn't possible to figure out what idmapping has been attached to an idmapped mount. Add an extension to statmount() which allows to read the idmapping from the mount. - Allow creating idmapped mounts from mounts that are already idmapped So far it isn't possible to allow the creation of idmapped mounts from already idmapped mounts as this has significant lifetime implications. Make the creation of idmapped mounts atomic by allow to pass struct mount_attr together with the open_tree_attr() system call allowing to solve these issues without complicating VFS lookup in any way. The system call has in general the benefit that creating a detached mount and applying mount attributes to it becomes an atomic operation for userspace. - Add a way to query statmount() for supported options Allow userspace to query which mount information can be retrieved through statmount(). - Allow superblock owners to force unmount * tag 'vfs-6.15-rc1.mount' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: (21 commits) umount: Allow superblock owners to force umount selftests: add tests for mount notification selinux: add FILE__WATCH_MOUNTNS samples/vfs: fix printf format string for size_t fs: allow changing idmappings fs: add kflags member to struct mount_kattr fs: add open_tree_attr() fs: add copy_mount_setattr() helper fs: add vfs_open_tree() helper statmount: add a new supported_mask field samples/vfs: add STATMOUNT_MNT_{G,U}IDMAP selftests: add tests for using detached mount with overlayfs samples/vfs: check whether flag was raised statmount: allow to retrieve idmappings uidgid: add map_id_range_up() fs: allow detached mounts in clone_private_mount() selftests/overlayfs: test specifying layers as O_PATH file descriptors fs: support O_PATH fds with FSCONFIG_SET_FD vfs: add notifications for mount attach and detach fanotify: notify on mount attach and detach ...
2025-03-23rust: enable `raw_ref_op` featureAntonio Hickey
Since Rust 1.82.0 the `raw_ref_op` feature is stable [1]. By enabling this feature we can use `&raw const place` and `&raw mut place` instead of using `addr_of!(place)` and `addr_of_mut!(place)` macros. Allowing us to reduce macro complexity, and improve consistency with existing reference syntax as `&raw const`, `&raw mut` are similar to `&`, `&mut` making it fit more naturally with other existing code. Suggested-by: Benno Lossin <benno.lossin@proton.me> Link: https://github.com/Rust-for-Linux/linux/issues/1148 Link: https://blog.rust-lang.org/2024/10/17/Rust-1.82.0.html#native-syntax-for-creating-a-raw-pointer [1] Signed-off-by: Antonio Hickey <contact@antoniohickey.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Tamir Duberstein <tamird@gmail.com> Link: https://lore.kernel.org/r/20250320020740.1631171-2-contact@antoniohickey.com [ Removed dashed line change as discussed. Added Link to the explanation of the feature in the Rust 1.82.0 release blog post. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-23kbuild: pacman-pkg: hardcode module installation pathMasahiro Yamada
'make pacman-pkg' for architectures with device tree support (i.e., arm, arm64, etc.) shows logs like follows: Installing dtbs... INSTALL /home/masahiro/linux/pacman/linux-upstream/pkg/linux-upstream/usr//lib/modules/6.14.0-rc6+/dtb/actions/s700-cubieboard7.dtb INSTALL /home/masahiro/linux/pacman/linux-upstream/pkg/linux-upstream/usr//lib/modules/6.14.0-rc6+/dtb/actions/s900-bubblegum-96.dtb INSTALL /home/masahiro/linux/pacman/linux-upstream/pkg/linux-upstream/usr//lib/modules/6.14.0-rc6+/dtb/airoha/en7581-evb.dtb ... The double slashes ('//') between 'usr' and 'lib' are somewhat ugly. Let's hardcode the module installation path because the package contents should remain unaffected even if ${MODLIB} is overridden. Please note that scripts/packages/{builddeb,kernel.spec} also hardcode the module installation path. With this change, the log will look better, as follows: Installing dtbs... INSTALL /home/masahiro/linux/pacman/linux-upstream/pkg/linux-upstream/usr/lib/modules/6.14.0-rc6+/dtb/actions/s700-cubieboard7.dtb INSTALL /home/masahiro/linux/pacman/linux-upstream/pkg/linux-upstream/usr/lib/modules/6.14.0-rc6+/dtb/actions/s900-bubblegum-96.dtb INSTALL /home/masahiro/linux/pacman/linux-upstream/pkg/linux-upstream/usr/lib/modules/6.14.0-rc6+/dtb/airoha/en7581-evb.dtb ... Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Nathan Chancellor <nathan@kernel.org>
2025-03-23kbuild: deb-pkg: don't set KBUILD_BUILD_VERSION unconditionallyAlexandru Gagniuc
In ThinPro, we use the convention <upstream_ver>+hp<patchlevel> for the kernel package. This does not have a dash in the name or version. This is built by editing ".version" before a build, and setting EXTRAVERSION="+hp" and KDEB_PKGVERSION make variables: echo 68 > .version make -j<n> EXTRAVERSION="+hp" bindeb-pkg KDEB_PKGVERSION=6.12.2+hp69 .deb name: linux-image-6.12.2+hp_6.12.2+hp69_amd64.deb Since commit 7d4f07d5cb71 ("kbuild: deb-pkg: squash scripts/package/deb-build-option to debian/rules"), this no longer works. The deb build logic changed, even though, the commit message implies that the logic should be unmodified. Before, KBUILD_BUILD_VERSION was not set if the KDEB_PKGVERSION did not contain a dash. After the change KBUILD_BUILD_VERSION is always set to KDEB_PKGVERSION. Since this determines UTS_VERSION, the uname output to look off: (now) uname -a: version 6.12.2+hp ... #6.12.2+hp69 (expected) uname -a: version 6.12.2+hp ... #69 Update the debian/rules logic to restore the original behavior. Fixes: 7d4f07d5cb71 ("kbuild: deb-pkg: squash scripts/package/deb-build-option to debian/rules") Signed-off-by: Alexandru Gagniuc <alexandru.gagniuc@hp.com> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2025-03-23modpost: require a MODULE_DESCRIPTION()Jeff Johnson
Since commit 1fffe7a34c89 ("script: modpost: emit a warning when the description is missing"), a module without a MODULE_DESCRIPTION() has resulted in a warning with make W=1. Since that time, all known instances of this issue have been fixed. Therefore, now make it an error if a MODULE_DESCRIPTION() is not present. Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2025-03-22kbuild: deb-pkg: add comment about future removal of KDEB_COMPRESSMasahiro Yamada
'man dpkg-deb' describes as follows: DPKG_DEB_COMPRESSOR_TYPE Sets the compressor type to use (since dpkg 1.21.10). The -Z option overrides this value. When commit 1a7f0a34ea7d ("builddeb: allow selection of .deb compressor") was applied, dpkg-deb did not support this environment variable. Later, dpkg commit c10aeffc6d71 ("dpkg-deb: Add support for DPKG_DEB_COMPRESSOR_TYPE/LEVEL") introduced support for DPKG_DEB_COMPRESSOR_TYPE, which provides the same functionality as KDEB_COMPRESS. KDEB_COMPRESS is still useful for users of older dpkg versions, but I would like to remove this redundant functionality in the future. This commit adds comments to notify users of the planned removal and to encourage migration to DPKG_DEB_COMPRESSOR_TYPE where possible. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2025-03-22kbuild: deb-pkg: remove "version" variable in mkdebianMasahiro Yamada
${version} and ${KERNELRELEASE} are the same. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org>
2025-03-22kbuild: deb-pkg: fix versioning for -rc releasesMasahiro Yamada
The version number with -rc should be considered older than the final release. For example, 6.14-rc1 should be older than 6.14, but to handle this correctly (just like Debian kernel), "-rc" must be replace with "~rc". $ dpkg --compare-versions 6.14-rc1 lt 6.14 $ echo $? 1 $ dpkg --compare-versions 6.14~rc1 lt 6.14 $ echo $? 0 Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org>
2025-03-20Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netPaolo Abeni
Cross-merge networking fixes after downstream PR (net-6.14-rc8). Conflict: tools/testing/selftests/net/Makefile 03544faad761 ("selftest: net: add proc_net_pktgen") 3ed61b8938c6 ("selftests: net: test for lwtunnel dst ref loops") tools/testing/selftests/net/config: 85cb3711acb8 ("selftests: net: Add test cases for link and peer netns") 3ed61b8938c6 ("selftests: net: test for lwtunnel dst ref loops") Adjacent commits: tools/testing/selftests/net/Makefile c935af429ec2 ("selftests: net: add support for testing SO_RCVMARK and SO_RCVPRIORITY") 355d940f4d5a ("Revert "selftests: Add IPv6 link-local address generation tests for GRE devices."") Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-20scripts/tracing: Remove scripts/tracing/draw_functrace.pySteven Rostedt
The draw_functrace.py hasn't worked in years. There's better ways to accomplish the same thing (via libtracefs). Remove it. Link: https://lore.kernel.org/linux-trace-kernel/20250210-debuginfo-v1-1-368feb58292a@purestorage.com/ Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Uday Shankar <ushankar@purestorage.com> Cc: Masahiro Yamada <masahiroy@kernel.org> Link: https://lore.kernel.org/20250307103941.070654e7@gandalf.local.home Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2025-03-19Merge tag 'v6.14-rc7' into x86/core, to pick up fixesIngo Molnar
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2025-03-17checkpatch: describe --min-conf-desc-lengthPhilipp Hahn
Neither the warning nor the help message gives any hint on the unit for length: Could be meters, inches, bytes, characters or ... lines. Extend the output of `--help` to name the unit "lines" and the default: - --min-conf-desc-length=n set the min description length, if shorter, warn + --min-conf-desc-length=n set the minimum description length for config symbols + in lines, if shorter, warn (default 4) Include the minimum number of lines as other error messages already do: - WARNING: please write a help paragraph that fully describes the config symbol + WARNING: please write a help paragraph that fully describes the config symbol with at least 4 lines Link: https://lkml.kernel.org/r/c71c170c90eba26265951e248adfedd3245fe575.1741605695.git.p.hahn@avm.de Signed-off-by: Philipp Hahn <p.hahn@avm.de> Cc: Andy Whitcroft <apw@canonical.com> Cc: Joe Perches <joe@perches.com> Cc: Dwaipayan Ray <dwaipayanray1@gmail.com> Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-03-17scripts/gdb/symbols: determine KASLR offset on s390Ilya Leoshkevich
Use QEMU's qemu.PhyMemMode [1] functionality to read vmcore from the physical memory the same way the existing dump tooling does this. Gracefully handle non-QEMU targets, early boot, and memory corruptions; print a warning if such situation is detected. [1] https://qemu-project.gitlab.io/qemu/system/gdb.html#examining-physical-memory Link: https://lkml.kernel.org/r/20250303110437.79070-1-iii@linux.ibm.com Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Acked-by: Jan Kiszka <jan.kiszka@siemens.com> Cc: Alexander Gordeev <agordeev@linux.ibm.com> Cc: Andrew Donnellan <ajd@linux.ibm.com> Cc: Christian Borntraeger <borntraeger@linux.ibm.com> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Kieran Bingham <kbingham@kernel.org> Cc: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-03-17scripts/gdb/linux/symbols.py: address changes to module_sect_attrsAntonio Quartulli
When loading symbols from kernel modules we used to iterate from 0 to module_sect_attrs::nsections, in order to retrieve their name and address. However module_sect_attrs::nsections has been removed from the struct by a previous commit. Re-arrange the iteration by accessing all items in module_sect_attrs::grp::bin_attrs[] until NULL is found (it's a NULL terminated array). At the same time the symbol address cannot be extracted from module_sect_attrs::attrs[]::address anymore because it has also been deleted. Fetch it from module_sect_attrs::grp::bin_attrs[]::private as described in 4b2c11e4aaf7. Link: https://lkml.kernel.org/r/20250221204034.4430-1-antonio@mandelbit.com Fixes: d8959b947a8d ("module: sysfs: Drop member 'module_sect_attrs::nsections'") Fixes: 4b2c11e4aaf7 ("module: sysfs: Drop member 'module_sect_attr::address'") Signed-off-by: Antonio Quartulli <antonio@mandelbit.com> Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com> Cc: Thomas Weißschuh <linux@weissschuh.net> Cc: Kieran Bingham <kbingham@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-03-17objtool: Add CONFIG_OBJTOOL_WERRORJosh Poimboeuf
Objtool warnings can be indicative of crashes, broken live patching, or even boot failures. Ignoring them is not recommended. Add CONFIG_OBJTOOL_WERROR to upgrade objtool warnings to errors by enabling the objtool --Werror option. Also set --backtrace to print the branches leading up to the warning, which can help considerably when debugging certain warnings. To avoid breaking bots too badly for now, make it the default for real world builds only (!COMPILE_TEST). Co-developed-by: Brendan Jackman <jackmanb@google.com> Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/r/3e7c109313ff15da6c80788965cc7450115b0196.1741975349.git.jpoimboe@kernel.org
2025-03-16coccinelle: misc: secs_to_jiffies: Patch expressions tooEaswar Hariharan
Patch series "Converge on using secs_to_jiffies() part two", v3. This is the second series that converts users of msecs_to_jiffies() that either use the multiply pattern of either of: - msecs_to_jiffies(N*1000) or - msecs_to_jiffies(N*MSEC_PER_SEC) where N is a constant or an expression, to avoid the multiplication. The conversion is made with Coccinelle with the secs_to_jiffies() script in scripts/coccinelle/misc. Attention is paid to what the best change can be rather than restricting to what the tool provides. This patch (of 16): Teach the script to suggest conversions for timeout patterns where the arguments to msecs_to_jiffies() are expressions as well. Link: https://lkml.kernel.org/r/20250225-converge-secs-to-jiffies-part-two-v3-0-a43967e36c88@linux.microsoft.com Link: https://lkml.kernel.org/r/20250225-converge-secs-to-jiffies-part-two-v3-1-a43967e36c88@linux.microsoft.com Signed-off-by: Easwar Hariharan <eahariha@linux.microsoft.com> Cc: Mark Brown <broonie@kernel.org> Cc: Carlos Maiolino <cem@kernel.org> Cc: Chris Mason <clm@fb.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Damien Le Maol <dlemoal@kernel.org> Cc: "Darrick J. Wong" <djwong@kernel.org> Cc: David Sterba <dsterba@suse.com> Cc: Dick Kennedy <dick.kennedy@broadcom.com> Cc: Dongsheng Yang <dongsheng.yang@easystack.cn> Cc: Fabio Estevam <festevam@gmail.com> Cc: Frank Li <frank.li@nxp.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Ilpo Jarvinen <ilpo.jarvinen@linux.intel.com> Cc: Ilya Dryomov <idryomov@gmail.com> Cc: James Bottomley <james.bottomley@HansenPartnership.com> Cc: James Smart <james.smart@broadcom.com> Cc: Jaroslav Kysela <perex@perex.cz> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Jens Axboe <axboe@kernel.dk> Cc: Josef Bacik <josef@toxicpanda.com> Cc: Julia Lawall <julia.lawall@inria.fr> Cc: Kalesh Anakkur Purayil <kalesh-anakkur.purayil@broadcom.com> Cc: Keith Busch <kbusch@kernel.org> Cc: Leon Romanovsky <leon@kernel.org> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: Nicolas Palix <nicolas.palix@imag.fr> Cc: Niklas Cassel <cassel@kernel.org> Cc: Oded Gabbay <ogabbay@kernel.org> Cc: Takashi Iwai <tiwai@suse.de> Cc: Sagi Grimberg <sagi@grimberg.me> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Sebastian Reichel <sre@kernel.org> Cc: Selvin Thyparampil Xavier <selvin.xavier@broadcom.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Shyam-sundar S-k <Shyam-sundar.S-k@amd.com> Cc: Takashi Iwai <tiwai@suse.com> Cc: Xiubo Li <xiubli@redhat.com> Cc: Carlos Maiolino <cmaiolino@redhat.com> Cc: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-03-16scripts/gdb: add $lx_per_cpu_ptr()Brendan Jackman
We currently have $lx_per_cpu() which works fine for stuff that kernel code would access via per_cpu(). But this doesn't work for stuff that kernel code accesses via per_cpu_ptr(): (gdb) p $lx_per_cpu(node_data[1].node_zones[2]->per_cpu_pageset) Cannot access memory at address 0xffff11105fbd6c28 This is because we take the address of the pointer and use that as the offset, instead of using the stored value. Add a GDB version that mirrors the kernel API, which uses the pointer value. To be consistent with per_cpu_ptr(), we need to return the pointer value instead of dereferencing it for the user. Therefore, move the existing dereference out of the per_cpu() Python helper and do that only in the $lx_per_cpu() implementation. Link: https://lkml.kernel.org/r/20250220-lx-per-cpu-ptr-v2-1-945dee8d8d38@google.com Signed-off-by: Brendan Jackman <jackmanb@google.com> Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com> Cc: Florian Rommel <mail@florommel.de> Cc: Kieran Bingham <kbingham@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-03-16get_maintainer: stop reporting subsystem status as maintainer roleVlastimil Babka
After introducing the --substatus option, we can stop adjusting the reported maintainer role by the subsystem's status. For compatibility with the --git-chief-penguins option, keep the "chief penguin" role. Link: https://lkml.kernel.org/r/20250203-b4-get_maintainer-v2-2-83ba008b491f@suse.cz Signed-off-by: Vlastimil Babka <vbabka@suse.cz> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Tested-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Cc: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Cc: Joe Perches <joe@perches.com> Cc: Kees Cook <kees@kernel.org> Cc: Ted Ts'o <tytso@mit.edu> Cc: Thorsten Leemhuis <linux@leemhuis.info> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-03-16get_maintainer: add --substatus for reporting subsystem statusVlastimil Babka
Patch series "get_maintainer: report subsystem status separately", v2. The subsystem status (S: field) can inform a patch submitter if the subsystem is well maintained or e.g. maintainers are missing. In get_maintainer, it is currently reported with --role(stats) by adjusting the maintainer role for any status different from Maintained. This has two downsides: - if a subsystem has only reviewers or mailing lists and no maintainers, the status is not reported. For example Orphan subsystems typically have no maintainers so there's nobody to report as orphan minder. - the Supported status means that someone is paid for maintaining, but it is reported as "supporter" for all the maintainers, which can be incorrect (only some of them may be paid). People (including myself) have been also confused about what "supporter" means. The second point has been brought up in 2022 and the discussion in the end resulted in adjusting documentation only [1]. I however agree with Ted's points that it's misleading to take the subsystem status and apply it to all maintainers [2]. The attempt to modify get_maintainer output was retracted after Joe objected that the status becomes not reported at all [3]. This series addresses that concern by reporting the status (unless it's the most common Maintained one) on separate lines that follow the reported emails, using a new --substatus parameter. Care is taken to reduce the noise to minimum by not reporting the most common Maintained status, by default require no opt-in that would need the users to discover the new parameter, and at the same time not to break existing git --cc-cmd usage. [1] https://lore.kernel.org/all/20221006162413.858527-1-bryan.odonoghue@linaro.org/ [2] https://lore.kernel.org/all/Yzen4X1Na0MKXHs9@mit.edu/ [3] https://lore.kernel.org/all/30776fe75061951777da8fa6618ae89bea7a8ce4.camel@perches.com/ This patch (of 2): The subsystem status is currently reported with --role(stats) by adjusting the maintainer role for any status different from Maintained. This has two downsides: - if a subsystem has only reviewers or mailing lists and no maintainers, the status is not reported (i.e. typically, Orphan subsystems have no maintainers) - the Supported status means that someone is paid for maintaining, but it is reported as "supporter" for all the maintainers, which can be incorrect. People have been also confused about what "supporter" means. This patch introduces a new --substatus option and functionality aimed to report the subsystem status separately, without adjusting the reported maintainer role. After the e-mails are output, the status of subsystems will follow, for example: ... linux-kernel@vger.kernel.org (open list:LIBRARY CODE) LIBRARY CODE status: Supported In order to allow replacing the role rewriting seamlessly, the new option works as follows: - it is automatically enabled when --email and --role are enabled (the defaults include --email and --rolestats which implies --role) - usages with --norolestats e.g. for git's --cc-cmd will thus need no adjustments - the most common Maintained status is not reported at all, to reduce unnecessary noise - THE REST catch-all section (contains lkml) status is not reported - the existing --subsystem and --status options are unaffected so their users will need no adjustments [vbabka@suse.cz: require that script output goes to a terminal] Link: https://lkml.kernel.org/r/66c2bf7a-9119-4850-b6b8-ac8f426966e1@suse.cz Link: https://lkml.kernel.org/r/20250203-b4-get_maintainer-v2-0-83ba008b491f@suse.cz Link: https://lkml.kernel.org/r/20250203-b4-get_maintainer-v2-1-83ba008b491f@suse.cz Fixes: c1565b6f7b53 ("get_maintainer: add --substatus for reporting subsystem status") Closes: https://lore.kernel.org/all/7aodxv46lj6rthjo4i5zhhx2lybrhb4uknpej2dyz3e7im5w3w@w23bz6fx3jnn/ Signed-off-by: Vlastimil Babka <vbabka@suse.cz> Acked-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Uwe Kleine-K=F6nig <u.kleine-koenig@baylibre.com> Cc: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Cc: Joe Perches <joe@perches.com> Cc: Kees Cook <kees@kernel.org> Cc: Ted Ts'o <tytso@mit.edu> Cc: Thorsten Leemhuis <linux@leemhuis.info> Cc: Vlastimil Babka <vbabka@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-03-16scripts: add script to extract built-in firmware blobsGuilherme G. Piccoli
There is currently no tool to extract a firmware blob that is built-in on vmlinux to the best of my knowledge. So if we have a kernel image containing the blobs, and we want to rebuild the kernel with some debug patches for example (and given that the image also has IKCONFIG=y), we currently can't do that for the same versions for all the firmware blobs, _unless_ we have exact commits of linux-firmware for the specific versions for each firmware included. Through the options CONFIG_EXTRA_FIRMWARE{_DIR} one is able to build a kernel including firmware blobs in a built-in fashion. This is usually the case of built-in drivers that require some blobs in order to work properly, for example, like in non-initrd based systems. Add hereby a script to extract these blobs from a non-stripped vmlinux, similar to the idea of "extract-ikconfig". The firmware loader interface saves such built-in blobs as rodata entries, having a field for the FW name as "_fw_<module_name>_<firmware_name>_bin"; the tool extracts files named "<module_name>_<firmware_name>" for each rodata firmware entry detected. It makes use of awk, bash, dd and readelf, pretty standard tooling for Linux development. With this tool, we can blindly extract the FWs and easily re-add them in the new debug kernel build, allowing a more deterministic testing without the burden of "hunting down" the proper version of each firmware binary. Link: https://lkml.kernel.org/r/20250120190436.127578-1-gpiccoli@igalia.com Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com> Suggested-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Reviewed-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Luis Chamberalin <mcgrof@kernel.org> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Nicolas Schier <nicolas@fjasle.eu> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Russ Weight <russ.weight@linux.dev> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-03-16rust: make pin-init its own crateBenno Lossin
Rename relative paths inside of the crate to still refer to the same items, also rename paths inside of the kernel crate and adjust the build system to build the crate. [ Remove the `expect` (and thus the `lint_reasons` feature) since the tree now uses `quote!` from `rust/macros/export.rs`. Remove the `TokenStream` import removal, since it is now used as well. In addition, temporarily (i.e. just for this commit) use an `--extern force:alloc` to prevent an unknown `new_uninit` error in the `rustdoc` target. For context, please see a similar case in: https://lore.kernel.org/lkml/20240422090644.525520-1-ojeda@kernel.org/ And adjusted the message above. - Miguel ] Signed-off-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Fiona Behrens <me@kloenk.dev> Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/r/20250308110339.2997091-16-benno.lossin@proton.me Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-16rust: add pin-init crate build infrastructureMiguel Ojeda
Add infrastructure for moving the initialization API to its own crate. Covers all make targets such as `rust-analyzer` and `rustdoc`. The tests of pin-init are not added to `rusttest`, as they are already tested in the user-space repository [1]. Link: https://github.com/Rust-for-Linux/pin-init [1] Co-developed-by: Benno Lossin <benno.lossin@proton.me> Signed-off-by: Benno Lossin <benno.lossin@proton.me> Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/r/20250308110339.2997091-15-benno.lossin@proton.me Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-17kbuild: Create intermediate vmlinux build with relocations preservedArd Biesheuvel
The imperative paradigm used to build vmlinux, extract some info from it or perform some checks on it, and subsequently modify it again goes against the declarative paradigm that is usually employed for defining make rules. In particular, the Makefile.postlink files that consume their input via an output rule result in some dodgy logic in the decompressor makefiles for RISC-V and x86, given that the vmlinux.relocs input file needed to generate the arch-specific relocation tables may not exist or be out of date, but cannot be constructed using the ordinary Make dependency based rules, because the info needs to be extracted while vmlinux is in its ephemeral, non-stripped form. So instead, for architectures that require the static relocations that are emitted into vmlinux when passing --emit-relocs to the linker, and are subsequently stripped out again, introduce an intermediate vmlinux target called vmlinux.unstripped, and organize the reset of the build logic accordingly: - vmlinux.unstripped is created only once, and not updated again - build rules under arch/*/boot can depend on vmlinux.unstripped without running the risk of the data disappearing or being out of date - the final vmlinux generated by the build is not bloated with static relocations that are never needed again after the build completes. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2025-03-17kbuild: link-vmlinux.sh: Make output file name configurableArd Biesheuvel
In order to introduce an intermediate, non-stripped vmlinux build that can be used by other build steps as an input, pass the output file name to link-vmlinux.sh via its command line. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2025-03-15Merge tag 'rust-fixes-6.14-3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux Pull rust fixes from Miguel Ojeda: "Toolchain and infrastructure: - Disallow BTF generation with Rust + LTO - Improve rust-analyzer support 'kernel' crate: - 'init' module: remove 'Zeroable' implementation for a couple types that should not have it - 'alloc' module: fix macOS failure in host test by satisfying POSIX alignment requirement - Add missing '\n's to 'pr_*!()' calls And a couple other minor cleanups" * tag 'rust-fixes-6.14-3' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux: scripts: generate_rust_analyzer: add uapi crate scripts: generate_rust_analyzer: add missing include_dirs scripts: generate_rust_analyzer: add missing macros deps rust: Disallow BTF generation with Rust + LTO rust: task: fix `SAFETY` comment in `Task::wake_up` rust: workqueue: add missing newline to pr_info! examples rust: sync: add missing newline in locked_by log example rust: init: add missing newline to pr_info! calls rust: error: add missing newline to pr_warn! calls rust: docs: add missing newline to printing macro examples rust: alloc: satisfy POSIX alignment requirement rust: init: fix `Zeroable` implementation for `Option<NonNull<T>>` and `Option<KBox<T>>` rust: remove leftover mentions of the `alloc` crate
2025-03-15kbuild: do not generate .tmp_vmlinux*.map when CONFIG_VMLINUX_MAP=yMasahiro Yamada
Commit 5cc124720461 ("kbuild: add CONFIG_VMLINUX_MAP expert option") mentioned that "the .map file can be rather large (several MB), and that's a waste of space when one isn't interested in these things." If that is the case, generating map files for the intermediate tmp_vmlinux* files is also a waste of space. It is unlikely that anyone would be interested in the .tmp_vmlinux*.map files. This commit stops passing the -Map= option when linking the .tmp_vmlinux* intermediates. I also hard-coded the file name 'vmlinux.map' instead of ${output}.map because a later commit will introduce vmlinux.unstripped but I want to keep the current name of the map file. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Ard Biesheuvel <ardb@kernel.org>
2025-03-15kbuild: exclude .rodata.(cst|str)* when building rangesKris Van Hees
The .rodata.(cst|str)* sections are often resized during the final linking and since these sections do not cover actual symbols there is no need to include them in the modules.builtin.ranges data. When these sections were included in processing and resizing occurred, modules were reported with ranges that extended beyond their true end, causing subsequent symbols (in address order) to be associated with the wrong module. Fixes: 5f5e7344322f ("kbuild: generate offset range data for builtin modules") Cc: stable@vger.kernel.org Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com> Reviewed-by: Jack Vogel <jack.vogel@oracle.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2025-03-15kbuild: add Kbuild bash completionMasahiro Yamada
Kernel build commands can sometimes be long, particularly when cross-compiling, making them tedious to type and prone to mistypes. This commit introduces bash completion support for common variables and targets in Kbuild. For installation instructions, please refer to the documentation in Documentation/kbuild/bash-completion.rst. The following examples demonstrate how this saves typing. [Example 1] a long command line for cross-compiling $ make A<TAB> -> completes 'A' to 'ARCH=' $ make ARCH=<TAB> -> displays all supported architectures $ make ARCH=arm64 CR<TAB> -> completes 'CR' to 'CROSS_COMPILE=' $ make ARCH=arm64 CROSS_COMPILE=<TAB> -> displays installed toolchains $ make ARCH=arm64 CROSS_COMPILE=aa<TAB> -> completes 'CROSS_COMPILE=aa' to 'CROSS_COMPILE=aarch64-linux-gnu-' $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- def<TAB> -> completes 'def' to 'defconfig' [Example 2] a single build target $ make f<TAB> -> completes 'f' to 'fs/' $ make fs/<TAB> -> displays objects and sub-directories in fs/ $ make fs/xf<TAB> -> completes 'fs/xf' to 'fs/xfs/' $ make fs/xfs/l<TAB> -> completes 'fs/xfs/l' to 'fs/xfs/libxfs/xfs_' $ make fs/xfs/libxfs/xfs_g<TAB> -> completes 'fs/xfs/libxfs/xfs_g' to 'fs/xfs/libxfs/xfs_group.o' This does not aim to provide a complete list of variables and targets, as there are too many. However, it covers variables and targets used in common scenarios, and I hope this is useful enough. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <n.schier@avm.de> Tested-by: Nicolas Schier <n.schier@avm.de>
2025-03-15kbuild: fix argument parsing in scripts/configSeyediman Seyedarab
The script previously assumed --file was always the first argument, which caused issues when it appeared later. This patch updates the parsing logic to scan all arguments to find --file, sets the config file correctly, and resets the argument list with the remaining commands. It also fixes --refresh to respect --file by passing KCONFIG_CONFIG=$FN to make oldconfig. Signed-off-by: Seyediman Seyedarab <imandevel@gmail.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2025-03-15kbuild: add dependency from vmlinux to sorttableXi Ruoyao
Without this dependency it's really puzzling when we bisect for a "bad" commit in a series of sorttable change: when "git bisect" switches to another commit, "make" just does nothing to vmlinux. Signed-off-by: Xi Ruoyao <xry111@xry111.site> Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2025-03-15kbuild: deb-pkg: add debarch for ARCH=loongarch64WangYuli
Fix follow warning when 'make ARCH=loongarch64 bindeb-pkg': ** ** ** WARNING ** ** ** Your architecture doesn't have its equivalent Debian userspace architecture defined! Falling back to the current host architecture (loong64). Please add support for loongarch64 to ./scripts/package/mkdebian ... Reported-by: Shiwei Liu <liushiwei@anheng.com.cn> Signed-off-by: WangYuli <wangyuli@uniontech.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2025-03-15kbuild: move -fzero-init-padding-bits=all to the top-level MakefileMasahiro Yamada
The -fzero-init-padding-bits=all option is not a warning flag, so defining it in scripts/Makefile.extrawarn is inconsistent. Move it to the top-level Makefile for consistency. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Kees Cook <kees@kernel.org>
2025-03-15scripts: make python shebangs specific about desired versionUday Shankar
The RPM packaging tools like to make sure that all packaged python scripts have version-unambiguous shebangs. Be more specific about the desired python version in a couple of places to avoid having to disable these checks in make rpm-pkg. Signed-off-by: Uday Shankar <ushankar@purestorage.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2025-03-15kbuild: rust: add rustc-min-version support functionMiguel Ojeda
Introduce `rustc-min-version` support function that mimics `{gcc,clang}-min-version` ones, following commit 88b61e3bff93 ("Makefile.compiler: replace cc-ifversion with compiler-specific macros"). In addition, use it in the first use case we have in the kernel (which was done independently to minimize the changes needed for the fix). Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Reviewed-by: Fiona Behrens <me@Kloenk.dev> Reviewed-by: Nicolas Schier <n.schier@avm.de> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2025-03-15modpost: use strstarts() to clean up parse_source_files()Masahiro Yamada
No functional changes are intended. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
2025-03-15modpost: introduce get_basename() helperMasahiro Yamada
The logic to retrieve the basename appears multiple times. Factor out the common pattern into a helper function. I copied kbasename() from include/linux/string.h and renamed it to get_basename(). Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
2025-03-15kconfig: remove unnecessary cast in sym_get_string()Masahiro Yamada
The explicit casting from (char *) to (const char *) is unneeded. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2025-03-15kconfig: do not clear SYMBOL_VALID when reading include/config/auto.confMasahiro Yamada
When conf_read_simple() is called with S_DEF_AUTO, it is meant to read previous symbol values from include/config/auto.conf to determine which include/config/* files should be touched. This process should not modify the current symbol status in any way. However, conf_touch_deps() currently invalidates all symbol values and recalculates them, which is totally unneeded. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2025-03-15genksyms: factor out APP for the ST_NORMAL stateMasahiro Yamada
For the ST_NORMAL state, APP is called regardless of the token type. Factor it out. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2025-03-15gen_compile_commands.py: remove code for '\#' replacementMasahiro Yamada
Since commit 9564a8cf422d ("Kbuild: fix # escaping in .cmd files for future Make"), '#' in the build command is replaced with $(pound) rather than '\#'. Calling .replace(r'\#', '#') is only necessary when this tool is used to parse .*.cmd files generated by Linux 4.16 or earlier, which is unlikely to happen. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org>
2025-03-15kbuild: remove EXTRA_*FLAGS supportMasahiro Yamada
Commit f77bf01425b1 ("kbuild: introduce ccflags-y, asflags-y and ldflags-y") deprecated these in 2007. The migration should have been completed by now. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Kees Cook <kees@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org>
2025-03-15gendwarfksyms: Add a separate pass to resolve FQNsSami Tolvanen
Using dwarf_getscopes_die to resolve fully-qualified names turns out to be rather slow, and also results in duplicate scopes being processed, which doesn't help. Simply adding an extra pass to resolve names for all DIEs before processing exports is noticeably faster. For the object files with the most exports in a defconfig+Rust build, the performance improvement is consistently >50%: rust/bindings.o: 1038 exports before: 9.5980 +- 0.0183 seconds time elapsed ( +- 0.19% ) after: 4.3116 +- 0.0287 seconds time elapsed ( +- 0.67% ) rust/core.o: 424 exports before: 5.3584 +- 0.0204 seconds time elapsed ( +- 0.38% ) after: 0.05348 +- 0.00129 seconds time elapsed ( +- 2.42% ) ^ Not a mistake. net/core/dev.o: 190 exports before: 9.0507 +- 0.0297 seconds time elapsed ( +- 0.33% ) after: 3.2882 +- 0.0165 seconds time elapsed ( +- 0.50% ) rust/kernel.o: 129 exports before: 6.8571 +- 0.0317 seconds time elapsed ( +- 0.46% ) after: 2.9096 +- 0.0316 seconds time elapsed ( +- 1.09% ) net/core/skbuff.o: 120 exports before: 5.4805 +- 0.0291 seconds time elapsed ( +- 0.53% ) after: 2.0339 +- 0.0231 seconds time elapsed ( +- 1.14% ) drivers/gpu/drm/display/drm_dp_helper.o: 101 exports before: 1.7877 +- 0.0187 seconds time elapsed ( +- 1.05% ) after: 0.69245 +- 0.00994 seconds time elapsed ( +- 1.44% ) net/core/sock.o: 97 exports before: 5.8327 +- 0.0653 seconds time elapsed ( +- 1.12% ) after: 2.0784 +- 0.0291 seconds time elapsed ( +- 1.40% ) drivers/net/phy/phy_device.o: 95 exports before: 3.0671 +- 0.0371 seconds time elapsed ( +- 1.21% ) after: 1.2127 +- 0.0207 seconds time elapsed ( +- 1.70% ) drivers/pci/pci.o: 93 exports before: 1.1130 +- 0.0113 seconds time elapsed ( +- 1.01% ) after: 0.4848 +- 0.0127 seconds time elapsed ( +- 2.63% ) kernel/sched/core.o: 83 exports before: 3.5092 +- 0.0223 seconds time elapsed ( +- 0.64% ) after: 1.1231 +- 0.0145 seconds time elapsed ( +- 1.29% ) Overall, a defconfig+DWARF5 build with gendwarfksyms and Rust is 14.8% faster with this patch applied on my test system. Without Rust, there's still a 10.4% improvement in build time when gendwarfksyms is used. Note that symbol versions are unchanged with this patch. Suggested-by: Giuliano Procida <gprocida@google.com> Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2025-03-13Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netPaolo Abeni
Cross-merge networking fixes after downstream PR (net-6.14-rc6). Conflicts: tools/testing/selftests/drivers/net/ping.py 75cc19c8ff89 ("selftests: drv-net: add xdp cases for ping.py") de94e8697405 ("selftests: drv-net: store addresses in dict indexed by ipver") https://lore.kernel.org/netdev/20250311115758.17a1d414@canb.auug.org.au/ net/core/devmem.c a70f891e0fa0 ("net: devmem: do not WARN conditionally after netdev_rx_queue_restart()") 1d22d3060b9b ("net: drop rtnl_lock for queue_mgmt operations") https://lore.kernel.org/netdev/20250313114929.43744df1@canb.auug.org.au/ Adjacent changes: tools/testing/selftests/net/Makefile 6f50175ccad4 ("selftests: Add IPv6 link-local address generation tests for GRE devices.") 2e5584e0f913 ("selftests/net: expand cmsg_ipv6.sh with ipv4") drivers/net/ethernet/broadcom/bnxt/bnxt.c 661958552eda ("eth: bnxt: do not use BNXT_VNIC_NTUPLE unconditionally in queue restart logic") fe96d717d38e ("bnxt_en: Extend queue stop/start for TX rings") Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-12scripts: get_feat.pl: substitute s390x with s390Heiko Carstens
Both get_feat.pl and list-arch.sh use uname -m to get the machine hardware name to figure out the current architecture if no architecture is specified with a command line option. This doesn't work for s390, since for 64 bit kernels the hardware name is s390x, while the architecture name within the kernel, as well as in all feature files is s390. Therefore substitute s390x with s390 similar to what is already done for x86_64 and i386. Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20250312155219.3597768-1-hca@linux.ibm.com
2025-03-12scripts: generate_rust_analyzer: add uapi crateTamir Duberstein
Commit 4e1746656839 ("rust: uapi: Add UAPI crate") did not update rust-analyzer to include the new crate. Add the missing definition to improve the developer experience. Fixes: 4e1746656839 ("rust: uapi: Add UAPI crate") Signed-off-by: Tamir Duberstein <tamird@gmail.com> Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/r/20250210-rust-analyzer-bindings-include-v2-2-23dff845edc3@gmail.com [ Slightly reworded title. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-12scripts: generate_rust_analyzer: add missing include_dirsTamir Duberstein
Commit 8c4555ccc55c ("scripts: add `generate_rust_analyzer.py`") specified OBJTREE for the bindings crate, and `source.include_dirs` for the kernel crate, likely in an attempt to support out-of-source builds for those crates where the generated files reside in `objtree` rather than `srctree`. This was insufficient because both bits of configuration are required for each crate; the result is that rust-analyzer is unable to resolve generated files for either crate in an out-of-source build. [ Originally we were not using `OBJTREE` in the `kernel` crate, but we did pass the variable anyway, so conceptually it could have been there since then. Regarding `include_dirs`, it started in `kernel` before being in mainline because we included the bindings directly there (i.e. there was no `bindings` crate). However, when that crate got created, we moved the `OBJTREE` there but not the `include_dirs`. Nowadays, though, we happen to need the `include_dirs` also in the `kernel` crate for `generated_arch_static_branch_asm.rs` which was not there back then -- Tamir confirms it is indeed required for that reason. - Miguel ] Add the missing bits to improve the developer experience. Fixes: 8c4555ccc55c ("scripts: add `generate_rust_analyzer.py`") Signed-off-by: Tamir Duberstein <tamird@gmail.com> Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/r/20250210-rust-analyzer-bindings-include-v2-1-23dff845edc3@gmail.com [ Slightly reworded title. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-11scripts: generate_rust_analyzer: add missing macros depsTamir Duberstein
The macros crate has depended on std and proc_macro since its introduction in commit 1fbde52bde73 ("rust: add `macros` crate"). These dependencies were omitted from commit 8c4555ccc55c ("scripts: add `generate_rust_analyzer.py`") resulting in missing go-to-definition and autocomplete, and false-positive warnings emitted from rust-analyzer such as: [{ "resource": "/Users/tamird/src/linux/rust/macros/module.rs", "owner": "_generated_diagnostic_collection_name_#1", "code": { "value": "non_snake_case", "target": { "$mid": 1, "path": "/rustc/", "scheme": "https", "authority": "doc.rust-lang.org", "query": "search=non_snake_case" } }, "severity": 4, "message": "Variable `None` should have snake_case name, e.g. `none`", "source": "rust-analyzer", "startLineNumber": 123, "startColumn": 17, "endLineNumber": 123, "endColumn": 21 }] Add the missing dependencies to improve the developer experience. [ Fiona had a different approach (thanks!) at: https://lore.kernel.org/rust-for-linux/20241205115438.234221-1-me@kloenk.dev/ But Tamir and Fiona agreed to this one. - Miguel ] Fixes: 8c4555ccc55c ("scripts: add `generate_rust_analyzer.py`") Reviewed-by: Fiona Behrens <me@kloenk.dev> Diagnosed-by: Chayim Refael Friedman <chayimfr@gmail.com> Link: https://github.com/rust-lang/rust-analyzer/issues/17759#issuecomment-2646328275 Signed-off-by: Tamir Duberstein <tamird@gmail.com> Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/r/20250210-rust-analyzer-macros-core-dep-v3-1-45eb4836f218@gmail.com [ Removed `return`. Changed tag name. Added Link. Slightly reworded. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-10riscv/crc: add "template" for Zbc optimized CRC functionsEric Biggers
Add a "template" crc-clmul-template.h that can generate RISC-V Zbc optimized CRC functions. Each generated CRC function is parameterized by CRC length and bit order, and it accepts a pointer to the constants struct required for the specific CRC polynomial desired. Update gen-crc-consts.py to support generating the needed constants structs. This makes it possible to easily wire up a Zbc optimized implementation of almost any CRC. The design generally follows what I did for x86, but it is simplified by using RISC-V's scalar carryless multiplication Zbc, which has no equivalent on x86. RISC-V's clmulr instruction is also helpful. A potential switch to Zvbc (or support for Zvbc alongside Zbc) is left for future work. For long messages Zvbc should be fastest, but it would need to be shown to be worthwhile over just using Zbc which is significantly more convenient to use, especially in the kernel context. Compared to the existing Zbc-optimized CRC32 code and the earlier proposed Zbc-optimized CRC-T10DIF code (https://lore.kernel.org/r/20250211071101.181652-1-zhihang.shao.iscas@gmail.com), this submission deduplicates the code among CRC variants and is significantly more optimized. It uses "folding" to take better advantage of instruction-level parallelism (to a more limited extent than x86 for now, but it could be extended to more), it reworks the Barrett reduction to eliminate unnecessary instructions, and it documents all the math used and makes all the constants reproducible. Tested-by: Björn Töpel <bjorn@rivosinc.com> Acked-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20250216225530.306980-2-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@google.com>
2025-03-10Merge 6.14-rc6 into char-misc-nextGreg Kroah-Hartman
We need the fixes in here as well to build on top of. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit (git 2.34.1) at 2025-07-16 14:18:10 +0000