Compare commits

...

17 Commits
rawhide ... f36

Author SHA1 Message Date
Coiby Xu 2479c8f687 Merge branch 'f37' into f36
Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-10-27 16:20:47 +08:00
Coiby Xu b8e2404a0e Merge branch 'rawhide' into f36 2022-07-26 19:47:22 +08:00
Coiby Xu f1f9612420 Merge branch 'rawhide' into f36 2022-05-23 18:40:59 +08:00
Coiby Xu 4b6445a794 Revert "Release 2.0.23-6"
This reverts commit 01a7da83f7.

Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-05-23 18:39:56 +08:00
Coiby Xu 1c7c89a76b Revert "arm64/kexec-arm64: add support for R_AARCH64_LDST128_ABS_LO12_NC rela"
This reverts commit 39789963fb.

Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-05-23 18:38:56 +08:00
Coiby Xu 799ff6c49a Revert "purgatory: do not enable vectorization automatically for purgatory compiling"
This reverts commit c6b2a4b26b.

Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-05-23 18:37:49 +08:00
Coiby Xu 873fe47f78 Revert "s390: handle R_390_PLT32DBL reloc entries in machine_apply_elf_rel()"
This reverts commit ca5a33855f.

Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-05-23 18:37:14 +08:00
Coiby Xu 01a7da83f7 Release 2.0.23-6
Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-04-02 12:21:45 +08:00
Coiby Xu 39789963fb arm64/kexec-arm64: add support for R_AARCH64_LDST128_ABS_LO12_NC rela
Resolves: bz2052949
Upstream: Fedora
Conflict: None

