rpms/kexec-tools
5
0
Fork 0
Code Issues Pull Requests Releases Activity

Release 2.0.26-7

Browse Source 
Resolves: RHEL-29044
Upstream: Fedora
Conflict: None

commit 20dc67f0ea5bd73289be99666cf0871c5ad7a6e6
Author: Coiby Xu <coxu@redhat.com>
Date:   Sun Apr 7 14:49:11 2024 +0800

    Release 2.0.26-7

    Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2269991

    Signed-off-by: Coiby Xu <coxu@redhat.com>

Signed-off-by: Lichen Liu <lichliu@redhat.com>
This commit is contained in:
Lichen Liu 2024-04-29 10:04:19 +08:00
parent 06bb5a10de
commit 27964382f6
No known key found for this signature in database
GPG Key ID: 2ED8215EF57B3D6C
3 changed files with 139 additions and 96 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

95
kexec-tools-2.0.23-s390_handle_R_390_PLT32DBL_reloc_entries_in_machine_apply_elf_rel_.patch
View File

@ -1,95 +0,0 @@
commit 186e7b0752d8fce1618fa37519671c834c46340e
Author: Alexander Egorenkov <egorenar@linux.ibm.com>
Date: Wed Dec 15 18:48:53 2021 +0100
s390: handle R_390_PLT32DBL reloc entries in machine_apply_elf_rel()
Starting with gcc 11.3, the C compiler will generate PLT-relative function
calls even if they are local and do not require it. Later on during linking,
the linker will replace all PLT-relative calls to local functions with
PC-relative ones. Unfortunately, the purgatory code of kexec/kdump is
not being linked as a regular executable or shared library would have been,
and therefore, all PLT-relative addresses remain in the generated purgatory
object code unresolved. This in turn lets kexec-tools fail with
"Unknown rela relocation: 0x14 0x73c0901c" for such relocation types.
Furthermore, the clang C compiler has always behaved like described above
and this commit should fix the purgatory code built with the latter.
Because the purgatory code is no regular executable or shared library,
contains only calls to local functions and has no PLT, all R_390_PLT32DBL
relocation entries can be resolved just like a R_390_PC32DBL one.
* https://refspecs.linuxfoundation.org/ELF/zSeries/lzsabi0_zSeries/x1633.html#AEN1699
Relocation entries of purgatory code generated with gcc 11.3
------------------------------------------------------------
$ readelf -r purgatory/purgatory.o
Relocation section '.rela.text' at offset 0x6e8 contains 27 entries:
Offset Info Type Sym. Value Sym. Name + Addend
00000000000c 000300000013 R_390_PC32DBL 0000000000000000 .data + 2
00000000001a 001000000014 R_390_PLT32DBL 0000000000000000 sha256_starts + 2
000000000030 001100000014 R_390_PLT32DBL 0000000000000000 sha256_update + 2
000000000046 001200000014 R_390_PLT32DBL 0000000000000000 sha256_finish + 2
000000000050 000300000013 R_390_PC32DBL 0000000000000000 .data + 102
00000000005a 001300000014 R_390_PLT32DBL 0000000000000000 memcmp + 2
...
000000000118 001600000014 R_390_PLT32DBL 0000000000000000 setup_arch + 2
00000000011e 000300000013 R_390_PC32DBL 0000000000000000 .data + 2
00000000012c 000f00000014 R_390_PLT32DBL 0000000000000000 verify_sha256_digest + 2
000000000142 001700000014 R_390_PLT32DBL 0000000000000000
post_verification[...] + 2
Relocation entries of purgatory code generated with gcc 11.2
------------------------------------------------------------
$ readelf -r purgatory/purgatory.o
Relocation section '.rela.text' at offset 0x6e8 contains 27 entries:
Offset Info Type Sym. Value Sym. Name + Addend
00000000000e 000300000013 R_390_PC32DBL 0000000000000000 .data + 2
00000000001c 001000000013 R_390_PC32DBL 0000000000000000 sha256_starts + 2
000000000036 001100000013 R_390_PC32DBL 0000000000000000 sha256_update + 2
000000000048 001200000013 R_390_PC32DBL 0000000000000000 sha256_finish + 2
000000000052 000300000013 R_390_PC32DBL 0000000000000000 .data + 102
00000000005c 001300000013 R_390_PC32DBL 0000000000000000 memcmp + 2
...
00000000011a 001600000013 R_390_PC32DBL 0000000000000000 setup_arch + 2
000000000120 000300000013 R_390_PC32DBL 0000000000000000 .data + 122
000000000130 000f00000013 R_390_PC32DBL 0000000000000000 verify_sha256_digest + 2
000000000146 001700000013 R_390_PC32DBL 0000000000000000 post_verification[...] + 2
Corresponding s390 kernel discussion:
* https://lore.kernel.org/linux-s390/20211208105801.188140-1-egorenar@linux.ibm.com/T/#u
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Reported-by: Tao Liu <ltao@redhat.com>
Suggested-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
[hca@linux.ibm.com: changed commit message as requested by Philipp Rudo]
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
diff --git a/kexec/arch/s390/kexec-elf-rel-s390.c b/kexec/arch/s390/kexec-elf-rel-s390.c
index a5e1b73455785ae3bc3aa72b3beee13ae202e82f..91ba86a9991dad4271b834fc3b24861c40309e52 100644
--- a/kexec/arch/s390/kexec-elf-rel-s390.c
+++ b/kexec/arch/s390/kexec-elf-rel-s390.c
@@ -56,6 +56,7 @@ void machine_apply_elf_rel(struct mem_ehdr *UNUSED(ehdr),
case R_390_PC16: /* PC relative 16 bit. */
case R_390_PC16DBL: /* PC relative 16 bit shifted by 1. */
case R_390_PC32DBL: /* PC relative 32 bit shifted by 1. */
+ case R_390_PLT32DBL: /* 32 bit PC rel. PLT shifted by 1. */
case R_390_PC32: /* PC relative 32 bit. */
case R_390_PC64: /* PC relative 64 bit. */
val -= address;
@@ -63,7 +64,7 @@ void machine_apply_elf_rel(struct mem_ehdr *UNUSED(ehdr),
*(unsigned short *) loc = val;
else if (r_type == R_390_PC16DBL)
*(unsigned short *) loc = val >> 1;
- else if (r_type == R_390_PC32DBL)
+ else if (r_type == R_390_PC32DBL || r_type == R_390_PLT32DBL)
*(unsigned int *) loc = val >> 1;
else if (r_type == R_390_PC32)
*(unsigned int *) loc = val;

132
kexec-tools-2.0.28-makedumfpile-0001-PATCH-ppc64-get-vmalloc-start-address-from-vmcoreinf.patch Normal file
View File

@ -0,0 +1,132 @@
From: Coiby Xu <coxu@redhat.com>
Subject: [PATCH] ppc64: get vmalloc start address from vmcoreinfo
Bugzilla: https://bugzilla.redhat.com/2269991
commit 94241fd2feed059227a243618f2acc6aabf366e8
Author: Aditya Gupta <adityag@linux.ibm.com>
Date: Sat Feb 24 00:33:42 2024 +0530
[PATCH] ppc64: get vmalloc start address from vmcoreinfo
Below error was noticed when running makedumpfile on linux-next kernel
crash (linux-next tag next-20240121):
Checking for memory holes : [100.0 %] | readpage_elf: Attempt to read non-existent page at 0xc000000000000.
[ 17.551718] kdump.sh[404]: readmem: type_addr: 0, addr:c00c000000000000, size:16384
[ 17.551793] kdump.sh[404]: __exclude_unnecessary_pages: Can't read the buffer of struct page.
[ 17.551864] kdump.sh[404]: create_2nd_bitmap: Can't exclude unnecessary pages.
[ 17.562632] kdump.sh[404]: The kernel version is not supported.
[ 17.562708] kdump.sh[404]: The makedumpfile operation may be incomplete.
[ 17.562773] kdump.sh[404]: makedumpfile Failed.
[ 17.564335] kdump[406]: saving vmcore failed, _exitcode:1
Above error was due to 'vmap_area_list' and 'vmlist' symbols missing
from the vmcore. 'vmap_area_list' was removed in the linux kernel
6.9-rc1 by the commit below:
commit 55c49fee57af99f3c663e69dedc5b85e691bbe50
mm/vmalloc: remove vmap_area_list
Subsequently the commit also introduced 'VMALLOC_START' in vmcoreinfo to
get base address of vmalloc area, instead of depending on 'vmap_area_list'
Hence if 'VMALLOC_START' symbol is there in vmcoreinfo:
1. Set vmalloc_start based on 'VMALLOC_START'
2. Don't error if vmap_area_list/vmlist are not defined
Reported-by: Sachin Sant <sachinp@linux.ibm.com>
Signed-off-by: Aditya Gupta <adityag@linux.ibm.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
diff --git a/makedumpfile-1.7.4/arch/ppc64.c b/makedumpfile-1.7.4/arch/ppc64.c
index 3b4f91981f71d035b94282f6c7e33323a4e4c1fd..a54f9a04db7f26eac2f1bd065b134a7e2fdaeb67 100644
--- a/makedumpfile-1.7.4/arch/ppc64.c
+++ b/makedumpfile-1.7.4/arch/ppc64.c
@@ -568,7 +568,9 @@ get_machdep_info_ppc64(void)
/*
* Get vmalloc_start value from either vmap_area_list or vmlist.
*/
- if ((SYMBOL(vmap_area_list) != NOT_FOUND_SYMBOL)
+ if (NUMBER(vmalloc_start) != NOT_FOUND_NUMBER) {
+ vmalloc_start = NUMBER(vmalloc_start);
+ } else if ((SYMBOL(vmap_area_list) != NOT_FOUND_SYMBOL)
&& (OFFSET(vmap_area.va_start) != NOT_FOUND_STRUCTURE)
&& (OFFSET(vmap_area.list) != NOT_FOUND_STRUCTURE)) {
if (!readmem(VADDR, SYMBOL(vmap_area_list) + OFFSET(list_head.next),
@@ -689,11 +691,16 @@ vaddr_to_paddr_ppc64(unsigned long vaddr)
if ((SYMBOL(vmap_area_list) == NOT_FOUND_SYMBOL)
|| (OFFSET(vmap_area.va_start) == NOT_FOUND_STRUCTURE)
|| (OFFSET(vmap_area.list) == NOT_FOUND_STRUCTURE)) {
- if ((SYMBOL(vmlist) == NOT_FOUND_SYMBOL)
- || (OFFSET(vm_struct.addr) == NOT_FOUND_STRUCTURE)) {
- ERRMSG("Can't get info for vmalloc translation.\n");
- return NOT_PADDR;
- }
+ /*
+ * Don't depend on vmap_area_list/vmlist if vmalloc_start is set in
+ * vmcoreinfo, in that case proceed without error
+ */
+ if (NUMBER(vmalloc_start) == NOT_FOUND_NUMBER)
+ if ((SYMBOL(vmlist) == NOT_FOUND_SYMBOL)
+ || (OFFSET(vm_struct.addr) == NOT_FOUND_STRUCTURE)) {
+ ERRMSG("Can't get info for vmalloc translation.\n");
+ return NOT_PADDR;
+ }
}
return ppc64_vtop_level4(vaddr);
diff --git a/makedumpfile-1.7.4/makedumpfile.c b/makedumpfile-1.7.4/makedumpfile.c
index 58c6639f289f19cdbf39ed3899be9893fdc317fe..d7f1dd41d2cab526d7d40e809ddccf656c586811 100644
--- a/makedumpfile-1.7.4/makedumpfile.c
+++ b/makedumpfile-1.7.4/makedumpfile.c
@@ -2978,6 +2978,8 @@ read_vmcoreinfo(void)
READ_NUMBER("PAGE_OFFLINE_MAPCOUNT_VALUE", PAGE_OFFLINE_MAPCOUNT_VALUE);
READ_NUMBER("phys_base", phys_base);
READ_NUMBER("KERNEL_IMAGE_SIZE", KERNEL_IMAGE_SIZE);
+
+ READ_NUMBER_UNSIGNED("VMALLOC_START", vmalloc_start);
#ifdef __aarch64__
READ_NUMBER("VA_BITS", VA_BITS);
READ_NUMBER("TCR_EL1_T1SZ", TCR_EL1_T1SZ);
@@ -2989,7 +2991,6 @@ read_vmcoreinfo(void)
READ_NUMBER("VA_BITS", va_bits);
READ_NUMBER_UNSIGNED("phys_ram_base", phys_ram_base);
READ_NUMBER_UNSIGNED("PAGE_OFFSET", page_offset);
- READ_NUMBER_UNSIGNED("VMALLOC_START", vmalloc_start);
READ_NUMBER_UNSIGNED("VMALLOC_END", vmalloc_end);
READ_NUMBER_UNSIGNED("VMEMMAP_START", vmemmap_start);
READ_NUMBER_UNSIGNED("VMEMMAP_END", vmemmap_end);
diff --git a/makedumpfile-1.7.4/makedumpfile.h b/makedumpfile-1.7.4/makedumpfile.h
index c04c330b69ecbe5fb232a2eabbd2d71f14b60cc0..c31f3a4371af8aae38dcba8cac4d6de1012b4cfd 100644
--- a/makedumpfile-1.7.4/makedumpfile.h
+++ b/makedumpfile-1.7.4/makedumpfile.h
@@ -541,8 +541,6 @@ do { \
* The value of dependence on machine
*/
#define PAGE_OFFSET (info->page_offset)
-#define VMALLOC_START (info->vmalloc_start)
-#define VMALLOC_END (info->vmalloc_end)
#define VMEMMAP_START (info->vmemmap_start)
#define VMEMMAP_END (info->vmemmap_end)
#define PMASK (0x7ffffffffffff000UL)
@@ -2263,6 +2261,9 @@ struct number_table {
long HUGETLB_PAGE_DTOR;
long phys_base;
long KERNEL_IMAGE_SIZE;
+
+ unsigned long vmalloc_start;
+
#ifdef __aarch64__
long VA_BITS;
long TCR_EL1_T1SZ;
@@ -2273,7 +2274,6 @@ struct number_table {
long va_bits;
unsigned long phys_ram_base;
unsigned long page_offset;
- unsigned long vmalloc_start;
unsigned long vmalloc_end;
unsigned long vmemmap_start;
unsigned long vmemmap_end;

8
kexec-tools.spec
View File

@ -5,7 +5,7 @@
Name: kexec-tools
Version: 2.0.28
Release: 6%{?dist}
Release: 7%{?dist}
License: GPL-2.0-only
Summary: The kexec/kdump userspace component
@ -111,6 +111,8 @@ Patch101: kexec-tools-2.0.28-Fix-building-on-x86_64-with-binutils-2.41.patch
# Author: Jiri Bohac <jbohac@suse.cz>
Patch601: kexec-tools-2.0.28-kexec-don-t-use-kexec_file_load-on-XEN.patch
Patch602: kexec-tools-2.0.28-makedumfpile-0001-PATCH-ppc64-get-vmalloc-start-address-from-vmcoreinf.patch
%description
kexec-tools provides /sbin/kexec binary that facilitates a new
kernel to boot using the kernel's kexec feature either on a
@ -158,6 +160,7 @@ tar -z -x -v -f %{SOURCE19}
%patch 101 -p1
%patch 601 -p1
%patch 602 -p1
%ifarch ppc
%define archdef ARCH=ppc
@ -395,6 +398,9 @@ fi
%changelog
* Sun Apr 07 2024 Coiby Xu <coxu@redhat.com> - 2.0.28-7
- Release 2.0.28-7
* Sat Mar 16 2024 Coiby Xu <coxu@redhat.com> - 2.0.28-6
- let kexec-tools depends on makedumpfile