05 Sep, 2022
1 commit
-
commit 23a0cb8e3225122496bfa79172005c587c2d64bf upstream.
When building an external module, if users don't need to separate the
compilation output and source code, they run the following command:
"make -C $(LINUX_SRC_DIR) M=$(PWD)". At this point, "$(KBUILD_EXTMOD)"
and "$(src)" are the same.If they need to separate them, they run "make -C $(KERNEL_SRC_DIR)
O=$(KERNEL_OUT_DIR) M=$(OUT_DIR) src=$(PWD)". Before running the
command, they need to copy "Kbuild" or "Makefile" to "$(OUT_DIR)" to
prevent compilation failure.So the kernel should change the included path to avoid the copy operation.
Signed-off-by: Jing Leng
[masahiro: I do not think "M=$(OUT_DIR) src=$(PWD)" is the official way,
but this patch is a nice clean up anyway.]
Signed-off-by: Masahiro Yamada
Signed-off-by: Nicolas Schier
Signed-off-by: Greg Kroah-Hartman
25 Aug, 2022
3 commits
-
[ Upstream commit 87c482bdfa79f378297d92af49cdf265be199df5 ]
In the kernel image vmlinux.lds.S linker scripts the .altinstructions
and __bug_table sections are 4- or 8-byte aligned because they hold 32-
and/or 64-bit values.Most architectures use altinstructions and BUG() or WARN() in modules as
well, but in the module linker script (module.lds.S) those sections are
currently missing. As consequence the linker will store their content
byte-aligned by default, which then can lead to unnecessary unaligned
memory accesses by the CPU when those tables are processed at runtime.Usually unaligned memory accesses are unnoticed, because either the
hardware (as on x86 CPUs) or in-kernel exception handlers (e.g. on
parisc or sparc) emulate and fix them up at runtime. Nevertheless, such
unaligned accesses introduce a performance penalty and can even crash
the kernel if there is a bug in the unalignment exception handlers
(which happened once to me on the parisc architecture and which is why I
noticed that issue at all).This patch fixes a non-critical issue and might be backported at any time.
It's trivial and shouldn't introduce any regression because it simply
tells the linker to use a different (8-byte alignment) for those
sections by default.Signed-off-by: Helge Deller
Link: https://lore.kernel.org/all/Yr8%2Fgr8e8I7tVX4d@p100/
Signed-off-by: Luis Chamberlain
Signed-off-by: Sasha Levin -
commit 012e8d2034f1bda8863435cd589636e618d6a659 upstream.
Commit 36d4b36b6959 ("lib/nodemask: inline next_node_in() and
node_random()") refactored some code by moving node_random() from
lib/nodemask.c to include/linux/nodemask.h, thus requiring nodemask.h to
include random.h, which conditionally defines add_latent_entropy()
depending on whether the macro LATENT_ENTROPY_PLUGIN is defined.This broke the build on powerpc, where nodemask.h is indirectly included
in arch/powerpc/kernel/prom_init.c, part of the early boot machinery that
is excluded from the latent entropy plugin using
DISABLE_LATENT_ENTROPY_PLUGIN. It turns out that while we add a gcc flag
to disable the actual plugin, we don't undefine LATENT_ENTROPY_PLUGIN.This leads to the following:
CC arch/powerpc/kernel/prom_init.o
In file included from ./include/linux/nodemask.h:97,
from ./include/linux/mmzone.h:17,
from ./include/linux/gfp.h:7,
from ./include/linux/xarray.h:15,
from ./include/linux/radix-tree.h:21,
from ./include/linux/idr.h:15,
from ./include/linux/kernfs.h:12,
from ./include/linux/sysfs.h:16,
from ./include/linux/kobject.h:20,
from ./include/linux/pci.h:35,
from arch/powerpc/kernel/prom_init.c:24:
./include/linux/random.h: In function 'add_latent_entropy':
./include/linux/random.h:25:46: error: 'latent_entropy' undeclared (first use in this function); did you mean 'add_latent_entropy'?
25 | add_device_randomness((const void *)&latent_entropy, sizeof(latent_entropy));
| ^~~~~~~~~~~~~~
| add_latent_entropy
./include/linux/random.h:25:46: note: each undeclared identifier is reported only once for each function it appears in
make[2]: *** [scripts/Makefile.build:249: arch/powerpc/kernel/prom_init.o] Fehler 1
make[1]: *** [scripts/Makefile.build:465: arch/powerpc/kernel] Fehler 2
make: *** [Makefile:1855: arch/powerpc] Error 2Change the DISABLE_LATENT_ENTROPY_PLUGIN flags to undefine
LATENT_ENTROPY_PLUGIN for files where the plugin is disabled.Cc: Yury Norov
Fixes: 38addce8b600 ("gcc-plugins: Add latent_entropy plugin")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216367
Link: https://lore.kernel.org/linuxppc-dev/alpine.DEB.2.22.394.2208152006320.289321@ramsan.of.borg/
Reported-by: Erhard Furtner
Signed-off-by: Andrew Donnellan
Reviewed-by: Yury Norov
Signed-off-by: Kees Cook
Link: https://lore.kernel.org/r/20220816051720.44108-1-ajd@linux.ibm.com
Signed-off-by: Greg Kroah-Hartman -
commit aac289653fa5adf9e9985e4912c1d24a3e8cbab2 upstream.
When passed -print-file-name=plugin, the dummy gcc script creates a
temporary directory that is never cleaned up. To avoid cluttering
$TMPDIR, instead use a static directory included in the source tree.Fixes: 76426e238834 ("kbuild: add dummy toolchains to enable all cc-option etc. in Kconfig")
Signed-off-by: Ondrej Mosnacek
Signed-off-by: Masahiro Yamada
Signed-off-by: Greg Kroah-Hartman
17 Aug, 2022
3 commits
-
[ Upstream commit b6a5068854cfe372da7dee3224dcf023ed5b00cb ]
Since commit dcea997beed6 ("faddr2line: Fix overlapping text section
failures, the sequel"), faddr2line is completely broken on arm64.For some reason, on arm64, the vmlinux ELF object file type is ET_DYN
rather than ET_EXEC. Check for both when determining whether the object
is vmlinux.Modules and vmlinux.o have type ET_REL on all arches.
Fixes: dcea997beed6 ("faddr2line: Fix overlapping text section failures, the sequel")
Reported-by: John Garry
Signed-off-by: Josh Poimboeuf
Signed-off-by: Ingo Molnar
Tested-by: John Garry
Link: https://lore.kernel.org/r/dad1999737471b06d6188ce4cdb11329aa41682c.1658426357.git.jpoimboe@kernel.org
Signed-off-by: Sasha Levin -
[ Upstream commit e3c8d33e0d62175c31ca7ab7ab01b18f0b6318d3 ]
The type atomic_long_t can have size 4 or 8 bytes, depending on
CONFIG_64BIT; it's only content, the field 'counter', is either an
int or a s64 value.Current code incorrectly uses the fixed size utils.read_u64() to
read the field 'counter' inside atomic_long_t.On 32 bits architectures reading the last element 'tail_id' of the
struct prb_desc_ring:
struct prb_desc_ring {
...
atomic_long_t tail_id;
};
causes the utils.read_u64() to access outside the boundary of the
struct and the gdb command 'lx-dmesg' exits with error:
Python Exception : index out of range
Error occurred in Python: index out of rangeQuery the really used atomic_long_t counter type size.
Link: https://lore.kernel.org/r/20220617143758.137307-1-antonio.borneo@foss.st.com
Fixes: e60768311af8 ("scripts/gdb: update for lockless printk ringbuffer")
Signed-off-by: Antonio Borneo
[pmladek@suse.com: Query the really used atomic_long_t counter type size]
Tested-by: Antonio Borneo
Reviewed-by: John Ogness
Signed-off-by: Petr Mladek
Link: https://lore.kernel.org/r/20220719122831.19890-1-pmladek@suse.com
Signed-off-by: Sasha Levin -
[ Upstream commit deaee2704a157dfcca77301ddaa10c62a9840952 ]
For the gdb command lx-dmesg, the entire descriptor, info, and text
data regions are read into memory before printing any records. For
large kernel log buffers, this not only causes a huge delay before
seeing any records, but it may also lead to python errors of too
much memory allocation.Rather than reading in all these regions in advance, read them as
needed and only read the regions for the particular record that is
being printed.The gdb macro "dmesg" in Documentation/admin-guide/kdump/gdbmacros.txt
already prints out the kernel log buffer like this.Signed-off-by: John Ogness
Signed-off-by: Petr Mladek
Link: https://lore.kernel.org/r/874k79c3a9.fsf@jogness.linutronix.de
Signed-off-by: Sasha Levin
29 Jul, 2022
1 commit
-
[ Upstream commit 46d28947d9876fc0f8f93d3c69813ef6e9852595 ]
The exception table entries contain the instruction address, the fixup
address and the handler address. All addresses are relative. Storing the
handler address has a few downsides:1) Most handlers need to be exported
2) Handlers can be defined everywhere and there is no overview about the
handler types3) MCE needs to check the handler type to decide whether an in kernel #MC
can be recovered. The functionality of the handler itself is not in any
way special, but for these checks there need to be separate functions
which in the worst case have to be exported.Some of these 'recoverable' exception fixups are pretty obscure and
just reuse some other handler to spare code. That obfuscates e.g. the
#MC safe copy functions. Cleaning that up would require more handlers
and exportsRework the exception fixup mechanics by storing a fixup type number instead
of the handler address and invoke the proper handler for each fixup
type. Also teach the extable sort to leave the type field alone.This makes most handlers static except for special cases like the MCE
MSR fixup and the BPF fixup. This allows to add more types for cleaning up
the obscure places without adding more handler code and exports.There is a marginal code size reduction for a production config and it
removes _eight_ exported symbols.Signed-off-by: Thomas Gleixner
Signed-off-by: Borislav Petkov
Acked-by: Alexei Starovoitov
Link: https://lkml.kernel.org/r/20210908132525.211958725@linutronix.de
Signed-off-by: Sasha Levin
23 Jul, 2022
2 commits
-
commit f43b9876e857c739d407bc56df288b0ebe1a9164 upstream.
Do fine-grained Kconfig for all the various retbleed parts.
NOTE: if your compiler doesn't support return thunks this will
silently 'upgrade' your mitigation to IBPB, you might not like this.Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Borislav Petkov
[cascardo: there is no CONFIG_OBJTOOL]
[cascardo: objtool calling and option parsing has changed]
Signed-off-by: Thadeu Lima de Souza Cascardo
Signed-off-by: Greg Kroah-Hartman -
commit a09a6e2399ba0595c3042b3164f3ca68a3cff33e upstream.
Since entry asm is tricky, add a validation pass that ensures the
retbleed mitigation has been done before the first actual RET
instruction.Entry points are those that either have UNWIND_HINT_ENTRY, which acts
as UNWIND_HINT_EMPTY but marks the instruction as an entry point, or
those that have UWIND_HINT_IRET_REGS at +0.This is basically a variant of validate_branch() that is
intra-function and it will simply follow all branches from marked
entry points and ensures that all paths lead to ANNOTATE_UNRET_END.If a path hits RET or an indirection the path is a fail and will be
reported.There are 3 ANNOTATE_UNRET_END instances:
- UNTRAIN_RET itself
- exception from-kernel; this path doesn't need UNTRAIN_RET
- all early exceptions; these also don't need UNTRAIN_RETSigned-off-by: Peter Zijlstra (Intel)
Signed-off-by: Borislav Petkov
Reviewed-by: Josh Poimboeuf
Signed-off-by: Borislav Petkov
[cascardo: tools/objtool/builtin-check.c no link option validation]
[cascardo: tools/objtool/check.c opts.ibt is ibt]
[cascardo: tools/objtool/include/objtool/builtin.h leave unret option as bool, no struct opts]
[cascardo: objtool is still called from scripts/link-vmlinux.sh]
[cascardo: no IBT support]
Signed-off-by: Thadeu Lima de Souza Cascardo
Signed-off-by: Greg Kroah-Hartman
12 Jul, 2022
3 commits
-
[ Upstream commit 3080ea5553cc909b000d1f1d964a9041962f2c5b ]
There are many places where kernel code wants to have several different
typed trailing flexible arrays. This would normally be done with multiple
flexible arrays in a union, but since GCC and Clang don't (on the surface)
allow this, there have been many open-coded workarounds, usually involving
neighboring 0-element arrays at the end of a structure. For example,
instead of something like this:struct thing {
...
union {
struct type1 foo[];
struct type2 bar[];
};
};code works around the compiler with:
struct thing {
...
struct type1 foo[0];
struct type2 bar[];
};Another case is when a flexible array is wanted as the single member
within a struct (which itself is usually in a union). For example, this
would be worked around as:union many {
...
struct {
struct type3 baz[0];
};
};These kinds of work-arounds cause problems with size checks against such
zero-element arrays (for example when building with -Warray-bounds and
-Wzero-length-bounds, and with the coming FORTIFY_SOURCE improvements),
so they must all be converted to "real" flexible arrays, avoiding warnings
like this:fs/hpfs/anode.c: In function 'hpfs_add_sector_to_btree':
fs/hpfs/anode.c:209:27: warning: array subscript 0 is outside the bounds of an interior zero-length array 'struct bplus_internal_node[0]' [-Wzero-length-bounds]
209 | anode->btree.u.internal[0].down = cpu_to_le32(a);
| ~~~~~~~~~~~~~~~~~~~~~~~^~~
In file included from fs/hpfs/hpfs_fn.h:26,
from fs/hpfs/anode.c:10:
fs/hpfs/hpfs.h:412:32: note: while referencing 'internal'
412 | struct bplus_internal_node internal[0]; /* (internal) 2-word entries giving
| ^~~~~~~~drivers/net/can/usb/etas_es58x/es58x_fd.c: In function 'es58x_fd_tx_can_msg':
drivers/net/can/usb/etas_es58x/es58x_fd.c:360:35: warning: array subscript 65535 is outside the bounds of an interior zero-length array 'u8[0]' {aka 'unsigned char[]'} [-Wzero-length-bounds]
360 | tx_can_msg = (typeof(tx_can_msg))&es58x_fd_urb_cmd->raw_msg[msg_len];
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/net/can/usb/etas_es58x/es58x_core.h:22,
from drivers/net/can/usb/etas_es58x/es58x_fd.c:17:
drivers/net/can/usb/etas_es58x/es58x_fd.h:231:6: note: while referencing 'raw_msg'
231 | u8 raw_msg[0];
| ^~~~~~~However, it _is_ entirely possible to have one or more flexible arrays
in a struct or union: it just has to be in another struct. And since it
cannot be alone in a struct, such a struct must have at least 1 other
named member -- but that member can be zero sized. Wrap all this nonsense
into the new DECLARE_FLEX_ARRAY() in support of having flexible arrays
in unions (or alone in a struct).As with struct_group(), since this is needed in UAPI headers as well,
implement the core there, with a non-UAPI wrapper.Additionally update kernel-doc to understand its existence.
https://github.com/KSPP/linux/issues/137
Cc: Arnd Bergmann
Cc: "Gustavo A. R. Silva"
Signed-off-by: Kees Cook
Signed-off-by: Sasha Levin -
[ Upstream commit 86cffecdeaa278444870c8745ab166a65865dbf0 ]
GCC and Clang can use the "alloc_size" attribute to better inform the
results of __builtin_object_size() (for compile-time constant values).
Clang can additionally use alloc_size to inform the results of
__builtin_dynamic_object_size() (for run-time values).Because GCC sees the frequent use of struct_size() as an allocator size
argument, and notices it can return SIZE_MAX (the overflow indication),
it complains about these call sites overflowing (since SIZE_MAX is
greater than the default -Walloc-size-larger-than=PTRDIFF_MAX). This
isn't helpful since we already know a SIZE_MAX will be caught at
run-time (this was an intentional design). To deal with this, we must
disable this check as it is both a false positive and redundant. (Clang
does not have this warning option.)Unfortunately, just checking the -Wno-alloc-size-larger-than is not
sufficient to make the __alloc_size attribute behave correctly under
older GCC versions. The attribute itself must be disabled in those
situations too, as there appears to be no way to reliably silence the
SIZE_MAX constant expression cases for GCC versions less than 9.1:In file included from ./include/linux/resource_ext.h:11,
from ./include/linux/pci.h:40,
from drivers/net/ethernet/intel/ixgbe/ixgbe.h:9,
from drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c:4:
In function 'kmalloc_node',
inlined from 'ixgbe_alloc_q_vector' at ./include/linux/slab.h:743:9:
./include/linux/slab.h:618:9: error: argument 1 value '18446744073709551615' exceeds maximum object size 9223372036854775807 [-Werror=alloc-size-larger-than=]
return __kmalloc_node(size, flags, node);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./include/linux/slab.h: In function 'ixgbe_alloc_q_vector':
./include/linux/slab.h:455:7: note: in a call to allocation function '__kmalloc_node' declared here
void *__kmalloc_node(size_t size, gfp_t flags, int node) __assume_slab_alignment __malloc;
^~~~~~~~~~~~~~Specifically:
'-Wno-alloc-size-larger-than' is not correctly handled by GCC < 9.1
https://godbolt.org/z/hqsfG7q84 (doesn't disable)
https://godbolt.org/z/P9jdrPTYh (doesn't admit to not knowing about option)
https://godbolt.org/z/465TPMWKb (only warns when other warnings appear)'-Walloc-size-larger-than=18446744073709551615' is not handled by GCC < 8.2
https://godbolt.org/z/73hh1EPxz (ignores numeric value)Since anything marked with __alloc_size would also qualify for marking
with __malloc, just include __malloc along with it to avoid redundant
markings. (Suggested by Linus Torvalds.)Finally, make sure checkpatch.pl doesn't get confused about finding the
__alloc_size attribute on functions. (Thanks to Joe Perches.)Link: https://lkml.kernel.org/r/20210930222704.2631604-3-keescook@chromium.org
Signed-off-by: Kees Cook
Tested-by: Randy Dunlap
Cc: Andy Whitcroft
Cc: Christoph Lameter
Cc: Daniel Micay
Cc: David Rientjes
Cc: Dennis Zhou
Cc: Dwaipayan Ray
Cc: Joe Perches
Cc: Joonsoo Kim
Cc: Lukas Bulwahn
Cc: Pekka Enberg
Cc: Tejun Heo
Cc: Vlastimil Babka
Cc: Alexandre Bounine
Cc: Gustavo A. R. Silva
Cc: Ira Weiny
Cc: Jing Xiangfeng
Cc: John Hubbard
Cc: kernel test robot
Cc: Matt Porter
Cc: Miguel Ojeda
Cc: Nathan Chancellor
Cc: Nick Desaulniers
Cc: Souptick Joarder
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin -
[ Upstream commit 50d7bd38c3aafc4749e05e8d7fcb616979143602 ]
Kernel code has a regular need to describe groups of members within a
structure usually when they need to be copied or initialized separately
from the rest of the surrounding structure. The generally accepted design
pattern in C is to use a named sub-struct:struct foo {
int one;
struct {
int two;
int three, four;
} thing;
int five;
};This would allow for traditional references and sizing:
memcpy(&dst.thing, &src.thing, sizeof(dst.thing));
However, doing this would mean that referencing struct members enclosed
by such named structs would always require including the sub-struct name
in identifiers:do_something(dst.thing.three);
This has tended to be quite inflexible, especially when such groupings
need to be added to established code which causes huge naming churn.
Three workarounds exist in the kernel for this problem, and each have
other negative properties.To avoid the naming churn, there is a design pattern of adding macro
aliases for the named struct:#define f_three thing.three
This ends up polluting the global namespace, and makes it difficult to
search for identifiers.Another common work-around in kernel code avoids the pollution by avoiding
the named struct entirely, instead identifying the group's boundaries using
either a pair of empty anonymous structs of a pair of zero-element arrays:struct foo {
int one;
struct { } start;
int two;
int three, four;
struct { } finish;
int five;
};struct foo {
int one;
int start[0];
int two;
int three, four;
int finish[0];
int five;
};This allows code to avoid needing to use a sub-struct named for member
references within the surrounding structure, but loses the benefits of
being able to actually use such a struct, making it rather fragile. Using
these requires open-coded calculation of sizes and offsets. The efforts
made to avoid common mistakes include lots of comments, or adding various
BUILD_BUG_ON()s. Such code is left with no way for the compiler to reason
about the boundaries (e.g. the "start" object looks like it's 0 bytes
in length), making bounds checking depend on open-coded calculations:if (length > offsetof(struct foo, finish) -
offsetof(struct foo, start))
return -EINVAL;
memcpy(&dst.start, &src.start, offsetof(struct foo, finish) -
offsetof(struct foo, start));However, the vast majority of places in the kernel that operate on
groups of members do so without any identification of the grouping,
relying either on comments or implicit knowledge of the struct contents,
which is even harder for the compiler to reason about, and results in
even more fragile manual sizing, usually depending on member locations
outside of the region (e.g. to copy "two" and "three", use the start of
"four" to find the size):BUILD_BUG_ON((offsetof(struct foo, four) <
offsetof(struct foo, two)) ||
(offsetof(struct foo, four) <
offsetof(struct foo, three));
if (length > offsetof(struct foo, four) -
offsetof(struct foo, two))
return -EINVAL;
memcpy(&dst.two, &src.two, length);In order to have a regular programmatic way to describe a struct
region that can be used for references and sizing, can be examined for
bounds checking, avoids forcing the use of intermediate identifiers,
and avoids polluting the global namespace, introduce the struct_group()
macro. This macro wraps the member declarations to create an anonymous
union of an anonymous struct (no intermediate name) and a named struct
(for references and sizing):struct foo {
int one;
struct_group(thing,
int two;
int three, four;
);
int five;
};if (length > sizeof(src.thing))
return -EINVAL;
memcpy(&dst.thing, &src.thing, length);
do_something(dst.three);There are some rare cases where the resulting struct_group() needs
attributes added, so struct_group_attr() is also introduced to allow
for specifying struct attributes (e.g. __align(x) or __packed).
Additionally, there are places where such declarations would like to
have the struct be tagged, so struct_group_tagged() is added.Given there is a need for a handful of UAPI uses too, the underlying
__struct_group() macro has been defined in UAPI so it can be used there
too.To avoid confusing scripts/kernel-doc, hide the macro from its struct
parsing.Co-developed-by: Keith Packard
Signed-off-by: Keith Packard
Acked-by: Gustavo A. R. Silva
Link: https://lore.kernel.org/lkml/20210728023217.GC35706@embeddedor
Enhanced-by: Rasmus Villemoes
Link: https://lore.kernel.org/lkml/41183a98-bdb9-4ad6-7eab-5a7292a6df84@rasmusvillemoes.dk
Enhanced-by: Dan Williams
Link: https://lore.kernel.org/lkml/1d9a2e6df2a9a35b2cdd50a9a68cac5991e7e5f0.camel@intel.com
Enhanced-by: Daniel Vetter
Link: https://lore.kernel.org/lkml/YQKa76A6XuFqgM03@phenom.ffwll.local
Acked-by: Dan Williams
Signed-off-by: Kees Cook
Signed-off-by: Sasha Levin
29 Jun, 2022
1 commit
-
commit 28438794aba47a27e922857d27b31b74e8559143 upstream.
Since commit f02e8a6596b7 ("module: Sort exported symbols"),
EXPORT_SYMBOL* is placed in the individual section ___ksymtab(_gpl)+
(3 leading underscores instead of 2).Since then, modpost cannot detect the bad combination of EXPORT_SYMBOL
and __init/__exit.Fix the .fromsec field.
Fixes: f02e8a6596b7 ("module: Sort exported symbols")
Signed-off-by: Masahiro Yamada
Reviewed-by: Nick Desaulniers
Signed-off-by: Greg Kroah-Hartman
22 Jun, 2022
1 commit
-
[ Upstream commit dcea997beed694cbd8705100ca1a6eb0d886de69 ]
If a function lives in a section other than .text, but .text also exists
in the object, faddr2line may wrongly assume .text. This can result in
comically wrong output. For example:$ scripts/faddr2line vmlinux.o enter_from_user_mode+0x1c
enter_from_user_mode+0x1c/0x30:
find_next_bit at /home/jpoimboe/git/linux/./include/linux/find.h:40
(inlined by) perf_clear_dirty_counters at /home/jpoimboe/git/linux/arch/x86/events/core.c:2504Fix it by passing the section name to addr2line, unless the object file
is vmlinux, in which case the symbol table uses absolute addresses.Fixes: 1d1a0e7c5100 ("scripts/faddr2line: Fix overlapping text section failures")
Reported-by: Peter Zijlstra
Signed-off-by: Josh Poimboeuf
Link: https://lore.kernel.org/r/7d25bc1408bd3a750ac26e60d2f2815a5f4a8363.1654130536.git.jpoimboe@kernel.org
Signed-off-by: Sasha Levin
15 Jun, 2022
3 commits
-
[ Upstream commit 1f7a6cf6b07c74a17343c2559cd5f5018a245961 ]
MAGIC_START("IKCFG_ST") and MAGIC_END("IKCFG_ED") are moved out
from the kernel_config_data variable.Thus, we parse kernel_config_data directly instead of considering
offset of MAGIC_START and MAGIC_END.Fixes: 13610aa908dc ("kernel/configs: use .incbin directive to embed config_data.gz")
Signed-off-by: Kuan-Ying Lee
Signed-off-by: Masahiro Yamada
Signed-off-by: Sasha Levin -
[ Upstream commit d6b732666a1bae0df3c3ae06925043bba34502b1 ]
The return value of is_arm_mapping_symbol() is unpredictable when "$"
is passed in.strchr(3) says:
The strchr() and strrchr() functions return a pointer to the matched
character or NULL if the character is not found. The terminating null
byte is considered part of the string, so that if c is specified as
'\0', these functions return a pointer to the terminator.When str[1] is '\0', strchr("axtd", str[1]) is not NULL, and str[2] is
referenced (i.e. buffer overrun).Test code
---------char str1[] = "abc";
char str2[] = "ab";strcpy(str1, "$");
strcpy(str2, "$");printf("test1: %d\n", is_arm_mapping_symbol(str1));
printf("test2: %d\n", is_arm_mapping_symbol(str2));Result
------test1: 0
test2: 1Signed-off-by: Masahiro Yamada
Reviewed-by: Nick Desaulniers
Signed-off-by: Sasha Levin -
[ Upstream commit b5beffa20d83c4e15306c991ffd00de0d8628338 ]
With the `-z unique-symbol` linker flag or any similar mechanism,
it is possible to trigger the following:ERROR: modpost: "param_set_uint.0" [vmlinux] is a static EXPORT_SYMBOL
The reason is that for now the condition from remove_dot():
if (m && (s[n + m] == '.' || s[n + m] == 0))
which was designed to test if it's a dot or a '\0' after the suffix
is never satisfied.
This is due to that `s[n + m]` always points to the last digit of a
numeric suffix, not on the symbol next to it (from a custom debug
print added to modpost):param_set_uint.0, s[n + m] is '0', s[n + m + 1] is '\0'
So it's off-by-one and was like that since 2014.
Fix this for the sake of any potential upcoming features, but don't
bother stable-backporting, as it's well hidden -- apart from that
LD flag, it can be triggered only with GCC LTO which never landed
upstream.Fixes: fcd38ed0ff26 ("scripts: modpost: fix compilation warning")
Signed-off-by: Alexander Lobakin
Reviewed-by: Petr Mladek
Signed-off-by: Masahiro Yamada
Signed-off-by: Sasha Levin
09 Jun, 2022
1 commit
-
[ Upstream commit 1d1a0e7c5100d332583e20b40aa8c0a8ed3d7849 ]
There have been some recent reports of faddr2line failures:
$ scripts/faddr2line sound/soundcore.ko sound_devnode+0x5/0x35
bad symbol size: base: 0x0000000000000000 end: 0x0000000000000000$ ./scripts/faddr2line vmlinux.o enter_from_user_mode+0x24
bad symbol size: base: 0x0000000000005fe0 end: 0x0000000000005fe0The problem is that faddr2line is based on 'nm', which has a major
limitation: it doesn't know how to distinguish between different text
sections. So if an offset exists in multiple text sections in the
object, it may fail.Rewrite faddr2line to be section-aware, by basing it on readelf.
Fixes: 67326666e2d4 ("scripts: add script for translating stack dump function offsets")
Reported-by: Kaiwan N Billimoria
Reported-by: Peter Zijlstra
Signed-off-by: Josh Poimboeuf
Link: https://lore.kernel.org/r/29ff99f86e3da965b6e46c1cc2d72ce6528c17c3.1652382321.git.jpoimboe@kernel.org
Signed-off-by: Sasha Levin
16 May, 2022
2 commits
-
[ Upstream commit e463a09af2f0677b9485a7e8e4e70b396b2ffb6f ]
Make use of an upcoming GCC feature to mitigate
straight-line-speculation for x86:https://gcc.gnu.org/g:53a643f8568067d7700a9f2facc8ba39974973d3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102952
https://bugs.llvm.org/show_bug.cgi?id=52323It's built tested on x86_64-allyesconfig using GCC-12 and GCC-11.
Maintenance overhead of this should be fairly low due to objtool
validation.Size overhead of all these additional int3 instructions comes to:
text data bss dec hex filename
22267751 6933356 2011368 31212475 1dc43bb defconfig-build/vmlinux
22804126 6933356 1470696 31208178 1dc32f2 defconfig-build/vmlinux.slsOr roughly 2.4% additional text.
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Borislav Petkov
Link: https://lore.kernel.org/r/20211204134908.140103474@infradead.org
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 8f0c32c788fffa8e88f995372415864039347c8a ]
Commit b1a1a1a09b46 ("kbuild: lto: postpone objtool") moved objtool_args
to Makefile.lib, so the arguments can be used in Makefile.modfinal as
well as Makefile.build.With commit 850ded46c642 ("kbuild: Fix TRIM_UNUSED_KSYMS with
LTO_CLANG"), module LTO linking came back to scripts/Makefile.build
again.So, there is no more reason to keep objtool_args in a separate file.
Get it back to the original place, close to the objtool command.
Remove the stale comment too.
Signed-off-by: Masahiro Yamada
Reviewed-by: Kees Cook
Acked-by: Josh Poimboeuf
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
20 Apr, 2022
1 commit
-
commit c40160f2998c897231f8454bf797558d30a20375 upstream.
While the latent entropy plugin mostly doesn't derive entropy from
get_random_const() for measuring the call graph, when __latent_entropy is
applied to a constant, then it's initialized statically to output from
get_random_const(). In that case, this data is derived from a 64-bit
seed, which means a buffer of 512 bits doesn't really have that amount
of compile-time entropy.This patch fixes that shortcoming by just buffering chunks of
/dev/urandom output and doling it out as requested.At the same time, it's important that we don't break the use of
-frandom-seed, for people who want the runtime benefits of the latent
entropy plugin, while still having compile-time determinism. In that
case, we detect whether gcc's set_random_seed() has been called by
making a call to get_random_seed(noinit=true) in the plugin init
function, which is called after set_random_seed() is called but before
anything that calls get_random_seed(noinit=false), and seeing if it's
zero or not. If it's not zero, we're in deterministic mode, and so we
just generate numbers with a basic xorshift prng.Note that we don't detect if -frandom-seed is being used using the
documented local_tick variable, because it's assigned via:
local_tick = (unsigned) tv.tv_sec * 1000 + tv.tv_usec / 1000;
which may well overflow and become -1 on its own, and so isn't
reliable: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105171[kees: The 256 byte rnd_buf size was chosen based on average (250),
median (64), and std deviation (575) bytes of used entropy for a
defconfig x86_64 build]Fixes: 38addce8b600 ("gcc-plugins: Add latent_entropy plugin")
Cc: stable@vger.kernel.org
Cc: PaX Team
Signed-off-by: Jason A. Donenfeld
Signed-off-by: Kees Cook
Link: https://lore.kernel.org/r/20220405222815.21155-1-Jason@zx2c4.com
Signed-off-by: Greg Kroah-Hartman
14 Apr, 2022
1 commit
-
commit 69d0db01e210e07fe915e5da91b54a867cda040f upstream.
The object-size sanitizer is redundant to -Warray-bounds, and
inappropriately performs its checks at run-time when all information
needed for the evaluation is available at compile-time, making it quite
difficult to use:https://bugzilla.kernel.org/show_bug.cgi?id=214861
With -Warray-bounds almost enabled globally, it doesn't make sense to
keep this around.Link: https://lkml.kernel.org/r/20211203235346.110809-1-keescook@chromium.org
Signed-off-by: Kees Cook
Reviewed-by: Marco Elver
Cc: Masahiro Yamada
Cc: Michal Marek
Cc: Nick Desaulniers
Cc: Nathan Chancellor
Cc: Andrey Ryabinin
Cc: "Peter Zijlstra (Intel)"
Cc: Stephen Rothwell
Cc: Arnd Bergmann
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Cc: Tadeusz Struk
Signed-off-by: Greg Kroah-Hartman
08 Apr, 2022
4 commits
-
commit bf5c0c2231bcab677e5cdfb7f73e6c79f6d8c2d4 upstream.
This log message was accidentally chopped off.
I was wondering why this happened, but checking the ML log, Mark
precisely followed my suggestion [1].I just used "..." because I was too lazy to type the sentence fully.
Sorry for the confusion.[1]: https://lore.kernel.org/all/CAK7LNAR6bXXk9-ZzZYpTqzFqdYbQsZHmiWspu27rtsFxvfRuVA@mail.gmail.com/
Fixes: 4a6795933a89 ("kbuild: modpost: Explicitly warn about unprototyped symbols")
Signed-off-by: Masahiro Yamada
Acked-by: Mark Brown
Reviewed-by: Nick Desaulniers
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit dc1b4df09acdca7a89806b28f235cd6d8dcd3d24 ]
Arnd reports that on 32-bit architectures, the fallbacks for
atomic64_read_acquire() and atomic64_set_release() are broken as they
use smp_load_acquire() and smp_store_release() respectively, which do
not work on types larger than the native word size.Since those contain compiletime_assert_atomic_type(), any attempt to use
those fallbacks will result in a build-time error. e.g. with the
following added to arch/arm/kernel/setup.c:| void test_atomic64(atomic64_t *v)
| {
| atomic64_set_release(v, 5);
| atomic64_read_acquire(v);
| }The compiler will complain as follows:
| In file included from :
| In function 'arch_atomic64_set_release',
| inlined from 'test_atomic64' at ./include/linux/atomic/atomic-instrumented.h:669:2:
| ././include/linux/compiler_types.h:346:38: error: call to '__compiletime_assert_9' declared with attribute error: Need native word sized stores/loads for atomicity.
| 346 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| | ^
| ././include/linux/compiler_types.h:327:4: note: in definition of macro '__compiletime_assert'
| 327 | prefix ## suffix(); \
| | ^~~~~~
| ././include/linux/compiler_types.h:346:2: note: in expansion of macro '_compiletime_assert'
| 346 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| | ^~~~~~~~~~~~~~~~~~~
| ././include/linux/compiler_types.h:349:2: note: in expansion of macro 'compiletime_assert'
| 349 | compiletime_assert(__native_word(t), \
| | ^~~~~~~~~~~~~~~~~~
| ./include/asm-generic/barrier.h:133:2: note: in expansion of macro 'compiletime_assert_atomic_type'
| 133 | compiletime_assert_atomic_type(*p); \
| | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| ./include/asm-generic/barrier.h:164:55: note: in expansion of macro '__smp_store_release'
| 164 | #define smp_store_release(p, v) do { kcsan_release(); __smp_store_release(p, v); } while (0)
| | ^~~~~~~~~~~~~~~~~~~
| ./include/linux/atomic/atomic-arch-fallback.h:1270:2: note: in expansion of macro 'smp_store_release'
| 1270 | smp_store_release(&(v)->counter, i);
| | ^~~~~~~~~~~~~~~~~
| make[2]: *** [scripts/Makefile.build:288: arch/arm/kernel/setup.o] Error 1
| make[1]: *** [scripts/Makefile.build:550: arch/arm/kernel] Error 2
| make: *** [Makefile:1831: arch/arm] Error 2Fix this by only using smp_load_acquire() and smp_store_release() for
native atomic types, and otherwise falling back to the regular barriers
necessary for acquire/release semantics, as we do in the more generic
acquire and release fallbacks.Since the fallback templates are used to generate the atomic64_*() and
atomic_*() operations, the __native_word() check is added to both. For
the atomic_*() operations, which are always 32-bit, the __native_word()
check is redundant but not harmful, as it is always true.For the example above this works as expected on 32-bit, e.g. for arm
multi_v7_defconfig:| :
| push {r4, r5}
| dmb ish
| pldw [r0]
| mov r2, #5
| mov r3, #0
| ldrexd r4, [r0]
| strexd r4, r2, [r0]
| teq r4, #0
| bne 484
| ldrexd r2, [r0]
| dmb ish
| pop {r4, r5}
| bx lr... and also on 64-bit, e.g. for arm64 defconfig:
| :
| bti c
| paciasp
| mov x1, #0x5
| stlr x1, [x0]
| ldar x0, [x0]
| autiasp
| retReported-by: Arnd Bergmann
Signed-off-by: Mark Rutland
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Ard Biesheuvel
Reviewed-by: Boqun Feng
Link: https://lore.kernel.org/r/20220207101943.439825-1-mark.rutland@arm.com
Signed-off-by: Sasha Levin -
[ Upstream commit 27e9faf415dbf94af19b9c827842435edbc1fbbc ]
Since STRING_CST may not be NUL terminated, strncmp() was used for check
for equality. However, this may lead to mismatches for longer section
names where the start matches the tested-for string. Test for exact
equality by checking for the presences of NUL termination.Cc: Alexander Popov
Signed-off-by: Kees Cook
Signed-off-by: Sasha Levin -
[ Upstream commit a8b309ce9760943486e0585285e0125588a31650 ]
Running with POSIXLY_CORRECT=1 in the environment the scripts/dtc build
fails, because pkg-config doesn't output anything when the flags come
after the arguments.Fixes: 067c650c456e ("dtc: Use pkg-config to locate libyaml")
Signed-off-by: Thomas Bracht Laumann Jespersen
Signed-off-by: Rob Herring
Link: https://lore.kernel.org/r/20220131112028.7907-1-t@laumann.xyz
Signed-off-by: Sasha Levin
23 Feb, 2022
2 commits
-
[ Upstream commit 1b9e740a81f91ae338b29ed70455719804957b80 ]
When the KCONFIG_AUTOCONFIG is specified (e.g. export \
KCONFIG_AUTOCONFIG=output/config/auto.conf), the directory of
include/config/ will not be created, so kconfig can't create deps
files in it and auto.conf can't be generated.Signed-off-by: Jing Leng
Signed-off-by: Masahiro Yamada
Signed-off-by: Sasha Levin -
[ Upstream commit 8a4c5b2a6d8ea079fa36034e8167de87ab6f8880 ]
The 'shell' built-in only returns the first 256 bytes of the command's
output. In some cases, 'shell' is used to return a path; by bumping up
the buffer size to 4096 this lets us capture up to PATH_MAX.The specific case where I ran into this was due to commit 1e860048c53e
("gcc-plugins: simplify GCC plugin-dev capability test"). After this
change, we now use `$(shell,$(CC) -print-file-name=plugin)` to return
a path; if the gcc path is particularly long, then the path ends up
truncated at the 256 byte mark, which makes the HAVE_GCC_PLUGINS
depends test always fail.Signed-off-by: Brenda Streiff
Signed-off-by: Masahiro Yamada
Signed-off-by: Sasha Levin
16 Feb, 2022
1 commit
-
commit 1cf5f151d25fcca94689efd91afa0253621fb33a upstream.
-Wunaligned-access is a new warning in clang that is default enabled for
arm and arm64 under certain circumstances within the clang frontend (see
LLVM commit below). On v5.17-rc2, an ARCH=arm allmodconfig build shows
1284 total/70 unique instances of this warning (most of the instances
are in header files), which is quite noisy.To keep a normal build green through CONFIG_WERROR, only show this
warning with W=1, which will allow automated build systems to catch new
instances of the warning so that the total number can be driven down to
zero eventually since catching unaligned accesses at compile time would
be generally useful.Cc: stable@vger.kernel.org
Link: https://github.com/llvm/llvm-project/commit/35737df4dcd28534bd3090157c224c19b501278a
Link: https://github.com/ClangBuiltLinux/linux/issues/1569
Link: https://github.com/ClangBuiltLinux/linux/issues/1576
Signed-off-by: Nathan Chancellor
Reviewed-by: Nick Desaulniers
Signed-off-by: Masahiro Yamada
Signed-off-by: Greg Kroah-Hartman
27 Jan, 2022
3 commits
-
commit 87d6576ddf8ac25f36597bc93ca17f6628289c16 upstream.
The name of the package with ctexhook.sty is different on
Debian/Ubuntu.Reported-by: Akira Yokosawa
Signed-off-by: Mauro Carvalho Chehab
Tested-by: Akira Yokosawa
Link: https://lore.kernel.org/r/63882425609a2820fac78f5e94620abeb7ed5f6f.1641429634.git.mchehab@kernel.org
Signed-off-by: Jonathan Corbet
Signed-off-by: Greg Kroah-Hartman -
commit 7baab965896eaeea60a54b8fe742feea2f79060f upstream.
After a change meant to fix support for oriental characters
(Chinese, Japanese, Korean), ctex stylesheet is now a requirement
for PDF output.Reported-by: Christoph Hellwig
Signed-off-by: Mauro Carvalho Chehab
Link: https://lore.kernel.org/r/165aa6167f21e3892a6e308688c93c756e94f4e0.1641243581.git.mchehab@kernel.org
Signed-off-by: Jonathan Corbet
Signed-off-by: Greg Kroah-Hartman -
commit d8adf5b92a9d2205620874d498c39923ecea8749 upstream.
dtx_diff suggests to use
Reviewed-by: Frank Rowand
Signed-off-by: Rob Herring
Link: https://lore.kernel.org/r/20220113081918.10387-1-matthias.schiffer@ew.tq-group.com
Signed-off-by: Greg Kroah-Hartman
05 Jan, 2022
1 commit
-
commit 4eb1782eaa9fa1c224ad1fa0d13a9f09c3ab2d80 upstream.
Commit 85bf17b28f97 ("recordmcount.pl: look for jgnop instruction as well
as bcrl on s390") added a new alternative mnemonic for the existing brcl
instruction. This is required for the combination old gcc version (pre 9.0)
and binutils since version 2.37.
However at the same time this commit introduced a typo, replacing brcl with
bcrl. As a result no mcount locations are detected anymore with old gcc
versions (pre 9.0) and binutils before version 2.37.
Fix this by using the correct mnemonic again.Reported-by: Miroslav Benes
Cc: Jerome Marchand
Cc:
Fixes: 85bf17b28f97 ("recordmcount.pl: look for jgnop instruction as well as bcrl on s390")
Link: https://lore.kernel.org/r/alpine.LSU.2.21.2112230949520.19849@pobox.suse.cz
Signed-off-by: Heiko Carstens
Signed-off-by: Greg Kroah-Hartman
22 Dec, 2021
1 commit
-
commit 85bf17b28f97ca2749968d8786dc423db320d9c2 upstream.
On s390, recordmcount.pl is looking for "bcrl 0," instructions in
the objdump -d outpout. However since binutils 2.37, objdump -d
display "jgnop " for the same instruction. Update the
mcount_regex so that it accepts both.Signed-off-by: Jerome Marchand
Reviewed-by: Miroslav Benes
Acked-by: Steven Rostedt (VMware)
Cc:
Link: https://lore.kernel.org/r/20211210093827.1623286-1-jmarchan@redhat.com
Signed-off-by: Heiko Carstens
Signed-off-by: Greg Kroah-Hartman
19 Nov, 2021
1 commit
-
[ Upstream commit cf2a85efdade117e2169d6e26641016cbbf03ef0 ]
For files that lack trailing newlines and match a leaking address (e.g.
wchan[1]), the leaking_addresses.pl report would run together with the
next line, making things look corrupted.Unconditionally remove the newline on input, and write it back out on
output.[1] https://lore.kernel.org/all/20210103142726.GC30643@xsang-OptiPlex-9020/
Signed-off-by: Kees Cook
Signed-off-by: Peter Zijlstra (Intel)
Link: https://lkml.kernel.org/r/20211008111626.151570317@infradead.org
Signed-off-by: Sasha Levin
17 Oct, 2021
1 commit
-
Tracing fixes for 5.15:
- Fix defined but not use warning/error for osnoise function
- Fix memory leak in event probe
- Fix memblock leak in bootconfig
- Fix the API of event probes to be like kprobes
- Added test to check removal of event probe API
- Fix recordmcount.pl for nds32 failed build
* tag 'trace-v5.15-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
nds32/ftrace: Fix Error: invalid operands (*UND* and *UND* sections) for `^'
selftests/ftrace: Update test for more eprobe removal process
tracing: Fix event probe removal from dynamic events
tracing: Fix missing * in comment block
bootconfig: init: Fix memblock leak in xbc_make_cmdline()
tracing: Fix memory leak in eprobe_register()
tracing: Fix missing osnoise tracer on max_latency
16 Oct, 2021
1 commit
-
I received a build failure for a new patch I'm working on the nds32
architecture, and when I went to test it, I couldn't get to my build error,
because it failed to build with a bunch of:Error: invalid operands (*UND* and *UND* sections) for `^'
issues with various files. Those files were temporary asm files that looked
like: kernel/.tmp_mc_fork.sI decided to look deeper, and found that the "mc" portion of that name
stood for "mcount", and was created by the recordmcount.pl script. One that
I wrote over a decade ago. Once I knew the source of the problem, I was
able to investigate it further.The way the recordmcount.pl script works (BTW, there's a C version that
simply modifies the ELF object) is by doing an "objdump" on the object
file. Looks for all the calls to "mcount", and creates an offset of those
locations from some global variable it can use (usually a global function
name, found with :). Creates a asm file that is a table of references
to these locations, using the found variable/function. Compiles it and
links it back into the original object file. This asm file is called
".tmp_mc_.s".The problem here is that the objdump produced by the nds32 object file,
contains things that look like:0000159a :
159a: c6 00 beqz38 $r6, 159a
159a: R_NDS32_9_PCREL_RELA .text+0x159e
159c: 84 d2 movi55 $r6, #-14
159e: 80 06 mov55 $r0, $r6
15a0: ec 3c addi10.sp #0x3cWhere ".L3^B1 is somehow selected as the "global" variable to index off of.
Then the assembly file that holds the mcount locations looks like this:
.section __mcount_loc,"a",@progbits
.align 2
.long .L3^B1 + -5522
.long .L3^B1 + -5384
.long .L3^B1 + -5270
.long .L3^B1 + -5098
.long .L3^B1 + -4970
.long .L3^B1 + -4758
.long .L3^B1 + -4122
[...]And when it is compiled back to an object to link to the original object,
the compile fails on the "^" symbol.Simple solution for now, is to have the perl script ignore using function
symbols that have an "^" in the name.Link: https://lkml.kernel.org/r/20211014143507.4ad2c0f7@gandalf.local.home
Cc: stable@vger.kernel.org
Acked-by: Greentime Hu
Fixes: fbf58a52ac088 ("nds32/ftrace: Add RECORD_MCOUNT support")
Signed-off-by: Steven Rostedt (VMware)
12 Oct, 2021
1 commit
-
…/linux/kernel/git/shuah/linux-kselftest
Pull Kunit fixes from Shuah Khan:
- Fixes to address the structleak plugin causing the stack frame size
to grow immensely when used with KUnit. Fixes include adding a new
makefile to disable structleak and using it from KUnit iio, device
property, thunderbolt, and bitfield tests to disable it.- KUnit framework reference count leak in kfree_at_end
- KUnit tool fix to resolve conflict between --json and --raw_output
and generate correct test output in either case.- kernel-doc warnings due to mismatched arg names
* tag 'linux-kselftest-kunit-fixes-5.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest:
kunit: fix kernel-doc warnings due to mismatched arg names
bitfield: build kunit tests without structleak plugin
thunderbolt: build kunit tests without structleak plugin
device property: build kunit tests without structleak plugin
iio/test-format: build kunit tests without structleak plugin
gcc-plugins/structleak: add makefile var for disabling structleak
kunit: fix reference count leak in kfree_at_end
kunit: tool: better handling of quasi-bool args (--json, --raw_output)
10 Oct, 2021
1 commit
-
Pull RISC-V fixes from Palmer Dabbelt:
- A pair of fixes (along with the necessory cleanup) to our VDSO, to
avoid a locking during OOM and to prevent the text from overflowing
into the data page- A fix to checksyscalls to teach it about our rv32 UABI
- A fix to add clone3() to the rv32 UABI, which was pointed out by
checksyscalls- A fix to properly flush the icache on the local CPU in addition to
the remote CPUs* tag 'riscv-for-linus-5.15-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
checksyscalls: Unconditionally ignore fstat{,at}64
riscv: Flush current cpu icache before other cpus
RISC-V: Include clone3() on rv32
riscv/vdso: make arch_setup_additional_pages wait for mmap_sem for write killable
riscv/vdso: Move vdso data page up front
riscv/vdso: Refactor asm/vdso.h