aboutsummaryrefslogtreecommitdiff
path: root/scripts
AgeCommit message (Collapse)AuthorFilesLines
2022-10-03kallsyms: ignore __kstrtab_* and __kstrtabns_* symbolsMasahiro Yamada1-0/+4
Every EXPORT_SYMBOL creates __kstrtab_* and __kstrtabns_*, which consumes 15-20% of the kallsyms entries. For example, on the system built from the x86_64 defconfig, $ cat /proc/kallsyms | wc 129527 388581 5685465 $ cat /proc/kallsyms | grep __kstrtab | wc 23489 70467 1187932 We already ignore __crc_* symbols populated by EXPORT_SYMBOL, so it should be fine to ignore __kstrtab_* and __kstrtabns_* as well. This makes vmlinux a bit smaller. $ size vmlinux.before vmlinux.after text data bss dec hex filename 22785374 8559694 1413328 32758396 1f3da7c vmlinux.before 22785374 8137806 1413328 32336508 1ed6a7c vmlinux.after Signed-off-by: Masahiro Yamada <[email protected]>
2022-10-02kallsyms: take the input file instead of reading stdinMasahiro Yamada2-19/+34
This gets rid of the pipe operator connected with 'cat'. Also use getopt_long() to parse the command line. Signed-off-by: Masahiro Yamada <[email protected]>
2022-10-02kallsyms: drop duplicated ignore patterns from kallsyms.cMasahiro Yamada2-4/+13
Now that kallsyms.c parses the output from mksysmap, some symbols have already been dropped. Move comments to scripts/mksysmap. Also, make the grep command readable. Signed-off-by: Masahiro Yamada <[email protected]>
2022-10-02kbuild: reuse mksysmap output for kallsymsMasahiro Yamada1-6/+5
scripts/mksysmap internally runs ${NM} (dropping some symbols). When CONFIG_KALLSYMS=y, mksysmap creates .tmp_System.map, but it is almost the same as the output from the ${NM} invocation in kallsyms(). It is true scripts/mksysmap drops some symbols, but scripts/kallsyms.c ignores more anyway. Keep the mksysmap output as *.syms, and reuse it for kallsyms and 'cmp -s'. It saves one ${NM} invocation. Signed-off-by: Masahiro Yamada <[email protected]>
2022-10-02mksysmap: update comment about __crc_*Masahiro Yamada1-4/+4
Since commit 7b4537199a4a ("kbuild: link symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS"), __crc_* symbols never become absolute. Keep ignoring __crc_*, but update the comment. Signed-off-by: Masahiro Yamada <[email protected]>
2022-10-02kbuild: remove head-y syntaxMasahiro Yamada1-0/+53
Kbuild puts the objects listed in head-y at the head of vmlinux. Conventionally, we do this for head*.S, which contains the kernel entry point. A counter approach is to control the section order by the linker script. Actually, the code marked as __HEAD goes into the ".head.text" section, which is placed before the normal ".text" section. I do not know if both of them are needed. From the build system perspective, head-y is not mandatory. If you can achieve the proper code placement by the linker script only, it would be cleaner. I collected the current head-y objects into head-object-list.txt. It is a whitelist. My hope is it will be reduced in the long run. Signed-off-by: Masahiro Yamada <[email protected]> Tested-by: Nick Desaulniers <[email protected]> Reviewed-by: Nicolas Schier <[email protected]>
2022-10-02kbuild: use obj-y instead extra-y for objects placed at the headMasahiro Yamada4-30/+10
The objects placed at the head of vmlinux need special treatments: - arch/$(SRCARCH)/Makefile adds them to head-y in order to place them before other archives in the linker command line. - arch/$(SRCARCH)/kernel/Makefile adds them to extra-y instead of obj-y to avoid them going into built-in.a. This commit gets rid of the latter. Create vmlinux.a to collect all the objects that are unconditionally linked to vmlinux. The objects listed in head-y are moved to the head of vmlinux.a by using 'ar m'. With this, arch/$(SRCARCH)/kernel/Makefile can consistently use obj-y for builtin objects. There is no *.o that is directly linked to vmlinux. Drop unneeded code in scripts/clang-tools/gen_compile_commands.py. $(AR) mPi needs 'T' to workaround the llvm-ar bug. The fix was suggested by Nathan Chancellor [1]. [1]: https://lore.kernel.org/llvm/[email protected]/ Signed-off-by: Masahiro Yamada <[email protected]> Tested-by: Nick Desaulniers <[email protected]> Reviewed-by: Nicolas Schier <[email protected]>
2022-10-01Makefile.extrawarn: Move -Wcast-function-type-strict to W=1Sami Tolvanen1-0/+1
We enable -Wcast-function-type globally in the kernel to warn about mismatching types in function pointer casts. Compilers currently warn only about ABI incompability with this flag, but Clang 16 will enable a stricter version of the check by default that checks for an exact type match. This will be very noisy in the kernel, so disable -Wcast-function-type-strict without W=1 until the new warnings have been addressed. Cc: [email protected] Link: https://reviews.llvm.org/D134831 Link: https://github.com/ClangBuiltLinux/linux/issues/1724 Suggested-by: Nathan Chancellor <[email protected]> Signed-off-by: Sami Tolvanen <[email protected]> Signed-off-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-09-29Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski4-18/+10
No conflicts. Signed-off-by: Jakub Kicinski <[email protected]>
2022-09-29checkpatch: warn on usage of VM_BUG_ON() and other BUG variantsDavid Hildenbrand1-3/+3
checkpatch does not point out that VM_BUG_ON() and friends should be avoided, however, Linus notes: VM_BUG_ON() has the exact same semantics as BUG_ON. It is literally no different, the only difference is "we can make the code smaller because these are less important". [1] So let's warn on VM_BUG_ON() and other BUG variants as well. While at it, make it clearer that the kernel really shouldn't be crashed. As there are some subsystem BUG macros that actually don't end up crashing the kernel -- for example, KVM_BUG_ON() -- exclude these manually. [1] https://lore.kernel.org/r/CAHk-=wg40EAZofO16Eviaj7mfqDhZ2gVEbvfsMf6gYzspRjYvw@mail.gmail.com Signed-off-by: David Hildenbrand <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Corbet <[email protected]>
2022-09-29docs: move asm-annotations.rst into core-apiJonathan Corbet1-1/+1
This one file should not really be in the top-level documentation directory. core-api/ may not be a perfect fit but seems to be best, so move it there. Adjust a couple of internal document references to make them location-independent, and point checkpatch.pl at the new location. Cc: Jiri Slaby <[email protected]> Cc: Joe Perches <[email protected]> Reviewed-by: David Vernet <[email protected]> Acked-by: Jani Nikula <[email protected]> Signed-off-by: Jonathan Corbet <[email protected]> Acked-by: Randy Dunlap <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Corbet <[email protected]>
2022-09-29kbuild: re-run modpost when it is updatedMasahiro Yamada1-6/+8
Modpost generates .vmlinux.export.c and *.mod.c, which are prerequisites of vmlinux and modules, respectively. The modpost stage should be re-run when the modpost code is updated. Signed-off-by: Masahiro Yamada <[email protected]>
2022-09-29kbuild: unify two modpost invocationsMasahiro Yamada3-69/+29
Currently, modpost is executed twice; first for vmlinux, second for modules. This commit merges them. Current build flow ================== 1) build obj-y and obj-m objects 2) link vmlinux.o 3) modpost for vmlinux 4) link vmlinux 5) modpost for modules 6) link modules (*.ko) The build steps 1) through 6) are serialized, that is, modules are built after vmlinux. You do not get benefits of parallel builds when scripts/link-vmlinux.sh is being run. New build flow ============== 1) build obj-y and obj-m objects 2) link vmlinux.o 3) modpost for vmlinux and modules 4a) link vmlinux 4b) link modules (*.ko) In the new build flow, modpost is invoked just once. vmlinux and modules are built in parallel. One exception is CONFIG_DEBUG_INFO_BTF_MODULES=y, where modules depend on vmlinux. Signed-off-by: Masahiro Yamada <[email protected]> Tested-by: Nick Desaulniers <[email protected]> Reviewed-by: Nicolas Schier <[email protected]>
2022-09-29kbuild: move vmlinux.o rule to the top MakefileMasahiro Yamada1-3/+0
Move the build rules of vmlinux.o out of scripts/link-vmlinux.sh to clearly separate 1) pre-modpost, 2) modpost, 3) post-modpost stages. This will make further refactoring possible. Signed-off-by: Masahiro Yamada <[email protected]> Tested-by: Nick Desaulniers <[email protected]> Reviewed-by: Nicolas Schier <[email protected]>
2022-09-29kbuild: move .vmlinux.objs rule to Makefile.modpostMasahiro Yamada2-20/+28
.vmlinux.objs is used by modpost, so scripts/Makefile.modpost is a better place to generate it. It is used only when CONFIG_MODVERSIONS=y. It should be guarded by "ifdef CONFIG_MODVERSIONS". Signed-off-by: Masahiro Yamada <[email protected]> Tested-by: Nick Desaulniers <[email protected]> Reviewed-by: Nicolas Schier <[email protected]>
2022-09-29kbuild: list sub-directories in ./KbuildMasahiro Yamada1-0/+2
Use the ordinary obj-y syntax to list subdirectories. Note1: Previously, the link order of lib-y depended on CONFIG_MODULES; lib-y was linked before drivers-y when CONFIG_MODULES=y, otherwise after drivers-y. This was a bug of commit 7273ad2b08f8 ("kbuild: link lib-y objects to vmlinux forcibly when CONFIG_MODULES=y"), but it was not a big deal after all. Now, all objects listed in lib-y are linked last, irrespective of CONFIG_MODULES. Note2: Finally, the single target build in arch/*/lib/ works correctly. There was a bug report about this. [1] $ make ARCH=arm arch/arm/lib/findbit.o CALL scripts/checksyscalls.sh AS arch/arm/lib/findbit.o [1]: https://lore.kernel.org/linux-kbuild/YvUQOwL6lD4%2F5%[email protected]/ Signed-off-by: Masahiro Yamada <[email protected]> Tested-by: Nick Desaulniers <[email protected]> Reviewed-by: Nicolas Schier <[email protected]>
2022-09-29Makefile.compiler: replace cc-ifversion with compiler-specific macrosNick Desaulniers2-5/+9
cc-ifversion is GCC specific. Replace it with compiler specific variants. Update the users of cc-ifversion to use these new macros. Link: https://github.com/ClangBuiltLinux/linux/issues/350 Link: https://lore.kernel.org/llvm/CAGG=3QWSAUakO42kubrCap8fp-gm1ERJJAYXTnP1iHk_wrH=BQ@mail.gmail.com/ Suggested-by: Bill Wendling <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2022-09-29kbuild: rpm-pkg: fix breakage when V=1 is usedJanis Schoetterl-Glausch1-2/+2
Doing make V=1 binrpm-pkg results in: Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.EgV6qJ + umask 022 + cd . + /bin/rm -rf /home/scgl/rpmbuild/BUILDROOT/kernel-6.0.0_rc5+-1.s390x + /bin/mkdir -p /home/scgl/rpmbuild/BUILDROOT + /bin/mkdir /home/scgl/rpmbuild/BUILDROOT/kernel-6.0.0_rc5+-1.s390x + mkdir -p /home/scgl/rpmbuild/BUILDROOT/kernel-6.0.0_rc5+-1.s390x/boot + make -f ./Makefile image_name + cp test -e include/generated/autoconf.h -a -e include/config/auto.conf || ( \ echo >&2; \ echo >&2 " ERROR: Kernel configuration is invalid."; \ echo >&2 " include/generated/autoconf.h or include/config/auto.conf are missing.";\ echo >&2 " Run 'make oldconfig && make prepare' on kernel src to fix it."; \ echo >&2 ; \ /bin/false) arch/s390/boot/bzImage /home/scgl/rpmbuild/BUILDROOT/kernel-6.0.0_rc5+-1.s390x/boot/vmlinuz-6.0.0-rc5+ cp: invalid option -- 'e' Try 'cp --help' for more information. error: Bad exit status from /var/tmp/rpm-tmp.EgV6qJ (%install) Because the make call to get the image name is verbose and prints additional information. Fixes: 993bdde94547 ("kbuild: add image_name to no-sync-config-targets") Signed-off-by: Janis Schoetterl-Glausch <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2022-09-29scripts: remove unused argument 'type'Zeng Heng1-3/+3
Remove unused function argument, and there is no logic changes. Signed-off-by: Zeng Heng <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2022-09-29Kconfig: remove sym_set_choice_valueZeng Heng2-6/+1
sym_set_choice_value could be removed and directly call sym_set_tristate_value instead. Signed-off-by: Zeng Heng <[email protected]> Suggested-by: Masahiro Yamada <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2022-09-29kbuild: use objtool-args-y to clean up objtool argumentsMasahiro Yamada2-26/+20
Based on Linus' patch. Refactor scripts/Makefile.vmlinux_o as well. Link: https://lore.kernel.org/lkml/CAHk-=wgjTMQgiKzBZTmb=uWGDEQxDdyF1+qxBkODYciuNsmwnw@mail.gmail.com/ Suggested-by: Linus Torvalds <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> Acked-by: Peter Zijlstra <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]>
2022-09-29kbuild: fix and refactor single target buildMasahiro Yamada1-38/+16
The single target build has a subtle bug for the combination for an individual file and a subdirectory. [1] 'make kernel/fork.i' builds only kernel/fork.i $ make kernel/fork.i CALL scripts/checksyscalls.sh DESCEND objtool CPP kernel/fork.i [2] 'make kernel/' builds only under the kernel/ directory. $ make kernel/ CALL scripts/checksyscalls.sh DESCEND objtool CC kernel/fork.o CC kernel/exec_domain.o [snip] CC kernel/rseq.o AR kernel/built-in.a But, if you try to do [1] and [2] in a single command, you will get only [1] with a weird log: $ make kernel/fork.i kernel/ CALL scripts/checksyscalls.sh DESCEND objtool CPP kernel/fork.i make[2]: Nothing to be done for 'kernel/'. With 'make kernel/fork.i kernel/', you should get both [1] and [2]. Rewrite the single target build. Signed-off-by: Masahiro Yamada <[email protected]>
2022-09-29kbuild: rewrite check-local-export in sh/awkOwen Rafferty1-49/+48
Remove the bash build dependency for those who otherwise do not have it installed. This also provides a significant speedup: $ make defconfig $ make yes2modconfig ... $ find . -name "*.o" | grep -v vmlinux | wc 3169 3169 89615 $ export NM=nm $ time sh -c 'find . -name "*.o" | grep -v vmlinux | xargs -n1 ./scripts/check-local-export' Without patch: 0m15.90s real 0m12.17s user 0m05.28s system With patch: dash + nawk 0m02.16s real 0m02.92s user 0m00.34s system dash + busybox awk 0m02.36s real 0m03.36s user 0m00.34s system dash + gawk 0m02.07s real 0m03.26s user 0m00.32s system bash + gawk 0m03.55s real 0m05.00s user 0m00.54s system Signed-off-by: Owen Rafferty <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2022-09-29Revert "kbuild: Make scripts/compile.h when sh != bash"Masahiro Yamada1-3/+0
This reverts commit [1] in the pre-git era. I do not know what problem happened in the script when sh != bash because there is no commit message. Now that this script is much simpler than it used to be, let's revert it, and let' see. (If this turns out to be problematic, fix the code with proper commit description.) [1]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=11acbbbb8a50f4de7dbe4bc1b5acc440dfe81810 Signed-off-by: Masahiro Yamada <[email protected]>
2022-09-29scripts/mkcompile_h: move LC_ALL=C to '$LD -v'Masahiro Yamada1-6/+2
Minimize the scope of LC_ALL=C like before commit 87c94bfb8ad3 ("kbuild: override build timestamp & version"). Give LC_ALL=C to '$LD -v' to get the consistent version output, as commit bcbcf50f5218 ("kbuild: fix ld-version.sh to not be affected by locale") mentioned the LD version is affected by locale. While I was here, I merged two sed invocations. Signed-off-by: Masahiro Yamada <[email protected]>
2022-09-29kbuild: build init/built-in.a just onceMasahiro Yamada2-91/+15
Kbuild builds init/built-in.a twice; first during the ordinary directory descending, second from scripts/link-vmlinux.sh. We do this because UTS_VERSION contains the build version and the timestamp. We cannot update it during the normal directory traversal since we do not yet know if we need to update vmlinux. UTS_VERSION is temporarily calculated, but omitted from the update check. Otherwise, vmlinux would be rebuilt every time. When Kbuild results in running link-vmlinux.sh, it increments the version number in the .version file and takes the timestamp at that time to really fix UTS_VERSION. However, updating the same file twice is a footgun. To avoid nasty timestamp issues, all build artifacts that depend on init/built-in.a are atomically generated in link-vmlinux.sh, where some of them do not need rebuilding. To fix this issue, this commit changes as follows: [1] Split UTS_VERSION out to include/generated/utsversion.h from include/generated/compile.h include/generated/utsversion.h is generated just before the vmlinux link. It is generated under include/generated/ because some decompressors (s390, x86) use UTS_VERSION. [2] Split init_uts_ns and linux_banner out to init/version-timestamp.c from init/version.c init_uts_ns and linux_banner contain UTS_VERSION. During the ordinary directory descending, they are compiled with __weak and used to determine if vmlinux needs relinking. Just before the vmlinux link, they are compiled without __weak to embed the real version and timestamp. Signed-off-by: Masahiro Yamada <[email protected]>
2022-09-29kbuild: do not deduplicate modules.orderMasahiro Yamada1-1/+1
The AWK code was added to deduplicate modules.order in case $(obj-m) contains the same module multiple times, but it is actually unneeded since commit b2c885549122 ("kbuild: update modules.order only when contained modules are updated"). The list is already deduplicated before being processed by AWK because $^ is the deduplicated list of prerequisites. (Please note the real-prereqs macro uses $^) Yet, modules.order will contain duplication if two different Makefiles build the same module: foo/Makefile: obj-m += bar/baz.o foo/bar/Makefile: obj-m += baz.o However, the parallel builds cannot properly handle this case in the first place. So, it is better to let it fail (as already done by scripts/modules-check.sh). Signed-off-by: Masahiro Yamada <[email protected]>
2022-09-29kbuild: check sha1sum just once for each atomic headerMasahiro Yamada1-33/+0
It is unneeded to check the sha1sum every time. Create the timestamp files to manage it. Add '.' to clean-dirs because 'make clean' must visit ./Kbuild to clean up the timestamp files. Signed-off-by: Masahiro Yamada <[email protected]>
2022-09-29kbuild: hard-code KBUILD_ALLDIRS in scripts/Makefile.packageMasahiro Yamada1-1/+4
My future plan is to list subdirectories in ./Kbuild. When it occurs, $(vmlinux-alldirs) will not contain all subdirectories. Let's hard-code the directory list until I get around to implementing a more sophisticated way for generating a source tarball. Signed-off-by: Masahiro Yamada <[email protected]> Tested-by: Nick Desaulniers <[email protected]> Reviewed-by: Nicolas Schier <[email protected]>
2022-09-29kbuild: remove the target in signal traps when interruptedMasahiro Yamada1-1/+22
When receiving some signal, GNU Make automatically deletes the target if it has already been changed by the interrupted recipe. If the target is possibly incomplete due to interruption, it must be deleted so that it will be remade from scratch on the next run of make. Otherwise, the target would remain corrupted permanently because its timestamp had already been updated. Thanks to this behavior of Make, you can stop the build any time by pressing Ctrl-C, and just run 'make' to resume it. Kbuild also relies on this feature, but it is equivalently important for any build systems that make decisions based on timestamps (if you want to support Ctrl-C reliably). However, this does not always work as claimed; Make immediately dies with Ctrl-C if its stderr goes into a pipe. [Test Makefile] foo: echo hello > $@ sleep 3 echo world >> $@ [Test Result] $ make # hit Ctrl-C echo hello > foo sleep 3 ^Cmake: *** Deleting file 'foo' make: *** [Makefile:3: foo] Interrupt $ make 2>&1 | cat # hit Ctrl-C echo hello > foo sleep 3 ^C$ # 'foo' is often left-over The reason is because SIGINT is sent to the entire process group. In this example, SIGINT kills 'cat', and 'make' writes the message to the closed pipe, then dies with SIGPIPE before cleaning the target. A typical bad scenario (as reported by [1], [2]) is to save build log by using the 'tee' command: $ make 2>&1 | tee log This can be problematic for any build systems based on Make, so I hope it will be fixed in GNU Make. The maintainer of GNU Make stated this is a long-standing issue and difficult to fix [3]. It has not been fixed yet as of writing. So, we cannot rely on Make cleaning the target. We can do it by ourselves, in signal traps. As far as I understand, Make takes care of SIGHUP, SIGINT, SIGQUIT, and SITERM for the target removal. I added the traps for them, and also for SIGPIPE just in case cmd_* rule prints something to stdout or stderr (but I did not observe an actual case where SIGPIPE was triggered). [Note 1] The trap handler might be worth explaining. rm -f $@; trap - $(sig); kill -s $(sig) $$ This lets the shell kill itself by the signal it caught, so the parent process can tell the child has exited on the signal. Generally, this is a proper manner for handling signals, in case the calling program (like Bash) may monitor WIFSIGNALED() and WTERMSIG() for WCE although this may not be a big deal here because GNU Make handles SIGHUP, SIGINT, SIGQUIT in WUE and SIGTERM in IUE. IUE - Immediate Unconditional Exit WUE - Wait and Unconditional Exit WCE - Wait and Cooperative Exit For details, see "Proper handling of SIGINT/SIGQUIT" [4]. [Note 2] Reverting 392885ee82d3 ("kbuild: let fixdep directly write to .*.cmd files") would directly address [1], but it only saves if_changed_dep. As reported in [2], all commands that use redirection can potentially leave an empty (i.e. broken) target. [Note 3] Another (even safer) approach might be to always write to a temporary file, and rename it to $@ at the end of the recipe. <command> > $(tmp-target) mv $(tmp-target) $@ It would require a lot of Makefile changes, and result in ugly code, so I did not take it. [Note 4] A little more thoughts about a pattern rule with multiple targets (or a grouped target). %.x %.y: %.z <recipe> When interrupted, GNU Make deletes both %.x and %.y, while this solution only deletes $@. Probably, this is not a big deal. The next run of make will execute the rule again to create $@ along with the other files. [1]: https://lore.kernel.org/all/[email protected]/ [2]: https://lore.kernel.org/all/[email protected]/ [3]: https://lists.gnu.org/archive/html/help-make/2021-06/msg00001.html [4]: https://www.cons.org/cracauer/sigint.html Fixes: 392885ee82d3 ("kbuild: let fixdep directly write to .*.cmd files") Reported-by: Ingo Molnar <[email protected]> Reported-by: Rob Herring <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> Tested-by: Ingo Molnar <[email protected]> Reviewed-by: Nicolas Schier <[email protected]>
2022-09-28x86: enable initial Rust supportMiguel Ojeda1-2/+13
Note that only x86_64 is covered and not all features nor mitigations are handled, but it is enough as a starting point and showcases the basics needed to add Rust support for a new architecture. Reviewed-by: Kees Cook <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Co-developed-by: David Gow <[email protected]> Signed-off-by: David Gow <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
2022-09-28Kbuild: add Rust supportMiguel Ojeda9-15/+203
Having most of the new files in place, we now enable Rust support in the build system, including `Kconfig` entries related to Rust, the Rust configuration printer and a few other bits. Reviewed-by: Kees Cook <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Tested-by: Nick Desaulniers <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Finn Behrens <[email protected]> Signed-off-by: Finn Behrens <[email protected]> Co-developed-by: Adam Bratschi-Kaye <[email protected]> Signed-off-by: Adam Bratschi-Kaye <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Co-developed-by: Michael Ellerman <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Co-developed-by: Sven Van Asbroeck <[email protected]> Signed-off-by: Sven Van Asbroeck <[email protected]> Co-developed-by: Gary Guo <[email protected]> Signed-off-by: Gary Guo <[email protected]> Co-developed-by: Boris-Chengbiao Zhou <[email protected]> Signed-off-by: Boris-Chengbiao Zhou <[email protected]> Co-developed-by: Boqun Feng <[email protected]> Signed-off-by: Boqun Feng <[email protected]> Co-developed-by: Douglas Su <[email protected]> Signed-off-by: Douglas Su <[email protected]> Co-developed-by: Dariusz Sosnowski <[email protected]> Signed-off-by: Dariusz Sosnowski <[email protected]> Co-developed-by: Antonio Terceiro <[email protected]> Signed-off-by: Antonio Terceiro <[email protected]> Co-developed-by: Daniel Xu <[email protected]> Signed-off-by: Daniel Xu <[email protected]> Co-developed-by: Björn Roy Baron <[email protected]> Signed-off-by: Björn Roy Baron <[email protected]> Co-developed-by: Martin Rodriguez Reboredo <[email protected]> Signed-off-by: Martin Rodriguez Reboredo <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
2022-09-28scripts: add `is_rust_module.sh`Daniel Xu1-0/+16
This script is used to detect whether a kernel module is written in Rust. It will later be used to disable BTF generation on Rust modules as BTF does not yet support Rust. Reviewed-by: Kees Cook <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Daniel Xu <[email protected]> Co-developed-by: Miguel Ojeda <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
2022-09-28scripts: add `rust_is_available.sh`Miguel Ojeda3-0/+168
This script tests whether the Rust toolchain requirements are in place to enable Rust support. It uses `min-tool-version.sh` to fetch the version numbers. The build system will call it to set `CONFIG_RUST_IS_AVAILABLE` in a later patch. It also has an option (`-v`) to explain what is missing, which is useful to set up the development environment. This is used via the `make rustavailable` target added in a later patch. Reviewed-by: Kees Cook <[email protected]> Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Co-developed-by: Finn Behrens <[email protected]> Signed-off-by: Finn Behrens <[email protected]> Co-developed-by: Miguel Cano <[email protected]> Signed-off-by: Miguel Cano <[email protected]> Co-developed-by: Tiago Lam <[email protected]> Signed-off-by: Tiago Lam <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
2022-09-28scripts: add `generate_rust_target.rs`Miguel Ojeda2-0/+172
This script takes care of generating the custom target specification file for `rustc`, based on the kernel configuration. It also serves as an example of a Rust host program. A dummy architecture is kept in this patch so that a later patch adds x86 support on top with as few changes as possible. Reviewed-by: Kees Cook <[email protected]> Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Co-developed-by: David Gow <[email protected]> Signed-off-by: David Gow <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
2022-09-28scripts: add `generate_rust_analyzer.py`Miguel Ojeda1-0/+135
The `generate_rust_analyzer.py` script generates the configuration file (`rust-project.json`) for rust-analyzer. rust-analyzer is a modular compiler frontend for the Rust language. It provides an LSP server which can be used in editors such as VS Code, Emacs or Vim. Reviewed-by: Kees Cook <[email protected]> Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Finn Behrens <[email protected]> Signed-off-by: Finn Behrens <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Co-developed-by: Gary Guo <[email protected]> Signed-off-by: Gary Guo <[email protected]> Co-developed-by: Boris-Chengbiao Zhou <[email protected]> Signed-off-by: Boris-Chengbiao Zhou <[email protected]> Co-developed-by: Björn Roy Baron <[email protected]> Signed-off-by: Björn Roy Baron <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
2022-09-28scripts: decode_stacktrace: demangle Rust symbolsMiguel Ojeda1-0/+14
Recent versions of both Binutils (`c++filt`) and LLVM (`llvm-cxxfilt`) provide Rust v0 mangling support. Reviewed-by: Kees Cook <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
2022-09-28scripts: checkpatch: enable language-independent checks for RustMiguel Ojeda1-2/+2
Include Rust in the "source code files" category, so that the language-independent tests are checked for Rust too, and teach `checkpatch` about the comment style for Rust files. This enables the malformed SPDX check, the misplaced SPDX license tag check, the long line checks, the lines without a newline check and the embedded filename check. Reviewed-by: Kees Cook <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
2022-09-28scripts: checkpatch: diagnose uses of `%pA` in the C side as errorsMiguel Ojeda1-2/+6
The `%pA` format specifier is only intended to be used from Rust. `checkpatch.pl` already gives a warning for invalid specificers: WARNING: Invalid vsprintf pointer extension '%pA' This makes it an error and introduces an explanatory message: ERROR: Invalid vsprintf pointer extension '%pA' - '%pA' is only intended to be used from Rust code Suggested-by: Kees Cook <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Co-developed-by: Joe Perches <[email protected]> Signed-off-by: Joe Perches <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
2022-09-28kallsyms: increase maximum kernel symbol length to 512Miguel Ojeda1-2/+2
Rust symbols can become quite long due to namespacing introduced by modules, types, traits, generics, etc. For instance, the following code: pub mod my_module { pub struct MyType; pub struct MyGenericType<T>(T); pub trait MyTrait { fn my_method() -> u32; } impl MyTrait for MyGenericType<MyType> { fn my_method() -> u32 { 42 } } } generates a symbol of length 96 when using the upcoming v0 mangling scheme: _RNvXNtCshGpAVYOtgW1_7example9my_moduleINtB2_13MyGenericTypeNtB2_6MyTypeENtB2_7MyTrait9my_method At the moment, Rust symbols may reach up to 300 in length. Setting 512 as the maximum seems like a reasonable choice to keep some headroom. Reviewed-by: Kees Cook <[email protected]> Reviewed-by: Petr Mladek <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Co-developed-by: Gary Guo <[email protected]> Signed-off-by: Gary Guo <[email protected]> Co-developed-by: Boqun Feng <[email protected]> Signed-off-by: Boqun Feng <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
2022-09-28kallsyms: support "big" kernel symbolsMiguel Ojeda1-3/+26
Rust symbols can become quite long due to namespacing introduced by modules, types, traits, generics, etc. Increasing to 255 is not enough in some cases, therefore introduce longer lengths to the symbol table. In order to avoid increasing all lengths to 2 bytes (since most of them are small, including many Rust ones), use ULEB128 to keep smaller symbols in 1 byte, with the rest in 2 bytes. Reviewed-by: Kees Cook <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Co-developed-by: Gary Guo <[email protected]> Signed-off-by: Gary Guo <[email protected]> Co-developed-by: Boqun Feng <[email protected]> Signed-off-by: Boqun Feng <[email protected]> Co-developed-by: Matthew Wilcox <[email protected]> Signed-off-by: Matthew Wilcox <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
2022-09-28kallsyms: add static relationship between `KSYM_NAME_LEN{,_BUFFER}`Miguel Ojeda1-2/+12
This adds a static assert to ensure `KSYM_NAME_LEN_BUFFER` gets updated when `KSYM_NAME_LEN` changes. The relationship used is one that keeps the new size (512+1) close to the original buffer size (500). Reviewed-by: Greg Kroah-Hartman <[email protected]> Co-developed-by: Boqun Feng <[email protected]> Signed-off-by: Boqun Feng <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
2022-09-28kallsyms: avoid hardcoding buffer sizeBoqun Feng1-2/+8
This introduces `KSYM_NAME_LEN_BUFFER` in place of the previously hardcoded size of the input buffer. It will also make it easier to update the size in a single place in a later patch. Reviewed-by: Kees Cook <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Boqun Feng <[email protected]> Co-developed-by: Miguel Ojeda <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
2022-09-28kallsyms: use `ARRAY_SIZE` instead of hardcoded sizeBoqun Feng1-1/+1
This removes one place where the `500` constant is hardcoded. Reviewed-by: Kees Cook <[email protected]> Reviewed-by: Geert Stappers <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Boqun Feng <[email protected]> Co-developed-by: Miguel Ojeda <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
2022-09-27dt: Add a check for undocumented compatible strings in kernelRob Herring1-0/+69
Add a make target, dt_compatible_check, to extract compatible strings from kernel sources and check if they are documented by a schema. At least version v2022.08 of dtschema with dt-check-compatible is required. This check can also be run manually on specific files or directories: scripts/dtc/dt-extract-compatibles drivers/clk/ | \ xargs dt-check-compatible -v -s Documentation/devicetree/bindings/processed-schema.json Currently, there are about 3800 undocumented compatible strings. Most of these are cases where the binding is not yet converted (given there are 1900 .txt binding files remaining). Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Rob Herring <[email protected]>
2022-09-27kbuild: take into account DT_SCHEMA_FILES changes while checking dtbsDmitry Baryshkov1-8/+6
It is useful to be able to recheck dtbs files against a limited set of DT schema files. This can be accomplished by using differnt DT_SCHEMA_FILES argument values while rerunning make dtbs_check. However for some reason if_changed_rule doesn't pick up the rule_dtc changes (and doesn't retrigger the build). Fix this by changing if_changed_rule to if_changed_dep and squashing DTC and dt-validate into a single new command. Then if_changed_dep triggers on DT_SCHEMA_FILES changes and reruns the build/check. Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Herring <[email protected]>
2022-09-26cfi: Switch to -fsanitize=kcfiSami Tolvanen1-19/+4
Switch from Clang's original forward-edge control-flow integrity implementation to -fsanitize=kcfi, which is better suited for the kernel, as it doesn't require LTO, doesn't use a jump table that requires altering function references, and won't break cross-module function address equality. Signed-off-by: Sami Tolvanen <[email protected]> Reviewed-by: Kees Cook <[email protected]> Tested-by: Kees Cook <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Tested-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-09-26scripts/kallsyms: Ignore __kcfi_typeid_Sami Tolvanen1-0/+1
The compiler generates __kcfi_typeid_ symbols for annotating assembly functions with type information. These are constants that can be referenced in assembly code and are resolved by the linker. Ignore them in kallsyms. Signed-off-by: Sami Tolvanen <[email protected]> Reviewed-by: Kees Cook <[email protected]> Tested-by: Kees Cook <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Tested-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-09-24Makefile.debug: re-enable debug info for .S filesNick Desaulniers1-10/+11
Alexey reported that the fraction of unknown filename instances in kallsyms grew from ~0.3% to ~10% recently; Bill and Greg tracked it down to assembler defined symbols, which regressed as a result of: commit b8a9092330da ("Kbuild: do not emit debug info for assembly with LLVM_IAS=1") In that commit, I allude to restoring debug info for assembler defined symbols in a follow up patch, but it seems I forgot to do so in commit a66049e2cf0e ("Kbuild: make DWARF version a choice") Link: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=31bf18645d98b4d3d7357353be840e320649a67d Fixes: b8a9092330da ("Kbuild: do not emit debug info for assembly with LLVM_IAS=1") Reported-by: Alexey Alexandrov <[email protected]> Reported-by: Bill Wendling <[email protected]> Reported-by: Greg Thelen <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Suggested-by: Masahiro Yamada <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2022-09-24Makefile.debug: set -g unconditional on CONFIG_DEBUG_INFO_SPLITNick Desaulniers1-3/+1
Dmitrii, Fangrui, and Mashahiro note: Before GCC 11 and Clang 12 -gsplit-dwarf implicitly uses -g2. Fix CONFIG_DEBUG_INFO_SPLIT for gcc-11+ & clang-12+ which now need -g specified in order for -gsplit-dwarf to work at all. -gsplit-dwarf has been mutually exclusive with -g since support for CONFIG_DEBUG_INFO_SPLIT was introduced in commit 866ced950bcd ("kbuild: Support split debug info v4") I don't think it ever needed to be. Link: https://lore.kernel.org/lkml/[email protected]/ Link: https://lore.kernel.org/lkml/CAK7LNARPAmsJD5XKAw7m_X2g7Fi-CAAsWDQiP7+ANBjkg7R7ng@mail.gmail.com/ Link: https://reviews.llvm.org/D80391 Cc: Andi Kleen <[email protected]> Reported-by: Dmitrii Bundin <[email protected]> Reported-by: Fangrui Song <[email protected]> Reported-by: Masahiro Yamada <[email protected]> Suggested-by: Dmitrii Bundin <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>