- May 24, 2019
-
-
Thomas Gleixner authored
Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details you should have received a copy of the gnu general public license along with this program if not write to the free software foundation inc 675 mass ave cambridge ma 02139 usa extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 441 file(s). Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc) Reviewed-by:
Richard Fontana <rfontana@redhat.com> Reviewed-by:
Allison Randal <allison@lohutok.net> Reviewed-by:
Kate Stewart <kstewart@linuxfoundation.org> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190520071858.739733335@linutronix.de Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Thomas Gleixner authored
Based on 1 normalized pattern(s): this program is a part of the linux kernel and may be freely copied under the terms of the gnu general public license gpl version 2 or at your option any later version extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 1 file(s). Signed-off-by:
-
Thomas Gleixner authored
Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public licence as published by the free software foundation either version 2 of the licence or at your option any later version extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 114 file(s). Signed-off-by:
-
- May 21, 2019
-
-
Thomas Gleixner authored
Add SPDX license identifiers to all Make/Kconfig files which: - Have no license information of any form These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is: GPL-2.0-only Signed-off-by:
-
Thomas Gleixner authored
Add SPDX license identifiers to all files which: - Have no license information of any form - Have EXPORT_.*_SYMBOL_GPL inside which was used in the initial scan/conversion to ignore the file These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is: GPL-2.0-only Signed-off-by:
-
- May 20, 2019
-
-
Masahiro Yamada authored
I just thought it was a good idea to scan builtin.modules in the name uniqueness checking, but a couple of false positives were found. Stephen reported a false positive for ppc64_defconfig: warning: same basename if the following are built as modules: arch/powerpc/platforms/powermac/nvram.ko drivers/char/nvram.ko The former is never built as a module as you see in arch/powerpc/platforms/powermac/Makefile: # CONFIG_NVRAM is an arch. independent tristate symbol, for pmac32 we really # need this to be a bool. Cheat here and pretend CONFIG_NVRAM=m is really # CONFIG_NVRAM=y obj-$(CONFIG_NVRAM:m=y) += nvram.o Another example of false positive is arm64 defconfig: warning: same basename if the following are built as modules: arch/arm64/lib/crc32.ko lib/crc32.ko It is true CONFIG_CRC32 is a tristate option but it is always 'y' since it is select'ed by ARM64. Hence, neither of them is built as a module for the arm64 build. From the above, modules.builtin essentially contains false positives. I do not think it is a big deal as far as kmod is concerned, but false positive warnings in the kernel build make people upset. It is better to not check it. Even without builtin.modules checked, we have enough (and more solid) test coverage with allmodconfig. While I touched this part, I replaced the sed code with neater one provided by Stephen. Link: https://lkml.org/lkml/2019/5/19/120 Link: https://lkml.org/lkml/2019/5/19/123 Fixes: 3a48a919 ("kbuild: check uniqueness of module names") Reported-by:Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
-
Nick Desaulniers authored
If you want to see if your linker supports a certain flag, then ask the linker directly with ld-option (not the compiler with cc-ldoption). Checking for linker flag support is an antipattern that complicates the usage of various linkers other than bfd via -fuse-ld={bfd|gold|lld}. Cc: clang-built-linux@googlegroups.com Suggested-by:Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
-
- May 19, 2019
-
-
Masahiro Yamada authored
'ifeq ... else ifneq ... endif' notation is supported by GNU Make 3.81 or later, which is the requirement for building the kernel since commit 37d69ee3 ("docs: bump minimal GNU Make version to 3.81"). Use it to improve the readability. Signed-off-by:
-
- May 18, 2019
-
-
Masahiro Yamada authored
In the recent build test of linux-next, Stephen saw a build error caused by a broken .tmp_versions/*.mod file: https://lkml.org/lkml/2019/5/13/991 drivers/net/phy/asix.ko and drivers/net/usb/asix.ko have the same basename, and there is a race in generating .tmp_versions/asix.mod Kbuild has not checked this before, and it suddenly shows up with obscure error messages when this kind of race occurs. Non-unique module names cause various sort of problems, but it is not trivial to catch them by eyes. Hence, this script. It checks not only real modules, but also built-in modules (i.e. controlled by tristate CONFIG option, but currently compiled with =y). Non-unique names for built-in modules also cause problems because /sys/modules/ would fall over. For the latest kernel, I tested "make allmodconfig all" (or more quickly "make allyesconfig modules"), and it detected the following: warning: same basename if the following are built as modules: drivers/regulator/88pm800.ko drivers/mfd/88pm800.ko warning: same basename if the following are built as modules: drivers/gpu/drm/bridge/adv7511/adv7511.ko drivers/media/i2c/adv7511.ko warning: same basename if the following are built as modules: drivers/net/phy/asix.ko drivers/net/usb/asix.ko warning: same basename if the following are built as modules: fs/coda/coda.ko drivers/media/platform/coda/coda.ko warning: same basename if the following are built as modules: drivers/net/phy/realtek.ko drivers/net/dsa/realtek.ko Reported-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com>
-
Alexander Popov authored
Currently menu blocks start with a pretty header but end with nothing in the generated config. So next config options stick together with the options from the menu block. Let's terminate menu blocks in the generated config with a comment and a newline if needed. Example: ... CONFIG_BPF_STREAM_PARSER=y CONFIG_NET_FLOW_LIMIT=y # # Network testing # CONFIG_NET_PKTGEN=y CONFIG_NET_DROP_MONITOR=y # end of Network testing # end of Networking options CONFIG_HAMRADIO=y ... Signed-off-by:
Alexander Popov <alex.popov@linux.com> Reviewed-by:
-
Masahiro Yamada authored
The 'addtree' and 'flags' in scripts/Kbuild.include are so compilecated and ugly. As I mentioned in [1], Kbuild should stop automatic prefixing of header search path options. I fixed up (almost) all Makefiles in the kernel. Now 'addtree' and 'flags' have been removed. Kbuild still caters to add $(srctree)/$(src) and $(objtree)/$(obj) to the header search path for O= building, but never touches extra compiler options from ccflags-y etc. [1]: https://patchwork.kernel.org/patch/9632347/ Signed-off-by:
-
Masahiro Yamada authored
Currently, the Kbuild core manipulates header search paths in a crazy way [1]. To fix this mess, I want all Makefiles to add explicit $(srctree)/ to the search paths in the srctree. Some Makefiles are already written in that way, but not all. The goal of this work is to make the notation consistent, and finally get rid of the gross hacks. Having whitespaces after -I does not matter since commit 48f6e3cf ("kbuild: do not drop -I without parameter"). [1]: https://patchwork.kernel.org/patch/9632347/ Signed-off-by:
-
Masahiro Yamada authored
If the compiler specified by $(CC) is not present, the Kconfig stage sprinkles 'not found' messages, then succeeds. $ make CROSS_COMPILE=foo defconfig /bin/sh: 1: foogcc: not found /bin/sh: 1: foogcc: not found *** Default configuration is based on 'x86_64_defconfig' ./scripts/gcc-version.sh: 17: ./scripts/gcc-version.sh: foogcc: not found ./scripts/gcc-version.sh: 18: ./scripts/gcc-version.sh: foogcc: not found ./scripts/gcc-version.sh: 19: ./scripts/gcc-version.sh: foogcc: not found ./scripts/gcc-version.sh: 17: ./scripts/gcc-version.sh: foogcc: not found ./scripts/gcc-version.sh: 18: ./scripts/gcc-version.sh: foogcc: not found ./scripts/gcc-version.sh: 19: ./scripts/gcc-version.sh: foogcc: not found ./scripts/clang-version.sh: 11: ./scripts/clang-version.sh: foogcc: not found ./scripts/gcc-plugin.sh: 11: ./scripts/gcc-plugin.sh: foogcc: not found init/Kconfig:16:warning: 'GCC_VERSION': number is invalid # # configuration written to .config # Terminate parsing files immediately if $(CC) or $(LD) is not found. "make *config" will fail more nicely. $ make CROSS_COMPILE=foo defconfig *** Default configuration is based on 'x86_64_defconfig' scripts/Kconfig.include:34: compiler 'foogcc' not found make[1]: *** [scripts/kconfig/Makefile;82: defconfig] Error 1 make: *** [Makefile;557: defconfig] Error 2 Signed-off-by: -
Masahiro Yamada authored
We do not support old Clang versions. Upgrade your clang version if any of these flags is unsupported. Let's add all flags inside ifdef CONFIG_CC_IS_CLANG unconditionally. Signed-off-by:
Sedat Dilek <sedat.dilek@gmail.com> Reviewed-by:
Nathan Chancellor <natechancellor@gmail.com> Tested-by:
-
Masahiro Yamada authored
These flags are documented in the GCC 4.6 manual, and recognized by Clang as well. Let's rip off the cc-option / cc-disable-warning switches. Signed-off-by:
-
- May 15, 2019
-
-
Leonard Crestez authored
The clk rate is always stored in clk_core but might be out of date and require calls to update from hardware. Deal with that case by printing a (c) suffix. Link: http://lkml.kernel.org/r/1a474318982a5f0125f2360c4161029b17f56bd1.1556881728.git.leonard.crestez@nxp.com Signed-off-by:
Leonard Crestez <leonard.crestez@nxp.com> Cc: Jan Kiszka <jan.kiszka@siemens.com> Cc: Jason Wessel <jason.wessel@windriver.com> Cc: Kieran Bingham <kbingham@kernel.org> Cc: Stephen Boyd <swboyd@chromium.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Leonard Crestez authored
An incorrect argument to list_for_each is an internal error in gdb scripts so a TypeError should be raised. The gdb.GdbError exception type is intended for user errors such as incorrect invocation. Drop the type assertion in list_for_each_entry because list_for_each isn't going to suddenly yield something else. Applies to both list and hlist Link: http://lkml.kernel.org/r/c1d3fd4db13d999a3ba57f5bbc1924862d824f61.1556881728.git.leonard.crestez@nxp.com Signed-off-by:
Stephen Boyd <sboyd@kernel.org> Cc: Jan Kiszka <jan.kiszka@siemens.com> Cc: Jason Wessel <jason.wessel@windriver.com> Cc: Kieran Bingham <kbingham@kernel.org> Signed-off-by:
-
Leonard Crestez authored
Finding an individual clk_core requires walking the tree which can be quite complicated so add a helper for easy access. (gdb) print *(struct clk_scu*)$lx_clk_core_lookup("uart0_clk")->hw Link: http://lkml.kernel.org/r/Message-ID : Signed-off-by: -
Leonard Crestez authored
Add an lx-clk-summary command which prints a subset of /sys/kernel/debug/clk/clk_summary. This can be used to examine hangs caused by clk not being enabled. Link: http://lkml.kernel.org/r/Message-ID : Signed-off-by:
-
Leonard Crestez authored
This allows easily examining kernel hlists in python. Link: http://lkml.kernel.org/r/Message-ID : Signed-off-by:
-
Stephen Boyd authored
These scripts have some pep8 style warnings. Fix them up so that this directory is all pep8 clean. Link: http://lkml.kernel.org/r/20190329220844.38234-6-swboyd@chromium.org Signed-off-by:
Stephen Boyd <swboyd@chromium.org> Cc: Douglas Anderson <dianders@chromium.org> Cc: Nikolay Borisov <n.borisov.lkml@gmail.com> Cc: Kieran Bingham <kbingham@kernel.org> Cc: Jan Kiszka <jan.kiszka@siemens.com> Cc: Jackie Liu <liuyun01@kylinos.cn> Cc: Jason Wessel <jason.wessel@windriver.com> Signed-off-by:
-
Stephen Boyd authored
Implement a command to print the timer list, much like how /proc/timer_list is implemented. This can be used to look at the pending timers on a crashed system. [swboyd@chromium.org: v2] Link: http://lkml.kernel.org/r/20190329220844.38234-5-swboyd@chromium.org Link: http://lkml.kernel.org/r/20190325184522.260535-5-swboyd@chromium.org Signed-off-by:
-
Stephen Boyd authored
Implement gdb functions for rb_first(), rb_last(), rb_next(), and rb_prev(). These can be useful to iterate through the kernel's red-black trees. [swboyd@chromium.org: v2] Link: http://lkml.kernel.org/r/20190329220844.38234-4-swboyd@chromium.org Link: http://lkml.kernel.org/r/20190325184522.260535-4-swboyd@chromium.org Signed-off-by:
-
Stephen Boyd authored
lx-configdump <file> dumps the contents of the gzipped .config to a text file when the config is included in the kernel with CONFIG_IKCONFIG. By default, the file written is called config.txt, but it can be any user supplied filename as well. If the kernel config is in a module (configs.ko), then it can be loaded along with symbols for the module loaded with 'lx-symbols' and then this command will still work. Obviously if you have the whole vmlinux then this can also be achieved with scripts/extract-ikconfig, but this gdb script can be useful to confirm that the memory contents of the config in memory and the vmlinux contents on disk match what is expected. [swboyd@chromium.org: v2] Link: http://lkml.kernel.org/r/20190329220844.38234-3-swboyd@chromium.org Link: http://lkml.kernel.org/r/20190325184522.260535-3-swboyd@chromium.org Signed-off-by:
-
Stephen Boyd authored
Patch series "gdb script for kconfig and timer list". This is a handful of changes to the kernel's gdb scripts to do some more debugging with kgdb. The first patch allows the vmlinux to be reloaded from where it was specified on the command line so that this set of scripts can be used from anywhere. The second patch adds a script to dump the config.gz to a file on the host debugging machine. The third patch adds some rb tree utilities and the last patch uses those rb tree walking utilities to dump out the contents of /proc/timer_list from a system under debug. This patch (of 5): If I run 'gdb <path/to/vmlinux>' and there's the vmlinux-gdb.py file there I can properly see symbols and use the lx commands provided by the GDB scripts. But once I run 'lx-symbols' at the command prompt, gdb reloads the vmlinux symbols assuming that this script was run from the directory that has vmlinux at the root. That isn't always true, but we could just look and see what symbols were already loaded and use that instead. Let's do that so this can work by being invoked anywhere. Link: http://lkml.kernel.org/r/20190325184522.260535-2-swboyd@chromium.org Signed-off-by:
-
- May 14, 2019
-
-
Masahiro Yamada authored
This is only used in confdata.c Signed-off-by: -
Jacob Garber authored
Valid pathnames will never exceed PATH_MAX, but these file names are unsanitized and can cause buffer overflow if set incorrectly. Use snprintf to avoid this. This was flagged during a Coverity scan of the coreboot project, which also uses kconfig for its build system. Signed-off-by:
Jacob Garber <jgarber1@ualberta.ca> Signed-off-by:
-
Masahiro Yamada authored
conf_write_dep() has just one caller: conf_write_dep("include/config/auto.conf.cmd"); "name" always points to a valid string. Signed-off-by:
-
- May 12, 2019
-
-
Quentin Monnet authored
The script broke on parsing function prototype for bpf_strtoul(). This is because the last argument for the function is a pointer to an "unsigned long". The current version of the script only accepts "const" and "struct", but not "unsigned", at the beginning of argument types made of several words. One solution could be to add "unsigned" to the list, but the issue could come up again in the future (what about "long int"?). It turns out we do not need to have such restrictions on the words: so let's simply accept any series of words instead. Reported-by:
Yonghong Song <yhs@fb.com> Signed-off-by:
Quentin Monnet <quentin.monnet@netronome.com> Acked-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net>
-
- May 10, 2019
-
-
Chris Packham authored
Use gen_rtx_set instead of gen_rtx_SET. The former is a wrapper macro that handles the difference between GCC versions implementing the latter. This fixes the following error on my system with g++ 5.4.0 as the host compiler HOSTCXX -fPIC scripts/gcc-plugins/arm_ssp_per_task_plugin.o scripts/gcc-plugins/arm_ssp_per_task_plugin.c:42:14: error: macro "gen_rtx_SET" requires 3 arguments, but only 2 given mask)), ^ scripts/gcc-plugins/arm_ssp_per_task_plugin.c: In function ‘unsigned int arm_pertask_ssp_rtl_execute()’: scripts/gcc-plugins/arm_ssp_per_task_plugin.c:39:20: error: ‘gen_rtx_SET’ was not declared in this scope emit_insn_before(gen_rtx_SET Signed-off-by:Chris Packham <chris.packham@alliedtelesis.co.nz> Fixes: 189af465 ("ARM: smp: add support for per-task stack canaries") Cc: stable@vger.kernel.org Tested-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
Masahiro Yamada authored
With menuconfig / nconfig, users can input any file path from the "Save" menu, but it fails if the parent directory does not exist. Why not create the parent directory automatically. I think this is a user-friendly behavior. I changed the error messages in menuconfig / nconfig. "Nonexistent directory" is no longer the most likely reason of the failure. Perhaps, the user specified the existing directory, or attempted to write to the location without write permission. Signed-off-by: -
Masahiro Yamada authored
Kconfig updates the .config when it exits even if its content is exactly the same as before. Since its timestamp becomes newer than that of other build artifacts, additional processing is invoked, which is annoying. - syncconfig is invoked to update include/config/auto.conf, etc. - kernel/configs.o is recompiled if CONFIG_IKCONFIG is enabled, then vmlinux is relinked as well. If the .config is not changed at all, we do not have to even touch it. Just bail out showing "No change to .config". $ make allmodconfig scripts/kconfig/conf --allmodconfig Kconfig # # configuration written to .config # $ make allmodconfig scripts/kconfig/conf --allmodconfig Kconfig # # No change to .config # Reported-by:
-
Masahiro Yamada authored
Currently, conf_write() can be called with a directory name instead of a file name. As far as I see, this can happen for menuconfig, nconfig, gconfig. If it is given with a directory path, conf_write() kindly appends getenv("KCONFIG_CONFIG"), but this ends up with hacky dir/basename handling, and screwed up in corner-cases like "what if KCONFIG_CONFIG is an absolute path?" as discussed before: https://patchwork.kernel.org/patch/9910037/ Since conf_write() is already messed up, I'd say "do not do it". Please pass a file path all the time. If a directory path is specified for the configuration output, conf_write() will simply error out. Now that the tmp file is created in the same directory as the .config, the previously reported "what if KCONFIG_CONFIG points to a different file system?" has been solved. Signed-off-by:
-
- May 09, 2019
-
-
Masahiro Yamada authored
There are still some trailing whitespaces under scripts/kconfig/tests/, but they must be kept. Otherwise, "make testconfig" would break. Signed-off-by:
-
- May 07, 2019
-
-
Alexey Gladkov authored
Problem: When a kernel module is compiled as a separate module, some important information about the kernel module is available via .modinfo section of the module. In contrast, when the kernel module is compiled into the kernel, that information is not available. Information about built-in modules is necessary in the following cases: 1. When it is necessary to find out what additional parameters can be passed to the kernel at boot time. 2. When you need to know which module names and their aliases are in the kernel. This is very useful for creating an initrd image. Proposal: The proposed patch does not remove .modinfo section with module information from the vmlinux at the build time and saves it into a separate file after kernel linking. So, the kernel does not increase in size and no additional information remains in it. Information is stored in the same format as in the separate modules (null-terminated string array). Because the .modinfo section is already exported with a separate modules, we are not creating a new API. It can be easily read in the userspace: $ tr '\0' '\n' < modules.builtin.modinfo ext4.softdep=pre: crc32c ext4.license=GPL ext4.description=Fourth Extended Filesystem ext4.author=Remy Card, Stephen Tweedie, Andrew Morton, Andreas Dilger, Theodore Ts'o and others ext4.alias=fs-ext4 ext4.alias=ext3 ext4.alias=fs-ext3 ext4.alias=ext2 ext4.alias=fs-ext2 md_mod.alias=block-major-9-* md_mod.alias=md md_mod.description=MD RAID framework md_mod.license=GPL md_mod.parmtype=create_on_open:bool md_mod.parmtype=start_dirty_degraded:int ... Co-Developed-by:
Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org> Signed-off-by:
Alexey Gladkov <gladkov.alexey@gmail.com> Acked-by:
Jessica Yu <jeyu@kernel.org> Signed-off-by:
-
- May 06, 2019
-
-
Andrey Ryabinin authored
The kernel the kernel is built with -Wvla for some time, so is not supposed to have any variable length arrays. Remove vla bounds checking from ubsan since it's useless now. Signed-off-by:
Andrey Ryabinin <aryabinin@virtuozzo.com> Signed-off-by:
-
Andrii Nakryiko authored
When BTF generation is enabled through CONFIG_DEBUG_INFO_BTF, scripts/link-vmlinux.sh detects if pahole version is too old and gracefully continues build process, skipping BTF generation build step. But if pahole is not available, build will still fail. This patch adds check for whether pahole exists at all and bails out gracefully, if not. Cc: Alexei Starovoitov <ast@fb.com> Reported-by:
Andrii Nakryiko <andriin@fb.com> Signed-off-by:
-
- May 03, 2019
-
-
Masahiro Yamada authored
I thought this script was run via "make tags" etc. but some people run it directly. Prior to commit a9a49c2a ("kbuild: use $(srctree) instead of KBUILD_SRC to check out-of-tree build"), in such a usecase, "tree" was set empty since KBUILD_SRC is undefined. Now, "tree" is set to "${srctree}/", which is evaluated to "/". Fix it by taking into account the case where "srctree" is unset. Link: https://lkml.org/lkml/2019/4/19/501 Fixes: a9a49c2a ("kbuild: use $(srctree) instead of KBUILD_SRC to check out-of-tree build") Reported-by:
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> Signed-off-by:
-
Daniel Dadap authored
recordmcount.pl uses a set of regular expressions to parse the output of objdump(1). However, if objdump(1) output is localized, it may not match the regular expressions, thereby preventing recordmcount.pl from parsing object files correctly. In order to allow recordmcount.pl to function correctly regardless of the current locale settings, set LANG=C when running objdump(1). LC_ALL is already unset in the top-level Makefile, so it is not necessary to also override that environment variable. Signed-off-by:
Daniel Dadap <ddadap@nvidia.com> Reviewed-by:
Robert Morell <rmorell@nvidia.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
As we keep migrating documents to ReST, we're starting to see more of such tags. Right now, all such tags are pointing to a documentation file, but regressions may be introduced. So, add a check for such kind of issues as well. Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
Jonathan Corbet <corbet@lwn.net>
-
