summaryrefslogtreecommitdiff
path: root/scripts
AgeCommit message (Collapse)AuthorFilesLines
2019-08-29kbuild: remove unneeded comments and code from scripts/basic/MakefileMasahiro Yamada1-12/+2
Kbuild descends into scripts/basic/ even before the Kconfig. I do not expect any other host programs added to this Makefile. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-08-25kbuild: pkg: rename scripts/package/Makefile to scripts/Makefile.packageMasahiro Yamada1-1/+4
scripts/package/Makefile does not use $(obj) or $(src) at all. It actually generates files and directories in the top of $(objtree). I do not see much sense in descending into scripts/package/. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-08-25kbuild: pkg: add package targets to PHONY instead of FORCEMasahiro Yamada1-9/+20
These are not real targets. Adding them to PHONY is preferred. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-08-25kbuild: pkg: clean up package files/dirs from the top MakefileMasahiro Yamada2-10/+1
I am not a big fan of the $(objtree)/ hack for clean-files/clean-dirs. These are created in the top of $(objtree), so let's clean them up from the top Makefile. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-08-21merge_config.sh: Check error codes from makeMark Brown1-5/+5
When we execute make after merging the configurations we ignore any errors it produces causing whatever is running merge_config.sh to be unaware of any failures. This issue was noticed by Guillaume Tucker while looking at problems with testing of clang only builds in KernelCI which caused Kbuild to be unable to find a working host compiler. This implementation was suggested by Yamada-san. Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reported-by: Guillaume Tucker <guillaume.tucker@collabora.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-08-21kbuild: move modkern_{c,a}flags to Makefile.lib from Makefile.buildMasahiro Yamada3-16/+15
Makefile.lib is included by Makefile.modfinal as well as Makefile.build. Move modkern_cflags to Makefile.lib in order to simplify cmd_cc_o_c in Makefile.modfinal. Move modkern_cflags as well for consistency. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-08-21kbuild: add CONFIG_ASM_MODVERSIONSMasahiro Yamada1-6/+1
Add CONFIG_ASM_MODVERSIONS. This allows to remove one if-conditional nesting in scripts/Makefile.build. scripts/Makefile.build is run every time Kbuild descends into a sub-directory. So, I want to avoid $(wildcard ...) evaluation where possible although computing $(wildcard ...) is so cheap that it may not make measurable performance difference. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
2019-08-21kbuild: split final module linking out into Makefile.modfinalMasahiro Yamada2-68/+71
I think splitting the modpost and linking modules into separate Makefiles will be useful especially when more complex build steps come in. The main motivation of this commit is to integrate the proposed klp-convert feature cleanly. I moved the logging 'Building modules, stage 2.' to Makefile.modpost to avoid the code duplication although I do not know whether or not this message is needed in the first place. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-08-21kbuild: rebuild modules when module linker scripts are updatedMasahiro Yamada1-2/+3
Currently, the timestamp of module linker scripts are not checked. Add them to the dependency of modules so they are correctly rebuilt. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-08-21kbuild: make single targets work more correctlyMasahiro Yamada1-6/+39
Currently, the single target build directly descends into the directory of the target. For example, $ make foo/bar/baz.o ... directly descends into foo/bar/. On the other hand, the normal build usually descends one directory at a time, i.e. descends into foo/, and then foo/bar/. This difference causes some problems. [1] miss subdir-asflags-y, subdir-ccflags-y in upper Makefiles The options in subdir-{as,cc}flags-y take effect in the current and its sub-directories. In other words, they are inherited downward. In the example above, the single target will miss subdir-{as,cc}flags-y if they are defined in foo/Makefile. [2] could be built in a different directory As Documentation/kbuild/modules.rst section 4.3 says, Kbuild can handle files that are spread over several sub-directories. The build rule of foo/bar/baz.o may not necessarily be specified in foo/bar/Makefile. It might be specifies in foo/Makefile as follows: [foo/Makefile] obj-y := bar/baz.o This often happens when a module is so big that its source files are divided into sub-directories. In this case, there is no Makefile in the foo/bar/ directory, yet the single target descends into foo/bar/, then fails due to the missing Makefile. You can still do 'make foo/bar/' for partial building, but cannot do 'make foo/bar/baz.s'. I believe the single target '%.s' is a useful feature for inspecting the compiler output. Some modules work around this issue by putting an empty Makefile in every sub-directory. This commit fixes those problems by making the single target build descend in the same way as the normal build does. Another change is the single target build will observe the CONFIG options. Previously, it allowed users to build the foo.o even when the corresponding CONFIG_FOO is disabled: obj-$(CONFIG_FOO) += foo.o In the new behavior, the single target build will just fail and show "No rule to make target ..." (or "Nothing to be done for ..." if the stale object already exists, but cannot be updated). The disadvantage of this commit is the build speed. Now that the single target build visits every directory and parses lots of Makefiles, it is slower than before. (But, I hope it will not be too slow.) Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-08-21kbuild: Parameterize kallsyms generation and correct reportingKees Cook1-19/+19
When kallsyms generation happens, temporary vmlinux outputs are linked but the quiet make output didn't report it, giving the impression that the prior command is taking longer than expected. Instead, report the linking step explicitly. While at it, this consolidates the repeated "kallsyms generation step" into a single function and removes the existing copy/pasting. Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-08-21kbuild: re-implement detection of CONFIG options leaked to user-spaceMasahiro Yamada1-0/+72
scripts/headers_check.pl can detect references to CONFIG options in exported headers, but it has been disabled for more than a decade. Reverting commit 7e3fa5614117 ("kbuild: drop check for CONFIG_ in headers_check") would emit the following warnings for headers_check on x86: usr/include/mtd/ubi-user.h:283: leaks CONFIG_MTD_UBI_BEB_LIMIT to userspace where it is not valid usr/include/linux/cm4000_cs.h:26: leaks CONFIG_COMPAT to userspace where it is not valid usr/include/linux/pkt_cls.h:301: leaks CONFIG_NET_CLS_ACT to userspace where it is not valid usr/include/linux/videodev2.h:2465: leaks CONFIG_VIDEO_ADV_DEBUG to userspace where it is not valid usr/include/linux/bpf.h:249: leaks CONFIG_EFFICIENT_UNALIGNED_ACCESS to userspace where it is not valid usr/include/linux/bpf.h:819: leaks CONFIG_CGROUP_NET_CLASSID to userspace where it is not valid usr/include/linux/bpf.h:1011: leaks CONFIG_IP_ROUTE_CLASSID to userspace where it is not valid usr/include/linux/bpf.h:1742: leaks CONFIG_BPF_KPROBE_OVERRIDE to userspace where it is not valid usr/include/linux/bpf.h:1747: leaks CONFIG_FUNCTION_ERROR_INJECTION to userspace where it is not valid usr/include/linux/bpf.h:1936: leaks CONFIG_XFRM to userspace where it is not valid usr/include/linux/bpf.h:2184: leaks CONFIG_BPF_LIRC_MODE2 to userspace where it is not valid usr/include/linux/bpf.h:2210: leaks CONFIG_BPF_LIRC_MODE2 to userspace where it is not valid usr/include/linux/bpf.h:2227: leaks CONFIG_SOCK_CGROUP_DATA to userspace where it is not valid usr/include/linux/bpf.h:2311: leaks CONFIG_NET to userspace where it is not valid usr/include/linux/bpf.h:2348: leaks CONFIG_NET to userspace where it is not valid usr/include/linux/bpf.h:2422: leaks CONFIG_BPF_LIRC_MODE2 to userspace where it is not valid usr/include/linux/bpf.h:2528: leaks CONFIG_NET to userspace where it is not valid usr/include/linux/pktcdvd.h:37: leaks CONFIG_CDROM_PKTCDVD_WCACHE to userspace where it is not valid usr/include/linux/hw_breakpoint.h:27: leaks CONFIG_HAVE_MIXED_BREAKPOINTS_REGS to userspace where it is not valid usr/include/linux/raw.h:17: leaks CONFIG_MAX_RAW_DEVS to userspace where it is not valid usr/include/linux/elfcore.h:62: leaks CONFIG_BINFMT_ELF_FDPIC to userspace where it is not valid usr/include/linux/eventpoll.h:82: leaks CONFIG_PM_SLEEP to userspace where it is not valid usr/include/linux/atmdev.h:104: leaks CONFIG_COMPAT to userspace where it is not valid usr/include/asm-generic/unistd.h:651: leaks CONFIG_MMU to userspace where it is not valid usr/include/asm-generic/bitsperlong.h:9: leaks CONFIG_64BIT to userspace where it is not valid usr/include/asm-generic/fcntl.h:119: leaks CONFIG_64BIT to userspace where it is not valid usr/include/asm/auxvec.h:14: leaks CONFIG_IA32_EMULATION to userspace where it is not valid usr/include/asm/e820.h:14: leaks CONFIG_NODES_SHIFT to userspace where it is not valid usr/include/asm/e820.h:39: leaks CONFIG_X86_PMEM_LEGACY to userspace where it is not valid usr/include/asm/e820.h:49: leaks CONFIG_INTEL_TXT to userspace where it is not valid usr/include/asm/mman.h:7: leaks CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS to userspace where it is not valid Most of these are false positives because scripts/headers_check.pl parses comment lines. It is also false negative. arch/x86/include/uapi/asm/auxvec.h contains CONFIG_IA32_EMULATION and CONFIG_X86_64, but the only former is reported. It would be possible to fix scripts/headers_check.pl, of course. However, we already have some duplicated checks between headers_check and CONFIG_UAPI_HEADER_TEST. At this moment of time, there are still dozens of headers excluded from the header test (usr/include/Makefile), but we might be able to remove headers_check eventually. I re-implemented it in scripts/headers_install.sh by using sed because the most of code in scripts/headers_install.sh is written in sed. This patch works like this: [1] Run scripts/unifdef first because we need to drop the code surrounded by #ifdef __KERNEL__ ... #endif [2] Remove all C style comments. The sed code is somewhat complicated since we need to deal with both single and multi line comments. Precisely speaking, a comment block is replaced with a space just in case. CONFIG_FOO/* this is a comment */CONFIG_BAR should be converted into: CONFIG_FOO CONFIG_BAR instead of: CONFIG_FOOCONFIG_BAR [3] Match CONFIG_... pattern. It correctly matches to all CONFIG options that appear in a single line. After this commit, this would detect the following warnings, all of which are real ones. warning: include/uapi/linux/pktcdvd.h: leak CONFIG_CDROM_PKTCDVD_WCACHE to user-space warning: include/uapi/linux/hw_breakpoint.h: leak CONFIG_HAVE_MIXED_BREAKPOINTS_REGS to user-space warning: include/uapi/linux/raw.h: leak CONFIG_MAX_RAW_DEVS to user-space warning: include/uapi/linux/elfcore.h: leak CONFIG_BINFMT_ELF_FDPIC to user-space warning: include/uapi/linux/eventpoll.h: leak CONFIG_PM_SLEEP to user-space warning: include/uapi/linux/atmdev.h: leak CONFIG_COMPAT to user-space warning: include/uapi/asm-generic/fcntl.h: leak CONFIG_64BIT to user-space warning: arch/x86/include/uapi/asm/auxvec.h: leak CONFIG_IA32_EMULATION to user-space warning: arch/x86/include/uapi/asm/auxvec.h: leak CONFIG_X86_64 to user-space warning: arch/x86/include/uapi/asm/mman.h: leak CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS to user-space However, it is not nice to show them right now. I created a list of existing leakages. They are not warned, but a new leakage will be blocked by the 0-day bot. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Sam Ravnborg <sam@ravnborg.org>
2019-08-14kbuild: fix modkern_aflags implementationMasahiro Yamada1-4/+3
For the single target building %.symtypes from %.S, $(a_flags) is expanded into the _KERNEL flags even if the object is a part of a module. $(real-obj-m:.o=.symtypes): modkern_aflags := $(KBUILD_AFLAGS_MODULE) $(AFLAGS_MODULE) ... would fix the issue, but it is not nice to duplicate similar code for every suffix. Implement modkern_aflags in the same way as modkern_cflags. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-08-14kbuild: refactor part-of-module moreMasahiro Yamada1-2/+1
Make it even shorter. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-08-14kbuild: treat an object as multi-used when $(foo-) is setMasahiro Yamada1-5/+5
Currently, Kbuild treats an object as multi-used when any of $(foo-objs), $(foo-y), $(foo-m) is set. It makes more sense to check $(foo-) as well. In the context of foo-$(CONFIG_FOO_FEATURE1), CONFIG_FOO_FEATURE1 could be unset. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-08-13kbuild: add [M] marker for build log of *.mod.oMasahiro Yamada1-1/+1
This builds module objects, so [M] makes sense. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-08-13Kbuild: Handle PREEMPT_RT for version string and magicThomas Gleixner2-2/+4
Update the build scripts and the version magic to reflect when CONFIG_PREEMPT_RT is enabled in the same way as CONFIG_PREEMPT is treated. The resulting version strings: Linux m 5.3.0-rc1+ #100 SMP Fri Jul 26 ... Linux m 5.3.0-rc1+ #101 SMP PREEMPT Fri Jul 26 ... Linux m 5.3.0-rc1+ #102 SMP PREEMPT_RT Fri Jul 26 ... The module vermagic: 5.3.0-rc1+ SMP mod_unload modversions 5.3.0-rc1+ SMP preempt mod_unload modversions 5.3.0-rc1+ SMP preempt_rt mod_unload modversions Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-08-13kbuild: move flex and bison rules to Makefile.hostMasahiro Yamada2-16/+17
Flex and bison are used for kconfig, dtc, genksyms, all of which are host programs. I never imagine the kernel embeds a parser or a lexer. Move the flex and bison rules to scripts/Makefile.host. This file is included only when hostprogs-y etc. is present in the Makefile in the directory. So, parsing these rules are skipped in most of directories. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-08-13kbuild: make bison create C file and header in a single pattern ruleMasahiro Yamada2-17/+4
We generally expect bison to create not only a C file, but also a header, which will be included from the lexer. Currently, Kbuild generates them in separate rules. So, for instance, when building Kconfig, you will notice bison is invoked twice: HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/confdata.o HOSTCC scripts/kconfig/expr.o LEX scripts/kconfig/lexer.lex.c YACC scripts/kconfig/parser.tab.h HOSTCC scripts/kconfig/lexer.lex.o YACC scripts/kconfig/parser.tab.c HOSTCC scripts/kconfig/parser.tab.o HOSTCC scripts/kconfig/preprocess.o HOSTCC scripts/kconfig/symbol.o HOSTLD scripts/kconfig/conf Make handles such cases nicely in pattern rules [1]. Merge the two rules so that one invokcation of bison can generate both of them. HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/confdata.o HOSTCC scripts/kconfig/expr.o LEX scripts/kconfig/lexer.lex.c YACC scripts/kconfig/parser.tab.[ch] HOSTCC scripts/kconfig/lexer.lex.o HOSTCC scripts/kconfig/parser.tab.o HOSTCC scripts/kconfig/preprocess.o HOSTCC scripts/kconfig/symbol.o HOSTLD scripts/kconfig/conf [1] Pattern rule GNU Make manual says: "Pattern rules may have more than one target. Unlike normal rules, this does not act as many different rules with the same prerequisites and recipe. If a pattern rule has multiple targets, make knows that the rule's recipe is responsible for making all of the targets. The recipe is executed only once to make all the targets. When searching for a pattern rule to match a target, the target patterns of a rule other than the one that matches the target in need of a rule are incidental: make worries only about giving a recipe and prerequisites to the file presently in question. However, when this file's recipe is run, the other targets are marked as having been updated themselves." https://www.gnu.org/software/make/manual/html_node/Pattern-Intro.html Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-08-13kbuild: use $(basename ...) for cmd_asn1_compilerMasahiro Yamada1-2/+2
$(basename ...) trims the last suffix. Using it is more intuitive in my opinion. This pattern rule makes %.asn1.c and %.asn1.h at the same time. Previously, the short log showed only either of them, depending on the target file in question. To clarify that two files are being generated by the single recipe, I changed the log as follows: Before: ASN.1 crypto/asymmetric_keys/x509.asn1.c After: ASN.1 crypto/asymmetric_keys/x509.asn1.[ch] Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-08-13kbuild: Fail if gold linker is detectedThomas Gleixner1-0/+3
The gold linker has known issues of failing the build both in random and in predictible ways: - The x86/X32 VDSO build fails with: arch/x86/entry/vdso/vclock_gettime-x32.o:vclock_gettime.c:function do_hres: error: relocation overflow: reference to 'hvclock_page' That's a known issue for years and the usual workaround is to disable CONFIG_X86_32 - A recent build failure is caused by turning a relocation into an absolute one for unknown reasons. See link below. - There are a couple of gold workarounds applied already, but reports about broken builds with ld.gold keep coming in on a regular base and in most cases the root cause is unclear. In context of the most recent fail H.J. stated: "Since building a workable kernel for different kernel configurations isn't a requirement for gold, I don't recommend gold for kernel." So instead of dealing with attempts to duct tape gold support without understanding the root cause and without support from the gold folks, fail the build when gold is detected. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/CAMe9rOqMqkQ0LNpm25yE_Yt0FKp05WmHOrwc0aRDb53miFKM+w@mail.gmail.com Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-08-13modpost: check for static EXPORT_SYMBOL* functionsDenis Efremov1-0/+32
This patch adds a check to warn about static EXPORT_SYMBOL* functions during the modpost. In most of the cases, a static symbol marked for exporting is an odd combination that should be fixed either by deleting the exporting mark or by removing the static attribute and adding the appropriate declaration to headers. This check could help to detect the following problems: 1. 550113d4e9f5 ("i2c: add newly exported functions to the header, too") 2. 54638c6eaf44 ("net: phy: make exported variables non-static") 3. 98ef2046f28b ("mm: remove the exporting of totalram_pages") 4. 73df167c819e ("s390/zcrypt: remove the exporting of ap_query_configuration") 5. a57caf8c527f ("sunrpc/cache: remove the exporting of cache_seq_next") 6. e4e4730698c9 ("crypto: skcipher - remove the exporting of skcipher_walk_next") 7. 14b4c48bb1ce ("gve: Remove the exporting of gve_probe") 8. 9b79ee9773a8 ("scsi: libsas: remove the exporting of sas_wait_eh") 9. ... The build time impact is very limited and is almost at the unnoticeable level (< 1 sec). Acked-by: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Denis Efremov <efremov@linux.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-08-09kbuild: show hint if subdir-y/m is used to visit module MakefileMasahiro Yamada1-0/+7
Since commit ff9b45c55b26 ("kbuild: modpost: read modules.order instead of $(MODVERDIR)/*.mod"), a module is no longer built in the following pattern: [Makefile] subdir-y := some-module [some-module/Makefile] obj-m := some-module.o You cannot write Makefile this way in upstream because modules.order is not correctly generated. subdir-y is used to descend to a sub-directory that builds tools, device trees, etc. For external modules, the modules order does not matter. So, the Makefile above was known to work. I believe the Makefile should be re-written as follows: [Makefile] obj-m := some-module/ [some-module/Makefile] obj-m := some-module.o However, people will have no idea if their Makefile suddenly stops working. In fact, I received questions from multiple people. Show a warning for a while if obj-m is specified in a Makefile visited by subdir-y or subdir-m. I touched the %/ rule to avoid false-positive warnings for the single target. Cc: Jan Kiszka <jan.kiszka@siemens.com> Cc: Tom Stonecypher <thomas.edwardx.stonecypher@intel.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Tested-by: Jan Kiszka <jan.kiszka@siemens.com>
2019-08-09kbuild: generate modules.order only in directories visited by obj-y/mMasahiro Yamada1-1/+2
The modules.order files in directories visited by the chain of obj-y or obj-m are merged to the upper-level ones, and become parts of the top-level modules.order. On the other hand, there is no need to generate modules.order in directories visited by subdir-y or subdir-m since they would become orphan anyway. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-08-09kbuild: fix false-positive need-builtin calculationMasahiro Yamada1-1/+2
The current implementation of need-builtin is false-positive, for example, in the following Makefile: obj-m := foo/ obj-y := foo/bar/ ..., where foo/built-in.a is not required. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-08-09kbuild: revive single target %.koMasahiro Yamada1-4/+2
I removed the single target %.ko in commit ff9b45c55b26 ("kbuild: modpost: read modules.order instead of $(MODVERDIR)/*.mod") because the modpost stage does not work reliably. For instance, the module dependency, modversion, etc. do not work if we lack symbol information from the other modules. Yet, some people still want to build only one module in their interest, and it may be still useful if it is used within those limitations. Fixes: ff9b45c55b26 ("kbuild: modpost: read modules.order instead of $(MODVERDIR)/*.mod") Reported-by: Don Brace <don.brace@microsemi.com> Reported-by: Arend Van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-08-04kconfig: Clear "written" flag to avoid data lossM. Vefa Bicakci1-0/+4
Prior to this commit, starting nconfig, xconfig or gconfig, and saving the .config file more than once caused data loss, where a .config file that contained only comments would be written to disk starting from the second save operation. This bug manifests itself because the SYMBOL_WRITTEN flag is never cleared after the first call to conf_write, and subsequent calls to conf_write then skip all of the configuration symbols due to the SYMBOL_WRITTEN flag being set. This commit resolves this issue by clearing the SYMBOL_WRITTEN flag from all symbols before conf_write returns. Fixes: 8e2442a5f86e ("kconfig: fix missing choice values in auto.conf") Cc: linux-stable <stable@vger.kernel.org> # 4.19+ Signed-off-by: M. Vefa Bicakci <m.v.b@runbox.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-07-31kbuild: Check for unknown options with cc-option usage in Kconfig and clangStephen Boyd1-1/+1
If the particular version of clang a user has doesn't enable -Werror=unknown-warning-option by default, even though it is the default[1], then make sure to pass the option to the Kconfig cc-option command so that testing options from Kconfig files works properly. Otherwise, depending on the default values setup in the clang toolchain we will silently assume options such as -Wmaybe-uninitialized are supported by clang, when they really aren't. A compilation issue only started happening for me once commit 589834b3a009 ("kbuild: Add -Werror=unknown-warning-option to CLANG_FLAGS") was applied on top of commit b303c6df80c9 ("kbuild: compute false-positive -Wmaybe-uninitialized cases in Kconfig"). This leads kbuild to try and test for the existence of the -Wmaybe-uninitialized flag with the cc-option command in scripts/Kconfig.include, and it doesn't see an error returned from the option test so it sets the config value to Y. Then the Makefile tries to pass the unknown option on the command line and -Werror=unknown-warning-option catches the invalid option and breaks the build. Before commit 589834b3a009 ("kbuild: Add -Werror=unknown-warning-option to CLANG_FLAGS") the build works fine, but any cc-option test of a warning option in Kconfig files silently evaluates to true, even if the warning option flag isn't supported on clang. Note: This doesn't change cc-option usages in Makefiles because those use a different rule that includes KBUILD_CFLAGS by default (see the __cc-option command in scripts/Kbuild.incluide). The KBUILD_CFLAGS variable already has the -Werror=unknown-warning-option flag set. Thanks to Doug for pointing out the different rule. [1] https://clang.llvm.org/docs/DiagnosticsReference.html#wunknown-warning-option Cc: Peter Smith <peter.smith@linaro.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Douglas Anderson <dianders@chromium.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-07-31kbuild: modpost: do not parse unnecessary rules for vmlinux modpostMasahiro Yamada2-36/+42
Since commit ff9b45c55b26 ("kbuild: modpost: read modules.order instead of $(MODVERDIR)/*.mod"), 'make vmlinux' emits a warning, like this: $ make defconfig vmlinux [ snip ] LD vmlinux.o cat: modules.order: No such file or directory MODPOST vmlinux.o MODINFO modules.builtin.modinfo KSYM .tmp_kallsyms1.o KSYM .tmp_kallsyms2.o LD vmlinux SORTEX vmlinux SYSMAP System.map When building only vmlinux, KBUILD_MODULES is not set. Hence, the modules.order is not generated. For the vmlinux modpost, it is not necessary at all. Separate scripts/Makefile.modpost for the vmlinux/modules stages. This works more efficiently because the vmlinux modpost does not need to include .*.cmd files. Fixes: ff9b45c55b26 ("kbuild: modpost: read modules.order instead of $(MODVERDIR)/*.mod") Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-07-31kbuild: modpost: remove unnecessary dependency for __modpostMasahiro Yamada1-2/+2
__modpost is a phony target. The dependency on FORCE is pointless. All the objects have been built in the previous stage, so the dependency on the objects are not necessary either. Count the number of modules in a more straightforward way. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-07-31kbuild: modpost: handle KBUILD_EXTRA_SYMBOLS only for external modulesMasahiro Yamada1-1/+1
KBUILD_EXTRA_SYMBOLS makes sense only when building external modules. Moreover, the modpost sets 'external_module' if the -e option is given. I replaced $(patsubst %, -e %,...) with simpler $(addprefix -e,...) while I was here. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-07-31kbuild: modpost: include .*.cmd files only when targets existMasahiro Yamada1-4/+2
If a build rule fails, the .DELETE_ON_ERROR special target removes the target, but does nothing for the .*.cmd file, which might be corrupted. So, .*.cmd files should be included only when the corresponding targets exist. Commit 392885ee82d3 ("kbuild: let fixdep directly write to .*.cmd files") missed to fix up this file. Fixes: 392885ee82d3 ("kbuild: let fixdep directly write to .*.cmd") Cc: <stable@vger.kernel.org> # v5.0+ Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-07-29kbuild: detect missing "WITH Linux-syscall-note" for uapi headersMasahiro Yamada1-0/+6
UAPI headers licensed under GPL are supposed to have exception "WITH Linux-syscall-note" so that they can be included into non-GPL user space application code. Unfortunately, people often miss to add it. Break 'make headers' when any of exported headers lacks the exception note so that the 0-day bot can easily catch it. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-07-28Merge tag 'kbuild-fixes-v5.3' of ↵Linus Torvalds3-7/+2
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild fixes from Masahiro Yamada: - add compile_commands.json to .gitignore - fix false-positive warning from gen_compile_commands.py after allnoconfig build - remove unused code * tag 'kbuild-fixes-v5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: kbuild: remove unused single-used-m gen_compile_commands: lower the entry count threshold .gitignore: Add compilation database file kbuild: remove unused objectify macro
2019-07-27kbuild: remove unused single-used-mMasahiro Yamada1-2/+0
This is unused since commit 9f69a496f100 ("kbuild: split out *.mod out of {single,multi}-used-m rules"). Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-07-27gen_compile_commands: lower the entry count thresholdMasahiro Yamada1-2/+2
Running gen_compile_commands.py after building the kernel with allnoconfig gave this: $ ./scripts/gen_compile_commands.py WARNING: Found 449 entries. Have you compiled the kernel? Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-07-27kbuild: remove unused objectify macroMasahiro Yamada1-3/+0
Commit 415008af3219 ("docs-rst: convert lsm from DocBook to ReST") removed the last users of this macro. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-07-22Merge branch 'pdf_fixes_v1' of https://git.linuxtv.org/mchehab/experimental ↵Jonathan Corbet1-21/+97
into mauro Bring in a set of post-thrashup fixes from Mauro.
2019-07-20Merge tag 'kbuild-v5.3-2' of ↵Linus Torvalds18-87/+119
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull more Kbuild updates from Masahiro Yamada: - match the directory structure of the linux-libc-dev package to that of Debian-based distributions - fix incorrect include/config/auto.conf generation when Kconfig creates it along with the .config file - remove misleading $(AS) from documents - clean up precious tag files by distclean instead of mrproper - add a new coccinelle patch for devm_platform_ioremap_resource migration - refactor module-related scripts to read modules.order instead of $(MODVERDIR)/*.mod files to get the list of created modules - remove MODVERDIR - update list of header compile-test - add -fcf-protection=none flag to avoid conflict with the retpoline flags when CONFIG_RETPOLINE=y - misc cleanups * tag 'kbuild-v5.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: (25 commits) kbuild: add -fcf-protection=none when using retpoline flags kbuild: update compile-test header list for v5.3-rc1 kbuild: split out *.mod out of {single,multi}-used-m rules kbuild: remove 'prepare1' target kbuild: remove the first line of *.mod files kbuild: create *.mod with full directory path and remove MODVERDIR kbuild: export_report: read modules.order instead of .tmp_versions/*.mod kbuild: modpost: read modules.order instead of $(MODVERDIR)/*.mod kbuild: modsign: read modules.order instead of $(MODVERDIR)/*.mod kbuild: modinst: read modules.order instead of $(MODVERDIR)/*.mod scsi: remove pointless $(MODVERDIR)/$(obj)/53c700.ver kbuild: remove duplication from modules.order in sub-directories kbuild: get rid of kernel/ prefix from in-tree modules.{order,builtin} kbuild: do not create empty modules.order in the prepare stage coccinelle: api: add devm_platform_ioremap_resource script kbuild: compile-test headers listed in header-test-m as well kbuild: remove unused hostcc-option kbuild: remove tag files by distclean instead of mrproper kbuild: add --hash-style= and --build-id unconditionally kbuild: get rid of misleading $(AS) from documents ...
2019-07-17kbuild: split out *.mod out of {single,multi}-used-m rulesMasahiro Yamada1-9/+13
Currently, *.mod is created as a side-effect of obj-m. Split out *.mod as a dedicated build rule, which allows to unify the %.c -> %.o rule, and remove the single-used-m rule. This also makes the incremental build of allmodconfig faster because it saves $(NM) invocation when there is no change in the module. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-07-17kbuild: remove the first line of *.mod filesMasahiro Yamada3-11/+6
The current format of *.mod is like this: line 1: directory path to the .ko file line 2: a list of objects linked into this module line 3: unresolved symbols (only when CONFIG_TRIM_UNUSED_KSYMS=y) Now that *.mod and *.ko are created in the same directory, the line 1 provides no valuable information. It can be derived by replacing the extension .mod with .ko. In fact, nobody uses the first line any more. Cut down the first line. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-07-17kbuild: create *.mod with full directory path and remove MODVERDIRMasahiro Yamada5-37/+14
While descending directories, Kbuild produces objects for modules, but do not link final *.ko files; it is done in the modpost. To keep track of modules, Kbuild creates a *.mod file in $(MODVERDIR) for every module it is building. Some post-processing steps read the necessary information from *.mod files. This avoids descending into directories again. This mechanism was introduced in 2003 or so. Later, commit 551559e13af1 ("kbuild: implement modules.order") added modules.order. So, we can simply read it out to know all the modules with directory paths. This is easier than parsing the first line of *.mod files. $(MODVERDIR) has a flat directory structure, that is, *.mod files are named only with base names. This is based on the assumption that the module name is unique across the tree. This assumption is really fragile. Stephen Rothwell reported a race condition caused by a module name conflict: https://lkml.org/lkml/2019/5/13/991 In parallel building, two different threads could write to the same $(MODVERDIR)/*.mod simultaneously. Non-unique module names are the source of all kind of troubles, hence commit 3a48a91901c5 ("kbuild: check uniqueness of module names") introduced a new checker script. However, it is still fragile in the build system point of view because this race happens before scripts/modules-check.sh is invoked. If it happens again, the modpost will emit unclear error messages. To fix this issue completely, create *.mod with full directory path so that two threads never attempt to write to the same file. $(MODVERDIR) is no longer needed. Since modules with directory paths are listed in modules.order, Kbuild is still able to find *.mod files without additional descending. I also killed cmd_secanalysis; scripts/mod/sumversion.c computes MD4 hash for modules with MODULE_VERSION(). When CONFIG_DEBUG_SECTION_MISMATCH=y, it occurs not only in the modpost stage, but also during directory descending, where sumversion.c may parse stale *.mod files. It would emit 'No such file or directory' warning when an object consisting a module is renamed, or when a single-obj module is turned into a multi-obj module or vice versa. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Nicolas Pitre <nico@fluxnic.net>
2019-07-17kbuild: export_report: read modules.order instead of .tmp_versions/*.modMasahiro Yamada1-6/+5
Towards the goal of removing MODVERDIR aka .tmp_versions, read out modules.order to get the list of modules to be processed. This is simpler than parsing *.mod files in .tmp_versions. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-07-17kbuild: modpost: read modules.order instead of $(MODVERDIR)/*.modMasahiro Yamada1-6/+9
Towards the goal of removing MODVERDIR, read out modules.order to get the list of modules to be processed. This is simpler than parsing *.mod files in $(MODVERDIR). For external modules, $(KBUILD_EXTMOD)/modules.order should be read. I removed the single target %.ko from the top Makefile. To make sure modpost works correctly, vmlinux and the other modules must be built. You cannot build a particular .ko file alone. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-07-17Merge branch 'akpm' (patches from Andrew)Linus Torvalds5-4/+283
Merge more updates from Andrew Morton: "VM: - z3fold fixes and enhancements by Henry Burns and Vitaly Wool - more accurate reclaimed slab caches calculations by Yafang Shao - fix MAP_UNINITIALIZED UAPI symbol to not depend on config, by Christoph Hellwig - !CONFIG_MMU fixes by Christoph Hellwig - new novmcoredd parameter to omit device dumps from vmcore, by Kairui Song - new test_meminit module for testing heap and pagealloc initialization, by Alexander Potapenko - ioremap improvements for huge mappings, by Anshuman Khandual - generalize kprobe page fault handling, by Anshuman Khandual - device-dax hotplug fixes and improvements, by Pavel Tatashin - enable synchronous DAX fault on powerpc, by Aneesh Kumar K.V - add pte_devmap() support for arm64, by Robin Murphy - unify locked_vm accounting with a helper, by Daniel Jordan - several misc fixes core/lib: - new typeof_member() macro including some users, by Alexey Dobriyan - make BIT() and GENMASK() available in asm, by Masahiro Yamada - changed LIST_POISON2 on x86_64 to 0xdead000000000122 for better code generation, by Alexey Dobriyan - rbtree code size optimizations, by Michel Lespinasse - convert struct pid count to refcount_t, by Joel Fernandes get_maintainer.pl: - add --no-moderated switch to skip moderated ML's, by Joe Perches misc: - ptrace PTRACE_GET_SYSCALL_INFO interface - coda updates - gdb scripts, various" [ Using merge message suggestion from Vlastimil Babka, with some editing - Linus ] * emailed patches from Andrew Morton <akpm@linux-foundation.org>: (100 commits) fs/select.c: use struct_size() in kmalloc() mm: add account_locked_vm utility function arm64: mm: implement pte_devmap support mm: introduce ARCH_HAS_PTE_DEVMAP mm: clean up is_device_*_page() definitions mm/mmap: move common defines to mman-common.h mm: move MAP_SYNC to asm-generic/mman-common.h device-dax: "Hotremove" persistent memory that is used like normal RAM mm/hotplug: make remove_memory() interface usable device-dax: fix memory and resource leak if hotplug fails include/linux/lz4.h: fix spelling and copy-paste errors in documentation ipc/mqueue.c: only perform resource calculation if user valid include/asm-generic/bug.h: fix "cut here" for WARN_ON for __WARN_TAINT architectures scripts/gdb: add helpers to find and list devices scripts/gdb: add lx-genpd-summary command drivers/pps/pps.c: clear offset flags in PPS_SETPARAMS ioctl kernel/pid.c: convert struct pid count to refcount_t drivers/rapidio/devices/rio_mport_cdev.c: NUL terminate some strings select: shift restore_saved_sigmask_unless() into poll_select_copy_remaining() select: change do_poll() to return -ERESTARTNOHAND rather than -EINTR ...
2019-07-17kbuild: modsign: read modules.order instead of $(MODVERDIR)/*.modMasahiro Yamada1-2/+1
Towards the goal of removing MODVERDIR, read out modules.order to get the list of modules to be signed. This is simpler than parsing *.mod files in $(MODVERDIR). The modules_sign target is only supported for in-kernel modules. So, this commit does not take care of external modules. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-07-17kbuild: modinst: read modules.order instead of $(MODVERDIR)/*.modMasahiro Yamada1-4/+1
Towards the goal of removing MODVERDIR, read out modules.order to get the list of modules to be installed. This is simpler than parsing *.mod files in $(MODVERDIR). For external modules, $(KBUILD_EXTMOD)/modules.order should be read. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-07-17kbuild: remove duplication from modules.order in sub-directoriesMasahiro Yamada1-6/+3
Currently, only the top-level modules.order drops duplicated entries. The modules.order files in sub-directories potentially contain duplication. To list out the paths of all modules, I want to use modules.order instead of parsing *.mod files in $(MODVERDIR). To achieve this, I want to rip off duplication from modules.order of external modules too. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-07-17kbuild: get rid of kernel/ prefix from in-tree modules.{order,builtin}Masahiro Yamada3-3/+3
Removing the 'kernel/' prefix will make our life easier because we can simply do 'cat modules.order' to get all built modules with full paths. Currently, we parse the first line of '*.mod' files in $(MODVERDIR). Since we have duplicated functionality here, I plan to remove MODVERDIR entirely. In fact, modules.order is generated also for external modules in a broken format. It adds the 'kernel/' prefix to the absolute path of the module, like this: kernel//path/to/your/external/module/foo.ko This is fine for now since modules.order is not used for external modules. However, I want to sanitize the format everywhere towards the goal of removing MODVERDIR. We cannot change the format of installed module.{order,builtin}. So, 'make modules_install' will add the 'kernel/' prefix while copying them to $(MODLIB)/. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-07-17kbuild: do not create empty modules.order in the prepare stageMasahiro Yamada1-1/+1
Currently, $(objtree)/modules.order is touched in two places. In the 'prepare0' rule, scripts/Makefile.build creates an empty modules.order while processing 'obj=.' In the 'modules' rule, the top-level Makefile overwrites it with the correct list of modules. While this might be a good side-effect that modules.order is made empty every time (probably this is not intended functionality), I personally do not like this behavior. Create modules.order only when it is sensible to do so. This avoids creating the following pointless files: scripts/basic/modules.order scripts/dtc/modules.order scripts/gcc-plugins/modules.order scripts/genksyms/modules.order scripts/mod/modules.order scripts/modules.order scripts/selinux/genheaders/modules.order scripts/selinux/mdp/modules.order scripts/selinux/modules.order Going forward, $(objtree)/modules.order lists the modules that was built in the last successful build. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>