commit 8e3f663a4dfe39b303e25ea2b945a4fab9fef7ae
Author: Pingfan Liu <piliu@redhat.com>
Date:   Thu Mar 31 11:38:05 2022 +0800

    arm64/kexec-arm64: add support for R_AARCH64_LDST128_ABS_LO12_NC rela

    GCC 12 has some changes, which affects the generated AArch64 code of kexec-tools.
    Accordingly, a new rel type R_AARCH64_LDST128_ABS_LO12_NC is confronted
    by machine_apply_elf_rel() on AArch64. This fails the load of kernel
    with the message "machine_apply_elf_rel: ERROR Unknown type: 299"

    Citing from objdump -rDSl purgatory/purgatory.ro

    0000000000000f80 <sha256_starts>:
    sha256_starts():
         f80:       90000001        adrp    x1, 0 <verify_sha256_digest>
                            f80: R_AARCH64_ADR_PREL_PG_HI21 .text+0xfa0
         f84:       a9007c1f        stp     xzr, xzr, [x0]
         f88:       3dc00021        ldr     q1, [x1]
                            f88: R_AARCH64_LDST128_ABS_LO12_NC      .text+0xfa0
         f8c:       90000001        adrp    x1, 0 <verify_sha256_digest>
                            f8c: R_AARCH64_ADR_PREL_PG_HI21 .text+0xfb0
         f90:       3dc00020        ldr     q0, [x1]
                            f90: R_AARCH64_LDST128_ABS_LO12_NC      .text+0xfb0
         f94:       ad008001        stp     q1, q0, [x0, #16]
         f98:       d65f03c0        ret
         f9c:       d503201f        nop
         fa0:       6a09e667        .inst   0x6a09e667 ; undefined
         fa4:       bb67ae85        .inst   0xbb67ae85 ; undefined
         fa8:       3c6ef372        .inst   0x3c6ef372 ; undefined
         fac:       a54ff53a        ld3w    {z26.s-z28.s}, p5/z, [x9, #-3, mul vl]
         fb0:       510e527f        sub     wsp, w19, #0x394
         fb4:       9b05688c        madd    x12, x4, x5, x26
         fb8:       1f83d9ab        .inst   0x1f83d9ab ; undefined
         fbc:       5be0cd19        .inst   0x5be0cd19 ; undefined

    Here, gcc generates codes, which make loads and stores carried out using
    the 128-bits floating-point registers. And a new rel type
    R_AARCH64_LDST128_ABS_LO12_NC should be handled.

    Make machine_apply_elf_rel() coped with this new reloc, so kexec-tools
    can work smoothly.

    Signed-off-by: Pingfan Liu <piliu@redhat.com>
    Signed-off-by: Simon Horman <horms@verge.net.au>
2022-04-02 12:08:56 +08:00
Coiby Xu c6b2a4b26b purgatory: do not enable vectorization automatically for purgatory compiling
Resolves: bz2057391
Upstream: Fedora
Conflict: None

commit 1b03cf7adc3c156ecab2618acb1ec585336a3f75
Author: Baoquan He <bhe@redhat.com>
Date:   Tue Mar 29 18:12:28 2022 +0800

    purgatory: do not enable vectorization automatically for purgatory compiling

    Redhat CKI reported kdump kernel will hang a while very early after crash
    triggered, then reset to firmware to reboot.

    This failure can only be observed with kdump or kexec reboot via
    kexec_load system call. With kexec_file_load interface, both kdump and
    kexec reboot work very well. And further investigation shows that gcc
    version 11 doesn't have this issue, while gcc version 12 does.

    After checking the release notes of the latest gcc, Dave found out it's
    because gcc 12 enables auto-vectorization for -O2 optimization level.
    Please see below link for more information:

      https://www.phoronix.com/scan.php?page=news_item&px=GCC-12-Auto-Vec-O2

    Adding -fno-tree-vectorize to Makefile of purgatory can fix the issue.

    Signed-off-by: Baoquan He <bhe@redhat.com>
    Signed-off-by: Simon Horman <horms@verge.net.au>
2022-04-02 12:08:29 +08:00
Lichen Liu 85888c8d23 kdumpctl: sync the $TARGET_INITRD after rebuild
There is a system-wide sync call at the end of mkdumprd, move it to
kdumpctl after rebuild initrd and add another one for mkfadumprd.
Sync only the $TARGET_INITRD to avoid a system-wide sync taking too
long on a system with high disk activity.

Also update the sync in kdumpctl:restore_default_initrd which will
mv the $DEFAULT_INITRD_BAK to $DEFAULT_INITRD.

Signed-off-by: Lichen Liu <lichliu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
2022-04-02 11:45:39 +08:00
Coiby Xu ee97b48d7b try to update the crashkernel in GRUB_ETC_DEFAULT after kexec-tools updates the default crashkernel value
If GRUB_ETC_DEFAULT use crashkernel=auto or
crashkernel=OLD_DEFAULT_CRASHKERNEL, it should be updated as well.

Add a helper function to read kernel cmdline parameter from
GRUB_ETC_DEFAULT. This function is used to read kernel cmdline
parameter like fadump or crashkernel.

Reviewed-by: Philipp Rudo <prudo@redhat.com>
2022-04-02 11:45:32 +08:00
Coiby Xu 1f98ed97bd address the case where there are multiple values for the same kernel arg
There is the case where there are multiple entries of the same parameter on
the command line, e.g.
GRUB_CMDLINE_LINUX="crashkernel=110M crashkernel=220M fadump=on crashkernel=330M".

In such an situation _update_kernel_cmdline_in_grub_etc_default only
updates/removes the last entry which is usually not what you want as the
kernel (for crashkernel) takes the last entry it can find.

Thus make sure the case with multiple entries of the same parameter is
handled properly by removing all occurrences of given parameter first.

Note
1. sed command group and conditional control has been used to get rid of
   grep.
2. Fully supporting kernel cmdline as documented in
   Documentation/admin-guide/kernel-parameters.rst is complex and in
   foreseeable future a full implementation is not needed. So simply
   document the unsupported cases instead.

Fixes: 140da74 ("rewrite reset_crashkernel to support fadump and to used by RPM scriptlet")

Reported-by: Philipp Rudo <prudo@redhat.com>
Suggested-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
2022-04-02 11:45:25 +08:00
Coiby Xu 685e07eccd update kernel crashkernel in posttrans RPM scriptlet when updating kexec-tools
When doing in-place upgrading using leapp on x86_64, kdumpcl can't
acquire instance lock when running in %post RPM scriplet on x86_64,
  localhost upgrade[1306]: /bin/kdumpctl: line 49: /var/lock/kdump: No such file or directory
  localhost upgrade[1306]: kdump: Create file lock failed

and running "touch /var/lock/dkump" also fails with
"No such file or directory". Thus kdumpctl can't be run in %post
scriptlet. But kdumpctl can be run in %posttrans RPM scriplet.

Besides, it's better to update crashkernel after the kernel has been
updated. So let's update kernel crashkernel in the %posttrans
scriptlet which will be run in the end of a transaction i.e. after
the kernel has been updated.

Note for %posttrans scriptlet, "$1 == 1" means both installing a new
package and upgrading a package.

[1] https://github.com/apptainer/singularity/issues/2386#issuecomment-474747054

Reported-by: Jie Li <jieli@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
2022-04-02 11:45:20 +08:00
Tao Liu d8968f43d9 kdump-lib.sh: Check the output of blkid with sed instead of eval
Previously the output of blkid is not checked. If the output
is empty, the eval will report the following error message:

    /lib/kdump/kdump-lib.sh: eval: line 925: syntax error near unexpected token `;'
    /lib/kdump/kdump-lib.sh: eval: line 925: `; echo $TYPE'

For example, we can observe such a failing when blkid is invoked
against a lvm thinpool block device:

    $ blkid -u filesystem,crypto -o export -- "/dev/block/253\:2"
    $ echo $?
    2
    $ udevadm info /dev/block/253\:2|grep S\:
    S: mapper/vg00-thinpoll_tmeta

In this patch, we will use sed instead of eval, to output the
fstype of block device if any.

Signed-off-by: Tao Liu <ltao@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
2022-04-02 11:45:15 +08:00
Coiby Xu 8c72b6135e Release 2.0.23-5
Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-02-14 12:38:01 +08:00
Coiby Xu f447d5d00e fix incorrect usage of _get_all_kernels_from_grubby
It's found that the kernel cmdline crashkernel=auto doesn't get updated
when upgrading kexec-tools. This happens because _get_all_kernels_from_grubby
is called with no argument by reset_crashkernel_after_update. When retrieving
all kernel paths on the system, "grubby --info ALL" should be used. Fix this
error by passing "ALL" argument.

Fixes: 0adb0f4 ("try to reset kernel crashkernel when kexec-tools updates the default crashkernel value")

Reported-by: Jie Li <jieli@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Tao Liu <ltao@redhat.com>
2022-02-14 12:37:36 +08:00
1 changed files with 0 additions and 95 deletions

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;