summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2018-03-26kconfig: only write '# CONFIG_FOO is not set' for visible symbolsUlf Magnusson
=== Background === - Visible n-valued bool/tristate symbols generate a '# CONFIG_FOO is not set' line in the .config file. The idea is to remember the user selection without having to set a Makefile variable. Having n correspond to the variable being undefined in the Makefiles makes for easy CONFIG_* tests. - Invisible n-valued bool/tristate symbols normally do not generate a '# CONFIG_FOO is not set' line, because user values from .config files have no effect on invisible symbols anyway. Currently, there is one exception to this rule: Any bool/tristate symbol that gets the value n through a 'default' property generates a '# CONFIG_FOO is not set' line, even if the symbol is invisible. Note that this only applies to explicitly given defaults, and not when the symbol implicitly defaults to n (like bool/tristate symbols without 'default' properties do). This is inconsistent, and seems redundant: - As mentioned, the '# CONFIG_FOO is not set' won't affect the symbol once the .config is read back in. - Even if the symbol is invisible at first but becomes visible later, there shouldn't be any harm in recalculating the default value rather than viewing the '# CONFIG_FOO is not set' as a previous user value of n. === Changes === Change sym_calc_value() to only set SYMBOL_WRITE (write to .config) for non-n-valued 'default' properties. Note that SYMBOL_WRITE is always set for visible symbols regardless of whether they have 'default' properties or not, so this change only affects invisible symbols. This reduces the size of the x86 .config on my system by about 1% (due to removed '# CONFIG_FOO is not set' entries). One side effect of (and the main motivation for) this change is making the following two definitions behave exactly the same: config FOO bool config FOO bool default n With this change, neither of these will generate a '# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied). That might make it clearer to people that a bare 'default n' is redundant. This change only affects generated .config files and not autoconf.h: autoconf.h only includes #defines for non-n bool/tristate symbols. === Testing === The following testing was done with the x86 Kconfigs: - .config files generated before and after the change were compared to verify that the only difference is some '# CONFIG_FOO is not set' entries disappearing. A couple of these were inspected manually, and most turned out to be from redundant 'default n/def_bool n' properties. - The generated include/generated/autoconf.h was compared before and after the change and verified to be identical. - As a sanity check, the same modification was done to Kconfiglib. The Kconfiglib test suite was then run to check for any mismatches against the output of the C implementation. Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-03-26kconfig: Print reverse dependencies in groupsEugeniu Rosca
Surprisingly or not, disabling a CONFIG option (which is assumed to be unneeded) may be not so trivial. Especially it is not trivial, when this CONFIG option is selected by a dozen of other configs. Before the moment commit 1ccb27143360 ("kconfig: make "Selected by:" and "Implied by:" readable") popped up in v4.16-rc1, it was an absolute pain to break down the "Selected by" reverse dependency expression in order to identify all those configs which select (IOW *do not allow disabling*) a certain feature (assumed to be not needed). This patch tries to make one step further by putting at users' fingertips the revdep top level OR sub-expressions grouped/clustered by the tristate value they evaluate to. This should allow the users to directly concentrate on and tackle the _active_ reverse dependencies. To give some numbers and quantify the complexity of certain reverse dependencies, assuming commit 617aebe6a97e ("Merge tag 'usercopy-v4.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux"), ARCH=arm64 and vanilla arm64 defconfig, here is the top 10 CONFIG options with the highest amount of top level "||" sub-expressions/tokens that make up the final "Selected by" reverse dependency expression. | Config | All revdep | Active revdep | |-------------------|------------|---------------| | REGMAP_I2C | 212 | 9 | | CRC32 | 167 | 25 | | FW_LOADER | 128 | 5 | | MFD_CORE | 124 | 9 | | FB_CFB_IMAGEBLIT | 114 | 2 | | FB_CFB_COPYAREA | 111 | 2 | | FB_CFB_FILLRECT | 110 | 2 | | SND_PCM | 103 | 2 | | CRYPTO_HASH | 87 | 19 | | WATCHDOG_CORE | 86 | 6 | The story behind the above is that users need to visually review/evaluate 212 expressions which *potentially* select REGMAP_I2C in order to identify the expressions which *actually* select REGMAP_I2C, for a particular ARCH and for a particular defconfig used. To make this experience smoother, change the way reverse dependencies are displayed to the user from [1] to [2]. [1] Old representation of DMA_ENGINE_RAID: Selected by: - AMCC_PPC440SPE_ADMA [=n] && DMADEVICES [=y] && (440SPe || 440SP) - BCM_SBA_RAID [=m] && DMADEVICES [=y] && (ARM64 [=y] || ... - FSL_RAID [=n] && DMADEVICES [=y] && FSL_SOC && ... - INTEL_IOATDMA [=n] && DMADEVICES [=y] && PCI [=y] && X86_64 - MV_XOR [=n] && DMADEVICES [=y] && (PLAT_ORION || ARCH_MVEBU [=y] ... - MV_XOR_V2 [=y] && DMADEVICES [=y] && ARM64 [=y] - XGENE_DMA [=n] && DMADEVICES [=y] && (ARCH_XGENE [=y] || ... - DMATEST [=n] && DMADEVICES [=y] && DMA_ENGINE [=y] [2] New representation of DMA_ENGINE_RAID: Selected by [y]: - MV_XOR_V2 [=y] && DMADEVICES [=y] && ARM64 [=y] Selected by [m]: - BCM_SBA_RAID [=m] && DMADEVICES [=y] && (ARM64 [=y] || ... Selected by [n]: - AMCC_PPC440SPE_ADMA [=n] && DMADEVICES [=y] && (440SPe || ... - FSL_RAID [=n] && DMADEVICES [=y] && FSL_SOC && ... - INTEL_IOATDMA [=n] && DMADEVICES [=y] && PCI [=y] && X86_64 - MV_XOR [=n] && DMADEVICES [=y] && (PLAT_ORION || ARCH_MVEBU [=y] ... - XGENE_DMA [=n] && DMADEVICES [=y] && (ARCH_XGENE [=y] || ... - DMATEST [=n] && DMADEVICES [=y] && DMA_ENGINE [=y] Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Petr Vorel <pvorel@suse.cz> Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-03-26kconfig: clean-up reverse dependency help implementationMasahiro Yamada
This commit splits out the special E_OR handling ('-' instead of '||') into a dedicated helper expr_print_revdev(). Restore the original expr_print() prior to commit 1ccb27143360 ("kconfig: make "Selected by:" and "Implied by:" readable"). This makes sense because: - We need to chop those expressions only when printing the reverse dependency, and only when E_OR is encountered - Otherwise, it should be printed as before, so fall back to expr_print() This also improves the behavior; for a single line, it was previously displayed in the same line as "Selected by", like this: Selected by: A [=n] && B [=n] This will be displayed in a new line, consistently: Selected by: - A [=n] && B [=n] Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Petr Vorel <pvorel@suse.cz>
2018-03-26checkpatch: kconfig: prefer 'help' over '---help---'Ulf Magnusson
IMO, we should discourage '---help---' for new help texts, even in cases where it would be consistent with other help texts in the file. This will help if we ever want to get rid of '---help---' in the future. Also simplify the code to only check for exactly '---help---'. Since commit c2264564df3d ("kconfig: warn of unhandled characters in Kconfig commands"), '---help---' is a proper keyword and can only appear in that form. Prior to that commit, '---help---' working was more of a syntactic quirk. Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-03-26checkpatch: kconfig: check help texts for menuconfig and choiceUlf Magnusson
Currently, only Kconfig symbols are checked for a missing or short help text, and are only checked if they are defined with the 'config' keyword. To make the check more general, extend it to also check help texts for choices and for symbols defined with the 'menuconfig' keyword. This increases the accuracy of the check for symbols that would already have been checked as well, since e.g. a 'menuconfig' symbol after a help text will be recognized as ending the preceding symbol/choice definition. To increase the accuracy of the check further, also recognize 'if', 'endif', 'menu', 'endmenu', 'endchoice', and 'source' as ending a symbol/choice definition. Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-03-26checkpatch: kconfig: recognize more prompts when checking help textsUlf Magnusson
The check for a missing or short help text only considers symbols with a prompt, but doesn't recognize any of the following as a prompt: bool 'foo' tristate 'foo' prompt "foo" prompt 'foo' Make the check recognize those too. Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-03-26kbuild: clean up link rule of composite modulesMasahiro Yamada
cmd_link_multi-link is used only for cmd_link_multi-m. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-03-26kbuild: clean up archive rule of built-in.aMasahiro Yamada
With the incremental linking entirely dropped, we can simplify the Makefile. While I am here, I renamed cmd_link_o_target to cmd_ar_builtin. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-03-26kbuild: remove partial section mismatch detection for built-in.aMasahiro Yamada
When built-in.o was incrementally linked with 'ld -r', the section mismatch analysis for the individual built-in.o was possible when CONFIG_DEBUG_SECTION_MISMATCH was enabled. With the migration to the thin archive, built-in.a (former, built-in.o) is no longer an ELF file. So, the modpost does nothing useful. scripts/mod/modpost.c just checks the header to bail out, as follows: /* Is this a valid ELF file? */ if ((hdr->e_ident[EI_MAG0] != ELFMAG0) || (hdr->e_ident[EI_MAG1] != ELFMAG1) || (hdr->e_ident[EI_MAG2] != ELFMAG2) || (hdr->e_ident[EI_MAG3] != ELFMAG3)) { /* Not an ELF file - silently ignore it */ return 0; } We have the full analysis in the final link stage anyway, so we would not miss the section mismatching. I do not see a good reason to require extra linking only for the purpose of the per-directory analysis. Just get rid of this part. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-03-26net: liquidio: clean up Makefile for simpler composite object handlingMasahiro Yamada
Now, Kbuild nicely handles composite objects to avoid multiple definition. Makefiles can simply add the same objects multiple times across composite objects. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-03-26lib: zstd: clean up Makefile for simpler composite object handlingMasahiro Yamada
Now, Kbuild nicely handles composite objects to avoid multiple definition. Makefiles can simply add the same objects multiple times across composite objects. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-03-26kbuild: link $(real-obj-y) instead of $(obj-y) into built-in.aMasahiro Yamada
In Kbuild, Makefiles can add the same object to obj-y multiple times. So, obj-y += foo.o obj-y += foo.o is fine. However, this is not true when the same object is added multiple times via composite objects. For example, obj-y += foo.o bar.o foo-objs := foo-bar-common.o foo-only.o bar-objs := foo-bar-common.o bar-only.o causes build error because two instances of foo-bar-common.o are linked into the vmlinux. Makefiles tend to invent ugly work-around, for example - lib/zstd/Makefile - drivers/net/ethernet/cavium/liquidio/Makefile The technique used in Kbuild to avoid the multiple definition error is to use $(filter $(obj-y), $^). Here, $^ lists the names of all the prerequisites with duplicated names removed. By replacing it with $(filter $(real-obj-y), $^) we can do likewise for composite objects. For built-in objects, we do not need to keep the composite object structure. We can simply expand them, and link $(real-obj-y) to built-in.a. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-03-26kbuild: rename real-objs-y/m to real-obj-y/mMasahiro Yamada
When I was refactoring Makefiles, I stupidly mistook 'real-obj-y' for 'real-objs-y' over and over again. Finally, I decide to rename it to 'real-obj-y'. This is consistent with 'obj-y', 'subdir-obj-y'. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-03-26kbuild: move modname and modname-multi close to modname_flagsMasahiro Yamada
Just a cosmetic change to put related code close together. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Cao jin <caoj.fnst@cn.fujitsu.com>
2018-03-26kbuild: simplify modname calculationMasahiro Yamada
modname can be calculated much more simply. If modname-multi is empty, it is a single-used object. So, modname = $(basetarget). Otherwise, modname = $(modname-multi). Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Cao jin <caoj.fnst@cn.fujitsu.com>
2018-03-26kbuild: fix modname for composite modulesCao jin
Commit cf4f21938e13 ("kbuild: Allow to specify composite modules with modname-m") added modname-m support, but missed to update the corresponding multi-objs-m & modname-multi definition. Signed-off-by: Cao jin <caoj.fnst@cn.fujitsu.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-03-26kbuild: define KBUILD_MODNAME even if multiple modules share objectsMasahiro Yamada
Currently, KBUILD_MODNAME is defined only when $(modname) contains just one word. If an object is shared among multiple modules, undefined KBUILD_MODNAME could cause a build error. For example, if CONFIG_DYNAMIC_DEBUG is enabled, any call of printk() populates .modname, then fails to build due to undefined KBUILD_MODNAME. Take the following code as an example: obj-m += foo.o obj-m += bar.o foo-objs := foo-bar-common.o foo-only.o bar-objs := foo-bar-common.o bar-only.o In this case, there is room for argument what to define for KBUILD_MODNAME when foo-bar-common.o is being compiled. "foo", "bar", or what else? One idea is to define colon-separated modules that share the object, in this case, "bar:foo" (modules are sorted alphabetically by $(sort ...)). Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Cao jin <caoj.fnst@cn.fujitsu.com>
2018-03-26kbuild: remove unnecessary $(subst $(obj)/, , ...) in modname-multiMasahiro Yamada
In the context ... $(obj)/%.s: $(src)/%.c FORCE $(call if_changed_dep,cc_s_c) $(obj)/%.i: $(src)/%.c FORCE $(call if_changed_dep,cpp_i_c) $(obj)/%.o: $(src)/%.c $(recordmcount_source) $(objtool_dep) FORCE $(call cmd,force_checksrc) $(call if_changed_rule,cc_o_c) $(obj)/%.lst: $(src)/%.c FORCE $(call if_changed_dep,cc_lst_c) '$*' returns the stem of the target (the part of '%'), so $(obj)/ has already been ripped off. $(subst $(obj)/,,$*.o) is the same as $*.o Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Cao jin <caoj.fnst@cn.fujitsu.com>
2018-03-26kbuild: Use ls(1) instead of stat(1) to obtain file sizeMichael Forney
stat(1) is not standardized and different implementations have their own (conflicting) flags for querying the size of a file. ls(1) provides the same information (value of st.st_size) in the 5th column, except when the file is a character or block device. This output is standardized[0]. The -n option turns on -l, which writes lines formatted like "%s %u %s %s %u %s %s\n", <file mode>, <number of links>, <owner name>, <group name>, <size>, <date and time>, <pathname> but instead of writing the <owner name> and <group name>, it writes the numeric owner and group IDs (this avoids /etc/passwd and /etc/group lookups as well as potential field splitting issues). The <size> field is specified as "the value that would be returned for the file in the st_size field of struct stat". To avoid duplicating logic in several locations in the tree, create scripts/file-size.sh and update callers to use that instead of stat(1). [0] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ls.html#tag_20_73_10 Signed-off-by: Michael Forney <forney@google.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-03-26kbuild: link vmlinux only once for CONFIG_TRIM_UNUSED_KSYMSMasahiro Yamada
If CONFIG_TRIM_UNUSED_KSYMS is enabled and the kernel is built from a pristine state, the vmlinux is linked twice. [1] A user runs 'make' [2] First build with empty autoksyms.h [3] adjust_autoksyms.sh updates autoksyms.h and recurses 'make vmlinux' --------(begin sub-make)-------- [4] Second build with new autoksyms.h [5] link-vmlinux.sh is invoked because vmlinux is missing ---------(end sub-make)--------- [6] link-vmlinux.sh is invoked again despite vmlinux is up-to-date. The reason of [6] is probably because Make already decided to update vmlinux at the time of [2] because vmlinux was missing when Make built up the dependency graph. Because if_changed is implemented based on $?, this issue can be narrowed down to how Make handles $?. You can test it with the following simple code: [Test Makefile] A: B @echo newer prerequisite: $? cp B A B: C cp C B touch A [Result] $ rm -f A B $ touch C $ make cp C B touch A newer prerequisite: B cp B A Here, 'A' has been touched in the recipe of 'B'. So, the dependency 'A: B' has already been met before the recipe of 'A' is executed. However, Make does not notice the fact that the recipe of 'B' also updates 'A' as a side-effect. The situation is similar in this case; the vmlinux has actually been updated in the vmlinux_prereq target. Make cannot predict this, so judges the vmlinux is old. link-vmlinux.sh is costly, so it is better to not run it when unneeded. Split CONFIG_TRIM_UNUSED_KSYMS recursion to a dedicated target. The reason of commit 2441e78b1919 ("kbuild: better abstract vmlinux sequential prerequisites") was to cater to CONFIG_BUILD_DOCSRC, but it was later removed by commit 184892925118 ("samples: move blackfin gptimers-example from Documentation"). Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Nicolas Pitre <nico@linaro.org>
2018-03-26kbuild: move include/config/ksym/* to include/ksym/*Masahiro Yamada
The idea of using fixdep was inspired by Kconfig, but autoksyms belongs to a different group. So, I want to move those touched files under include/config/ksym/ to include/ksym/. The directory include/ksym/ can be removed by 'make clean' because it is meaningless for the external module building. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Nicolas Pitre <nico@linaro.org>
2018-03-26kbuild: move CONFIG_TRIM_UNUSED_KSYMS code unneeded for external moduleMasahiro Yamada
The external module building does not need to parse this code because KBUILD_MODULES is always set anyway. Move this code inside the "ifeq ($(KBUILD_EXTMOD),) ... endif" block. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Nicolas Pitre <nico@linaro.org>
2018-03-26kbuild: restore autoksyms.h touch to the top MakefileMasahiro Yamada
Commit d3fc425e819b ("kbuild: make sure autoksyms.h exists early") moved the code that touches autoksyms.h to scripts/kconfig/Makefile with obscure reason. From Nicolas' comment [1], he did not seem to be sure about the root cause. I guess I figured it out, so here is a fix-up I think is more correct. According to the error log in the original post [2], the build failed in scripts/mod/devicetable-offsets.c scripts/mod/Makefile is descended from scripts/Makefile, which is invoked from the top-level Makefile by the 'scripts' target. To build vmlinux and/or modules, Kbuild descend into $(vmlinux-dirs). This depends on 'prepare' and 'scripts' as follows: $(vmlinux-dirs): prepare scripts Because there is no dependency between 'prepare' and 'scripts', the parallel building can execute them simultaneously. 'prepare' depends on 'prepare1', which touched autoksyms.h, while 'scripts' descends into script/, then scripts/mod/, which needs <generated/autoksyms.h> if CONFIG_TRIM_UNUSED_KSYMS. It was the reason of the race. I am not happy to have unrelated code in the Kconfig Makefile, so getting it back to the top Makefile. I removed the standalone test target because I want to use it to create an empty autoksyms.h file. Here is a little improvement; unnecessary autoksyms.h is not created when CONFIG_TRIM_UNUSED_KSYMS is disabled. [1] https://lkml.org/lkml/2016/11/30/734 [2] https://lkml.org/lkml/2016/11/30/531 Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Nicolas Pitre <nico@linaro.org>
2018-03-26kbuild: move 'scripts' target belowMasahiro Yamada
Just a trivial change to prepare for the next commit. This target is still invisible from external module building. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-03-26kbuild: remove wrong 'touch' in adjust_autoksyms.shMasahiro Yamada
The comment mentions it creates autoksyms.h in case it is missing, but the actual code touches it when it does exists. The build system creates it anyway because <linux/export.h> and <asm-generic/export.h> need it. The code would not have worked as intended, and people have not noticed it. This is a proof that we can simply remove it. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Nicolas Pitre <nico@linaro.org>
2018-03-26kbuild: clear LDFLAGS in the top MakefileMasahiro Yamada
Currently LDFLAGS is not cleared, so same flags are accumulated in LDFLAGS when the top Makefile is recursively invoked. I found unneeded rebuild for ARCH=arm64 when CONFIG_TRIM_UNUSED_KSYMS is enabled. If include/generated/autoksyms.h is updated, the top Makefile is recursively invoked, then arch/arm64/Makefile adds one more '-maarch64linux'. Due to the command line change, modules are rebuilt needlessly. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Nicolas Pitre <nico@linaro.org>
2018-03-26kbuild: remove internally used LDFLAGS_vmlinux from kbuild.txtMasahiro Yamada
Documentation/kbuild/makefiles.txt lists variables used in Makefile whereas Documentation/kbuild/kbuild.txt describes user assignable parameters given via environments or the command line. The top Makefile and arch/*/Makefile accumulate proper linker flags to LDFLAGS_vmlinux. So, users can not override it from the command line. Generally, per-file options are not supposed to be user-assignable. Remove the misleading entry from kbuild.txt. If we need a way to append user-specific flags for linking the kernel, LDFLAGS_KERNEL would be a consistent choice because we already expose LDFLAGS_MODULE counter-part to users. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-03-26kbuild: remove command line interface LDFLAGS_MODULE from makefiles.txtMasahiro Yamada
Documentation/kbuild/makefiles.txt lists variables used in Makefile whereas Documentation/kbuild/kbuild.txt describes user assignable parameters given via environments or the command line. LDFLAGS_MODULE is a command line interface, so it should be dropped from makefiles.txt. Some lines below in this file, it is clearly explained that KBUILD_LDFLAGS_MODULE is the right one for the internal use: KBUILD_LDFLAGS_MODULE Options for $(LD) when linking modules $(KBUILD_LDFLAGS_MODULE) is used to add arch-specific options used when linking modules. This is often a linker script. From commandline LDFLAGS_MODULE shall be used (see kbuild.txt). Then, kbuild.txt explains LDFLAGS_MODULE, like follows: LDFLAGS_MODULE -------------------------------------------------- Additional options used for $(LD) when linking modules. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-03-26kbuild: simplify ld-option implementationMasahiro Yamada
Currently, linker options are tested by the coordination of $(CC) and $(LD) because $(LD) needs some object to link. As commit 86a9df597cdd ("kbuild: fix linker feature test macros when cross compiling with Clang") addressed, we need to make sure $(CC) and $(LD) agree the underlying architecture of the passed object. This could be a bit complex when we combine tools from different groups. For example, we can use clang for $(CC), but we still need to rely on GCC toolchain for $(LD). So, I was searching for a way of standalone testing of linker options. A trick I found is to use '-v'; this not only prints the version string, but also tests if the given option is recognized. If a given option is supported, $ aarch64-linux-gnu-ld -v --fix-cortex-a53-843419 GNU ld (Linaro_Binutils-2017.11) 2.28.2.20170706 $ echo $? 0 If unsupported, $ aarch64-linux-gnu-ld -v --fix-cortex-a53-843419 GNU ld (crosstool-NG linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) 2.23.1 aarch64-linux-gnu-ld: unrecognized option '--fix-cortex-a53-843419' aarch64-linux-gnu-ld: use the --help option for usage information $ echo $? 1 Gold works likewise. $ aarch64-linux-gnu-ld.gold -v --fix-cortex-a53-843419 GNU gold (Linaro_Binutils-2017.11 2.28.2.20170706) 1.14 masahiro@pug:~/ref/linux$ echo $? 0 $ aarch64-linux-gnu-ld.gold -v --fix-cortex-a53-999999 GNU gold (Linaro_Binutils-2017.11 2.28.2.20170706) 1.14 aarch64-linux-gnu-ld.gold: --fix-cortex-a53-999999: unknown option aarch64-linux-gnu-ld.gold: use the --help option for usage information $ echo $? 1 LLD too. $ ld.lld -v --gc-sections LLD 7.0.0 (http://llvm.org/git/lld.git 4a0e4190e74cea19f8a8dc625ccaebdf8b5d1585) (compatible with GNU linkers) $ echo $? 0 $ ld.lld -v --fix-cortex-a53-843419 LLD 7.0.0 (http://llvm.org/git/lld.git 4a0e4190e74cea19f8a8dc625ccaebdf8b5d1585) (compatible with GNU linkers) $ echo $? 0 $ ld.lld -v --fix-cortex-a53-999999 ld.lld: error: unknown argument: --fix-cortex-a53-999999 LLD 7.0.0 (http://llvm.org/git/lld.git 4a0e4190e74cea19f8a8dc625ccaebdf8b5d1585) (compatible with GNU linkers) $ echo $? 1 Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com>
2018-03-26kbuild: process mixture of clean/build targets one by oneMasahiro Yamada
Support parallel building of clean, config, and build targets in a single command. For example, make -j<N> clean all or make -j<N> mrproper defconfig all They should be handled one by one. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-03-26kbuild: rename built-in.o to built-in.aNicholas Piggin
Incremental linking is gone, so rename built-in.o to built-in.a, which is the usual extension for archive files. This patch does two things, first is a simple search/replace: git grep -l 'built-in\.o' | xargs sed -i 's/built-in\.o/built-in\.a/g' The second is to invert nesting of nested text manipulations to avoid filtering built-in.a out from libs-y2: -libs-y2 := $(filter-out %.a, $(patsubst %/, %/built-in.a, $(libs-y))) +libs-y2 := $(patsubst %/, %/built-in.a, $(filter-out %.a, $(libs-y))) Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-03-26kbuild: remove incremental linking optionNicholas Piggin
This removes the old `ld -r` incremental link option, which has not been selected by any architecture since June 2017. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-03-26kbuild: Improve portability of some sed invocationsMichael Forney
* Use BREs where EREs aren't necessary. * Pass -E instead of -r to use EREs. This will be standardized in the next POSIX revision[0]. GNU sed supports this since 4.2 (May 2009), and busybox since 1.22.0 (Jan 2014). * Use the [:space:] character class instead of ` \t` in bracket expressions. In bracket expressions, POSIX says that <backslash> loses its special meaning, so a conforming implementation cannot expand \t to <tab>[1]. * In BREs, use interval expressions (\{n,m\}) instead of non-standard features like \+ and \?. * Use a loop instead of -s flag. There are still plenty of other cases of non-standard sed invocations (use of ERE features in BREs, in-place editing), but this fixes some core ones. [0] http://austingroupbugs.net/view.php?id=528 [1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_03_05 Signed-off-by: Michael Forney <forney@google.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-03-26kbuild: add clang-version.shSami Tolvanen
Based on gcc-version.sh, clang-version.sh prints out the correct version of clang. Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-03-25syscalls: define and explain goal to not call syscalls in the kernelDominik Brodowski
The syscall entry points to the kernel defined by SYSCALL_DEFINEx() and COMPAT_SYSCALL_DEFINEx() should only be called from userspace through kernel entry points, but not from the kernel itself. This will allow cleanups and optimizations to the entry paths *and* to the parts of the kernel code which currently need to pretend to be userspace in order to make use of syscalls. Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
2018-03-25usb: core: Add USB_QUIRK_DELAY_CTRL_MSG to usbcore quirksKai-Heng Feng
There's a new quirk, USB_QUIRK_DELAY_CTRL_MSG. Add it to usbcore quirks for completeness. Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-03-25usb: core: Copy parameter string correctly and remove superfluous null checkKai-Heng Feng
strsep() slices string, so the string gets copied by param_set_copystring() at the end of quirks_param_set() is not the original value. Fix that by calling param_set_copystring() earlier. The null check for val is unnecessary, the caller of quirks_param_set() does not pass null string. Remove the superfluous null check. This is found by Smatch. Fixes: 027bd6cafd9a ("usb: core: Add "quirks" parameter for usbcore") Cc: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-03-25USB: announce bcdDevice as well as idVendor, idProduct.Benson Leung
Print bcdDevice which is used by vendors to identify different versions of the same product (or different versions of firmware). Adding this to the logs will be useful for support purposes. Match the %2x.%02x formatting that's used by lsusb -v for this same value. Signed-off-by: Benson Leung <bleung@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-03-25x86/purgatory: Avoid creating stray .<pid>.d files, remove -MD from ↵Sven Wegener
KBUILD_CFLAGS The kernel build system already takes care of generating the dependency files. Having the additional -MD in KBUILD_CFLAGS leads to stray .<pid>.d files in the build directory when we call the cc-option macro. Signed-off-by: Sven Wegener <sven.wegener@stealer.net> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Kees Cook <keescook@chromium.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matthias Kaehlcke <mka@chromium.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vivek Goyal <vgoyal@redhat.com> Link: http://lkml.kernel.org/r/alpine.LNX.2.21.1803242219380.30139@titan.int.lan.stealer.net Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-25Merge tag 'perf-core-for-mingo-4.17-20180323' of ↵Ingo Molnar
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core Pull perf/core improvements and fixes from Arnaldo Carvalho de Melo: - Move non-TUI specific annotation routines out of the TUI browser so that it can be used in other UIs, and to demonstrate that introduce a 'perf annotate --stdio2' option that will apply those formatting routines to provide a non-interactive annotation mode (Arnaldo Carvalho de Melo) - Add 'P' hotkey to the annotation TUI, so dump the current annotated symbol to a file, easing report thru e-mail, by getting rid of the spaces + right hand side scrollbar chars (Arnaldo Carvalho de Melo) - Support --ignore-vmlinux to 'perf report' and 'perf annotate', that was already present in 'perf top', to use /proc/{kcore,kallsyms}, allowing to see what is in fact running (patched stuff, alternatives, ftrace, etc), not the initial state of the kernel (vmlinux) (Arnaldo Carvalho de Melo) - Support 'jump' instructions to a different function, treating them as 'call' instructions (Arnaldo Carvalho de Melo) - Fix some jump artifacts when using vmlinux + ASM functions, where the ELF symtab for instance, for entry_SYSCALL_64 includes that and what comes after the 'syscall_return_via_sysret' label, but the objdump -dS prints the jump targets + offsets using the syscall_return_via_sysret address, which was confusing 'perf annotate'. See the cset comments for further info (Arnaldo Carvalho de Melo) - Report error from dwfl_attach_state() in the unwind code (Martin Vuille) - Reference Py_None before returning it in the python extension (Petr Machata) Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-24Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace Pull mqueuefs revert from Eric Biederman: "This fixes a regression that came in the merge window for v4.16. The problem is that the permissions for mounting and using the mqueuefs filesystem are broken. The necessary permission check is missing letting people who should not be able to mount mqueuefs mount mqueuefs. The field sb->s_user_ns is set incorrectly not allowing the mounter of mqueuefs to remount and otherwise have proper control over the filesystem. Al Viro and I see the path to the necessary fixes differently and I am not even certain at this point he actually sees all of the necessary fixes. Given a couple weeks we can probably work something out but I don't see the review being resolved in time for the final v4.16. I don't want v4.16 shipping with a nasty regression. So unfortunately I am sending a revert" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace: Revert "mqueue: switch to on-demand creation of internal mount"
2018-03-24Revert "mqueue: switch to on-demand creation of internal mount"Eric W. Biederman
This reverts commit 36735a6a2b5e042db1af956ce4bcc13f3ff99e21. Aleksa Sarai <asarai@suse.de> writes: > [REGRESSION v4.16-rc6] [PATCH] mqueue: forbid unprivileged user access to internal mount > > Felix reported weird behaviour on 4.16.0-rc6 with regards to mqueue[1], > which was introduced by 36735a6a2b5e ("mqueue: switch to on-demand > creation of internal mount"). > > Basically, the reproducer boils down to being able to mount mqueue if > you create a new user namespace, even if you don't unshare the IPC > namespace. > > Previously this was not possible, and you would get an -EPERM. The mount > is the *host* mqueue mount, which is being cached and just returned from > mqueue_mount(). To be honest, I'm not sure if this is safe or not (or if > it was intentional -- since I'm not familiar with mqueue). > > To me it looks like there is a missing permission check. I've included a > patch below that I've compile-tested, and should block the above case. > Can someone please tell me if I'm missing something? Is this actually > safe? > > [1]: https://github.com/docker/docker/issues/36674 The issue is a lot deeper than a missing permission check. sb->s_user_ns was is improperly set as well. So in addition to the filesystem being mounted when it should not be mounted, so things are not allow that should be. We are practically to the release of 4.16 and there is no agreement between Al Viro and myself on what the code should looks like to fix things properly. So revert the code to what it was before so that we can take our time and discuss this properly. Fixes: 36735a6a2b5e ("mqueue: switch to on-demand creation of internal mount") Reported-by: Felix Abecassis <fabecassis@nvidia.com> Reported-by: Aleksa Sarai <asarai@suse.de> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-03-24Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nfDavid S. Miller
Pablo Neira Ayuso says: ==================== Netfilter fixes for net The following patchset contains Netfilter fixes for your net tree, they are: 1) Don't pick fixed hash implementation for NFT_SET_EVAL sets, otherwise userspace hits EOPNOTSUPP with valid rules using the meter statement, from Florian Westphal. 2) If you send a batch that flushes the existing ruleset (that contains a NAT chain) and the new ruleset definition comes with a new NAT chain, don't bogusly hit EBUSY. Also from Florian. 3) Missing netlink policy attribute validation, from Florian. 4) Detach conntrack template from skbuff if IP_NODEFRAG is set on, from Paolo Abeni. 5) Cache device names in flowtable object, otherwise we may end up walking over devices going aways given no rtnl_lock is held. 6) Fix incorrect net_device ingress with ingress hooks. 7) Fix crash when trying to read more data than available in UDP packets from the nf_socket infrastructure, from Subash. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-24netfilter: nf_socket: Fix out of bounds access in nf_sk_lookup_slow_v{4,6}Subash Abhinov Kasiviswanathan
skb_header_pointer will copy data into a buffer if data is non linear, otherwise it will return a pointer in the linear section of the data. nf_sk_lookup_slow_v{4,6} always copies data of size udphdr but later accesses memory within the size of tcphdr (th->doff) in case of TCP packets. This causes a crash when running with KASAN with the following call stack - BUG: KASAN: stack-out-of-bounds in xt_socket_lookup_slow_v4+0x524/0x718 net/netfilter/xt_socket.c:178 Read of size 2 at addr ffffffe3d417a87c by task syz-executor/28971 CPU: 2 PID: 28971 Comm: syz-executor Tainted: G B W O 4.9.65+ #1 Call trace: [<ffffff9467e8d390>] dump_backtrace+0x0/0x428 arch/arm64/kernel/traps.c:76 [<ffffff9467e8d7e0>] show_stack+0x28/0x38 arch/arm64/kernel/traps.c:226 [<ffffff946842d9b8>] __dump_stack lib/dump_stack.c:15 [inline] [<ffffff946842d9b8>] dump_stack+0xd4/0x124 lib/dump_stack.c:51 [<ffffff946811d4b0>] print_address_description+0x68/0x258 mm/kasan/report.c:248 [<ffffff946811d8c8>] kasan_report_error mm/kasan/report.c:347 [inline] [<ffffff946811d8c8>] kasan_report.part.2+0x228/0x2f0 mm/kasan/report.c:371 [<ffffff946811df44>] kasan_report+0x5c/0x70 mm/kasan/report.c:372 [<ffffff946811bebc>] check_memory_region_inline mm/kasan/kasan.c:308 [inline] [<ffffff946811bebc>] __asan_load2+0x84/0x98 mm/kasan/kasan.c:739 [<ffffff94694d6f04>] __tcp_hdrlen include/linux/tcp.h:35 [inline] [<ffffff94694d6f04>] xt_socket_lookup_slow_v4+0x524/0x718 net/netfilter/xt_socket.c:178 Fix this by copying data into appropriate size headers based on protocol. Fixes: a583636a83ea ("inet: refactor inet[6]_lookup functions to take skb") Signed-off-by: Tejaswi Tanikella <tejaswit@codeaurora.org> Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2018-03-24nfp: bpf: fix check of program max insn countJakub Kicinski
NFP program allocation length is in bytes and NFP program length is in instructions, fix the comparison of the two. Fixes: 9314c442d7dd ("nfp: bpf: move translation prepare to offload.c") Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Jiong Wang <jiong.wang@netronome.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2018-03-24tools: bpftool: don't use hex numbers in JSON outputJakub Kicinski
JSON does not accept hex numbers with 0x prefix. Simply print as decimal numbers, JSON should be primarily machine-readable. Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com> Fixes: 831a0aafe5c3 ("tools: bpftool: add JSON output for `bpftool map *` commands") Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2018-03-24Merge tag 'pinctrl-v4.16-3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl Pull pin control fixes from Linus Walleij: "Two fixes for pin control for v4.16: - Renesas SH-PFC: remove a duplicate clkout pin which was causing crashes - fix Samsung out of bounds exceptions" * tag 'pinctrl-v4.16-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: pinctrl: samsung: Validate alias coming from DT pinctrl: sh-pfc: r8a7795: remove duplicate of CLKOUT pin in pinmux_pins[]
2018-03-24ipc/util: Helpers for making the sysvipc operations pid namespace awareEric W. Biederman
Capture the pid namespace when /proc/sysvipc/msg /proc/sysvipc/shm and /proc/sysvipc/sem are opened, and make it available through the new helper ipc_seq_pid_ns. This makes it possible to report the pids in these files in the pid namespace of the opener of the files. Implement ipc_update_pid. A simple impline helper that will only update a struct pid pointer if the new value does not equal the old value. This removes the need for wordy code sequences like: old = object->pid; object->pid = new; put_pid(old); and old = object->pid; if (old != new) { object->pid = new; put_pid(old); } Allowing the following to be written instead: ipc_update_pid(&object->pid, new); Which is easier to read and ensures that the pid reference count is not touched the old and the new values are the same. Not touching the reference count in this case is important to help avoid issues like af_unix experienced, where multiple threads of the same process managed to bounce the struct pid between cpu cache lines, but updating the pids reference count. Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-03-24ipc: Move IPCMNI from include/ipc.h into ipc/util.hEric W. Biederman
The definition IPCMNI is only used in ipc/util.h and ipc/util.c. So there is no reason to keep it in a header file that the whole kernel can see. Move it into util.h to simplify future maintenance. Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2018-03-24msg: Move struct msg_queue into ipc/msg.cEric W. Biederman
All of the users are now in ipc/msg.c so make the definition local to that file to make code maintenance easier. AKA to prevent rebuilding the entire kernel when struct msg_queue changes. Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
generated by cgit (git 2.34.1) at 2025-09-29 12:04:29 +0000