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 stable@vger.kernel.org.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From abf0e8e4ef25478a4390115e6a953d589d1f9ffd Mon Sep 17 00:00:00 2001
From: Alexander Egorenkov egorenar@linux.ibm.com 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#...
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
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 Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20211209073817.82196-1-egorenar@linux.ibm.com Signed-off-by: Heiko Carstens hca@linux.ibm.com
diff --git a/arch/s390/kernel/machine_kexec_file.c b/arch/s390/kernel/machine_kexec_file.c index 876cdd3c994e..8f43575a4dd3 100644 --- a/arch/s390/kernel/machine_kexec_file.c +++ b/arch/s390/kernel/machine_kexec_file.c @@ -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,
gregkh@linuxfoundation.org writes:
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 stable@vger.kernel.org.
thanks,
greg k-h
please apply the following upstream commits (in this order):
1. edce10ee21f3916f5da34e55bbc03103c604ba70 2. 41967a37b8eedfee15b81406a9f3015be90d3980 3. abf0e8e4ef25478a4390115e6a953d589d1f9ffd (the failed commit)
Thanks!
Regards Alex
On Wed, Jan 12, 2022 at 10:06:14AM +0100, Alexander Egorenkov wrote:
Hi Greg,
gregkh@linuxfoundation.org writes:
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 stable@vger.kernel.org.
thanks,
greg k-h
please apply the following upstream commits (in this order):
- edce10ee21f3916f5da34e55bbc03103c604ba70
This commit fails to apply.
- 41967a37b8eedfee15b81406a9f3015be90d3980
- abf0e8e4ef25478a4390115e6a953d589d1f9ffd (the failed commit)
Can you please send a working set of backported patches that we can apply?
thanks,
greg k-h
Hi Greg,
Greg KH gregkh@linuxfoundation.org writes:
On Wed, Jan 12, 2022 at 10:06:14AM +0100, Alexander Egorenkov wrote:
Hi Greg,
gregkh@linuxfoundation.org writes:
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 stable@vger.kernel.org.
thanks,
greg k-h
please apply the following upstream commits (in this order):
- edce10ee21f3916f5da34e55bbc03103c604ba70
This commit fails to apply.
- 41967a37b8eedfee15b81406a9f3015be90d3980
- abf0e8e4ef25478a4390115e6a953d589d1f9ffd (the failed commit)
Can you please send a working set of backported patches that we can apply?
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
On Wed, Jan 12, 2022 at 01:50:12PM +0100, Alexander Egorenkov wrote:
Hi Greg,
Greg KH gregkh@linuxfoundation.org writes:
On Wed, Jan 12, 2022 at 10:06:14AM +0100, Alexander Egorenkov wrote:
Hi Greg,
gregkh@linuxfoundation.org writes:
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 stable@vger.kernel.org.
thanks,
greg k-h
please apply the following upstream commits (in this order):
- edce10ee21f3916f5da34e55bbc03103c604ba70
This commit fails to apply.
- 41967a37b8eedfee15b81406a9f3015be90d3980
- abf0e8e4ef25478a4390115e6a953d589d1f9ffd (the failed commit)
Can you please send a working set of backported patches that we can apply?
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.
Ah, yes, I think that is what must have happened here, it now worked, thanks.
greg k-h
linux-stable-mirror@lists.linaro.org