FAILED: patch "[PATCH] s390/kexec: handle R_390_PLT32DBL rela in" failed to apply to 5.15-stable tree

The patch below does not apply to the 5.15-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

From abf0e8e4ef25478a4390115e6a953d589d1f9ffd Mon Sep 17 00:00:00 2001
From: Alexander Egorenkov <[email protected]>
Date: Thu, 9 Dec 2021 08:38:17 +0100
Subject: [PATCH] s390/kexec: handle R_390_PLT32DBL rela in
arch_kexec_apply_relocations_add()

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 leads to the situation where the purgatory code is being executed during kdump with all PLT-relative addresses unresolved. And this results in endless loops within the purgatory code.

Furthermore, the clang C compiler has always behaved like described above and this commit should fix kdump for kernels 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 linux/arch/s390/purgatory/purgatory.o

Relocation section '.rela.text' at offset 0x370 contains 5 entries:
Offset Info Type Sym. Value Sym. Name + Addend

00000000005c  000c00000013 R_390_PC32DBL     0000000000000000 purgatory_sha_regions + 2
00000000007a  000d00000014 R_390_PLT32DBL    0000000000000000 sha256_update + 2
00000000008c  000e00000014 R_390_PLT32DBL    0000000000000000 sha256_final + 2
000000000092  000800000013 R_390_PC32DBL     0000000000000000 .LC0 + 2
0000000000a0  000f00000014 R_390_PLT32DBL    0000000000000000 memcmp + 2

Relocation entries of purgatory code generated with gcc 11.2
------------------------------------------------------------

$ readelf -r linux/arch/s390/purgatory/purgatory.o

Relocation section '.rela.text' at offset 0x368 contains 5 entries:
Offset Info Type Sym. Value Sym. Name + Addend

00000000005c  000c00000013 R_390_PC32DBL     0000000000000000 purgatory_sha_regions + 2
00000000007a  000d00000013 R_390_PC32DBL     0000000000000000 sha256_update + 2
00000000008c  000e00000013 R_390_PC32DBL     0000000000000000 sha256_final + 2
000000000092  000800000013 R_390_PC32DBL     0000000000000000 .LC0 + 2
0000000000a0  000f00000013 R_390_PC32DBL     0000000000000000 memcmp + 2

index 876cdd3c994e..8f43575a4dd3 100644
@@ -348,6 +348,10 @@ int arch_kexec_apply_relocations_add(struct purgatory_info *pi,
 		addr = section->sh_addr + relas[i].r_offset;
 
 		r_type = ELF64_R_TYPE(relas[i].r_info);
+
+		if (r_type == R_390_PLT32DBL)
+			r_type = R_390_PC32DBL;
+
 		ret = arch_kexec_do_relocs(r_type, loc, val, addr);
 		if (ret) {
 			pr_err("Unknown rela relocation: %d\n", r_type);

Hi Greg,

please apply the following upstream commits (in this order):

1. edce10ee21f3916f5da34e55bbc03103c604ba70
2. 41967a37b8eedfee15b81406a9f3015be90d3980
3. abf0e8e4ef25478a4390115e6a953d589d1f9ffd (the failed commit)

Thanks!

Regards
Alex

This commit fails to apply.

Can you please send a working set of backported patches that we can apply?

thanks,

greg k-h

Hi Greg,

I tested the stable branch 5.15.y and discovered that the fix 41967a37b8eedfee15b81406a9f3015be90d3980 is already present there.

Please try to apply just abf0e8e4ef25478a4390115e6a953d589d1f9ffd again. I think you probably tried to apply abf0e8e4ef25478a4390115e6a953d589d1f9ffd before 41967a37b8eedfee15b81406a9f3015be90d3980 was present ?
And now that is there, everything works.

Regards
Alex

Ah, yes, I think that is what must have happened here, it now worked, thanks.

greg k-h