| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Currently, every expression in Kconfig files produces a new abstract
syntax tree (AST), even if it is identical to a previously encountered
one.
Consider the following code:
config FOO
bool "FOO"
depends on (A || B) && C
config BAR
bool "BAR"
depends on (A || B) && C
config BAZ
bool "BAZ"
depends on A || B
The "depends on" lines are similar, but currently a separate AST is
allocated for each one.
The current data structure looks like this:
FOO->dep ==> AND BAR->dep ==> AND BAZ->dep ==> OR
/ \ / \ / \
OR C OR C A B
/ \ / \
A B A B
This is redundant; FOO->dep and BAR->dep have identical ASTs but
different memory instances.
We can optimize this; FOO->dep and BAR->dep can share the same AST, and
BAZ->dep can reference its sub tree.
The optimized data structure looks like this:
FOO->dep, BAR->dep ==> AND
/ \
BAZ->dep ==> OR C
/ \
A B
This commit introduces a hash table to keep track of allocated
expressions. If an identical expression is found, it is reused.
This does not necessarily result in memory savings, as menu_finalize()
transforms expressions without freeing up stale ones. This will be
addressed later.
One optimization that can be easily implemented is caching the
expression's value. Once FOO's dependency, (A || B) && C, is calculated,
it can be cached, eliminating the need to recalculate it for BAR.
This commit also reverts commit e983b7b17ad1 ("kconfig/menu.c: fix
multiple references to expressions in menu_add_prop()").
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
Currently, expr_eliminate_dups() passes two identical pointers down to
expr_eliminate_dups1(), which later skips processing identical leaves.
This approach is somewhat tricky and, more importantly, it will not work
with the refactoring made in the next commit.
This commit slightly changes the recursion logic; it deduplicates both
the left and right arms, and then passes them to expr_eliminate_dups1().
expr_eliminate_dups() should produce the same result.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
Provide explanations for complex transformations.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
This clarifies the behavior of these functions.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
This function was originally added by commit 8af27e1dc4e4 ("fixdep: use
hash table instead of a single array").
Move it to scripts/include/ so that other host programs can use it.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
Change the 'overflow' variable to bool. Also, remove unnecessary
parentheses.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
After commit 64e166099b69 ("kallsyms: get rid of code for absolute,
kallsyms"), there is only one call site for output_address(). Squash it.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
When CONFIG_BUILTIN_MODULE_RANGES is enabled, the modules.builtin.ranges
file should be installed in the module install location.
Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com>
Reviewed-by: Nick Alcock <nick.alcock@oracle.com>
Tested-by: Sam James <sam@gentoo.org>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Tested-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
The modules.builtin.ranges offset range data for builtin modules is
generated at compile time based on the list of built-in modules and
the vmlinux.map and vmlinux.o.map linker maps. This data can be used
to determine whether a symbol at a particular address belongs to
module code that was configured to be compiled into the kernel proper
as a built-in module (rather than as a standalone module).
This patch adds a script that uses the generated modules.builtin.ranges
data to annotate the symbols in the System.map with module names if
their address falls within a range that belongs to one or more built-in
modules.
It then processes the vmlinux.map (and if needed, vmlinux.o.map) to
verify the annotation:
- For each top-level section:
- For each object in the section:
- Determine whether the object is part of a built-in module
(using modules.builtin and the .*.cmd file used to compile
the object as suggested in [0])
- For each symbol in that object, verify that the built-in
module association (or lack thereof) matches the annotation
given to the symbol.
Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com>
Reviewed-by: Nick Alcock <nick.alcock@oracle.com>
Reviewed-by: Alan Maguire <alan.maguire@oracle.com>
Tested-by: Sam James <sam@gentoo.org>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Tested-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
Create file module.builtin.ranges that can be used to find where
built-in modules are located by their addresses. This will be useful for
tracing tools to find what functions are for various built-in modules.
The offset range data for builtin modules is generated using:
- modules.builtin: associates object files with module names
- vmlinux.map: provides load order of sections and offset of first member
per section
- vmlinux.o.map: provides offset of object file content per section
- .*.cmd: build cmd file with KBUILD_MODFILE
The generated data will look like:
.text 00000000-00000000 = _text
.text 0000baf0-0000cb10 amd_uncore
.text 0009bd10-0009c8e0 iosf_mbi
...
.text 00b9f080-00ba011a intel_skl_int3472_discrete
.text 00ba0120-00ba03c0 intel_skl_int3472_discrete intel_skl_int3472_tps68470
.text 00ba03c0-00ba08d6 intel_skl_int3472_tps68470
...
.data 00000000-00000000 = _sdata
.data 0000f020-0000f680 amd_uncore
For each ELF section, it lists the offset of the first symbol. This can
be used to determine the base address of the section at runtime.
Next, it lists (in strict ascending order) offset ranges in that section
that cover the symbols of one or more builtin modules. Multiple ranges
can apply to a single module, and ranges can be shared between modules.
The CONFIG_BUILTIN_MODULE_RANGES option controls whether offset range data
is generated for kernel modules that are built into the kernel image.
How it works:
1. The modules.builtin file is parsed to obtain a list of built-in
module names and their associated object names (the .ko file that
the module would be in if it were a loadable module, hereafter
referred to as <kmodfile>). This object name can be used to
identify objects in the kernel compile because any C or assembler
code that ends up into a built-in module will have the option
-DKBUILD_MODFILE=<kmodfile> present in its build command, and those
can be found in the .<obj>.cmd file in the kernel build tree.
If an object is part of multiple modules, they will all be listed
in the KBUILD_MODFILE option argument.
This allows us to conclusively determine whether an object in the
kernel build belong to any modules, and which.
2. The vmlinux.map is parsed next to determine the base address of each
top level section so that all addresses into the section can be
turned into offsets. This makes it possible to handle sections
getting loaded at different addresses at system boot.
We also determine an 'anchor' symbol at the beginning of each
section to make it possible to calculate the true base address of
a section at runtime (i.e. symbol address - symbol offset).
We collect start addresses of sections that are included in the top
level section. This is used when vmlinux is linked using vmlinux.o,
because in that case, we need to look at the vmlinux.o linker map to
know what object a symbol is found in.
And finally, we process each symbol that is listed in vmlinux.map
(or vmlinux.o.map) based on the following structure:
vmlinux linked from vmlinux.a:
vmlinux.map:
<top level section>
<included section> -- might be same as top level section)
<object> -- built-in association known
<symbol> -- belongs to module(s) object belongs to
...
vmlinux linked from vmlinux.o:
vmlinux.map:
<top level section>
<included section> -- might be same as top level section)
vmlinux.o -- need to use vmlinux.o.map
<symbol> -- ignored
...
vmlinux.o.map:
<section>
<object> -- built-in association known
<symbol> -- belongs to module(s) object belongs to
...
3. As sections, objects, and symbols are processed, offset ranges are
constructed in a straight-forward way:
- If the symbol belongs to one or more built-in modules:
- If we were working on the same module(s), extend the range
to include this object
- If we were working on another module(s), close that range,
and start the new one
- If the symbol does not belong to any built-in modules:
- If we were working on a module(s) range, close that range
Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com>
Reviewed-by: Nick Alcock <nick.alcock@oracle.com>
Reviewed-by: Alan Maguire <alan.maguire@oracle.com>
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Tested-by: Sam James <sam@gentoo.org>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Tested-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
In order to create the file at build time, modules.builtin.ranges, that
contains the range of addresses for all built-in modules, there needs to
be a way to identify what code is compiled into modules.
To identify what code is compiled into modules during a kernel build,
one can look for the presence of the -DKBUILD_MODFILE and -DKBUILD_MODNAME
options in the compile command lines. A simple grep in .*.cmd files for
those options is sufficient for this.
Unfortunately, these options are only passed when compiling C source files.
Various modules also include objects built from assembler source, and these
options are not passed in that case.
Adding $(modfile_flags) to modkern_aflags (similar to modkern_cflags), and
adding $(modname_flags) to a_flags (similar to c_flags) makes it possible
to identify which objects are compiled into modules for both C and
assembler source files. While KBUILD_MODFILE is sufficient to generate
the modules ranges data, KBUILD_MODNAME is passed as well for consistency
with the C source code case.
Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com>
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Tested-by: Sam James <sam@gentoo.org>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Tested-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
When building the Linux kernel on an aarch64 macOS based host, if we don't
specify a value for ARCH when invoking make, we default to arm and thus
multi_v7_defconfig rather than the expected arm64 and arm64's defconfig.
This is because subarch.include invokes `uname -m` which on MacOS hosts
evaluates to `arm64` but on Linux hosts evaluates to `aarch64`,
This allows us to build ARCH=arm64 natively on macOS (as in ARCH need
not be specified on an aarch64-based system).
Avoid matching arm64 by excluding it from the arm.* sed expression.
Signed-off-by: Nick Desaulniers <nick.desaulniers@gmail.com>
Suggested-by: Nicolas Schier <nicolas@fjasle.eu>
Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
Add more macros used for removing hash table entries.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
scripts/Makefile.lib is included not only from scripts/Makefile.build
but also from scripts/Makefile.{modfinal,package,vmlinux,vmlinux_o},
where DT build rules are not required.
Split the DT build rules out to scripts/Makefile.dtbs, and include it
only when necessary.
While I was here, I added $(DT_TMP_SCHEMA) as a prerequisite of
$(multi-dtb-y).
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
|
|
Flex and Bison are used only for host programs. Move their intermediate
target processing from scripts/Makefile.build to scripts/Makefile.host.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
Various information about modules is compiled into the info sections.
For that a dedicated .mod.c file is generated by modpost for each module
and then linked into the module.
However most of the information in the .mod.c is the same for all
modules, internal and external.
Split the shared information into a dedicated source file that is
compiled once and then linked into all modules.
This avoids frequent rebuilds for all .mod.c files when using
CONFIG_LOCALVERSION_AUTO because the local version ends up in .mod.c
through UTS_RELEASE and VERMAGIC_STRING.
The modules are still relinked in this case.
The code is also easier to maintain as it's now in a proper source file
instead of an inline string literal.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
Remove the recently-added dependency on the truncate program for
building the kernel. truncate is not available when building the kernel
under Yocto. It could be added, but it would be better just to avoid
the unnecessary dependency.
Fixes: 1472464c6248 ("kbuild: avoid scripts/kallsyms parsing /dev/null")
Signed-off-by: Tony Battersby <tonyb@cybernetics.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
Add a new debug package to the PKGBUILD for the pacman-pkg target. The
debug package includes the non-stripped vmlinux file with debug symbols
for kernel debugging and profiling. The file is installed at
/usr/src/debug/${pkgbase}, with a symbolic link at
/usr/lib/modules/$(uname -r)/build/vmlinux. The debug package is built
by default.
Signed-off-by: Jose Fernandez <jose.fernandez@linux.dev>
Reviewed-by: Peter Jung <ptr1337@cachyos.org>
Acked-by: Thomas Weißschuh <linux@weissschuh.net>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
With commit cda5f94e88b4 ("modpost: avoid using the alias attribute"),
only two log levels remain: LOG_WARN and LOG_ERROR. Simplify this by
making it a boolean variable.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
|
|
objtree is defined and exported by the top-level Makefile. I prefer
not to override it.
There is no need to pass the absolute path of objtree. PKGBUILD can
detect it by itself.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Thomas Weißschuh <linux@weissschuh.net>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Christian Heusel <christian@heusel.eu>
|
|
All build and package functions share the following commands:
export MAKEFLAGS="${KBUILD_MAKEFLAGS}"
cd "${objtree}"
Factor out the common code.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Thomas Weißschuh <linux@weissschuh.net>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Christian Heusel <christian@heusel.eu>
|
|
Introduce the PACMAN_EXTRAPACKAGES variable in PKGBUILD to allow users
to specify which additional packages are built by the pacman-pkg target.
Previously, the api-headers package was always included, and the headers
package was included only if CONFIG_MODULES=y. With this change, both
headers and api-headers packages are included by default. Users can now
control this behavior by setting PACMAN_EXTRAPACKAGES to a
space-separated list of desired extra packages or leaving it empty to
exclude all.
For example, to build only the base package without extras:
make pacman-pkg PACMAN_EXTRAPACKAGES=""
Signed-off-by: Jose Fernandez <jose.fernandez@linux.dev>
Reviewed-by: Peter Jung <ptr1337@cachyos.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Christian Heusel <christian@heusel.eu>
Tested-by: Christian Heusel <christian@heusel.eu>
Acked-by: Thomas Weißschuh <linux@weissschuh.net>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
This commit improves the section mismatch warning format when there is
no suitable symbol name to print.
The section mismatch warning prints the reference source in the form
of <symbol_name>+<offset> and the reference destination in the form
of <symbol_name>.
However, there are some corner cases where <symbol_name> becomes
"(unknown)", as reported in commit 23dfd914d2bf ("modpost: fix null
pointer dereference").
In such cases, it is better to print the symbol address.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
When malloc() fails, there is not much userspace programs can do.
xmalloc() is useful to bail out on a memory allocation failure.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
When malloc() or realloc() fails, there is not much userspace programs
can do. xmalloc() and xrealloc() are useful to bail out on a memory
allocation failure.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
I think x*alloc() functions are cleaner.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
These functions will be useful for other host programs.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
P_SYMBOL is a pseudo property that was previously used for data linking
purposes.
It is no longer used except for debug prints. Remove it.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
I believe its last usage was in the following code:
if (prop == NULL)
prop = stack->sym->prop;
This code was previously used to print the file name and line number of
associated symbols in sym_check_print_recursive(), which was removed by
commit 9d0d26604657 ("kconfig: recursive checks drop file/lineno").
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
Since commit ca4c74ba306e ("kconfig: remove P_CHOICE property"),
menu_finalize() no longer calls menu_add_symbol(). No function
references cur_filename or cur_lineno after yyparse().
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
Parallel execution is supported by GNU Make:
$ make -j<N> modules_install
It is questionable to enable multithreading within each zstd process
by default.
If you still want to do it, you can use the environment variable:
$ ZSTD_NBTHREADS=<N> make modules_install
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
|
|
A long standing issue in the upstream kernel packaging is that the
linux-headers package is not cross-compiled.
For example, you can cross-build Debian packages for arm64 by running
the following command:
$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- bindeb-pkg
However, the generated linux-headers-*_arm64.deb is useless because the
host programs in it were built for your build machine architecture
(likely x86), not arm64.
The Debian kernel maintains its own Makefiles to cross-compile host
tools without relying on Kbuild. [1]
Instead of adding such full custom Makefiles, this commit adds a small
piece of code to cross-compile host programs located under the scripts/
directory.
A straightforward solution is to pass HOSTCC=${CROSS_COMPILE}gcc, but it
would also cross-compile scripts/basic/fixdep, which needs to be native
to process the if_changed_dep macro. (This approach may work under some
circumstances; you can execute foreign architecture programs with the
help of binfmt_misc because Debian systems enable CONFIG_BINFMT_MISC,
but it would require installing QEMU and libc for that architecture.)
A trick is to use the external module build (KBUILD_EXTMOD=), which
does not rebuild scripts/basic/fixdep. ${CC} needs to be able to link
userspace programs (CONFIG_CC_CAN_LINK=y).
There are known limitations:
- GCC plugins
It would possible to rebuild GCC plugins for the target architecture
by passing HOSTCXX=${CROSS_COMPILE}g++ with necessary packages
installed, but gcc on the installed system emits
"cc1: error: incompatible gcc/plugin versions".
- objtool and resolve_btfids
These are built by the tools build system. They are not covered by
the current solution. The resulting linux-headers package is broken
if CONFIG_OBJTOOL or CONFIG_DEBUG_INFO_BTF is enabled.
I only tested this with Debian, but it should work for other package
systems as well.
[1]: https://salsa.debian.org/kernel-team/linux/-/blob/debian/6.9.9-1/debian/rules.real#L586
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
|
|
Exclude directories and files unnecessary for building external modules:
- include/config/ (except include/config/{auto.conf,kernel.release})
- scripts/atomic/
- scripts/dtc/
- scripts/kconfig/
- scripts/mod/mk_elfconfig
- scripts/package/
- scripts/unifdef
- .config
- *.o
- .*.cmd
Avoid copying files twice for the following directories:
- include/generated/
- arch/*/include/generated/
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
|
|
Endianness is currently detected on compile-time, but we can defer this
until run-time. This change avoids re-executing scripts/mod/mk_elfconfig
even if modpost in the linux-headers package needs to be rebuilt for a
foreign architecture.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
|
|
HOST_ELFCLASS is output to elfconfig.h, but it is not used in modpost.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
|
|
As we discussed in the room at netdevconf earlier this week,
drop the requirement for special comment style for netdev.
For checkpatch, the general check accepts both right now, so
simply drop the special request there as well.
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Acked-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild
Pull Kbuild fixes from Masahiro Yamada:
- Eliminate the fdtoverlay command duplication in scripts/Makefile.lib
- Fix 'make compile_commands.json' for external modules
- Ensure scripts/kconfig/merge_config.sh handles missing newlines
- Fix some build errors on macOS
* tag 'kbuild-fixes-v6.11-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
kbuild: fix typos "prequisites" to "prerequisites"
Documentation/llvm: turn make command for ccache into code block
kbuild: avoid scripts/kallsyms parsing /dev/null
treewide: remove unnecessary <linux/version.h> inclusion
scripts: kconfig: merge_config: config files: add a trailing newline
Makefile: add $(srctree) to dependency of compile_commands.json target
kbuild: clean up code duplication in cmd_fdtoverlay
|
|
This typo in scripts/Makefile.build has been present for more than 20
years. It was accidentally copy-pasted to other scripts/Makefile.* files.
Fix them all.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
|
|
Pull rust fixes from Miguel Ojeda:
- Fix '-Os' Rust 1.80.0+ builds adding more intrinsics (also tweaked in
upstream Rust for the upcoming 1.82.0).
- Fix support for the latest version of rust-analyzer due to a change
on rust-analyzer config file semantics (considered a fix since most
developers use the latest version of the tool, which is the only one
actually supported by upstream). I am discussing stability of the
config file with upstream -- they may be able to start versioning it.
- Fix GCC 14 builds due to '-fmin-function-alignment' not skipped for
libclang (bindgen).
- A couple Kconfig fixes around '{RUSTC,BINDGEN}_VERSION_TEXT' to
suppress error messages in a foreign architecture chroot and to use a
proper default format.
- Clean 'rust-analyzer' target warning due to missing recursive make
invocation mark.
- Clean Clippy warning due to missing indentation in docs.
- Clean LLVM 19 build warning due to removed 3dnow feature upstream.
* tag 'rust-fixes-6.11' of https://github.com/Rust-for-Linux/linux:
rust: x86: remove `-3dnow{,a}` from target features
kbuild: rust-analyzer: mark `rust_is_available.sh` invocation as recursive
rust: add intrinsics to fix `-Os` builds
kbuild: rust: skip -fmin-function-alignment in bindgen flags
rust: Support latest version of `rust-analyzer`
rust: macros: indent list item in `module!`'s docs
rust: fix the default format for CONFIG_{RUSTC,BINDGEN}_VERSION_TEXT
rust: suppress error messages from CONFIG_{RUSTC,BINDGEN}_VERSION_TEXT
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux
Pull hardening fixes from Kees Cook:
- gcc-plugins: randstruct: Remove GCC 4.7 or newer requirement
(Thorsten Blum)
- kallsyms: Clean up interaction with LTO suffixes (Song Liu)
- refcount: Report UAF for refcount_sub_and_test(0) when counter==0
(Petr Pavlu)
- kunit/overflow: Avoid misallocation of driver name (Ivan Orlov)
* tag 'hardening-v6.11-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
kallsyms: Match symbols exactly with CONFIG_LTO_CLANG
kallsyms: Do not cleanup .llvm.<hash> suffix before sorting symbols
kunit/overflow: Fix UB in overflow_allocation_test
gcc-plugins: randstruct: Remove GCC 4.7 or newer requirement
refcount: Report UAF for refcount_sub_and_test(0) when counter==0
|
|
Cleaning up the symbols causes various issues afterwards. Let's sort
the list based on original name.
Signed-off-by: Song Liu <song@kernel.org>
Fixes: 8cc32a9bbf29 ("kallsyms: strip LTO-only suffixes from promoted global functions")
Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Tested-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Acked-by: Petr Mladek <pmladek@suse.com>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
Link: https://lore.kernel.org/r/20240807220513.3100483-2-song@kernel.org
Signed-off-by: Kees Cook <kees@kernel.org>
|
|
On macOS, as reported by Daniel Gomez, getline() sets ENOTTY to errno
if it is requested to read from /dev/null.
If this is worth fixing, I would rather pass an empty file to
scripts/kallsyms instead of adding the ugly #ifdef __APPLE__.
Fixes: c442db3f49f2 ("kbuild: remove PROVIDE() for kallsyms symbols")
Reported-by: Daniel Gomez <da.gomez@samsung.com>
Closes: https://lore.kernel.org/all/20240807-macos-build-support-v1-12-4cd1ded85694@samsung.com/
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
Reviewed-by: Daniel Gomez <da.gomez@samsung.com>
|
|
LLVM 19 is dropping support for 3DNow! in commit f0eb5587ceeb ("Remove
support for 3DNow!, both intrinsics and builtins. (#96246)"):
Remove support for 3DNow!, both intrinsics and builtins. (#96246)
This set of instructions was only supported by AMD chips starting in
the K6-2 (introduced 1998), and before the "Bulldozer" family
(2011). They were never much used, as they were effectively superseded
by the more-widely-implemented SSE (first implemented on the AMD side
in Athlon XP in 2001).
This is being done as a predecessor towards general removal of MMX
register usage. Since there is almost no usage of the 3DNow!
intrinsics, and no modern hardware even implements them, simple
removal seems like the best option.
Thus we should avoid passing these to the backend, since otherwise we
get a diagnostic about it:
'-3dnow' is not a recognized feature for this target (ignoring feature)
'-3dnowa' is not a recognized feature for this target (ignoring feature)
We could try to disable them only up to LLVM 19 (not the C side one,
but the one used by `rustc`, which may be built with a range of
LLVMs). However, to avoid more complexity, we can likely just remove
them altogether. According to Nikita [2]:
> I don't think it's needed because LLVM should not generate 3dnow
> instructions unless specifically asked to, using intrinsics that
> Rust does not provide in the first place.
Thus do so, like Rust did for one of their builtin targets [3].
For those curious: Clang will warn only about trying to enable them
(`-m3dnow{,a}`), but not about disabling them (`-mno-3dnow{,a}`), so
there is no change needed there.
Cc: Nikita Popov <github@npopov.com>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: x86@kernel.org
Link: https://github.com/llvm/llvm-project/commit/f0eb5587ceeb641445b64cb264c822b4751de04a [1]
Link: https://github.com/rust-lang/rust/pull/127864#issuecomment-2235898760 [2]
Link: https://github.com/rust-lang/rust/pull/127864 [3]
Closes: https://github.com/Rust-for-Linux/linux/issues/1094
Tested-by: Benno Lossin <benno.lossin@proton.me>
Tested-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20240806144558.114461-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
Sets the `sysroot` field in rust-project.json which is now needed in
newer versions of rust-analyzer instead of the `sysroot_src` field.
Till [1] `rust-analyzer` used to guess the `sysroot` based on the
`sysroot_src` at [2]. Now `sysroot` is a required parameter for a
`rust-project.json` file. It is required because `rust-analyzer`
need it to find the proc-macro server [3].
In the current version of `rust-analyzer` the `sysroot_src` is only used
to include the inbuilt library crates (std, core, alloc, etc) [4]. Since
we already specify the core library to be included in the
`rust-project.json` we don't need to define the `sysroot_src`.
Code editors like VS Code try to use the latest version of rust-analyzer
(which is updated every week) instead of the version of rust-analyzer
that comes with the rustup toolchain (which is updated every six weeks
along with the rust version).
Without this change `rust-analyzer` is breaking for anyone using VS Code.
As they are getting the latest version of `rust-analyzer` with the
changes made in [1].
`rust-analyzer` will also start breaking for other developers as they
update their rust version (assuming that also updates the rust-analyzer
version on their system).
This patch should work with every setup as there is no more guess work
being done by `rust-analyzer`.
[ Lukas, who leads the rust-analyzer team, says:
`sysroot_src` is required now if you want to have the sysroot
source libraries be loaded. I think we used to infer it as
`{sysroot}/lib/rustlib/src/rust/library` before when only the
`sysroot` field was given but that was since changed to make it
possible in having a sysroot without the standard library sources
(that is only have the binaries available). So if you want the
library sources to be loaded by rust-analyzer you will have to set
that field as well now.
- Miguel ]
Link: https://github.com/rust-lang/rust-analyzer/pull/17287 [1]
Link: https://github.com/rust-lang/rust-analyzer/blob/f372a8a1176ff8dd5f45ab2ddd45f3530db0374f/crates/project-model/src/workspace.rs#L367-L374 [2]
Link: https://github.com/rust-lang/rust-analyzer/blob/eeb192b79aeac47b40add66347022af17a74fbaf/crates/project-model/src/sysroot.rs#L180-L192 [3]
Link: https://github.com/search?q=repo%3AVeykril%2Frust-analyzer%20src_root()&type=code [4]
Tested-by: Dirk Behme <dirk.behme@de.bosch.com>
Signed-off-by: Sarthak Singh <sarthak.singh99@gmail.com>
Link: https://rust-for-linux.zulipchat.com/#narrow/stream/291565-Help/topic/How.20to.20rust-analyzer.20correctly.20working
Link: https://lore.kernel.org/r/20240724172713.899399-1-sarthak.singh99@gmail.com
[ Formatted comment, fixed typo and removed spurious empty line. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
The conversion from the old unistd.h file to syscall.tbl dropped the
nfsservctl macro. This one was handled inconsistently across architectures
in the original introduction of the syscall.tbl format, and I went the
other way on this.
The syscall was already gone in linux-3.1 before the current users
of the generic table (other than openrisc) first appeared, so nobody
could actally use it, but putting the number back helps for consistency
since there are build scripts that check the presence of all these
macros.
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2301919
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
When merging files without trailing newlines at the end of the file, two
config fragments end up at the same row if file1.config doens't have a
trailing newline at the end of the file.
file1.config "CONFIG_1=y"
file2.config "CONFIG_2=y"
./scripts/kconfig/merge_config.sh -m .config file1.config file2.config
This will generate a .config looking like this.
cat .config
...
CONFIG_1=yCONFIG_2=y"
Making sure so we add a newline at the end of every config file that is
passed into the script.
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
When resolving a merge conflict, Linus noticed the fdtoverlay command
duplication introduced by commit 49636c5680b9 ("kbuild: verify dtoverlay
files against schema"). He suggested a clean-up.
I eliminated the duplication and refactored the code a little further.
No functional changes are intended, except for the short logs.
The log will look as follows:
$ make ARCH=arm64 defconfig dtbs_check
[ snip ]
DTC [C] arch/arm64/boot/dts/freescale/imx93-tqma9352-mba93xxca.dtb
DTC [C] arch/arm64/boot/dts/freescale/imx93-tqma9352-mba93xxla.dtb
DTC [C] arch/arm64/boot/dts/freescale/imx93-var-som-symphony.dtb
DTC [C] arch/arm64/boot/dts/freescale/imx95-19x19-evk.dtb
DTC arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx-0x-imx219.dtbo
OVL [C] arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx-0x-imx219.dtb
The tag [C] indicates that the schema check is executed.
Link: https://lore.kernel.org/lkml/CAHk-=wiF3yeWehcvqY-4X7WNb8n4yw_5t0H1CpEpKi7JMjaMfw@mail.gmail.com/#t
Requested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
|
|
Since the kernel currently requires GCC 5.1 as a minimum, remove the
unnecessary GCC version >= 4.7 check.
Signed-off-by: Thorsten Blum <thorsten.blum@toblux.com>
Link: https://lore.kernel.org/r/20240723165332.1947-1-thorsten.blum@toblux.com
Signed-off-by: Kees Cook <kees@kernel.org>
|
|
The previous patch to fix the newfstatat() syscall entry ended up breaking
fstat() instead. Unfortunately these two are not handled the same way, so
I messed this one up the exact opposite way.
Fixes: 343416f0c11c ("syscalls: fix syscall macros for newfstat/newfstatat")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
The __NR_newfstat and __NR_newfstatat macros accidentally got renamed
in the conversion to the syscall.tbl format, dropping the 'new' portion
of the name.
In an unrelated change, the two syscalls are no longer architecture
specific but are once more defined on all 64-bit architectures, so the
'newstat' ABI keyword can be dropped from the table as a simplification.
Fixes: Fixes: 4fe53bf2ba0a ("syscalls: add generic scripts/syscall.tbl")
Closes: https://lore.kernel.org/lkml/838053e0-b186-4e9f-9668-9a3384a71f23@app.fastmail.com/T/#t
Reported-by: Florian Weimer <fweimer@redhat.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
