Now compilers can recognize fatal() never returns.
While GCC 4.5 dropped support for -Wunreachable-code, Clang is capable
of detecting the unreachable code.
$ make HOSTCC=clang HOSTCFLAGS=-Wunreachable-code-return
[snip]
HOSTCC scripts/mod/modpost.o
scripts/mod/modpost.c:520:11: warning: 'return' will never be executed [-Wunreachable-code-return]
return 0;
^
scripts/mod/modpost.c:477:10: warning: 'return' will never be executed [-Wunreachable-code-return]
return 0;
^
2 warnings generated.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
This initializer was added to avoid -Wmaybe-uninitialized (gcc) and
-Wsometimes-uninitialized (clang) warnings.
Now that compilers recognize fatal() never returns, it is unneeded.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
The function fatal() never returns because modpost_log() calls exit(1)
when LOG_FATAL is passed.
Inform compilers of this fact so that unreachable code flow can be
identified at compile time.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
This attribute must be added to the function declaration in a header
for comprehensive checking of all the callsites.
Fixes: 6d9a89ea4b ("kbuild: declare the modpost error functions as printf like")
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
When using the -dtbs syntax, you need to list the base first, as
follows:
foo-dtbs := foo_base.dtb foo_overlay1.dtbo foo_overlay2.dtbo
dtb-y := foo.dtb
You cannot do this arrangement:
foo-dtbs := foo_overlay1.dtbo foo_overlay2.dtbo foo_base.dtb
This restriction comes from $(firstword ...) in the current
implementation, but it is unneeded to rely on the order in the
-dtbs syntax.
Instead, you can simply determine the base by the suffix because
the base (*.dtb) and overlays (*.dtbo) use different suffixes.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
In 2017, the dpkg suite introduced the rootless builds support with the
following commits:
- 2436807c87b0 ("dpkg-deb: Add support for rootless builds")
- fca1bfe84068 ("dpkg-buildpackage: Add support for rootless builds")
This feature is available in the default dpkg on Debian 10 and Ubuntu
20.04.
Remove the old method.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Pull misc fixes from Andrew Morton:
"31 hotfixes. Ten of these address pre-6.6 issues and are marked
cc:stable. The remainder address post-6.6 issues or aren't considered
serious enough to justify backporting"
* tag 'mm-hotfixes-stable-2023-12-07-18-47' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: (31 commits)
mm/madvise: add cond_resched() in madvise_cold_or_pageout_pte_range()
nilfs2: prevent WARNING in nilfs_sufile_set_segment_usage()
mm/hugetlb: have CONFIG_HUGETLB_PAGE select CONFIG_XARRAY_MULTI
scripts/gdb: fix lx-device-list-bus and lx-device-list-class
MAINTAINERS: drop Antti Palosaari
highmem: fix a memory copy problem in memcpy_from_folio
nilfs2: fix missing error check for sb_set_blocksize call
kernel/Kconfig.kexec: drop select of KEXEC for CRASH_DUMP
units: add missing header
drivers/base/cpu: crash data showing should depends on KEXEC_CORE
mm/damon/sysfs-schemes: add timeout for update_schemes_tried_regions
scripts/gdb/tasks: fix lx-ps command error
mm/Kconfig: make userfaultfd a menuconfig
selftests/mm: prevent duplicate runs caused by TEST_GEN_PROGS
mm/damon/core: copy nr_accesses when splitting region
lib/group_cpus.c: avoid acquiring cpu hotplug lock in group_cpus_evenly
checkstack: fix printed address
mm/memory_hotplug: fix error handling in add_memory_resource()
mm/memory_hotplug: add missing mem_hotplug_lock
.mailmap: add a new address mapping for Chester Lin
...
Add some warnings for using ethtool_sprintf() where a simple
ethtool_puts() would suffice.
The two cases are:
1) Use ethtool_sprintf() with just two arguments:
| ethtool_sprintf(&data, driver[i].name);
or
2) Use ethtool_sprintf() with a standalone "%s" fmt string:
| ethtool_sprintf(&data, "%s", driver[i].name);
The former may cause -Wformat-security warnings while the latter is just
not preferred. Both are safely in the category of warnings, not errors.
Signed-off-by: Justin Stitt <justinstitt@google.com>
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Pull devicetree fixes from Rob Herring:
- Fix dt-extract-compatibles for builds with in tree build directory
- Drop Xinlei Lee <xinlei.lee@mediatek.com> bouncing email
- Fix the of_reconfig_get_state_change() return value documentation
- Add missing #power-domain-cells property to QCom MPM
- Fix warnings in i.MX LCDIF and adi,adv7533
* tag 'devicetree-fixes-for-6.7-1' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux:
dt-bindings: display: adi,adv75xx: Document #sound-dai-cells
dt-bindings: lcdif: Properly describe the i.MX23 interrupts
dt-bindings: interrupt-controller: Allow #power-domain-cells
of: dynamic: Fix of_reconfig_get_state_change() return value documentation
dt-bindings: display: mediatek: dsi: remove Xinlei's mail
dt: dt-extract-compatibles: Don't follow symlinks when walking tree
All addresses printed by checkstack have an extra incorrect 0 appended at
the end.
This was introduced with commit 677f1410e0 ("scripts/checkstack.pl: don't
display $dre as different entity"): since then the address is taken from
the line which contains the function name, instead of the line which
contains stack consumption. E.g. on s390:
0000000000100a30 <do_one_initcall>:
...
100a44: e3 f0 ff 70 ff 71 lay %r15,-144(%r15)
So the used regex which matches spaces and hexadecimal numbers to extract
an address now matches a different substring. Subsequently replacing spaces
with 0 appends a zero at the and, instead of replacing leading spaces.
Fix this by using the proper regex, and simplify the code a bit.
Link: https://lkml.kernel.org/r/20231120183719.2188479-2-hca@linux.ibm.com
Fixes: 677f1410e0 ("scripts/checkstack.pl: don't display $dre as different entity")
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Cc: Maninder Singh <maninder1.s@samsung.com>
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Vaneet Narang <v.narang@samsung.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
When a default property is missing in an int or hex symbol, it defaults
to an empty string, which is not a valid symbol value.
It results in an incorrect .config, and can also lead to an infinite
loop in scripting.
Use "0" for int and "0x0" for hex as a default value.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Yoann Congal <yoann.congal@smile.fr>
This is used only for initializing other variables.
Use the empty string "" directly.
Please note newval.tri is unused for S_INT/HEX/STRING.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
A little more janitorial work after commit cf8e865810 ("arch: Remove
Itanium (IA-64) architecture").
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
KCONFIG_WARN_UNKNOWN_SYMBOLS=1 and KCONFIG_WERROR=1 are descriptive
and suitable in scripting, but typing them from the command line can
be tedious.
Associate them with KBUILD_EXTRA_WARN (and the W= shorthand).
Support a new letter 'c' to enable extra checks in Kconfig. You can
still manage compiler warnings (W=1) and Kconfig warnings (W=c)
independently.
Reuse the letter 'e' to turn Kconfig warnings into errors.
As usual, you can combine multiple letters in KCONFIG_EXTRA_WARN.
$ KCONFIG_WARN_UNKNOWN_SYMBOLS=1 KCONFIG_WERROR=1 make defconfig
can be shortened to:
$ KBUILD_EXTRA_WARN=ce make defconfig
or, even shorter:
$ make W=ce defconfig
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Set up build time warnings to safeguard against future header changes of
organized structs.
Warning includes:
1) whether all variables are still in the same cache group
2) whether all the cache groups have the sum of the members size (in the
maximum condition, including all members defined in configs)
The __cache_group* variables are ignored in kernel-doc check in the
various header files they appear in to enforce the cache groups.
Suggested-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Coco Li <lixiaoyan@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Shakeel Butt <shakeelb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Pull hardening fixes from Kees Cook:
- struct_group: propagate attributes to top-level union (Dmitry
Antipov)
- gcc-plugins: randstruct: Update code comment in relayout_struct
(Gustavo A. R. Silva)
- MAINTAINERS: refresh LLVM support (Nick Desaulniers)
* tag 'hardening-v6.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
gcc-plugins: randstruct: Update code comment in relayout_struct()
uapi: propagate __struct_group() attributes to the container union
MAINTAINERS: refresh LLVM support
The rpm-pkg and deb-pkg targets have transitioned to using 'git archive'
for tarball creation.
Although the old cmd_src_tar is still used by snap-pkg, there is no need
to pack and unpack a tarball solely for passing the source to snapcraft.
Instead, you can use 'source-type: local' to tell the source location to
snapcraft.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
It is done for the same reasons as 4243afdb93 does it for builddeb:
always runs make modules to install modules.builtin* files, which are
needed for e.g. initramfs-tools or LTP testing tool.
Signed-off-by: Petr Vorel <pvorel@suse.cz>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The shell variable $dirs is not used any more since 1fc9095846
("kbuild: tar-pkg: use tar rules in scripts/Makefile.package"),
therefore remove it".
Fixes: 1fc9095846 ("kbuild: tar-pkg: use tar rules in scripts/Makefile.package")
Signed-off-by: Petr Vorel <pvorel@suse.cz>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Make the while-loop code a little more readable.
The gain is that "CONFIG_FOO" without '=' is warned as unexpected data.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Currently, any string starting "is not set" disables a CONFIG option.
For example, "# CONFIG_FOO is not settled down" is accepted as valid
input, functioning the same as "# CONFIG_FOO is not set". It is a
long-standing oddity.
Check the line against the exact pattern "is not set".
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Currently, newline characters are stripped away in multiple places
on the caller.
Doing that in the callee is helpful for further cleanups.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Kconfig accepts both "# CONFIG_FOO is not set" and "CONFIG_FOO=n" as
a valid input, but conf_read_simple() duplicates similar code to handle
them. Factor out the common code.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The 'else' arm here is unreachable in practical use cases.
include/config/auto.conf does not include "# CONFIG_... is not set"
line unless it is manually hacked.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Currently, when an input line starts with '#', (line + 2) is passed to
memcmp() without checking line[1].
It means that line[1] can be any arbitrary character. For example,
"#KCONFIG_FOO is not set" is accepted as valid input, functioning the
same as "# CONFIG_FOO is not set".
More importantly, this can potentially lead to a buffer overrun if
line[1] == '\0'. It occurs if the input only contains '#', as
(line + 2) points to an uninitialized buffer.
Check line[1], and skip the line if it is not a space.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
xrealloc() never returns NULL as it is checked in the callee.
This is a left-over of commit d717f24d8c ("kconfig: add xrealloc()
helper").
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The long version --rules-file and --jobs are available since 1.18.8
while their short analogues -R and -j have been added since 1.14.7.
The option --rules-file the way it works currently was introduced in the
commit 5cd52673aabdf5eaa58181972119a41041fc85f2 of dpkg dated 23.07.18
with the following changelog entry:
* Fix dpkg-buildpackage option --rules-file parsing. It was trying to parse
it as --rules-target, which due to the ordering was a no-op.
The current behavior of the long version --rules-file is guaranteed to
be in use starting 1.19.1 and might cause build failures for some
versions newer than 1.18.8 even in spite of being documented that way.
Signed-off-by: Dmitrii Bundin <dmitrii.bundin.a@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
When a user-supplied value is out of range, (NEW) and an incorrect default
value are shown.
[Test Kconfig]
config FOO
int "foo"
range 10 20
[Test .config]
CONFIG_FOO=30
[Result without this fix]
$ make config
*
* Main menu
*
foo (FOO) [10] (NEW)
[Result with this fix]
$ make config
*
* Main menu
*
foo (FOO) [20]
Currently, the SYMBOL_DEF_USER is cleared if the user input does not
reside within the range. Kconfig forgets the initial value 30, and
prints (NEW) and an incorrect default [10].
Kconfig should remember the user's input. The default should be [20]
because the user's input, 30, is closer to the upper limit of the range.
Please note it will not show up in "make oldconfig" because it is no
longer considered as a new symbol. It also fixes the inconsistent
behavior in listnewconfig/helpnewconfig.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
getopt_long() is used by various tools in the kernel (e.g. Kconfig).
It should be fine to use it all the time.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Commit 74d9317161 ("genksyms: remove symbol prefix support") removed
the -s (--symbol-prefix) option.
Clean up the left-over.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Update code comment to clarify that the only element whose layout is
not randomized is a proper C99 flexible-array member. This update is
complementary to commit 1ee60356c2 ("gcc-plugins: randstruct: Only
warn about true flexible arrays")
Signed-off-by: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/ZWJr2MWDjXLHE8ap@work
Fixes: 1ee60356c2 ("gcc-plugins: randstruct: Only warn about true flexible arrays")
Signed-off-by: Kees Cook <keescook@chromium.org>
uapi headers should not expose CONFIG switches since they are not
available in userspace. Fix it in arch/hexagon/include/uapi/asm/user.h
by always defining the cs0 and cs1 entries instead of pad values.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
For some unknown reason the regular expression for checkstack only matches
three digit numbers starting with the number "3", or any higher
number. Which means that it skips any stack sizes smaller than 304
bytes. This makes the checkstack script a bit less useful than it could be.
Change the script to match any number. To be filtered out stack sizes
can be configured with the min_stack variable, which omits any stack
frame sizes smaller than 100 bytes by default.
Tested-by: Alexander Gordeev <agordeev@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
Pull Kbuild fixes from Masahiro Yamada:
- Fix section mismatch warning messages for riscv and loongarch
- Remove CONFIG_IA64 left-over from linux/export-internal.h
- Fix the location of the quotes for UIMAGE_NAME
- Fix a memory leak bug in Kconfig
* tag 'kbuild-fixes-v6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
kconfig: fix memory leak from range properties
kbuild: Move the single quotes for image name
linux/export: clean up the IA-64 KSYM_FUNC macro
modpost: fix section mismatch message for RELA
Currently, sym_validate_range() duplicates the range string using
xstrdup(), which is overwritten by a subsequent sym_calc_value() call.
It results in a memory leak.
Instead, only the pointer should be copied.
Below is a test case, with a summary from Valgrind.
[Test Kconfig]
config FOO
int "foo"
range 10 20
[Test .config]
CONFIG_FOO=0
[Before]
LEAK SUMMARY:
definitely lost: 3 bytes in 1 blocks
indirectly lost: 0 bytes in 0 blocks
possibly lost: 0 bytes in 0 blocks
still reachable: 17,465 bytes in 21 blocks
suppressed: 0 bytes in 0 blocks
[After]
LEAK SUMMARY:
definitely lost: 0 bytes in 0 blocks
indirectly lost: 0 bytes in 0 blocks
possibly lost: 0 bytes in 0 blocks
still reachable: 17,462 bytes in 20 blocks
suppressed: 0 bytes in 0 blocks
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Add quotes where UIMAGE_NAME is used, rather than where it is defined.
This allows the UIMAGE_NAME variable to be set by the user.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The section mismatch check prints a bogus symbol name on some
architectures.
[test code]
#include <linux/init.h>
int __initdata foo;
int get_foo(void) { return foo; }
If you compile it with GCC for riscv or loongarch, modpost will show an
incorrect symbol name:
WARNING: modpost: vmlinux: section mismatch in reference: get_foo+0x8 (section: .text) -> done (section: .init.data)
To get the correct symbol address, the st_value must be added.
This issue has never been noticed since commit 93684d3b80 ("kbuild:
include symbol names in section mismatch warnings") presumably because
st_value becomes zero on most architectures when the referenced symbol
is looked up. It is not true for riscv or loongarch, at least.
With this fix, modpost will show the correct symbol name:
WARNING: modpost: vmlinux: section mismatch in reference: get_foo+0x8 (section: .text) -> foo (section: .init.data)
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
The iglob function, which we use to find C source files in the kernel
tree, always follows symbolic links. This can cause unintentional
recursions whenever a symbolic link points to a parent directory. A
common scenario is building the kernel with the output set to a
directory inside the kernel tree, which will contain such a symlink.
Instead of using the iglob function, use os.walk to traverse the
directory tree, which by default doesn't follow symbolic links. fnmatch
is then used to match the glob on the filename, as well as ignore hidden
files (which were ignored by default with iglob).
This approach runs just as fast as using iglob.
Fixes: b6acf80735 ("dt: Add a check for undocumented compatible strings in kernel")
Reported-by: Aishwarya TCV <aishwarya.tcv@arm.com>
Closes: https://lore.kernel.org/all/e90cb52f-d55b-d3ba-3933-6cc7b43fcfbc@arm.com
Signed-off-by: "Nícolas F. R. A. Prado" <nfraprado@collabora.com>
Link: https://lore.kernel.org/r/20231107225624.9811-1-nfraprado@collabora.com
Signed-off-by: Rob Herring <robh@kernel.org>
