| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
(gdb) lx-mounts
mount super_block devname pathname fstype options
Python Exception <class 'gdb.error'>: There is no member named list.
Error occurred in Python: There is no member named list.
We encounter the above issue after commit 2eea9ce4310d ("mounts: keep
list of mounts in an rbtree"). The commit move a mount from list into
rbtree.
So we can instead use rbtree to iterate all mounts information.
Link: https://lkml.kernel.org/r/[email protected]
Fixes: 2eea9ce4310d ("mounts: keep list of mounts in an rbtree")
Signed-off-by: Kuan-Ying Lee <[email protected]>
Cc: Jan Kiszka <[email protected]>
Cc: Kieran Bingham <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
|
|
Add inorder iteration function for rbtree usage.
This is a preparation patch for the next patch to fix the gdb mounts
issue.
Link: https://lkml.kernel.org/r/[email protected]
Fixes: 2eea9ce4310d ("mounts: keep list of mounts in an rbtree")
Signed-off-by: Kuan-Ying Lee <[email protected]>
Cc: Jan Kiszka <[email protected]>
Cc: Kieran Bingham <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
|
|
Patch series "Fix some GDB command error and add some GDB commands", v3.
Fix some GDB command errors and add some useful GDB commands.
This patch (of 5):
Commit 7988e5ae2be7 ("tick: Split nohz and highres features from
nohz_mode") and commit 7988e5ae2be7 ("tick: Split nohz and highres
features from nohz_mode") move 'tick_stopped' and 'nohz_mode' to flags
field which will break the gdb lx-mounts command:
(gdb) lx-timerlist
Python Exception <class 'gdb.error'>: There is no member named nohz_mode.
Error occurred in Python: There is no member named nohz_mode.
(gdb) lx-timerlist
Python Exception <class 'gdb.error'>: There is no member named tick_stopped.
Error occurred in Python: There is no member named tick_stopped.
We move 'tick_stopped' and 'nohz_mode' to flags field instead.
Link: https://lkml.kernel.org/r/[email protected]
Link: https://lkml.kernel.org/r/[email protected]
Fixes: a478ffb2ae23 ("tick: Move individual bit features to debuggable mask accesses")
Fixes: 7988e5ae2be7 ("tick: Split nohz and highres features from nohz_mode")
Signed-off-by: Kuan-Ying Lee <[email protected]>
Cc: Jan Kiszka <[email protected]>
Cc: Kieran Bingham <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
|
|
Recently, I saw a patch[1] on the ext4 mailing list regarding
the correction of a macro definition error. Jan mentioned
that "The bug in the macro is a really nasty trap...".
Because existing compilers are unable to detect
unused parameters in macro definitions. This inspired me
to write a script to check for unused parameters in
macro definitions and to run it.
Surprisingly, the script uncovered numerous issues across
various subsystems, including filesystems, drivers, and sound etc.
Some of these issues involved parameters that were accepted
but never used, for example:
#define XFS_DAENTER_DBS(mp,w) \
(XFS_DA_NODE_MAXDEPTH + (((w) == XFS_DATA_FORK) ? 2 : 0))
where mp was unused.
While others are actual bugs.
For example:
#define HAL_SEQ_WCSS_UMAC_CE0_SRC_REG(x) \
(ab->hw_params.regs->hal_seq_wcss_umac_ce0_src_reg)
#define HAL_SEQ_WCSS_UMAC_CE0_DST_REG(x) \
(ab->hw_params.regs->hal_seq_wcss_umac_ce0_dst_reg)
#define HAL_SEQ_WCSS_UMAC_CE1_SRC_REG(x) \
(ab->hw_params.regs->hal_seq_wcss_umac_ce1_src_reg)
#define HAL_SEQ_WCSS_UMAC_CE1_DST_REG(x) \
(ab->hw_params.regs->hal_seq_wcss_umac_ce1_dst_reg)
where x was entirely unused, and instead, a local variable ab was used.
I have submitted patches[2-5] to fix some of these issues,
but due to the large number, many still remain unaddressed.
I believe that the kernel and matainers would benefit from
this script to check for unused parameters in macro definitions.
It should be noted that it may cause some false positives
in conditional compilation scenarios, such as
#ifdef DEBUG
static int debug(arg) {};
#else
#define debug(arg)
#endif
So the caller needs to manually verify whether it is a true
issue. But this should be fine, because Maintainers should only
need to review their own subsystems, which typically results
in only a few reports.
[1]: https://patchwork.ozlabs.org/project/linux-ext4/patch/[email protected]/
[2]: https://lore.kernel.org/linux-xfs/[email protected]/
[3]: https://lore.kernel.org/linux-bcachefs/[email protected]/
[4]: https://sourceforge.net/p/linux-f2fs/mailman/message/58797811/
[5]: https://sourceforge.net/p/linux-f2fs/mailman/message/58797812/
[[email protected]: reduce false positives]
Link: https://lkml.kernel.org/r/[email protected]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Julian Sun <[email protected]>
Cc: Al Viro <[email protected]>
Cc: Christian Brauner <[email protected]>
Cc: Darrick J. Wong <[email protected]>
Cc: Jan Kara <[email protected]>
Cc: Junchao Sun <[email protected]>
Cc: Kalle Valo <[email protected]>
Cc: Masahiro Yamada <[email protected]>
Cc: Miguel Ojeda <[email protected]>
Cc: Nicolas Schier <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
|
|
Use LZMA2 options that match the arch-specific alignment of instructions.
This change reduces compressed kernel size 0-2 % depending on the arch.
On 1-byte-aligned x86 it makes no difference and on 4-byte-aligned archs
it helps the most.
Use the ARM-Thumb filter for ARM-Thumb2 kernels. This reduces compressed
kernel size about 5 %.[1] Previously such kernels were compressed using
the ARM filter which didn't do anything useful with ARM-Thumb2 code.
Add BCJ filter support for ARM64 and RISC-V. Compared to unfiltered XZ or
plain LZMA, the compressed kernel size is reduced about 5 % on ARM64 and 7
% on RISC-V. A new enough version of the xz tool is required: 5.4.0 for
ARM64 and 5.6.0 for RISC-V. With an old xz version, a message is printed
to standard error and the kernel is compressed without the filter.
Update lib/decompress_unxz.c to match the changes to xz_wrap.sh.
Update the CONFIG_KERNEL_XZ help text in init/Kconfig:
- Add the RISC-V and ARM64 filters.
- Clarify that the PowerPC filter is for big endian only.
- Omit IA-64.
Link: https://lore.kernel.org/lkml/[email protected]/ [1]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Lasse Collin <[email protected]>
Reviewed-by: Sam James <[email protected]>
Cc: Simon Glass <[email protected]>
Cc: Catalin Marinas <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: Paul Walmsley <[email protected]>
Cc: Palmer Dabbelt <[email protected]>
Cc: Albert Ou <[email protected]>
Cc: Jubin Zhong <[email protected]>
Cc: Jules Maselbas <[email protected]>
Cc: Emil Renner Berthing <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Herbert Xu <[email protected]>
Cc: Joel Stanley <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Cc: Krzysztof Kozlowski <[email protected]>
Cc: Michael Ellerman <[email protected]>
Cc: Randy Dunlap <[email protected]>
Cc: Rui Li <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
|
|
This only affects kernel image compression, not any other xz usage.
Desktop kernels on x86-64 are already around 60 MiB. Using a dictionary
larger than 32 MiB should have no downsides nowadays as anyone building
the kernel should have plenty of RAM. 128 MiB dictionary needs 1346 MiB
of RAM with xz versions 5.0.x - 5.6.x in single-threaded mode. On archs
that use xz_wrap.sh, kernel decompression is done in single-call mode so a
larger dictionary doesn't affect boot-time memory requirements.
xz >= 5.6.0 uses multithreaded mode by default which compresses slightly
worse than single-threaded mode. Kernel compression rarely used more than
one thread anyway because with 32 MiB dictionary size the default block
size was 96 MiB in multithreaded mode. So only a single thread was used
anyway unless the kernel was over 96 MiB.
Comparison to CONFIG_KERNEL_LZMA: It uses "lzma -9" which mapped to 32 MiB
dictionary in LZMA Utils 4.32.7 (the final release in 2008). Nowadays the
lzma tool on most systems is from XZ Utils where -9 maps to 64 MiB
dictionary. So using a 32 MiB dictionary with CONFIG_KERNEL_XZ may have
compressed big kernels slightly worse than the old LZMA option.
Comparison to CONFIG_KERNEL_ZSTD: zstd uses 128 MiB dictionary.
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Lasse Collin <[email protected]>
Reviewed-by: Sam James <[email protected]>
Cc: Albert Ou <[email protected]>
Cc: Catalin Marinas <[email protected]>
Cc: Emil Renner Berthing <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Herbert Xu <[email protected]>
Cc: Joel Stanley <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Cc: Jubin Zhong <[email protected]>
Cc: Jules Maselbas <[email protected]>
Cc: Krzysztof Kozlowski <[email protected]>
Cc: Michael Ellerman <[email protected]>
Cc: Palmer Dabbelt <[email protected]>
Cc: Paul Walmsley <[email protected]>
Cc: Randy Dunlap <[email protected]>
Cc: Rui Li <[email protected]>
Cc: Simon Glass <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Will Deacon <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
|
|
- Fix comments that were no longer in sync with the code below them.
- Fix language errors.
- Fix coding style.
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Lasse Collin <[email protected]>
Reviewed-by: Sam James <[email protected]>
Cc: Albert Ou <[email protected]>
Cc: Catalin Marinas <[email protected]>
Cc: Emil Renner Berthing <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Herbert Xu <[email protected]>
Cc: Joel Stanley <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Cc: Jubin Zhong <[email protected]>
Cc: Jules Maselbas <[email protected]>
Cc: Krzysztof Kozlowski <[email protected]>
Cc: Michael Ellerman <[email protected]>
Cc: Palmer Dabbelt <[email protected]>
Cc: Paul Walmsley <[email protected]>
Cc: Randy Dunlap <[email protected]>
Cc: Rui Li <[email protected]>
Cc: Simon Glass <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Will Deacon <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
|
|
Remove the public domain notices and add SPDX license identifiers.
Change MODULE_LICENSE from "GPL" to "Dual BSD/GPL" because 0BSD should
count as a BSD license variant here.
The switch to 0BSD was done in the upstream XZ Embedded project because
public domain has (real or perceived) legal issues in some jurisdictions.
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Lasse Collin <[email protected]>
Reviewed-by: Sam James <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Albert Ou <[email protected]>
Cc: Catalin Marinas <[email protected]>
Cc: Emil Renner Berthing <[email protected]>
Cc: Herbert Xu <[email protected]>
Cc: Joel Stanley <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Cc: Jubin Zhong <[email protected]>
Cc: Jules Maselbas <[email protected]>
Cc: Krzysztof Kozlowski <[email protected]>
Cc: Michael Ellerman <[email protected]>
Cc: Palmer Dabbelt <[email protected]>
Cc: Paul Walmsley <[email protected]>
Cc: Randy Dunlap <[email protected]>
Cc: Rui Li <[email protected]>
Cc: Simon Glass <[email protected]>
Cc: Will Deacon <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
|
|
Richard reports that since 772dd0342727c ("mm: enumerate all gfp flags"),
gfp-translate is broken, as the bit numbers are implicit, leaving the
shell script unable to extract them. Even more, some bits are now at a
variable location, making it double extra hard to parse using a simple
shell script.
Use a brute-force approach to the problem by generating a small C stub
that will use the enum to dump the interesting bits.
As an added bonus, we are now able to identify invalid bits for a given
configuration. As an added drawback, we cannot parse include files that
predate this change anymore. Tough luck.
Link: https://lkml.kernel.org/r/[email protected]
Fixes: 772dd0342727 ("mm: enumerate all gfp flags")
Signed-off-by: Marc Zyngier <[email protected]>
Reported-by: Richard Weinberger <[email protected]>
Cc: Petr Tesařík <[email protected]>
Cc: Suren Baghdasaryan <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Nathan Chancellor <[email protected]>
|
|
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 <[email protected]>
Acked-by: Thomas Weißschuh <[email protected]>
Reviewed-by: Nathan Chancellor <[email protected]>
Reviewed-by: Christian Heusel <[email protected]>
|
|
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 <[email protected]>
Acked-by: Thomas Weißschuh <[email protected]>
Reviewed-by: Nathan Chancellor <[email protected]>
Reviewed-by: Christian Heusel <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Peter Jung <[email protected]>
Reviewed-by: Nathan Chancellor <[email protected]>
Tested-by: Nathan Chancellor <[email protected]>
Reviewed-by: Christian Heusel <[email protected]>
Tested-by: Christian Heusel <[email protected]>
Acked-by: Thomas Weißschuh <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
I think x*alloc() functions are cleaner.
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
These functions will be useful for other host programs.
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Nicolas Schier <[email protected]>
Tested-by: Sedat Dilek <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Nicolas Schier <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Nicolas Schier <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Nicolas Schier <[email protected]>
|
|
HOST_ELFCLASS is output to elfconfig.h, but it is not used in modpost.
Signed-off-by: Masahiro Yamada <[email protected]>
Reviewed-by: Nicolas Schier <[email protected]>
|
|
For example Documentation/adming-guide/bug-hunting.rst suggest using
get_maintainer.pl to get a list of maintainers and mailing lists to
report bugs to, while a number of subsystems and drivers explicitly use
the "B:" MAINTAINERS entry to direct bug reports at issue trackers
instead of mailing lists and people.
Add the --bug option to get_maintainer.pl to print the bug reporting
URIs, if any.
Cc: Joe Perches <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Acked-by: Joe Perches <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Acked-by: Jakub Kicinski <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Some configuration options such as the supported sanitizer list are
arrays. To support using Rust with sanitizers on x86, we must update the
target.json generator to support this case.
The Push trait is removed in favor of the From trait because the Push
trait doesn't work well in the nested case where you are not really
pushing values to a TargetSpec.
Signed-off-by: Matthew Maurer <[email protected]>
Signed-off-by: Alice Ryhl <[email protected]>
Reviewed-by: Gary Guo <[email protected]>
Tested-by: Gatlin Newhouse <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Nathan Chancellor <[email protected]>
|
|
Enables an IPE policy to be enforced from kernel start, enabling access
control based on trust from kernel startup. This is accomplished by
transforming an IPE policy indicated by CONFIG_IPE_BOOT_POLICY into a
c-string literal that is parsed at kernel startup as an unsigned policy.
Signed-off-by: Deven Bowers <[email protected]>
Signed-off-by: Fan Wu <[email protected]>
Signed-off-by: Paul Moore <[email protected]>
|
|
Now that we should be `objtool`-warning free, enable `objtool` for
Rust too.
Before this patch series, we were already getting warnings under e.g. IBT
builds, since those would see Rust code via `vmlinux.o`.
Tested-by: Alice Ryhl <[email protected]>
Tested-by: Benno Lossin <[email protected]>
Reviewed-by: Gary Guo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Solved trivial conflict. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>
|
|
Support `MITIGATION_SLS` by enabling the target features that Clang does.
Without this, `objtool` would complain if enabled for Rust, e.g.:
rust/core.o: warning: objtool:
_R...next_up+0x44: missing int3 after ret
These should be eventually enabled via `-Ctarget-feature` when `rustc`
starts recognizing them (or via a new dedicated flag) [1].
Link: https://github.com/rust-lang/rust/issues/116851 [1]
Reviewed-by: Gary Guo <[email protected]>
Tested-by: Alice Ryhl <[email protected]>
Tested-by: Benno Lossin <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
|
|
Support `MITIGATION_RETPOLINE` by enabling the target features that
Clang does.
The existing target feature being enabled was a leftover from
our old `rust` branch, and it is not enough: the target feature
`retpoline-external-thunk` only implies `retpoline-indirect-calls`, but
not `retpoline-indirect-branches` (see LLVM's `X86.td`), unlike Clang's
flag of the same name `-mretpoline-external-thunk` which does imply both
(see Clang's `lib/Driver/ToolChains/Arch/X86.cpp`).
Without this, `objtool` would complain if enabled for Rust, e.g.:
rust/core.o: warning: objtool:
_R...escape_default+0x13: indirect jump found in RETPOLINE build
In addition, change the comment to note that LLVM is the one disabling
jump tables when retpoline is enabled, thus we do not need to use
`-Zno-jump-tables` for Rust here -- see commit c58f2166ab39 ("Introduce
the "retpoline" x86 mitigation technique ...") [1]:
The goal is simple: avoid generating code which contains an indirect
branch that could have its prediction poisoned by an attacker. In
many cases, the compiler can simply use directed conditional
branches and a small search tree. LLVM already has support for
lowering switches in this way and the first step of this patch is
to disable jump-table lowering of switches and introduce a pass to
rewrite explicit indirectbr sequences into a switch over integers.
As well as a live example at [2].
These should be eventually enabled via `-Ctarget-feature` when `rustc`
starts recognizing them (or via a new dedicated flag) [3].
Cc: Daniel Borkmann <[email protected]>
Link: https://github.com/llvm/llvm-project/commit/c58f2166ab3987f37cb0d7815b561bff5a20a69a [1]
Link: https://godbolt.org/z/G4YPr58qG [2]
Link: https://github.com/rust-lang/rust/issues/116852 [3]
Reviewed-by: Gary Guo <[email protected]>
Tested-by: Alice Ryhl <[email protected]>
Tested-by: Benno Lossin <[email protected]>
Link: https://github.com/Rust-for-Linux/linux/issues/945
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
|
|
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
|
|
Some pending overlay additions need the graph check fix.
This adds the following commits from upstream:
bcd02b523429 fdtoverlay: remove wrong singular article in a comment
84b056a89d3c checks: relax graph checks for overlays
Signed-off-by: Rob Herring (Arm) <[email protected]>
|
|
Cleaning up the symbols causes various issues afterwards. Let's sort
the list based on original name.
Signed-off-by: Song Liu <[email protected]>
Fixes: 8cc32a9bbf29 ("kallsyms: strip LTO-only suffixes from promoted global functions")
Reviewed-by: Masami Hiramatsu (Google) <[email protected]>
Tested-by: Masami Hiramatsu (Google) <[email protected]>
Acked-by: Petr Mladek <[email protected]>
Reviewed-by: Sami Tolvanen <[email protected]>
Reviewed-by: Luis Chamberlain <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Kees Cook <[email protected]>
|
|
As done with str_up_down(), add checks for str_down_up() opportunities.
5 cases currently exist in the tree.
Suggested-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Kees Cook <[email protected]>
|
|
Add rules for finding places where str_up_down() can be used.
This currently finds over 20 locations.
Signed-off-by: Michal Wajdeczko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Kees Cook <[email protected]>
|
|
This script is only used in lib/test_fortify/.
There is no reason to keep it in scripts/.
Signed-off-by: Masahiro Yamada <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Kees Cook <[email protected]>
|
|
There are some issues in the test_fortify Makefile code.
Problem 1: cc-disable-warning invokes compiler dozens of times
To see how many times the cc-disable-warning is evaluated, change
this code:
$(call cc-disable-warning,fortify-source)
to:
$(call cc-disable-warning,$(shell touch /tmp/fortify-$$$$)fortify-source)
Then, build the kernel with CONFIG_FORTIFY_SOURCE=y. You will see a
large number of '/tmp/fortify-<PID>' files created:
$ ls -1 /tmp/fortify-* | wc
80 80 1600
This means the compiler was invoked 80 times just for checking the
-Wno-fortify-source flag support.
$(call cc-disable-warning,fortify-source) should be added to a simple
variable instead of a recursive variable.
Problem 2: do not recompile string.o when the test code is updated
The test cases are independent of the kernel. However, when the test
code is updated, $(obj)/string.o is rebuilt and vmlinux is relinked
due to this dependency:
$(obj)/string.o: $(obj)/$(TEST_FORTIFY_LOG)
always-y is suitable for building the log files.
Problem 3: redundant code
clean-files += $(addsuffix .o, $(TEST_FORTIFY_LOGS))
... is unneeded because the top Makefile globally cleans *.o files.
This commit fixes these issues and makes the code readable.
Signed-off-by: Masahiro Yamada <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Kees Cook <[email protected]>
|
|
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 <[email protected]>
Closes: https://lore.kernel.org/all/[email protected]/
Signed-off-by: Masahiro Yamada <[email protected]>
Reviewed-by: Nicolas Schier <[email protected]>
Reviewed-by: Daniel Gomez <[email protected]>
|
|
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 <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: [email protected]
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 <[email protected]>
Tested-by: Alice Ryhl <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Sarthak Singh <[email protected]>
Link: https://rust-for-linux.zulipchat.com/#narrow/stream/291565-Help/topic/How.20to.20rust-analyzer.20correctly.20working
Link: https://lore.kernel.org/r/[email protected]
[ Formatted comment, fixed typo and removed spurious empty line. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
Reviewed-by: Nicolas Schier <[email protected]>
|
|
Since the kernel currently requires GCC 5.1 as a minimum, remove the
unnecessary GCC version >= 4.7 check.
Signed-off-by: Thorsten Blum <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Kees Cook <[email protected]>
|