__startup_64() uses fixup_pointer() to access global variables in a
position-independent fashion. Access to next_early_pgt was wrapped into
the helper, but one of the instance in 5-level paging branch was missed.
GCC generates a R_X86_64_PC32 PC-relative relocation for the access
which doesn't trigger the issue, but Clang emmits a R_X86_64_32S which
leads to an invalid memory and system reboot.
Signed-off-by: Kirill A. Shutemov <kirill.shute...@linux.intel.com>
Fixes: 187e91fe5e91 ("x86/boot/64/clang: Use fixup_pointer() to access
'next_early_pgt'")
Cc: Alexander Potapenko <gli...@google.com>
---
arch/x86/kernel/head64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 16b1cbd3a61e..4d98ba8063d1 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -184,7 +184,7 @@ unsigned long __head __startup_64(unsigned long physaddr,
pgtable_flags = _KERNPG_TABLE_NOENC + sme_get_me_mask();
if (la57) {
- p4d = fixup_pointer(early_dynamic_pgts[next_early_pgt++],
physaddr);
+ p4d = fixup_pointer(early_dynamic_pgts[(*next_pgt_ptr)++],
physaddr);
i = (physaddr >> PGDIR_SHIFT) % PTRS_PER_PGD;
pgd[i + 0] = (pgdval_t)p4d + pgtable_flags;
--
2.21.0
