summaryrefslogtreecommitdiff
path: root/Makefile
AgeCommit message (Collapse)AuthorFilesLines
2022-07-25io_uring: move to separate directoryJens Axboe1-0/+1
In preparation for splitting io_uring up a bit, move it into its own top level directory. It didn't really belong in fs/ anyway, as it's not a file system only API. This adds io_uring/ and moves the core files in there, and updates the MAINTAINERS file for the new location. Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-07-24Linux 5.19-rc8Linus Torvalds1-1/+1
2022-07-17Linux 5.19-rc7Linus Torvalds1-1/+1
2022-07-11Linux 5.19-rc6Linus Torvalds1-1/+1
2022-07-04Linux 5.19-rc5Linus Torvalds1-1/+1
2022-06-27Linux 5.19-rc4Linus Torvalds1-1/+1
2022-06-26kbuild: link vmlinux only once for CONFIG_TRIM_UNUSED_KSYMS (2nd attempt)Masahiro Yamada1-1/+1
If CONFIG_TRIM_UNUSED_KSYMS is enabled and the kernel is built from a pristine state, the vmlinux is linked twice. Commit 3fdc7d3fe4c0 ("kbuild: link vmlinux only once for CONFIG_TRIM_UNUSED_KSYMS") explains why this happens, but it did not fix the issue at all. Now I realized I had applied a wrong patch. In v1 patch [1], the autoksyms_recursive target correctly recurses to "$(MAKE) -f $(srctree)/Makefile autoksyms_recursive". In v2 patch [2], I accidentally dropped the diff line, and it recurses to "$(MAKE) -f $(srctree)/Makefile vmlinux". Restore the code I intended in v1. [1]: https://lore.kernel.org/linux-kbuild/1521045861-22418-8-git-send-email-yamada.masahiro@socionext.com/ [2]: https://lore.kernel.org/linux-kbuild/1521166725-24157-8-git-send-email-yamada.masahiro@socionext.com/ Fixes: 3fdc7d3fe4c0 ("kbuild: link vmlinux only once for CONFIG_TRIM_UNUSED_KSYMS") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Tested-by: Sami Tolvanen <samitolvanen@google.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
2022-06-19Linux 5.19-rc3Linus Torvalds1-1/+1
2022-06-13Linux 5.19-rc2Linus Torvalds1-1/+1
2022-06-09gcc-12: disable '-Warray-bounds' universally for nowLinus Torvalds1-0/+1
In commit 8b202ee21839 ("s390: disable -Warray-bounds") the s390 people disabled the '-Warray-bounds' warning for gcc-12, because the new logic in gcc would cause warnings for their use of the S390_lowcore macro, which accesses absolute pointers. It turns out gcc-12 has many other issues in this area, so this takes that s390 warning disable logic, and turns it into a kernel build config entry instead. Part of the intent is that we can make this all much more targeted, and use this conflig flag to disable it in only particular configurations that cause problems, with the s390 case as an example: select GCC12_NO_ARRAY_BOUNDS and we could do that for other configuration cases that cause issues. Or we could possibly use the CONFIG_CC_NO_ARRAY_BOUNDS thing in a more targeted way, and disable the warning only for particular uses: again the s390 case as an example: KBUILD_CFLAGS_DECOMPRESSOR += $(if $(CONFIG_CC_NO_ARRAY_BOUNDS),-Wno-array-bounds) but this ends up just doing it globally in the top-level Makefile, since the current issues are spread fairly widely all over: KBUILD_CFLAGS-$(CONFIG_CC_NO_ARRAY_BOUNDS) += -Wno-array-bounds We'll try to limit this later, since the gcc-12 problems are rare enough that *much* of the kernel can be built with it without disabling this warning. Cc: Kees Cook <keescook@chromium.org> Cc: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-06-09gcc-12: disable '-Wdangling-pointer' warning for nowLinus Torvalds1-0/+3
While the concept of checking for dangling pointers to local variables at function exit is really interesting, the gcc-12 implementation is not compatible with reality, and results in false positives. For example, gcc sees us putting things on a local list head allocated on the stack, which involves exactly those kinds of pointers to the local stack entry: In function ‘__list_add’, inlined from ‘list_add_tail’ at include/linux/list.h:102:2, inlined from ‘rebuild_snap_realms’ at fs/ceph/snap.c:434:2: include/linux/list.h:74:19: warning: storing the address of local variable ‘realm_queue’ in ‘*&realm_27(D)->rebuild_item.prev’ [-Wdangling-pointer=] 74 | new->prev = prev; | ~~~~~~~~~~^~~~~~ But then gcc - understandably - doesn't really understand the big picture how the doubly linked list works, so doesn't see how we then end up emptying said list head in a loop and the pointer we added has been removed. Gcc also complains about us (intentionally) using this as a way to store a kind of fake stack trace, eg drivers/acpi/acpica/utdebug.c:40:38: warning: storing the address of local variable ‘current_sp’ in ‘acpi_gbl_entry_stack_pointer’ [-Wdangling-pointer=] 40 | acpi_gbl_entry_stack_pointer = &current_sp; | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~ which is entirely reasonable from a compiler standpoint, and we may want to change those kinds of patterns, but not not. So this is one of those "it would be lovely if the compiler were to complain about us leaving dangling pointers to the stack", but not this way. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-06-06Linux 5.19-rc1Linus Torvalds1-2/+2
2022-06-05kbuild: clean .tmp_* pattern by make cleanMasahiro Yamada1-2/+2
Change the "make clean" rule to remove all the .tmp_* files. .tmp_objdiff is the only exception, which should be removed by "make mrproper". Rename the record directory of objdiff, .tmp_objdiff to .objdiff to avoid the removal by "make clean". Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> # LLVM-14 (x86-64)
2022-05-26Merge tag 'kbuild-v5.19' of ↵Linus Torvalds1-6/+10
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild updates from Masahiro Yamada: - Add HOSTPKG_CONFIG env variable to allow users to override pkg-config - Support W=e as a shorthand for KCFLAGS=-Werror - Fix CONFIG_IKHEADERS build to support toybox cpio - Add scripts/dummy-tools/pahole to ease distro packagers' life - Suppress false-positive warnings from checksyscalls.sh for W=2 build - Factor out the common code of arch/*/boot/install.sh into scripts/install.sh - Support 'kernel-install' tool in scripts/prune-kernel - Refactor module-versioning to link the symbol versions at the final link of vmlinux and modules - Remove CONFIG_MODULE_REL_CRCS because module-versioning now works in an arch-agnostic way - Refactor modpost, Makefiles * tag 'kbuild-v5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: (56 commits) genksyms: adjust the output format to modpost kbuild: stop merging *.symversions kbuild: link symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS modpost: extract symbol versions from *.cmd files modpost: add sym_find_with_module() helper modpost: change the license of EXPORT_SYMBOL to bool type modpost: remove left-over cross_compile declaration kbuild: record symbol versions in *.cmd files kbuild: generate a list of objects in vmlinux modpost: move *.mod.c generation to write_mod_c_files() modpost: merge add_{intree_flag,retpoline,staging_flag} to add_header scripts/prune-kernel: Use kernel-install if available kbuild: factor out the common installation code into scripts/install.sh modpost: split new_symbol() to symbol allocation and hash table addition modpost: make sym_add_exported() always allocate a new symbol modpost: make multiple export error modpost: dump Module.symvers in the same order of modules.order modpost: traverse the namespace_list in order modpost: use doubly linked list for dump_lists modpost: traverse unresolved symbols in order ...
2022-05-24Merge tag 'kernel-hardening-v5.19-rc1' of ↵Linus Torvalds1-0/+1
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux Pull kernel hardening updates from Kees Cook: - usercopy hardening expanded to check other allocation types (Matthew Wilcox, Yuanzheng Song) - arm64 stackleak behavioral improvements (Mark Rutland) - arm64 CFI code gen improvement (Sami Tolvanen) - LoadPin LSM block dev API adjustment (Christoph Hellwig) - Clang randstruct support (Bill Wendling, Kees Cook) * tag 'kernel-hardening-v5.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: (34 commits) loadpin: stop using bdevname mm: usercopy: move the virt_addr_valid() below the is_vmalloc_addr() gcc-plugins: randstruct: Remove cast exception handling af_unix: Silence randstruct GCC plugin warning niu: Silence randstruct warnings big_keys: Use struct for internal payload gcc-plugins: Change all version strings match kernel randomize_kstack: Improve docs on requirements/rationale lkdtm/stackleak: fix CONFIG_GCC_PLUGIN_STACKLEAK=n arm64: entry: use stackleak_erase_on_task_stack() stackleak: add on/off stack variants lkdtm/stackleak: check stack boundaries lkdtm/stackleak: prevent unexpected stack usage lkdtm/stackleak: rework boundary management lkdtm/stackleak: avoid spurious failure stackleak: rework poison scanning stackleak: rework stack high bound handling stackleak: clarify variable names stackleak: rework stack low bound handling stackleak: remove redundant check ...
2022-05-24Merge tag 'objtool-core-2022-05-23' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull objtool updates from Ingo Molnar: - Comprehensive interface overhaul: ================================= Objtool's interface has some issues: - Several features are done unconditionally, without any way to turn them off. Some of them might be surprising. This makes objtool tricky to use, and prevents porting individual features to other arches. - The config dependencies are too coarse-grained. Objtool enablement is tied to CONFIG_STACK_VALIDATION, but it has several other features independent of that. - The objtool subcmds ("check" and "orc") are clumsy: "check" is really a subset of "orc", so it has all the same options. The subcmd model has never really worked for objtool, as it only has a single purpose: "do some combination of things on an object file". - The '--lto' and '--vmlinux' options are nonsensical and have surprising behavior. Overhaul the interface: - get rid of subcmds - make all features individually selectable - remove and/or clarify confusing/obsolete options - update the documentation - fix some bugs found along the way - Fix x32 regression - Fix Kbuild cleanup bugs - Add scripts/objdump-func helper script to disassemble a single function from an object file. - Rewrite scripts/faddr2line to be section-aware, by basing it on 'readelf', moving it away from 'nm', which doesn't handle multiple sections well, which can result in decoding failure. - Rewrite & fix symbol handling - which had a number of bugs wrt. object files that don't have global symbols - which is rare but possible. Also fix a bunch of symbol handling bugs found along the way. * tag 'objtool-core-2022-05-23' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (23 commits) objtool: Fix objtool regression on x32 systems objtool: Fix symbol creation scripts/faddr2line: Fix overlapping text section failures scripts: Create objdump-func helper script objtool: Remove libsubcmd.a when make clean objtool: Remove inat-tables.c when make clean objtool: Update documentation objtool: Remove --lto and --vmlinux in favor of --link objtool: Add HAVE_NOINSTR_VALIDATION objtool: Rename "VMLINUX_VALIDATION" -> "NOINSTR_VALIDATION" objtool: Make noinstr hacks optional objtool: Make jump label hack optional objtool: Make static call annotation optional objtool: Make stack validation frame-pointer-specific objtool: Add CONFIG_OBJTOOL objtool: Extricate sls from stack validation objtool: Rework ibt and extricate from stack validation objtool: Make stack validation optional objtool: Add option to print section addresses objtool: Don't print parentheses in function addresses ...
2022-05-22Linux 5.18Linus Torvalds1-1/+1
2022-05-16Linux 5.18-rc7Linus Torvalds1-1/+1
2022-05-11kbuild: factor out the common installation code into scripts/install.shMasahiro Yamada1-1/+2
Many architectures have similar install.sh scripts. The first half is really generic; it verifies that the kernel image and System.map exist, then executes ~/bin/${INSTALLKERNEL} or /sbin/${INSTALLKERNEL} if available. The second half is kind of arch-specific; it copies the kernel image and System.map to the destination, but the code is slightly different. Factor out the generic part into scripts/install.sh. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <n.schier@avm.de>
2022-05-08Linux 5.18-rc6Linus Torvalds1-1/+1
2022-05-08randstruct: Split randstruct Makefile and CFLAGSKees Cook1-0/+1
To enable the new Clang randstruct implementation[1], move randstruct into its own Makefile and split the CFLAGS from GCC_PLUGINS_CFLAGS into RANDSTRUCT_CFLAGS. [1] https://reviews.llvm.org/D121556 Cc: linux-hardening@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20220503205503.3054173-5-keescook@chromium.org
2022-05-07Makefile: fix 2 typosRandy Dunlap1-2/+2
Fix typos in comments so that they make sense. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2022-05-07kbuild: support W=e to make build abort in case of warningYann Droneaud1-0/+1
When developing new code/feature, CONFIG_WERROR is most often turned off, especially for people using make W=12 to get more warnings. In such case, turning on -Werror temporarily would require switching on CONFIG_WERROR in the configuration, building, then switching off CONFIG_WERROR. For this use case, this patch introduces a new 'e' modifier to W= as a short hand for KCFLAGS+=-Werror" so that -Werror got added to the kernel (built-in) and modules' CFLAGS. Signed-off-by: Yann Droneaud <ydroneaud@opteya.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2022-05-07kbuild: make *.mod not depend on *.oMasahiro Yamada1-1/+2
The dependency $(obj)/%.mod: $(obj)/%$(mod-prelink-ext).o ... exists because *.mod files previously contained undefined symbols, which are computed from *.o files when CONFIG_TRIM_UNUSED_KSYMS=y. Now that the undefined symbols are put into separate *.usyms files, there is no reason to make *.mod depend on *.o files. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2022-05-07kbuild: split the second line of *.mod into *.usymsMasahiro Yamada1-1/+1
The *.mod files have two lines; the first line lists the member objects of the module, and the second line, if CONFIG_TRIM_UNUSED_KSYMS=y, lists the undefined symbols. Currently, we generate *.mod after constructing composite modules, otherwise, we cannot compute the second line. No prerequisite is required to print the first line. They are orthogonal. Splitting them into separate commands will ease further cleanups. This commit splits the list of undefined symbols out to *.usyms files. Previously, the list of undefined symbols ended up with a very long line, but now it has one symbol per line. Use sed like we did before commit 7d32358be8ac ("kbuild: avoid split lines in .mod files"). Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
2022-05-01Linux 5.18-rc5Linus Torvalds1-1/+1
2022-04-25Linux 5.18-rc4Linus Torvalds1-1/+1
2022-04-22objtool: Add CONFIG_OBJTOOLJosh Poimboeuf1-1/+1
Now that stack validation is an optional feature of objtool, add CONFIG_OBJTOOL and replace most usages of CONFIG_STACK_VALIDATION with it. CONFIG_STACK_VALIDATION can now be considered to be frame-pointer specific. CONFIG_UNWINDER_ORC is already inherently valid for live patching, so no need to "validate" it. Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Miroslav Benes <mbenes@suse.cz> Link: https://lkml.kernel.org/r/939bf3d85604b2a126412bf11af6e3bd3b872bcb.1650300597.git.jpoimboe@redhat.com
2022-04-17Linux 5.18-rc3Linus Torvalds1-1/+1
2022-04-11Linux 5.18-rc2Linus Torvalds1-1/+1
2022-04-05kbuild: Allow kernel installation packaging to override pkg-configChun-Tse Shao1-1/+2
Add HOSTPKG_CONFIG to allow tooling that builds the kernel to override what pkg-config and parameters are used. Signed-off-by: Chun-Tse Shao <ctshao@google.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2022-04-04Linux 5.18-rc1Linus Torvalds1-2/+2
2022-04-01kbuild: Remove '-mno-global-merge'Nathan Chancellor1-4/+0
This flag is specific to clang, where it is only used by the 32-bit and 64-bit ARM backends. In certain situations, the presence of this flag will cause a warning, as shown by commit 6580c5c18fb3 ("um: clang: Strip out -mno-global-merge from USER_CFLAGS"). Since commit 61163efae020 ("kbuild: LLVMLinux: Add Kbuild support for building kernel with Clang") that added this flag back in 2014, there have been quite a few changes to the GlobalMerge pass in LLVM. Building several different ARCH=arm and ARCH=arm64 configurations with LLVM 11 (minimum) and 15 (current main version) with this flag removed (i.e., with the default of '-mglobal-merge') reveals no modpost warnings, so it is likely that the issue noted in the comment is no longer relevant due to changes in LLVM or modpost, meaning this flag can be removed. If any new warnings show up that are a result of the removal of this flag, it can be added back under arch/arm{,64}/Makefile to avoid warnings on other architectures. Signed-off-by: Nathan Chancellor <nathan@kernel.org> Tested-by: David Gow <davidgow@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> Reviewed-by: Sedat Dilek <sedat.dilek@gmail.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2022-03-31Merge tag 'kbuild-v5.18-v2' of ↵Linus Torvalds1-19/+27
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild updates from Masahiro Yamada: - Add new environment variables, USERCFLAGS and USERLDFLAGS to allow additional flags to be passed to user-space programs. - Fix missing fflush() bugs in Kconfig and fixdep - Fix a minor bug in the comment format of the .config file - Make kallsyms ignore llvm's local labels, .L* - Fix UAPI compile-test for cross-compiling with Clang - Extend the LLVM= syntax to support LLVM=<suffix> form for using a particular version of LLVm, and LLVM=<prefix> form for using custom LLVM in a particular directory path. - Clean up Makefiles * tag 'kbuild-v5.18-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: kbuild: Make $(LLVM) more flexible kbuild: add --target to correctly cross-compile UAPI headers with Clang fixdep: use fflush() and ferror() to ensure successful write to files arch: syscalls: simplify uapi/kapi directory creation usr/include: replace extra-y with always-y certs: simplify empty certs creation in certs/Makefile certs: include certs/signing_key.x509 unconditionally kallsyms: ignore all local labels prefixed by '.L' kconfig: fix missing '# end of' for empty menu kconfig: add fflush() before ferror() check kbuild: replace $(if A,A,B) with $(or A,B) kbuild: Add environment variables for userprogs flags kbuild: unify cmd_copy and cmd_shipped
2022-03-31kbuild: Make $(LLVM) more flexibleNathan Chancellor1-10/+16
The LLVM make variable allows a developer to quickly switch between the GNU and LLVM tools. However, it does not handle versioned binaries, such as the ones shipped by Debian, as LLVM=1 just defines the tool variables with the unversioned binaries. There was some discussion during the review of the patch that introduces LLVM=1 around versioned binaries, ultimately coming to the conclusion that developers can just add the folder that contains the unversioned binaries to their PATH, as Debian's versioned suffixed binaries are really just symlinks to the unversioned binaries in /usr/lib/llvm-#/bin: $ realpath /usr/bin/clang-14 /usr/lib/llvm-14/bin/clang $ PATH=/usr/lib/llvm-14/bin:$PATH make ... LLVM=1 However, that can be cumbersome to developers who are constantly testing series with different toolchains and versions. It is simple enough to support these versioned binaries directly in the Kbuild system by allowing the developer to specify the version suffix with LLVM=, which is shorter than the above suggestion: $ make ... LLVM=-14 It does not change the meaning of LLVM=1 (which will continue to use unversioned binaries) and it does not add too much additional complexity to the existing $(LLVM) code, while allowing developers to quickly test their series with different versions of the whole LLVM suite of tools. Some developers may build LLVM from source but not add the binaries to their PATH, as they may not want to use that toolchain systemwide. Support those developers by allowing them to supply the directory that the LLVM tools are available in, as it is no more complex to support than the version suffix change above. $ make ... LLVM=/path/to/llvm/ Update and reorder the documentation to reflect these new additions. At the same time, notate that LLVM=0 is not the same as just omitting it altogether, which has confused people in the past. Link: https://lore.kernel.org/r/20200317215515.226917-1-ndesaulniers@google.com/ Link: https://lore.kernel.org/r/20220224151322.072632223@infradead.org/ Suggested-by: Masahiro Yamada <masahiroy@kernel.org> Suggested-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2022-03-26Merge tag 'array-bounds-v5.18-rc1' of ↵Linus Torvalds1-2/+0
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux Pull array-bounds updates from Kees Cook: "This enables -Warray-bounds and -Wzero-length-bounds, now that the many bug fixes have landed all over the place in the kernel, and in GCC itself[1]. A couple fixes[2] for known corner-case issues currently live in my "pending-fixes" tree which I'm expecting to send next week if other maintainers still haven't picked them up. I'm also expecting we can enable -Wstringop-overflow next cycle, as there are only a few stragglers[3], but it might even be possible for this release" [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 [2] https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=for-next/pending-fixes&id=2d253138910eec553fc706379914243d71de9b85 [3] https://github.com/KSPP/linux/issues/181 * tag 'array-bounds-v5.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: Makefile: Enable -Wzero-length-bounds Makefile: Enable -Warray-bounds
2022-03-25Merge tag 'kbuild-gnu11-v5.18' of ↵Linus Torvalds1-3/+4
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild update for C11 language base from Masahiro Yamada: "Kbuild -std=gnu11 updates for v5.18 Linus pointed out the benefits of C99 some years ago, especially variable declarations in loops [1]. At that time, we were not ready for the migration due to old compilers. Recently, Jakob Koschel reported a bug in list_for_each_entry(), which leaks the invalid pointer out of the loop [2]. In the discussion, we agreed that the time had come. Now that GCC 5.1 is the minimum compiler version, there is nothing to prevent us from going to -std=gnu99, or even straight to -std=gnu11. Discussions for a better list iterator implementation are ongoing, but this patch set must land first" [1] https://lore.kernel.org/all/CAHk-=wgr12JkKmRd21qh-se-_Gs69kbPgR9x4C+Es-yJV2GLkA@mail.gmail.com/ [2] https://lore.kernel.org/lkml/86C4CE7D-6D93-456B-AA82-F8ADEACA40B7@gmail.com/ * tag 'kbuild-gnu11-v5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: Kbuild: use -std=gnu11 for KBUILD_USERCFLAGS Kbuild: move to -std=gnu11 Kbuild: use -Wdeclaration-after-statement Kbuild: add -Wno-shift-negative-value where -Wextra is used
2022-03-20Linux 5.17Linus Torvalds1-1/+1
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-03-13Linux 5.17-rc8Linus Torvalds1-1/+1
2022-03-13Kbuild: use -std=gnu11 for KBUILD_USERCFLAGSArnd Bergmann1-1/+1
As we change the C language standard for the kernel from gnu89 to gnu11, it makes sense to also update the version for user space compilation. Some users have older native compilers than what they use for kernel builds, so I considered using gnu99 as the default version for wider compatibility with gcc-4.6 and earlier. However, testing with older compilers showed that we already require HOSTCC version 5.1 as well because a lot of host tools include linux/compiler.h that uses __has_attribute(): CC tools/objtool/exec-cmd.o In file included from tools/include/linux/compiler_types.h:36:0, from tools/include/linux/compiler.h:5, from exec-cmd.c:2: tools/include/linux/compiler-gcc.h:19:5: error: "__has_attribute" is not defined [-Werror=undef] Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2022-03-13Kbuild: move to -std=gnu11Arnd Bergmann1-2/+2
During a patch discussion, Linus brought up the option of changing the C standard version from gnu89 to gnu99, which allows using variable declaration inside of a for() loop. While the C99, C11 and later standards introduce many other features, most of these are already available in gnu89 as GNU extensions as well. An earlier attempt to do this when gcc-5 started defaulting to -std=gnu11 failed because at the time that caused warnings about designated initializers with older compilers. Now that gcc-5.1 is the minimum compiler version used for building kernels, that is no longer a concern. Similarly, the behavior of 'inline' functions changes between gnu89 using gnu_inline behavior and gnu11 using standard c99+ behavior, but this was taken care of by defining 'inline' to include __attribute__((gnu_inline)) in order to allow building with clang a while ago. Nathan Chancellor reported a new -Wdeclaration-after-statement warning that appears in a system header on arm, this still needs a workaround. The differences between gnu99, gnu11, gnu1x and gnu17 are fairly minimal and mainly impact warnings at the -Wpedantic level that the kernel never enables. Between these, gnu11 is the newest version that is supported by all supported compiler versions, though it is only the default on gcc-5, while all other supported versions of gcc or clang default to gnu1x/gnu17. Link: https://lore.kernel.org/lkml/CAHk-=wiyCH7xeHcmiFJ-YgXUy2Jaj7pnkdKpcovt8fYbVFW3TA@mail.gmail.com/ Link: https://github.com/ClangBuiltLinux/linux/issues/1603 Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Acked-by: Marco Elver <elver@google.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Acked-by: David Sterba <dsterba@suse.com> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> Reviewed-by: Alex Shi <alexs@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2022-03-13Kbuild: use -Wdeclaration-after-statementMark Rutland1-1/+2
The kernel is moving from using `-std=gnu89` to `-std=gnu11`, permitting the use of additional C11 features such as for-loop initial declarations. One contentious aspect of C99 is that it permits mixed declarations and code, and for now at least, it seems preferable to enforce that declarations must come first. These warnings were already enabled in the kernel itself, but not for KBUILD_USERCFLAGS or the compat VDSO on arch/arm64, which uses a separate set of CFLAGS. This patch fixes an existing violation in modpost.c, which is not reported because of the missing flag in KBUILD_USERCFLAGS: | scripts/mod/modpost.c: In function ‘match’: | scripts/mod/modpost.c:837:3: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] | 837 | const char *endp = p + strlen(p) - 1; | | ^~~~~ Signed-off-by: Mark Rutland <mark.rutland@arm.com> [arnd: don't add a duplicate flag to the default set, update changelog] Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> # LLVM/Clang v13.0.0 (x86-64) Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2022-03-07Linux 5.17-rc7Linus Torvalds1-1/+1
2022-02-28Linux 5.17-rc6Linus Torvalds1-1/+1
2022-02-21Linux 5.17-rc5Linus Torvalds1-1/+1
2022-02-15kbuild: replace $(if A,A,B) with $(or A,B)Masahiro Yamada1-4/+4
$(or ...) is available since GNU Make 3.81, and useful to shorten the code in some places. Covert as follows: $(if A,A,B) --> $(or A,B) This patch also converts: $(if A, A, B) --> $(or A, B) Strictly speaking, the latter is not an equivalent conversion because GNU Make keeps spaces after commas; if A is not empty, $(if A, A, B) expands to " A", while $(or A, B) expands to "A". Anyway, preceding spaces are not significant in the code hunks I touched. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
2022-02-14kbuild: Add environment variables for userprogs flagsElliot Berman1-4/+6
Allow additional arguments be passed to userprogs compilation. Reproducible clang builds need to provide a sysroot and gcc path to ensure the same toolchain is used across hosts. KCFLAGS is not currently used for any user programs compilation, so add new USERCFLAGS and USERLDFLAGS which serves similar purpose as HOSTCFLAGS/HOSTLDFLAGS. Clang might detect GCC installation on hosts which have it installed to a default location in /. With addition of these environment variables, you can specify flags such as: $ make USERCFLAGS=--sysroot=/path/to/sysroot This can also be used to specify different sysroots such as musl or bionic which may be installed on the host in paths that the compiler may not search by default. Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Fangrui Song <maskray@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2022-02-14Makefile: Enable -Wzero-length-boundsKees Cook1-1/+0
With all known internal zero-length accesses fixed, it is possible to enable -Wzero-length-bounds globally. Since this is included by default in -Warray-bounds, we just need to stop disabling it. Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: linux-kbuild@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Link: https://lore.kernel.org/lkml/CAKwvOd=bcs5W6eEDXGn5ROR2EuMiSp_2e6sLFxak=KK6yLWcvA@mail.gmail.com
2022-02-14Makefile: Enable -Warray-boundsKees Cook1-1/+0
With the recent fixes for flexible arrays and expanded FORTIFY_SOURCE coverage, it is now possible to enable -Warray-bounds. Since both GCC and Clang include -Warray-bounds in -Wall, adjust the Makefile to just stop disabling it. Note that this option can be conservative in its warnings (which is done at casting time rather than access time), but this is reasonable since the cast variables may be accessed out of a scope where the true size of the original object can't be evaluated. These handful of false positives (which are arguably bad casts and can be easily avoided), are worth dealing with because of the many places where this option has helped identify missed bounds checks and even accesses done against cases where a NULL pointer could be reached. https://github.com/KSPP/linux/issues/109 https://github.com/KSPP/linux/issues/151 Cc: Arnd Bergmann <arnd@arndb.de> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: linux-kbuild@vger.kernel.org Co-developed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Kees Cook <keescook@chromium.org>
2022-02-13Linux 5.17-rc4Linus Torvalds1-2/+2