- Jun 05, 2023
-
-
Nathan Chancellor authored
A future change will move CLANG_FLAGS from KBUILD_{A,C}FLAGS to KBUILD_CPPFLAGS so that '--target' is available while preprocessing. When that occurs, the following error appears when building the compat PowerPC vDSO: clang: error: unsupported option '-mbig-endian' for target 'x86_64-pc-linux-gnu' make[3]: *** [.../arch/powerpc/kernel/vdso/Makefile:76: arch/powerpc/kernel/vdso/vdso32.so.dbg] Error 1 Explicitly add CLANG_FLAGS to ldflags-y, so that '--target' will always be present. Signed-off-by:
Nathan Chancellor <nathan@kernel.org> Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Nathan Chancellor authored
A future change will move CLANG_FLAGS from KBUILD_{A,C}FLAGS to KBUILD_CPPFLAGS so that '--target' is available while preprocessing. When that occurs, the following error appears when building ARCH=mips with clang (tip of tree error shown): clang: error: unsupported option '-mabi=' for target 'x86_64-pc-linux-gnu' Add KBUILD_CPPFLAGS in the CHECKFLAGS invocation to keep everything working after the move. Signed-off-by:
Nathan Chancellor <nathan@kernel.org> Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
- Jun 04, 2023
-
-
Masahiro Yamada authored
For ARM, modpost fails to detect some types of section mismatches. [test code] .section .init.data,"aw" bar: .long 0 .section .data,"aw" .globl foo foo: .long bar - . It is apparently a bad reference, but modpost does not report anything. The test code above produces the following relocations. Relocation section '.rel.data' at offset 0xe8 contains 1 entry: Offset Info Type Sym.Value Sym. Name 00000000 00000403 R_ARM_REL32 00000000 .init.data Currently, R_ARM_REL32 is just skipped. Handle it like R_ARM_ABS32. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
addend_arm_rel() processes R_ARM_THM_CALL, R_ARM_THM_JUMP24, R_ARM_THM_JUMP19 in a wrong way. Here, test code. [test code for R_ARM_THM_JUMP24] .section .init.text,"ax" bar: bx lr .section .text,"ax" .globl foo foo: b bar [test code for R_ARM_THM_CALL] .section .init.text,"ax" bar: bx lr .section .text,"ax" .globl foo foo: push {lr} bl bar pop {pc} If you compile it with CONFIG_THUMB2_KERNEL=y, modpost will show the symbol name, (unknown). WARNING: modpost: vmlinux.o: section mismatch in reference: foo (section: .text) -> (unknown) (section: .init.text) (You need to use GNU linker instead of LLD to reproduce it.) Fix the code to make modpost show the correct symbol name. I checked arch/arm/kernel/module.c to learn the encoding of R_ARM_THM_CALL and R_ARM_THM_JUMP24. The module does not support R_ARM_THM_JUMP19, but I checked its encoding in ARM ARM. The '+4' is the compensation for pc-relative instruction. It is documented in "ELF for the Arm Architecture" [1]. "If the relocation is pc-relative then compensation for the PC bias (the PC value is 8 bytes ahead of the executing instruction in Arm state and 4 bytes in Thumb state) must be encoded in the relocation by the object producer." [1]: https://github.com/ARM-software/abi-aa/blob/main/aaelf32/aaelf32.rst Fixes: c9698e5c ("ARM: 7964/1: Detect section mismatches in thumb relocations") Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
When CONFIG_THUMB2_KERNEL is enabled, modpost fails to detect some types of section mismatches. [test code] #include <linux/init.h> int __initdata foo; int get_foo(void) { return foo; } It is apparently a bad reference, but modpost does not report anything. The test code above produces the following relocations. Relocation section '.rel.text' at offset 0x1e8 contains 2 entries: Offset Info Type Sym.Value Sym. Name 00000000 0000052f R_ARM_THM_MOVW_AB 00000000 .LANCHOR0 00000004 00000530 R_ARM_THM_MOVT_AB 00000000 .LANCHOR0 Currently, R_ARM_THM_MOVW_ABS_NC and R_ARM_THM_MOVT_ABS are just skipped. Add code to handle them. I checked arch/arm/kernel/module.c to learn how the offset is encoded in the instruction. One more thing to note for Thumb instructions - the st_value is an odd value, so you need to mask the bit 0 to get the offset. Otherwise, you will get an off-by-one error in the nearest symbol look-up. It is documented in "ELF for the ARM Architecture" [1]: In addition to the normal rules for symbol values the following rules shall also apply to symbols of type STT_FUNC: * If the symbol addresses an Arm instruction, its value is the address of the instruction (in a relocatable object, the offset of the instruction from the start of the section containing it). * If the symbol addresses a Thumb instruction, its value is the address of the instruction with bit zero set (in a relocatable object, the section offset with bit zero set). * For the purposes of relocation the value used shall be the address of the instruction (st_value & ~1). [1]: https://github.com/ARM-software/abi-aa/blob/main/aaelf32/aaelf32.rst Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
- Jun 02, 2023
-
-
Masahiro Yamada authored
find_fromsym() and find_tosym() are similar - both of them iterate in the .symtab section and return the nearest symbol. The difference between them is that find_tosym() allows a negative distance, but the distance must be less than 20. Factor out the common part into find_nearest_sym(). Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com>
-
Masahiro Yamada authored
For ARM defconfig (i.e. multi_v7_defconfig), modpost fails to detect some types of section mismatches. [test code] #include <linux/init.h> int __initdata foo; int get_foo(void) { return foo; } It is apparently a bad reference, but modpost does not report anything. The test code above produces the following relocations. Relocation section '.rel.text' at offset 0x200 contains 2 entries: Offset Info Type Sym.Value Sym. Name 00000000 0000062b R_ARM_MOVW_ABS_NC 00000000 .LANCHOR0 00000004 0000062c R_ARM_MOVT_ABS 00000000 .LANCHOR0 Currently, R_ARM_MOVW_ABS_NC and R_ARM_MOVT_ABS are just skipped. Add code to handle them. I checked arch/arm/kernel/module.c to learn how the offset is encoded in the instruction. The referenced symbol in relocation might be a local anchor. If is_valid_name() returns false, let's search for a better symbol name. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
addend_arm_rel() processes R_ARM_PC24, R_ARM_CALL, R_ARM_JUMP24 in a wrong way. Here, test code. [test code for R_ARM_JUMP24] .section .init.text,"ax" bar: bx lr .section .text,"ax" .globl foo foo: b bar [test code for R_ARM_CALL] .section .init.text,"ax" bar: bx lr .section .text,"ax" .globl foo foo: push {lr} bl bar pop {pc} If you compile it with ARM multi_v7_defconfig, modpost will show the symbol name, (unknown). WARNING: modpost: vmlinux.o: section mismatch in reference: foo (section: .text) -> (unknown) (section: .init.text) (You need to use GNU linker instead of LLD to reproduce it.) Fix the code to make modpost show the correct symbol name. I imported (with adjustment) sign_extend32() from include/linux/bitops.h. The '+8' is the compensation for pc-relative instruction. It is documented in "ELF for the Arm Architecture" [1]. "If the relocation is pc-relative then compensation for the PC bias (the PC value is 8 bytes ahead of the executing instruction in Arm state and 4 bytes in Thumb state) must be encoded in the relocation by the object producer." [1]: https://github.com/ARM-software/abi-aa/blob/main/aaelf32/aaelf32.rst Fixes: 56a974fa ("kbuild: make better section mismatch reports on arm") Fixes: 6e2e340b ("ARM: 7324/1: modpost: Fix section warnings for ARM for many compilers") Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
addend_arm_rel() processes R_ARM_ABS32 in a wrong way. Here, test code. [test code 1] #include <linux/init.h> int __initdata foo; int get_foo(void) { return foo; } If you compile it with ARM versatile_defconfig, modpost will show the symbol name, (unknown). WARNING: modpost: vmlinux.o: section mismatch in reference: get_foo (section: .text) -> (unknown) (section: .init.data) (You need to use GNU linker instead of LLD to reproduce it.) If you compile it for other architectures, modpost will show the correct symbol name. WARNING: modpost: vmlinux.o: section mismatch in reference: get_foo (section: .text) -> foo (section: .init.data) For R_ARM_ABS32, addend_arm_rel() sets r->r_addend to a wrong value. I just mimicked the code in arch/arm/kernel/module.c. However, there is more difficulty for ARM. Here, test code. [test code 2] #include <linux/init.h> int __initdata foo; int get_foo(void) { return foo; } int __initdata bar; int get_bar(void) { return bar; } With this commit applied, modpost will show the following messages for ARM versatile_defconfig: WARNING: modpost: vmlinux.o: section mismatch in reference: get_foo (section: .text) -> foo (section: .init.data) WARNING: modpost: vmlinux.o: section mismatch in reference: get_bar (section: .text) -> foo (section: .init.data) The reference from 'get_bar' to 'foo' seems wrong. I have no solution for this because it is true in assembly level. In the following output, relocation at 0x1c is no longer associated with 'bar'. The two relocation entries point to the same symbol, and the offset to 'bar' is encoded in the instruction 'r0, [r3, #4]'. Disassembly of section .text: 00000000 <get_foo>: 0: e59f3004 ldr r3, [pc, #4] @ c <get_foo+0xc> 4: e5930000 ldr r0, [r3] 8: e12fff1e bx lr c: 00000000 .word 0x00000000 00000010 <get_bar>: 10: e59f3004 ldr r3, [pc, #4] @ 1c <get_bar+0xc> 14: e5930004 ldr r0, [r3, #4] 18: e12fff1e bx lr 1c: 00000000 .word 0x00000000 Relocation section '.rel.text' at offset 0x244 contains 2 entries: Offset Info Type Sym.Value Sym. Name 0000000c 00000c02 R_ARM_ABS32 00000000 .init.data 0000001c 00000c02 R_ARM_ABS32 00000000 .init.data When find_elf_symbol() gets into a situation where relsym->st_name is zero, there is no guarantee to get the symbol name as written in C. I am keeping the current logic because it is useful in many architectures, but the symbol name is not always correct depending on the optimization. I left some comments in find_tosym(). Fixes: 56a974fa ("kbuild: make better section mismatch reports on arm") Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
- May 28, 2023
-
-
Masahiro Yamada authored
Use PATTERNS() macros to remove unneeded array definitions. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
There is no distinction between TEXT_TO_ANY_EXIT and DATA_TO_ANY_EXIT. Just merge them. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com>
-
Masahiro Yamada authored
You can merge these entries. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com>
-
Masahiro Yamada authored
This check is unneeded. Without it, sec_name() will returns the null string "", then section_mismatch() will return immediately. Anyway, special section indices rarely appear in these loops. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com>
-
Masahiro Yamada authored
r_offset/r_addend holds the offset address from/to which a symbol is referenced. It is unclear unless you are familiar with ELF. Rename them to faddr, taddr, respectively. The prefix 'f' means 'from', 't' means 'to'. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com>
-
Masahiro Yamada authored
find_tosym() takes 'sym' and stores the return value to another variable 'to'. You can use the same variable because we want to replace the original one when appropriate. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com>
-
Masahiro Yamada authored
secref_whitelist() does not use the argument 'mismatch'. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com>
-
Masahiro Yamada authored
This reverts commit a4d26f1a. The variable 'fromsym' never starts with ".L" since commit 87e5b1e8 ("module: Sync code of is_arm_mapping_symbol()"). In other words, Pattern 6 is now dead code. Previously, the .LANCHOR1 hid the symbols listed in Pattern 2. 87e5b1e8 provided a better solution. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com>
-
Masahiro Yamada authored
tar is used to build the kernel with CONFIG_IKHEADERS. GNU tar 1.28 or later is required. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Reviewed-by:
Nicolas Schier <nicolas@fjasle.eu>
-
Masahiro Yamada authored
This reverts commit 700dea5a . The reason for that commit was --sort=ORDER introduced in tar 1.28 (2014). More than 3 years have passed since then. Requiring GNU tar 1.28 should be fine now because we require GCC 5.1 (2015). Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Reviewed-by:
Nicolas Schier <nicolas@fjasle.eu>
-
- May 22, 2023
-
-
Ahmed S. Darwish authored
Kernel build now uses the gtags "-C (--directory)" option, available since GNU GLOBAL v6.6.5. Update the documentation accordingly. Signed-off-by:
Ahmed S. Darwish <darwi@linutronix.de> Cc: <stable@vger.kernel.org> Link: https://lists.gnu.org/archive/html/info-global/2020-09/msg00000.html Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Ahmed S. Darwish authored
gtags considers any file outside of its current working directory "outside the source tree" and refuses to index it. For O= kernel builds, or when "make" is invoked from a directory other then the kernel source tree, gtags ignores the entire kernel source and generates an empty index. Force-set gtags current working directory to the kernel source tree. Due to commit 9da0763b ("kbuild: Use relative path when building in a subdir of the source tree"), if the kernel build is done in a sub-directory of the kernel source tree, the kernel Makefile will set the kernel's $srctree to ".." for shorter compile-time and run-time warnings. Consequently, the list of files to be indexed will be in the "../*" form, rendering all such paths invalid once gtags switches to the kernel source tree as its current working directory. If gtags indexing is requested and the build directory is not the kernel source tree, index all files in absolute-path form. Note, indexing in absolute-path form will not affect the generated index, as paths in gtags indices are always relative to the gtags "root directory" anyway (as evidenced by "gtags --dump"). Signed-off-by:
Ahmed S. Darwish <darwi@linutronix.de> Cc: <stable@vger.kernel.org> Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
find_elf_symbol() and find_elf_symbol2() are not good names. Rename them to find_tosym(), find_fromsym(), respectively. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
find_elf_symbol2() converts the section index to the section name, then compares the two strings in each iteration. This is slow. It is faster to compare the section indices (i.e. integers) directly. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com>
-
Masahiro Yamada authored
default_mismatch_handler() does not need to compute 'tosec' because it is calculated by the caller. Pass it down to default_mismatch_handler() instead of calling sec_name() twice. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com>
-
Masahiro Yamada authored
Merging these two reduces several lines of code. The extable section mismatch is already distinguished by EXTABLE_TO_NON_TEXT. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com>
-
Masahiro Yamada authored
SHF_EXECINSTR is a bit flag (#define SHF_EXECINSTR 0x4). Compare the masked flag to '!= 0'. There is no good reason to stop modpost immediately even if a special section index is given. You will get a section mismatch error anyway. Also, change the return type to bool. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com>
-
Masahiro Yamada authored
report_sec_mismatch() and default_mismatch_handler() are small enough to be merged together. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com>
-
Masahiro Yamada authored
Collect relevant code into one place to clarify all the cases are covered by 'if () ... else if ... else ...'. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com>
-
Masahiro Yamada authored
This is the last user of get_pretty_name() - it is just used to distinguish whether the symbol is a function or not. It is not valuable information. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
report_extable_warnings() prints "from" in a pretty form, but we know it is always located in the __ex_table section, i.e. a collection of struct exception_table_entry. It is very likely to fail to get the symbol name and ends up with meaningless message: ... in reference from the (unknown reference) (unknown) to ... Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
find_extable_entry_size() is completely broken. It has awesome comments about how to calculate sizeof(struct exception_table_entry). It was based on these assumptions: - struct exception_table_entry has two fields - both of the fields have the same size Then, we came up with this equation: (offset of the second field) * 2 == (size of struct) It was true for all architectures when commit 52dc0595 ("modpost: handle relocations mismatch in __ex_table.") was applied. Our mathematics broke when commit 548acf19 ("x86/mm: Expand the exception table logic to allow new handling options") introduced the third field. Now, the definition of exception_table_entry is highly arch-dependent. For x86, sizeof(struct exception_table_entry) is apparently 12, but find_extable_entry_size() sets extable_entry_size to 8. I could fix it, but I do not see much value in this code. extable_entry_size is used just for selecting a slightly different error message. If the first field ("insn") references to a non-executable section, The relocation at %s+0x%lx references section "%s" which is not executable, IOW it is not possible for the kernel to fault at that address. Something is seriously wrong and should be fixed. If the second field ("fixup") references to a non-executable section, The relocation at %s+0x%lx references section "%s" which is not executable, IOW the kernel will fault if it ever tries to jump to it. Something is seriously wrong and should be fixed. Merge the two error messages rather than adding even more complexity. Change fatal() to error() to make it continue running and catch more possible errors. Fixes: 548acf19 ("x86/mm: Expand the exception table logic to allow new handling options") Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
The section mismatch check relies on the relocation entries. For REL, the addend value is implicit, so we need some code to compute it. Currently, EM_386, EM_ARM, and EM_MIPS are supported. This commit makes sure we covered all the cases. I believe the other architectures use RELA, where the explicit r_addend field exists. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Andrew Davis authored
As a follow up to the series allowing DTB overlays to built from .dtso files. Now that all overlays have been renamed, remove the ability to build from overlays from .dts files to prevent any files with the old name from accidental being added. Signed-off-by:
Andrew Davis <afd@ti.com> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
- May 15, 2023
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxlLinus Torvalds authored
Pull compute express link fixes from Dan Williams: - Fix a compilation issue with DEFINE_STATIC_SRCU() in the unit tests - Fix leaking kernel memory to a root-only sysfs attribute * tag 'cxl-fixes-6.4-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl: cxl: Add missing return to cdat read error path tools/testing/cxl: Use DEFINE_STATIC_SRCU()
-
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linuxLinus Torvalds authored
Pull parisc architecture fixes from Helge Deller: - Fix encoding of swp_entry due to added SWP_EXCLUSIVE flag - Include reboot.h to avoid gcc-12 compiler warning * tag 'parisc-for-6.4-2' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: Fix encoding of swp_entry due to added SWP_EXCLUSIVE flag parisc: kexec: include reboot.h
-
git://git.armlinux.org.uk/~rmk/linux-armLinus Torvalds authored
Pull ARM fixes from Russell King: - fix unwinder for uleb128 case - fix kernel-doc warnings for HP Jornada 7xx - fix unbalanced stack on vfp success path * tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm: ARM: 9297/1: vfp: avoid unbalanced stack on 'success' return path ARM: 9296/1: HP Jornada 7XX: fix kernel-doc warnings ARM: 9295/1: unwind:fix unwind abort for uleb128 case
-
- May 14, 2023
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull locking fix from Borislav Petkov: - Make sure __down_read_common() is always inlined so that the callers' names land in traceevents output and thus the blocked function can be identified * tag 'locking_urgent_for_v6.4_rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: locking/rwsem: Add __always_inline annotation to __down_read_common() and inlined callers
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull perf fixes from Borislav Petkov: - Make sure the PEBS buffer is flushed before reprogramming the hardware so that the correct record sizes are used - Update the sample size for AMD BRS events - Fix a confusion with using the same on-stack struct with different events in the event processing path * tag 'perf_urgent_for_v6.4_rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/x86/intel/ds: Flush PEBS DS when changing PEBS_DATA_CFG perf/x86: Fix missing sample size update on AMD BRS perf/core: Fix perf_sample_data not properly initialized for different swevents in perf_tp_event()
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull scheduler fix from Borislav Petkov: - Fix a couple of kernel-doc warnings * tag 'sched_urgent_for_v6.4_rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched: fix cid_lock kernel-doc warnings
-