mirror of
https://mirrors.bfsu.edu.cn/git/linux.git
synced 2025-01-05 21:35:04 +08:00
62d0fd591d
As the bug report [1] pointed out, <linux/vermagic.h> must be included after <linux/module.h>. I believe we should not impose any include order restriction. We often sort include directives alphabetically, but it is just coding style convention. Technically, we can include header files in any order by making every header self-contained. Currently, arch-specific MODULE_ARCH_VERMAGIC is defined in <asm/module.h>, which is not included from <linux/vermagic.h>. Hence, the straight-forward fix-up would be as follows: |--- a/include/linux/vermagic.h |+++ b/include/linux/vermagic.h |@@ -1,5 +1,6 @@ | /* SPDX-License-Identifier: GPL-2.0 */ | #include <generated/utsrelease.h> |+#include <linux/module.h> | | /* Simply sanity version stamp for modules. */ | #ifdef CONFIG_SMP This works enough, but for further cleanups, I split MODULE_ARCH_VERMAGIC definitions into <asm/vermagic.h>. With this, <linux/module.h> and <linux/vermagic.h> will be orthogonal, and the location of MODULE_ARCH_VERMAGIC definitions will be consistent. For arc and ia64, MODULE_PROC_FAMILY is only used for defining MODULE_ARCH_VERMAGIC. I squashed it. For hexagon, nds32, and xtensa, I removed <asm/modules.h> entirely because they contained nothing but MODULE_ARCH_VERMAGIC definition. Kbuild will automatically generate <asm/modules.h> at build-time, wrapping <asm-generic/module.h>. [1] https://lore.kernel.org/lkml/20200411155623.GA22175@zn.tnic Reported-by: Borislav Petkov <bp@suse.de> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Jessica Yu <jeyu@kernel.org>
69 lines
1.8 KiB
C
69 lines
1.8 KiB
C
/* SPDX-License-Identifier: GPL-2.0-only */
|
|
/*
|
|
* Copyright (C) 2012 ARM Ltd.
|
|
*/
|
|
#ifndef __ASM_MODULE_H
|
|
#define __ASM_MODULE_H
|
|
|
|
#include <asm-generic/module.h>
|
|
|
|
#ifdef CONFIG_ARM64_MODULE_PLTS
|
|
struct mod_plt_sec {
|
|
int plt_shndx;
|
|
int plt_num_entries;
|
|
int plt_max_entries;
|
|
};
|
|
|
|
struct mod_arch_specific {
|
|
struct mod_plt_sec core;
|
|
struct mod_plt_sec init;
|
|
|
|
/* for CONFIG_DYNAMIC_FTRACE */
|
|
struct plt_entry *ftrace_trampolines;
|
|
};
|
|
#endif
|
|
|
|
u64 module_emit_plt_entry(struct module *mod, Elf64_Shdr *sechdrs,
|
|
void *loc, const Elf64_Rela *rela,
|
|
Elf64_Sym *sym);
|
|
|
|
u64 module_emit_veneer_for_adrp(struct module *mod, Elf64_Shdr *sechdrs,
|
|
void *loc, u64 val);
|
|
|
|
#ifdef CONFIG_RANDOMIZE_BASE
|
|
extern u64 module_alloc_base;
|
|
#else
|
|
#define module_alloc_base ((u64)_etext - MODULES_VSIZE)
|
|
#endif
|
|
|
|
struct plt_entry {
|
|
/*
|
|
* A program that conforms to the AArch64 Procedure Call Standard
|
|
* (AAPCS64) must assume that a veneer that alters IP0 (x16) and/or
|
|
* IP1 (x17) may be inserted at any branch instruction that is
|
|
* exposed to a relocation that supports long branches. Since that
|
|
* is exactly what we are dealing with here, we are free to use x16
|
|
* as a scratch register in the PLT veneers.
|
|
*/
|
|
__le32 adrp; /* adrp x16, .... */
|
|
__le32 add; /* add x16, x16, #0x.... */
|
|
__le32 br; /* br x16 */
|
|
};
|
|
|
|
static inline bool is_forbidden_offset_for_adrp(void *place)
|
|
{
|
|
return IS_ENABLED(CONFIG_ARM64_ERRATUM_843419) &&
|
|
cpus_have_const_cap(ARM64_WORKAROUND_843419) &&
|
|
((u64)place & 0xfff) >= 0xff8;
|
|
}
|
|
|
|
struct plt_entry get_plt_entry(u64 dst, void *pc);
|
|
bool plt_entries_equal(const struct plt_entry *a, const struct plt_entry *b);
|
|
|
|
static inline bool plt_entry_is_initialized(const struct plt_entry *e)
|
|
{
|
|
return e->adrp || e->add || e->br;
|
|
}
|
|
|
|
#endif /* __ASM_MODULE_H */
|