| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
As for 'static data relocations', instead of patching an instruction (OR
ops), it should be assigned to value directly.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
According to ELF specification, if sh_addralign equals zero or one, then
the section has no alignment requirement on the start address. (I.e. it
can be aligned on 1 byte)
Since modern cpu asks the .text, .data, .bss to be aligned
on the machine word boundary at least, so in elf_rel_load(),
sh_addralign can not be zero, and
align = shdr->sh_addralign;
...
bufsz = _ALIGN(bufsz, align);
will not render a result of 'bufsz = 0'.
But it had better have a check on the case of 'sh_addralign == 0'
regardless of the assumption of machine word alignment.
This patch has no functional change.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
elf_info.page_offset is 'unsigned long long', while get_page_offset()
has the input param as a type of 'unsigned long *'. It demands explicit
type casting to mute the compiler warning.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Build kexec-tools with clang(clang version 13.0.1 (Fedora 13.0.1-1.fc36)).
Then when kexec loads kernel, it runs into the error message
"machine_apply_elf_rel: ERROR Unknown type: 264".
This is caused by the following reloc type in purgatory/purgatory.ro,
which is not supported yet.
R_AARCH64_MOVW_UABS_G0_NC
R_AARCH64_MOVW_UABS_G1_NC
R_AARCH64_MOVW_UABS_G2_NC
R_AARCH64_MOVW_UABS_G3
Adding code to support these relocs, so kexec can work smoothly.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
More and more reloc type need to be supported on aarch64. Using enum to
organize them to shorten the #ifdef macro list.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
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>
|
|
Close fp if file size is smaller than 13 bytes.
Fixes: dcfcc73c73e6 ("kexec-tools: Determine if the image is lzma commpressed")
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
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>
|
|
Currently there are 2 functions for decompressing compressed image. The
zlib_decompress_file() will determine if the image is compressed by gzip
before read, but lzma_decompress_file() will not. This can cause misleading
information to be printed when the image is not compressed by lzma and
debug option is used:
]# kexec -d -s -l /boot/vmlinuz-5.14.10-300.fc35.x86_64 \
--initrd /boot/initramfs-5.14.10-300.fc35.x86_64.img \
--reuse-cmdline
Try gzip decompression.
Try LZMA decompression.
lzma_decompress_file: read on /boot/vmlinuz-5.14.10-300.fc35.x86_64 of
65536 bytes failed
Add a helper function is_lzma_file() to help behave consistently.
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The old printk mechanism (> v3.5.0 and < v5.10.0) had a fixed size
buffer (log_buf) that contains all messages. The location for the next
message is stored in log_next_idx. In case the log_buf runs full
log_next_idx wraps around and starts overwriting old messages at the
beginning of the buffer. The wraparound is denoted by a message with
msg->len == 0.
Following the behavior described above blindly is dangerous as e.g. a
memory corruption could overwrite (parts of) the log_buf. If the
corruption adds a message with msg->len == 0 this leads to an endless
loop when dumping the dmesg. Fix this by verifying that not wrapped
around before when it encounters a message with msg->len == 0.
While at it also verify that the index is within the log_buf and thus
guard against corruptions with msg->len != 0.
The same bug has been reported and fixed in makedumpfile [1].
[1] http://lists.infradead.org/pipermail/kexec/2022-March/024272.html
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Refresh package database before installing dependencies to avoid failures
due to trying to install older, no longer available, versions of packages.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Currently, my_exec() does not expect the Xen KEXEC_CMD_kexec hypercall
to return on success, because it assumes that the hypercall always
triggers an immediate reboot. However, for Live Update, the hypercall
merely schedules the kexec operation and returns; the actual reboot
happens asynchronously. [1]
Therefore, rework the Xen code path of my_exec() such that it does not
treat a successfully processed Live Update request as an error. Also,
rephrase the comment above the function to remove ambiguity.
[1] https://lists.xen.org/archives/html/xen-devel/2021-05/msg00286.html
Signed-off-by: Raphael Ning <raphning@amazon.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Commit 4f77da634035 ("kexec-tools: Fix kexec_file_load(2) error
handling") introduced EFALLBACK for scenarios where fallbacking back
to kexec_load syscall is likely to work and dropped printing error
message for these scenarios. But printing error message for other
failure scenarios was inadvertently dropped. Restore printing error
message for such cases.
Fixes: 4f77da634035 ("kexec-tools: Fix kexec_file_load(2) error handling")
Cc: Petr Tesarik <ptesarik@suse.com>
Reported-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Reviewed-by: Petr Tesarik <ptesarik@suse.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Use concat_cmdline() to concatenate the --append string and
the --reuse-cmdline string, otherwise only one of the two
options is valid.
This is similar with commit 8b42c99aa3bc ("Fix --reuse-cmdline
so it is usable.").
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Use dbgprintf() to print command_line, initrd and dtb
in arch_process_options() for debugging.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Since kernel commit 14c127c957c1 ('arm64: mm: Flip kernel VA space'),
the memory layout on arm64 have changed, and kexec-tools can no longer
get the the right PAGE_OFFSET based on _text symbol.
Prior to that, the kimage (_text) lays above PAGE_END with this layout:
0 -> VA_START : Usespace
VA_START -> VA_START + 256M : BPF JIT, Modules
VA_START + 256M -> PAGE_OFFSET - (~GB misc) : Vmalloc (KERNEL _text HERE)
PAGE_OFFSET -> ... : * Linear map *
And here we have:
VA_START = -1UL << VA_BITS
PAGE_OFFSET = -1UL << (VA_BITS - 1)
_text < -1UL << (VA_BITS - 1)
Kernel image lays somewhere between VA_START and PAGE_OFFSET, so we just
calc VA_BITS by getting the highest unset bit of _text symbol address,
and shift one less bit of VA_BITS to get page offset. This works as long
as KASLR don't put kernel in a too high location (which is commented inline).
And after that commit, kernel layout have changed:
0 -> PAGE_OFFSET : Userspace
PAGE_OFFSET -> PAGE_END : * Linear map *
PAGE_END -> PAGE_END + 128M : bpf jit region
PAGE_END + 128M -> PAGE_END + 256MB : modules
PAGE_END + 256M -> ... : vmalloc (KERNEL _text HERE)
Here we have:
PAGE_OFFSET = -1UL << VA_BITS
PAGE_END = -1UL << (VA_BITS - 1)
_text > -1UL << (VA_BITS - 1)
Kernel image now lays above PAGE_END, so we have to shift one more bit to
get the VA_BITS, and shift the exact VA_BITS for PAGE_OFFSET.
We can simply check if "_text > -1UL << (VA_BITS - 1)" is true to judge
which layout is being used and shift the page offset occordingly.
Signed-off-by: Kairui Song <kasong@tencent.com>
(rebased and stripped by Pingfan )
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
phys_to_virt() calculates virtual address. As a important factor,
page_offset is excepted to be accurate.
Since arm64 kernel exposes va_bits through vmcore, using it.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
There are two funcs to get page_offset:
get_kernel_page_offset()
get_page_offset()
Since get_kernel_page_offset() does not observe the kernel formula, and
remove it. Unify them in order to introduce 52-bits VA kernel more
easily in the coming patch.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
After kernel commit 7bc1a0f9e176 ("arm64: mm: use single quantity to
represent the PA to VA translation"), phys_offset can be negative if
running 52-bits kernel on 48-bits hardware.
So changing phys_offset from unsigned to signed.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
--reuse-cmdline reads the command line of the currently
running kernel from /proc/cmdline and uses that for the
kernel that should be kexec'd.
Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
Reviewed-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This way the size of the command line that get_command_line() can handle
is no longer fixed.
Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
slurp_file() cannot be used to read proc files, as they are returning
a size of zero in stat(). Add a function slurp_proc_file() which is
similar to slurp_file(), but doesn't require the size of the file to
be known.
Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
KEXEC_ALL_OPTIONS could be used instead defining the same
array several times. This makes code easier to maintain when
new options are added.
Suggested-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
Reviewed-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Newer s390 kernels support a command line size longer than 896
bytes. Such kernels contain a new member in the parameter area,
which might be utilized by tools like kexec. Older kernels have
the location initialized to zero, so we check whether there's a
non-zero number present and use that. If there isn't, we fallback
to the legacy command line size of 896 bytes.
Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
Reviewed-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When crashkernel is reserved above 4G in memory, kernel should
reserve some amount of low memory for swiotlb and some DMA buffers.
So there may be two crash kernel regions, one is below 4G, the other
is above 4G.
Currently, there is only one crash kernel region on arm64, and pass
"linux,usable-memory-range = <BASE SIZE>" property to crash dump
kernel.
Now, we pass "linux,usable-memory-range = <BASE1 SIZE1 BASE2 SIZE2>"
to crash dump kernel to support two crash kernel regions and load crash
kernel high. Make the low memory region as the second range "BASE2 SIZE2"
to keep compatibility with existing user-space and older kdump kernels.
Signed-off-by: Chen Zhou <chenzhou10@huawei.com>
Co-developed-by: Zhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
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>
|
|
kexec-tools commit 61b8c79b0fb7 ("arm64/crashdump-arm64: deduce the
paddr of _text") tries to deduce the paddr of _text, but turns out
partially.
That commit is based on "The Image must be placed text_offset bytes from
a 2MB aligned base address anywhere in usable system RAM and called
there" in linux/Documentation/arm64/booting.rst, plus text_offset field
is zero.
But in practice, some boot loaders does not obey the convention, and
still boots up the kernel successfully.
Revisiting kernel commit e2a073dde921 ("arm64: omit [_text, _stext) from
permanent kernel mapping"), the kernel code size changes from (unsigned
long)__init_begin - (unsigned long)_text to (unsigned long)__init_begin
- (unsigned long)_stext
And it should be a better factor to decide which label starts the
"Kernel code" in /proc/iomem.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add .git to version so it doesn't look like a release.
This is just so when people build code from git it can
be identified as such from the version string.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Pass the following properties to the crash dump kernel, to provide a
modern DT interface between kexec and the crash dump kernel:
- linux,elfcorehdr: ELF core header segment, similar to the
"elfcorehdr=" kernel parameter.
- linux,usable-memory-range: Usable memory reserved for the crash dump
kernel.
This makes the memory reservation explicit, so Linux no longer needs
to mask the program counter, and rely on the "mem=" kernel parameter
to obtain the start and size of usable memory.
For backwards compatibility, the "elfcorehdr=" and "mem=" kernel
parameters are still appended to the kernel command line.
Loosely based on the ARM64 version by Akashi Takahiro.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
mem_lower and mem_upper are measured in kilobytes.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
free should be called before the function exit abnormally.
Signed-off-by: Kai Song <songkai01@inspur.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
fclose should be called before function exits
Signed-off-by: Kai Song <songkai01@inspur.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When the function exits abnormally,ph should be freed.
Signed-off-by: Kai Song <songkai01@inspur.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
In get_kernel_page_offset(),the local variable kv is unused,remove it.
Signed-off-by: Kai Song <songkai01@inspur.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Zhaofeng Li <hello@zhaofeng.li>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
In some cases, add_buffer will actually try to allocate the buffer
at 0x0, which may not be acceptable by some kernels. Let's avoid
the first 0x500 bytes so we don't screw up the IVT and BDA.
Signed-off-by: Zhaofeng Li <hello@zhaofeng.li>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This would segfault if mhi.rel_tag didn't exist.
Signed-off-by: Zhaofeng Li <hello@zhaofeng.li>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
tag_load_base_addr is dependent on rel_tag, and tag_framebuffer was
not accounted for.
Signed-off-by: Zhaofeng Li <hello@zhaofeng.li>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Zhaofeng Li <hello@zhaofeng.li>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Replace hardcoded FDT structure block tokens with proper names to
improve code readability.
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Since kernel commit e2a073dde921 ("arm64: omit [_text, _stext) from
permanent kernel mapping"), the physical address of 'Kernel code' in
/proc/iomem is mapped from _text, instead, from _stext.
Taking the compatibility into account, it had better deduce the paddr of
_text despite of the unavailability through /proc/iomem. It can be
achieved by utilizing the fact _text aligned on 2MB.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Cc: Simon Horman <horms@verge.net.au>
To: kexec@lists.infradead.org
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The ramdisk variable is defined in kexec/arch/ppc/kexec-ppc.c. This
other definition is not needed and breaks build with -fno-common.
Signed-off-by: Petr Tesarik <ptesarik@suse.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add .git to version so it doesn't look like a release.
This is just so when people build code from git it can
be identified as such from the version string.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
If the passed zImage happens to have a DTB appended, then the magic 4 bytes
of the DTB are copied together with the kernel image. This leads to
failed kexec boots because the decompressor finds the aforementioned
DTB magic and falsely tries to replace the DTB passed in the register r2
with the non-existent appended one.
Signed-off-by: Alexander Egorenkov <egorenar-dev@posteo.net>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
During kexec there are two kernel versions at play. The version of
the running kernel and the version of the kernel that will be booted.
On powerpc it appears people have been using the version of the
running kernel to attempt to detect properties of the kernel to be
booted which is just wrong. As the linux kernel version that is being
detected is a no longer supported kernel just remove that buggy and
confused code.
On x86_64 the kernel_version is used to compute the starting virtual
address of the running kernel so a proper core dump may be generated.
Using the kernel_version stopped working a while ago when the starting
virtual address became randomized.
The old code was kept for the case where the kernel was not built with
randomization support, but there is nothing in reading /proc/kcore
that won't work to detect the starting virtual address even there.
In fact /proc/kcore must have the starting virtual address or a
debugger can not make sense of the running kernel.
So just make computing the starting virtual address on x86_64
unconditional. With a hard coded fallback just in case something went
wrong.
Doing something with kernel_version() has become important as recent
stable kernels have seen the minor version to > 255. Just removing
kernel_version() looks like the best option.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
We risk throwing an entire large chunk away if it is just slightly
unaligned which then causes the crash kernel to run out of RAM. Keep
them and shrink them to alignment.
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The real mode ends at 0x400, not 0x100. The code intentionally excludes
the IVT as RAM, so use the correct address.
Also, 0x100 is not 1K aligned and will be rejected by add_memmap(). We
have observed problems that after a multiboot2 kexec, the next kexec
will throw away such unaligned chunks, losing memory for the next next
kernel. In some corner cases, such loss of memory can actually cause OOM
during boot.
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Initial github workflow which builds kexec on a range of architectures.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add distcheck target which aims to exercise build, install and uninstall
using distribution tarball.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This appears to have been copied from some generated code.
Simplify it by rolling repetitive operations into a for loop.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
For symmetry with the install target, also use DESTDIR in the uninstall
target.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
kexec_test is installed but not uninstalled.
Correct this oversight.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This provides a familiar alias for the existing tarball target.
The result is a tar.gz file.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The current method of creating the tarball, which is to the hard-link
the source directory to the target directory, results in self-referential
hardlinks which can be observed using tar xf.
This patch resolves this by using an intermediate tarball, held in memory,
which collects files to be distributed. This is then unpacked in the target
directory which is finally packed into the distribution tarball, a file.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
virtio-mem in Linux adds/removes individual memory blocks (e.g., 128 MB
each). Linux merges adjacent memory blocks added by virtio-mem devices, but
we can still end up with a very sparse memory layout when unplugging
memory in corner cases.
Let's increase the maximum number of crash memory ranges from ~2k to 32k.
32k should be sufficient for a very long time.
e_phnum field in the header is 16 bits wide, so we can fit a maximum of
~64k entries in there, shared with other entries (i.e., CPU). Therefore,
using up to 32k memory ranges is fine. (if we ever need more than ~64k,
we can switch to the sh_info field)
Move the temporary xen ranges off the stack, dynamically allocating
memory for them.
Note: We don't have to increase MAX_MEMORY_RANGES, because virtio-mem
added memory is driver managed and always detected and added by a
driver in the kexec'ed kernel; for ordinary kexec, we must not expose
these ranges in the firmware-provided memmap.
Cc: Simon Horman <horms@verge.net.au>
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
No need to iterate over empty entries.
Cc: Simon Horman <horms@verge.net.au>
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Traditionally, we had "System RAM" only on the top level of in the
kernel resource tree (-> /proc/iomem). Nowadays, we can also have
"System RAM" on lower levels of the tree -- driver-managed device memory
that is always detected and added via drivers. Current examples are
memory added via dax/kmem -- ("System RAM (kmem)") and virtio-mem ("System
RAM (virtio_mem)"). Note that in some kernel versions "System RAM
(kmem)" was exposed as "System RAM", but similarly, on lower levels of
the resource tree.
Let's add anything that contains "System RAM" to the elf core header, so
it will be dumped for kexec_load(). Handling kexec_file_load() in the
kernel is similarly getting fixed [1].
Loading a kdump kernel via "kexec -p -c" ... will result in the kdump
kernel to also dump dax/kmem and virtio-mem added System RAM now.
Note: We only want to dump this memory, we don't want to add this memory to
the memmap of an ordinary kexec'ed kernel ("fast system reboot").
[1] https://lkml.kernel.org/r/20210322160200.19633-1-david@redhat.com
Signed-off-by: David Hildenbrand <david@redhat.com>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Unlike xen_kexec_load(), xen_kexec_unload() and xen_kexec_status()
fail to distinguish between normal kexec and Xen Live Update image
types.
Fix that by introducing a new helper function that maps internal
flags to KEXEC_TYPE_*, and using it throughout kexec-xen.c.
Signed-off-by: Raphael Ning <raphning@amazon.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
According to kexec(8) manpage, --status (-S) works with both
normal kexec (loaded by -l) and crash kernel (loaded by -p) image
types, and defaults to the latter. However, the implementation does
not match the description: `kexec -l -S` queries the -p image type
as if -l were not specified. This is because there is no internal
flag defined for the normal kexec type, and -S treats the zero flag
as the trigger for the default behaviour (-p).
Fix that by making sure the default behaviour for -S is not applied
when the -l option is present.
Signed-off-by: Raphael Ning <raphning@amazon.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
On both Linux and Xen, an exit code of 0 from `kexec --status`
indicates that the kexec image being queried is NOT loaded, which
is contrary to what the man page and usage() say.
Signed-off-by: Raphael Ning <raphning@amazon.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When compiling for 32-bit:
util_lib/elf_info.c: In function ‘dump_dmesg_lockless’:
util_lib/elf_info.c:1095:39: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘size_t’ {aka ‘unsigned int’} [-Wformat=]
1095 | fprintf(stderr, "Failed to malloc %lu bytes for prb: %s\n",
| ~~^
| |
| long unsigned int
| %u
1096 | printk_ringbuffer_sz, strerror(errno));
| ~~~~~~~~~~~~~~~~~~~~
| |
| size_t {aka unsigned int}
util_lib/elf_info.c:1101:49: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘size_t’ {aka ‘unsigned int’} [-Wformat=]
1101 | fprintf(stderr, "Failed to read prb of size %lu bytes: %s\n",
| ~~^
| |
| long unsigned int
| %u
1102 | printk_ringbuffer_sz, strerror(errno));
| ~~~~~~~~~~~~~~~~~~~~
| |
| size_t {aka unsigned int}
Indeed, "size_t" is "unsigned int" on 32-bit platforms, and "unsigned
long" on 64-bit platforms.
Fix this by formatting using "%zu".
Fixes: 4149df9005f2cdd2 ("printk: add support for lockless ringbuffer")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When compiling for 32-bit:
util_lib/elf_info.c: In function ‘get_desc_state’:
util_lib/elf_info.c:923:31: warning: left shift count >= width of type [-Wshift-count-overflow]
923 | #define DESC_FLAGS_MASK (3UL << DESC_FLAGS_SHIFT)
| ^~
util_lib/elf_info.c:925:25: note: in expansion of macro ‘DESC_FLAGS_MASK’
925 | #define DESC_ID_MASK (~DESC_FLAGS_MASK)
| ^~~~~~~~~~~~~~~
util_lib/elf_info.c:926:30: note: in expansion of macro ‘DESC_ID_MASK’
926 | #define DESC_ID(sv) ((sv) & DESC_ID_MASK)
| ^~~~~~~~~~~~
util_lib/elf_info.c:947:12: note: in expansion of macro ‘DESC_ID’
947 | if (id != DESC_ID(state_val))
| ^~~~~~~
util_lib/elf_info.c: In function ‘id_inc’:
util_lib/elf_info.c:923:31: warning: left shift count >= width of type [-Wshift-count-overflow]
923 | #define DESC_FLAGS_MASK (3UL << DESC_FLAGS_SHIFT)
| ^~
util_lib/elf_info.c:925:25: note: in expansion of macro ‘DESC_FLAGS_MASK’
925 | #define DESC_ID_MASK (~DESC_FLAGS_MASK)
| ^~~~~~~~~~~~~~~
util_lib/elf_info.c:981:15: note: in expansion of macro ‘DESC_ID_MASK’
981 | return (id & DESC_ID_MASK);
| ^~~~~~~~~~~~
Indeed, "unsigned long" constants are 32-bit on 32-bit platforms, and
64-bit on 64-bit platforms.
Fix this by using a "ULL" suffix instead.
Fixes: 4149df9005f2cdd2 ("printk: add support for lockless ringbuffer")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When compiling for 32-bit:
kexec/kexec.c: In function ‘cmdline_add_liveupdate’:
kexec/kexec.c:1192:30: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘uint64_t’ {aka ‘long long unsigned int’} [-Wformat=]
1192 | sprintf(buf, " liveupdate=%luM@0x%lx", lu_sizeM, lu_start);
| ~~^ ~~~~~~~~
| | |
| | uint64_t {aka long long unsigned int}
| long unsigned int
| %llu
kexec/kexec.c:1192:37: warning: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘uint64_t’ {aka ‘long long unsigned int’} [-Wformat=]
1192 | sprintf(buf, " liveupdate=%luM@0x%lx", lu_sizeM, lu_start);
| ~~^ ~~~~~~~~
| | |
| | uint64_t {aka long long unsigned int}
| long unsigned int
| %llx
Indeed, "uint64_t" is "unsigned long long" on 32-bit formats, and
"unsigned long" on 64-bit formats.
Fix this by casting to "unsigned long long", and formatting using "%llu"
or "%llx".
Fixes: b13984c6f9ec7fdd ("kexec: Introduce --load-live-update for xen")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The added "mem=size@start" parameter actually corresponds to
"crashkernel=YM@XM", but 1 byte is missing when calculating
the size, so 1 byte should be added.
For example, when using crashkernel=108M@64M (110592K@65536K):
Without this patch:
the mem parameter added is: mem=110591K@65536K
With this patch:
the mem parameter added is: mem=110592K@65536K
Fixes: 0eac64052636 ("kexec: mips: Fix mem parameters")
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
kexec build will fail on older kernels (pre 4.4) as the define
VIDEO_CAPABILITY_64BIT_BASE was not present at that time.
This patch adds it, as per linux/include/uapi/linux/screen_info.h,
if not present.
Signed-off-by: Federico Pellegrin <fede@evolware.org>
Reviewed-by: Kairui Song <kasong@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Fix typo in comment.
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch adds an option "--reuse-cmdline" for people that are lazy
in typing --append="$(cat /proc/cmdline)", which will directly use the
command line of the currently running system.
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add .git to version so it doesn't look like a release.
This is just so when people build code from git it can
be identified as such from the version string.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
"mem=" is useful to indicate the memory region when capture kernel boot.
Otherwise, capture kernel will breakdown the memory of panic kernel.
Although it can be add by user, adding "mem" by software is a better way.
What's more, "mem" should contain elfcorehdr range. Elfcorehdr memory
should be managed by kernel.
Fixes: 7bd251654aad ("kexec-tools: mips: Remove commandline parameter "mem"")
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Signed-off-by: Jinyang He <hejinyang@loongson.cn>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
In function dtb_set_property, when malloc new_node fails,
we need to free new_dtb before return.
Fixes: f56cbcf4c2766 ("kexec/dt-ops.c: Fix '/chosen' v/s 'chosen' node
being passed to fdt helper functions")
Signed-off-by: qiuguorui1 <qiuguorui1@huawei.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
In function zlib_decompress_file, when gzdirect(fp) fails,
we should gzclose fp before return.
Fixes: d606837b56d46 ("Fix zlib/lzma decompression.")
Signed-off-by: qiuguorui1 <qiuguorui1@huawei.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Linux 5.10 moved to a new lockless ringbuffer. The new ringbuffer
is structured completely different to the previous iterations.
Add support for retrieving the ringbuffer using vmcoreinfo. The
new ringbuffer is detected based on the availability of the
"prb" symbol.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
fixed the same way as in 70cca82
"kexec: Fix snprintf related compilation warnings"
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
-mcmodel=large there
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add option to allow purgatory printing on arm64 hardware
by passing the console name which should be used.
Based on a patch by Geoff Levand.
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
Acked-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch fixes the following snprintf related compilation warning
seen currently with gcc versions 7 and 8 when kexec is compiled with
-Wformat-truncation option:
kexec/fs2dt.c:673:34: warning: ‘stdout-path’ directive output may be truncated writing 11 bytes into a region of size between 1 and 1024 [-Wformat-truncation=]
snprintf(filename, MAXPATH, "%sstdout-path", pathname);
^~~~~~~~~~~
kexec/fs2dt.c:673:3: note: ‘snprintf’ output between 12 and 1035 bytes into a destination of size 1024
snprintf(filename, MAXPATH, "%sstdout-path", pathname);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
kexec/fs2dt.c:676:35: warning: ‘linux,stdout-path’ directive output may be truncated writing 17 bytes into a region of size between 1 and 1024 [-Wformat-truncation=]
snprintf(filename, MAXPATH, "%slinux,stdout-path", pathname);
^~~~~~~~~~~~~~~~~
kexec/fs2dt.c:676:4: note: ‘snprintf’ output between 18 and 1041 bytes into a destination of size 1024
snprintf(filename, MAXPATH, "%slinux,stdout-path", pathname);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
kexec/firmware_memmap.c:132:35: warning: ‘%s’ directive output may be truncated writing 5 bytes into a region of size between 0 and 4095 [-Wformat-truncation=]
snprintf(filename, PATH_MAX, "%s/%s", entry, "start");
^~ ~~~~~~~
kexec/firmware_memmap.c:132:2: note: ‘snprintf’ output between 7 and 4102 bytes into a destination of size 4096
snprintf(filename, PATH_MAX, "%s/%s", entry, "start");
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
kexec/firmware_memmap.c:142:35: warning: ‘%s’ directive output may be truncated writing 3 bytes into a region of size between 0 and 4095 [-Wformat-truncation=]
snprintf(filename, PATH_MAX, "%s/%s", entry, "end");
^~ ~~~~~
kexec/firmware_memmap.c:142:2: note: ‘snprintf’ output between 5 and 4100 bytes into a destination of size 4096
snprintf(filename, PATH_MAX, "%s/%s", entry, "end");
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
kexec/firmware_memmap.c:152:35: warning: ‘%s’ directive output may be truncated writing 4 bytes into a region of size between 0 and 4095 [-Wformat-truncation=]
snprintf(filename, PATH_MAX, "%s/%s", entry, "type");
^~ ~~~~~~
kexec/firmware_memmap.c:152:2: note: ‘snprintf’ output between 6 and 4101 bytes into a destination of size 4096
snprintf(filename, PATH_MAX, "%s/%s", entry, "type");
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Since the simplest method to address the gcc warnings and possible
truncation would be to check the return value provided from snprintf
(well there are other methods like using 'asnprintf' or using
'open_memstream' function to create the FILE object, but these are more
intrusive), so this patch does the same.
Cc: Simon Horman <horms@verge.net.au>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: kexec@lists.infradead.org
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The vmcore-dmesg utility has been in usage for several years,
and is pretty stable now.
So its useful now to modify its man page to indicate the same.
Also fix some minor formatting issues.
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add some missing free() calls.
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Where Y specifies how much memory to reserve for the dump-capture kernel
and X specifies the beginning of this reserved memory. So Y should be
placed before X.
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Reviewed-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
"mem=" indicating the memory region the new kernel can use to boot into.
And passed to the dump-capture kernel by kernel commandline parameter
"mem=". But in the dump-capture kernel, we don’t need to use this parameter
now, so remove "mem" and don't add "mem=" to new kernel commandline.
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add missing close() call.
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Reviewed-by: Khalid Aziz <khalid@gonehiking.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
New email address for Khalid Aziz.
Signed-off-by: Khalid Aziz <khalid@gonehiking.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Fix the following warnings:
kexec/arch/mips/kexec-elf-mips.c:161:41: warning: passing argument 3 of
‘dtb_set_initrd’ makes integer from pointer without a cast
dtb_set_initrd(&dtb_buf, &dtb_length, initrd_buf, initrd_buf + initrd_size);
^
In file included from kexec/arch/mips/kexec-elf-mips.c:33:0:
kexec/arch/mips/../../dt-ops.h:6:5: note: expected ‘off_t’ but argument is
of type ‘char *’
int dtb_set_initrd(char **dtb, off_t *dtb_size, off_t start, off_t end);
^
kexec/arch/mips/kexec-elf-mips.c:161:53: warning: passing argument 4 of
‘dtb_set_initrd’ makes integer from pointer without a cast
dtb_set_initrd(&dtb_buf, &dtb_length, initrd_buf, initrd_buf + initrd_size);
^
In file included from kexec/arch/mips/kexec-elf-mips.c:33:0:
kexec/arch/mips/../../dt-ops.h:6:5: note: expected ‘off_t’ but argument is
of type ‘char *’
int dtb_set_initrd(char **dtb, off_t *dtb_size, off_t start, off_t end);
^
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
In the function elf_mips_load(), crash_cmdline was alloced memory.
But it seems to forget to free it when last used at line 131.
Signed-off-by: Jinyang He <hejinyang@loongson.cn>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
In the function kexec_iomem_for_each_line(), it is better to
check the callback first, it can return directly if the callback
is NULL.
Signed-off-by: Jinyang He <hejinyang@loongson.cn>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Increase the size of the zImage after seeking for the tag to avoid
reading past the end of the supplied buffer should there be not tag
in the zImage.
Fixes: f57f0bf8975d24fe1e7c4936fdfb5c3b123ab75f
Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
Cc: Russell King <rmk@armlinux.org.uk>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Fixes: 28d4ab532808 ("Add generic debug option")
Cc: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Redefine OPT_APPEND to avoid clash with OPT_KEXEC_SYSCALL_AUTO.
Redefine OPT_RAMDISK to avoid such problems in the future
Minor cleanup in HPPA too.
Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The command line is duplicated on s390 if kexec_file_load(2) is not
implemented. That's because the corresponding variable is not reset
to an empty string before re-parsing the kexec command line.
Fixes: 9cf721279f6c ("Reset getopt before falling back to legacy syscall")
Signed-off-by: Petr Tesarik <ptesarik@suse.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This signals xen to do a KEXEC_TYPE_LIVE_UPDATE kexec operation.
Signed-off-by: Varad Gautam <vrd@amazon.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Support loading a live update image for xen from kexec userspace.
For a multiboot2 Elf on a xen setup, this will:
- load the Elf into KEXEC_RANGE_MA_XEN
- load purgatory and modules into KEXEC_RANGE_MA_LIVEUPDATE
- append the Elf cmdline with " liveupdate=<size>@<addr>
v2: define xen related symbols outside of HAVE_LIBXENCTRL
Signed-off-by: Varad Gautam <vrd@amazon.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
And convert all callers of xc_kexec_get_range to use this. Allows reusing
sanity checks for other KEXEC_RANGEs
v2: define xen_get_kexec_range outside of HAVE_LIBXENCTRL
Signed-off-by: Varad Gautam <vrd@amazon.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When building kexec-tools for Fedora 32, following error is observed:
/usr/bin/ld: kexec/arch/x86_64/kexec-bzImage64.o:(.bss+0x0): multiple definition of `bzImage_support_efi_boot';
kexec/arch/i386/kexec-bzImage.o:(.bss+0x0): first defined here
/builddir/build/BUILD/kexec-tools-2.0.20/kexec/arch/arm/../../fs2dt.h:33: multiple definition of `my_debug';
kexec/fs2dt.o:/builddir/build/BUILD/kexec-tools-2.0.20/kexec/fs2dt.h:33: first defined here
/builddir/build/BUILD/kexec-tools-2.0.20/kexec/arch/arm64/kexec-arm64.h:68: multiple definition of `arm64_mem';
kexec/fs2dt.o:/builddir/build/BUILD/kexec-tools-2.0.20/././kexec/arch/arm64/kexec-arm64.h:68: first defined here
/builddir/build/BUILD/kexec-tools-2.0.20/kexec/arch/arm64/kexec-arm64.h:54: multiple definition of `initrd_size';
kexec/fs2dt.o:/builddir/build/BUILD/kexec-tools-2.0.20/././kexec/arch/arm64/kexec-arm64.h:54: first defined here
/builddir/build/BUILD/kexec-tools-2.0.20/kexec/arch/arm64/kexec-arm64.h:53: multiple definition of `initrd_base';
kexec/fs2dt.o:/builddir/build/BUILD/kexec-tools-2.0.20/././kexec/arch/arm64/kexec-arm64.h:53: first defined here
And apparently, these variables are wrongly declared multiple times. So
remove duplicated declaration.
Signed-off-by: Kairui Song <kasong@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Hi,
Looking in the kexec-tools code I found these conditions that
seems will never be met. Not sure if that was intentional for explicitity,
if it was the case, please disconsider this patch.
xmalloc and xrealloc when fails calls die() that calls exit(1).
Checks for if(!memory) after they are called will never be met that
condition, since the process will be exited after an allocation fail.
Signed-off-by: Leonidas S. Barbosa <kirotawa@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
reserved region
When loading kernel and initramfs for kexec, kexec-tools could get the
e820 reserved region from "/proc/iomem" in order to rebuild the e820
ranges for kexec kernel, but there may be the string "Reserved" in the
"/proc/iomem", which caused the failure of parsing. For example:
#cat /proc/iomem|grep -i reserved
00000000-00000fff : Reserved
7f338000-7f34dfff : Reserved
7f3cd000-8fffffff : Reserved
f17f0000-f17f1fff : Reserved
fe000000-ffffffff : Reserved
Currently, kexec-tools can not handle the above case because the memcmp()
is case sensitive when comparing the string.
So, let's fix this corner and make sure that the string "reserved" and
"Reserved" in the "/proc/iomem" are both parsed appropriately.
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
Acked-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The modules may need to parse the arguments again after
kexec_file_load(2) failed, but getopt is not reset.
This change fixes the --initrd option on s390x. Without this patch,
it will fail to load the initrd on kernels that do not implement
kexec_file_load(2).
Signed-off-by: Petr Tesarik <ptesarik@suse.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The handling of kexec_file_load() error conditions needs some
improvement.
First, on failure, the system call itself returns -1 and sets
errno. It is wrong to check the return value itself.
Second, do_kexec_file_load() mixes different types of error
codes (-1, return value of a load method, negative kernel error
number). Let it always return one of the reason codes defined in
kexec/kexec.h.
Third, the caller of do_kexec_file_load() cannot know what exactly
failed inside that function, so it should not check errno directly.
All it needs to know is whether it makes sense to fall back to the
other syscall. Add an error code for that purpose (EFALLBACK), and
let do_kexec_file_load() decide.
Fourth, do_kexec_file_load() should not print any error message if
it returns EFALLBACK, because the fallback syscall may succeed
later, and the user is confused whether the command failed, or not.
Move the error message towards the end of main().
Signed-off-by: Petr Tesarik <ptesarik@suse.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When reading the device-tree exported crashkernel-base and
crashkernel-size, their values should be converted from big-endian to the
CPU byte order.
These is the output of running kexec --print-ckr-size on a little-endian
ppc64 box.
$ kexec --print-ckr-size
137438953472
$ kexec --print-ckr-size
536870912
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This addresses the following compilation issues when building for i386.
kexec/arch/i386/kexec-x86.c:39:22: error: 'multiboot2_x86_probe' undeclared here (not in a function); did you mean 'multiboot_x86_probe'?
{ "multiboot2-x86", multiboot2_x86_probe, multiboot2_x86_load,
^~~~~~~~~~~~~~~~~~~~
multiboot_x86_probe
kexec/arch/i386/kexec-x86.c:39:44: error: 'multiboot2_x86_load' undeclared here (not in a function); did you mean 'multiboot_x86_load'?
{ "multiboot2-x86", multiboot2_x86_probe, multiboot2_x86_load,
^~~~~~~~~~~~~~~~~~~
multiboot_x86_load
kexec/arch/i386/kexec-x86.c:40:4: error: 'multiboot2_x86_usage' undeclared here (not in a function); did you mean 'multiboot_x86_usage'?
multiboot2_x86_usage },
^~~~~~~~~~~~~~~~~~~~
multiboot_x86_usage
make: *** [Makefile:114: kexec/arch/i386/kexec-x86.o] Error 1
make: *** Waiting for unfinished jobs....
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
We use a large initrd that maxes out our available RAM when loading
kexec. The problem can be mitigated by using slurp_file_mmap(), which
avoids creating a copy of the initrd. The initrd does not use free,
realloc, etc, so it should be safe to use.
Signed-off-by: Brandon Maier <brandon.maier@rockwellcollins.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
As described in the commit ("arm64: kexec: allocate memory space avoiding
reserved regions"), /proc/iomem now has a lot of "reserved" entries, and
it's not just enough to have a fixed size of memory range array.
With this patch, kdump is allowed to handle arbitrary number of memory
ranges, using mem_regions_alloc_and_xxx() functions.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Tested-by: Bhupesh Sharma <bhsharma@redhat.com>
Tested-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
On UEFI/ACPI-only system, some memory regions, including but not limited
to UEFI memory map and ACPI tables, must be preserved across kexec'ing.
Otherwise, they can be corrupted and result in early failure in booting
a new kernel.
In recent kernels, /proc/iomem now has an extended file format like:
40000000-5871ffff : System RAM
41800000-426affff : Kernel code
426b0000-42aaffff : reserved
42ab0000-42c64fff : Kernel data
54400000-583fffff : Crash kernel
58590000-585effff : reserved
58700000-5871ffff : reserved
58720000-58b5ffff : reserved
58b60000-5be3ffff : System RAM
58b61000-58b61fff : reserved
where the "reserved" entries at the top level or under System RAM (and
its descendant resources) are ones of such kind and should not be regarded
as usable memory ranges where several free spaces for loading kexec data
will be allocated.
With this patch, get_memory_ranges() will handle this format of file
correctly. Note that, for safety, unknown regions, in addition to
"reserved" ones, will also be excluded.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Tested-by: Bhupesh Sharma <bhsharma@redhat.com>
Tested-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
mem_regions_alloc_and_add() and mem_regions_alloc_and_exclude() are
functionally equivalent to, respectively, mem_regions_add() and
mem_regions_exclude() except the formers will re-allocate memory
dynamically when no more entries are available in 'ranges' array.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Tested-by: Bhupesh Sharma <bhsharma@redhat.com>
Tested-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When compiling kexec-tools on a 32-bit platform, assigning an
(unsigned long long) value to an (unsigned long) variable creates
this warning:
elf_info.c: In function 'read_phys_offset_elf_kcore':
elf_info.c:805:14: warning: conversion from 'long long unsigned int' to
'long unsigned int' changes value from '18446744073709551615' to '4294967295'
805 | *phys_off = UINT64_MAX;
Fix it by using ULONG_MAX instead of UINT64_MAX.
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Fix a possible out-of-bounds access in function ifdown():
ifdown.c: In function 'ifdown':
ifdown.c:56:4: warning: 'strncpy' specified bound 16 equals destination size [-Wstringop-truncation]
56 | strncpy(ifr.ifr_name, ifp->if_name, IFNAMSIZ);
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch adds support for the parisc Architecture. kexec support
for parisc is included with linux-5.4.
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Tested-by: Helge Deller <deller@gmx.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
In the kernel upstream commit 4ab65ba7a5cb
("ARM: add kexec_file_load system call number"),
__NR_kexec_file_load for arm has been defined to be 401.
This results that even if kexec_file_load isn't implemented
for arm but the function is_kexec_file_load_implemented()
will still return true. So undef __NR_kexec_file_load for
arm architecture.
Signed-off-by: Quanyang Wang <quanyang.wang@windriver.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch fixes the following compilation warning in
'i386/kexec-mb2-x86.c' regarding the variable 'result'
which is set but not used:
kexec/arch/i386/kexec-mb2-x86.c:402:6:
warning: variable ‘result’ set but not used [-Wunused-but-set-variable]
int result;
^~~~~~
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Running 'cppcheck' static code analyzer (see cppcheck(1))
on 'vmcore-dmesg/vmcore-dmesg.c' shows the following
shifting error:
$ cppcheck --enable=all vmcore-dmesg/vmcore-dmesg.c
Checking vmcore-dmesg/vmcore-dmesg.c ...
[vmcore-dmesg/vmcore-dmesg.c:17]: (error) Shifting signed 32-bit value by 31 bits is undefined behaviour
Fix the same via this patch.
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
With some corrupted vmcore files, the vmcore-dmesg.txt file may grow
forever till the kdump disk becomes full, and also probably causes
the disk error messages as follow:
...
sd 0:0:0:0: [sda] tag#6 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:0:0: [sda] tag#6 CDB: Read(10) 28 00 08 06 4c 98 00 00 08 00
blk_update_request: I/O error, dev sda, sector 134630552
sd 0:0:0:0: [sda] tag#7 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:0:0: [sda] tag#7 CDB: Read(10) 28 00 08 06 4c 98 00 00 08 00
blk_update_request: I/O error, dev sda, sector 134630552
...
If vmcore-dmesg.txt occupies the whole disk, the vmcore can not be
saved, this is also a problem.
Lets limit the size of vmcore-dmesg.txt to avoid such problems.
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Some code related to vmcore-dmesg.c is put into the util_lib, which
is not very reasonable, so lets move it back and tidy up those code.
In addition, that will also help to limit the size of vmcore-dmesg.txt
in vmcore-dmesg.c instead of elf_info.c.
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The variable 'fname' is mistakenly defined two twice, the first definition
is in the vmcore-dmesg.c, and the second definition is in the elf_info.c.
That is confused and incorrect although it's a static type, because the
value of variable 'fname' is not assigned(set) in elf_info.c. Anyway, its
value will be always 'null' when printing an error information.
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Here, no need to wrap the read_elf() again, lets invoke it directly.
So remove the read_elf_kcore() and clean up redundant code.
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Linux kernel commit d52888aa2753 ("x86/mm: Move LDT remap out of KASLR
region on 5-level paging") changed the base of the direct mapping
from 0xffff880000000000 to 0xffff888000000000. This was merged
into v4.20-rc2.
Update to new address accordingly.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add .git to version so it doesn't look like a release.
This is just so when people build code from git it can
be identified as such from the version string.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Currently the kexec_file_load() support for arm64 doesn't allow
handling zlib compressed (i.e. Image.gz) image.
Since most distributions use 'make zinstall' rule inside
'arch/arm64/boot/Makefile' to install the arm64
Image.gz compressed file inside the boot destination directory (for e.g.
/boot), currently we cannot use kexec_file_load() to load vmlinuz (or
Image.gz):
# file /boot/vmlinuz
/boot/vmlinuz: gzip compressed data, was "Image", <..snip..>, max
compression, from Unix, original size 21945120
Now, since via kexec_file_load() we pass the 'fd' of Image.gz
(compressed file) via the following command line ...
# kexec -s -l /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
-r`.img --reuse-cmdline
... kernel returns -EINVAL error value, as it is not able to locate
the magic number =0x644d5241, which is expected in the 64-byte header
of the decompressed kernel image.
We can fix this in user-space kexec-tools, which handles an
'Image.gz' being passed via kexec_file_load(), using an approach
as follows:
a). Copy the contents of Image.gz to a temporary file.
b). Decompress (gunzip-decompress) the contents inside the
temporary file.
c). Pass the 'fd' of the temporary file to the kernel space. So
basically the kernel space still gets a decompressed kernel
image to load via kexec-tools
I tested this patch for the following three use-cases:
1. Uncompressed Image file:
#kexec -s -l Image --initrd=/boot/initramfs-`uname -r`.img --reuse-cmdline
2. Signed Image file:
#kexec -s -l Image.signed --initrd=/boot/initramfs-`uname -r`.img --reuse-cmdline
3. zlib compressed Image.gz file:
#kexec -s -l /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname -r`.img --reuse-cmdline
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch adds 'is_zlib_file()' helper function which can be
used to quickly determine with the passed kernel image is a zlib
compressed kernel image.
This is specifically useful for arm64 zImage (or Image.gz) support,
which is introduced by later patches in this patchset.
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Commit bf06cf2095e1 ("kexec/uImage: probe to identify a corrupted image"),
defined the 'uImage_probe_kernel()' function return values and
correspondingly ;uImage_arm64_probe()' returns the same (0 -> If the
image is valid 'type' image, -1 -> If the image is corrupted and
1 -> If the image is not a uImage).
This causes issues because, in later patches we introduce zImage
support for arm64, and since it is probed after uImage, the return
values from 'uImage_arm64_probe()' needs to be fixed to make sure
that kexec will not return with an invalid error code.
Now, 'uImage_arm64_probe()' returns the following values instead:
0 - valid uImage.
-1 - uImage is corrupted.
1 - image is not a uImage.
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
In kexec/kexec.c, we open() the kernel Image file and pass this file
descriptor to the kexec_file_load() system call, but never call a
corresponding close().
Fix the same via this patch.
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Fixes: 22a2ed55132e ("x86: Support multiboot2 images")
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
xenctrl.h defines struct e820entry as:
if defined(__i386__) || defined(__x86_64__)
...
#define E820_RAM 1
...
struct e820entry {
uint64_t addr;
uint64_t size;
uint32_t type;
} __attribute__((packed));
...
#endif
$ dpkg-query -S /usr/include/xenctrl.h
libxen-dev:amd64: /usr/include/xenctrl.h
$ dpkg-query -W libxen-dev:amd64
libxen-dev:amd64 4.8.5+shim4.10.2+xsa282-1+deb9u11
./include/x86/x86-linux.h defines struct e820entry as:
#ifndef E820_RAM
struct e820entry {
uint64_t addr; /* start of memory segment */
uint64_t size; /* size of memory segment */
uint32_t type; /* type of memory segment */
#define E820_RAM 1
...
} __attribute__((packed));
#endif
Since cedeee0a3007 ("x86: Introduce helpers for getting RSDP address")
./kexec/arch/i386/kexec-x86-common.c includes
+#include "x86-linux-setup.h"
#include "../../kexec-xen.h"
When xenctrl.h is present the above results in:
$ gcc
...
In file included from kexec/arch/i386/../../kexec-xen.h:5:0,
from kexec/arch/i386/kexec-x86-common.c:43:
/usr/include/xenctrl.h:1271:8: error: redefinition of 'struct e820entry'
struct e820entry {
^~~~~~~~~
In file included from kexec/arch/i386/x86-linux-setup.h:3:0,
from kexec/arch/i386/kexec-x86-common.c:42:
./include/x86/x86-linux.h:16:8: note: originally defined here
struct e820entry {
^~~~~~~~~
...
$ gcc --version | head -1
gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
To militate this this problem re-order the includes so that
x86-linux.h is included after xenctrl.h and thus
struct e820entry will only be defined once due to it
being devined conditionally in x86-linux.h.
In practice the definitions are the same so it should
not matter which is chosen.
It also seems rather unpleasent to me to need to play
with include ordering. Perhaps a better solution in the longer
term would be to rename the local definition of struct e820entry.
Fixes: cedeee0a3007 ("x86: Introduce helpers for getting RSDP address")
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add a new type `multiboot2-x86` that allows loading multiboot2 [1] images
within the relocation range specified in the image header. The image is
always placed at the lowest available address, regardless of the
preference information.
[1] https://www.gnu.org/software/grub/manual/multiboot2/multiboot.html
Signed-off-by: Varad Gautam <vrd@amazon.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add a helper to allow loading an image within specified address range.
This will be used to load multiboot2 images later.
Signed-off-by: Varad Gautam <vrd@amazon.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Use the new introduce helper for getting RSDP, this ensures RSDP is
always accessible and avoid code duplication.
Signed-off-by: Kairui Song <kasong@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Since kernel commit e6e094e053af75 ("x86/acpi, x86/boot: Take RSDP address
from boot params if available"), kernel accept an acpi_rsdp_addr param in
boot_params. So fill in this parameter unconditionally, ensure second
kernel always get the right RSDP address consistently, and boot well on
EFI system even with EFI service disabled. User no longer need to change
the kernel cmdline to workaround the missing RSDP issue.
For older version of kernels (Before 5.0), there won't be any change of
behavior.
Signed-off-by: Kairui Song <kasong@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
On x86 RSDP is fundamental for booting the machine. When second kernel
is incapable of parsing the RSDP address (eg. kexec next kernel on an EFI
system with EFI service disabled), kexec should prepare the RSDP address
for second kernel.
Introduce helpers for getting RSDP from multiple sources, including boot
params and EFI firmware.
For legacy BIOS interface, there is no better way to find the RSDP address
rather than scanning the memory region and search for it, and this will
always be done by the kernel as a fallback, so this is no need to try to
get the RSDP address for that case.
Signed-off-by: Kairui Song <kasong@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Since kernel commit e6e094e053af75 ("x86/acpi, x86/boot: Take RSDP address
from boot params if available"), kernel accept a acpi_rsdp_addr param in
boot_params. Sync the x86_linux_param_header to support this param.
Signed-off-by: Kairui Song <kasong@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The name in mount invocations like
mount -t debugfs debugfs /sys/kernel/debug
is nothing but convention and cannot be relied upon.
For example, https://www.kernel.org/doc/Documentation/filesystems/debugfs.txt
recommends making the name "none" instead:
mount -t debugfs none /sys/kernel/debug
and many existing systems use mounts named "none" or otherwise.
Using `mnt_type` instead of `mnt_fsname` allows kexec to work
on such systems.
This fixes another instance of `poweroff` not working on kexec'ed
kernels because the lack of correctly matched mount results in EFI
variables not being read and propagated.
Signed-off-by: Niklas Hambüchen <mail@nh2.me>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
In many situations, especially on read-only file systems
and initial ramdisks (intramfs/initrd), /etc/mtab does not exist.
Before this commit, kexec would fail to read mounts on such systems
in `find_mnt_by_fsname()`, such that `get_bootparam()` would not
`boot_params/data`, which would then lead to e.g. `setup_efi_data()`
not being called in `setup_efi_info()`.
As a result, kexec'ed kernels would not obtain EFI data,
subsequentially lack an `ACPI RSDP` entry, emitting:
ACPI BIOS Error (bug): A valid RSDP was not found (20180810/tbxfroot-210)
and thus fail to turn off the machine on poweroff, instead printing only:
reboot: System halted
This problem had to be worked around by passing `acpi_rsdp=` manually
before. This commit obviates this workaround.
See also:
* https://github.com/coreos/bugs/issues/167#issuecomment-487320879
* http://lists.infradead.org/pipermail/kexec/2012-October/006924.html
Signed-off-by: Niklas Hambüchen <mail@nh2.me>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Unlike Linux which creates a full identity mapping, Xen only maps those
segments which are explicitly requested. Therefore, xen_kexec_load()
silently adds in a segment from zero to 1MiB to ensure that VGA memory
and other things are accessible.
However, this doesn't work when there are already segments to be loaded
under 1MiB, because the overlap causes Xen to reject the kexec_load.
Be more careful and just infill the ranges which are required instead
of naïvely adding a full 0-1MiB segment at the end of the list.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
After commit 060eee58 "x86: use old screen_info if needed", kexec-tools
will force use old screen_info and vga type if failed to determine
current vga type. But it is not always a good idea.
Currently kernel hanging is inspected on some hyper-v VMs after this
commit, because hyperv_fb will mimic EFI (or VESA) VGA on first boot
up, but after the real driver is loaded, it will switch to new mode
and no longer compatible with EFI/VESA VGA. Keep setting
orig_video_isVGA to EFI/VESA VGA flag will get wrong driver loaded and
try to manipulate the framebuffer in a wrong way.
We can't ensure this won't happen on other framebuffer drivers, But
it's a helpful feature if the framebuffer drivers just work. So this
patch introduce a --reuse-video-type options to let user decide if the
old screen_info hould be used unconditional or not.
Signed-off-by: Kairui Song <kasong@redhat.com>
Reviewed-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add .git to version so it doesn't look like a release.
This is just so when people build code from git it can
be identified as such from the version string.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When copying the DTB from the current kernel, if the user didn't pass an
initrd on the command-line, make sure that the new DTB doesn't contain
initrd properties with stale addresses. Otherwise the next kernel will
try to unpack the initramfs from a location that contains junk, since
the initial initrd is long gone:
[ 49.370026] Initramfs unpacking failed: junk in compressed archive
This issue used to be hidden by a successful recovery, but since commit
ff1522bb7d98 ("initramfs: cleanup incomplete rootfs") in Linux, the
kernel removes the default /root mountpoint after failing to load an
initramfs, and cannot mount the rootfs passed on the command-line
anymore.
Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
There has been a lot of workarounds for purgatory disabling many
specified CFLAGS that will break purgatory. It will be better to not
let the CFLAGS used to compile purgatory honor the CFLAGS from
environment variables. So we will have stable CFLAGS for purgatory.
If anyone still wants to change purgatory CFLAGS, PURGATORY_EXTRA_CFLAGS
is still honored.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
In a EFI system, the frame buffer address is 64bit, so currently
if the address is beyound 4G, kexec will set wrong address due to
truncate.
Linux kernel commit ae2ee627dc87 ('efifb: Add support for 64-bit
frame buffer addresses') added support for 64bit frame buffer
address, an 'ext_lfb_base' field is added as the upper 32-bits of
the frame buffer, and introduced a new capability flag
'VIDEO_TYPE_CAPABILITY_64BIT_BASE' to indicate if the extend field is
used.
This patch adopts this change, set proper extent address and capability
flag when the address is beyound 4G.
Signed-off-by: Kairui Song <kasong@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When the kernel requests video information, pass it the
framebuffer information in the multiboot header from
the linux framebuffer ioctl's.
With the arch specific --reset-vga or --consolve-vga
options, purgatory will reset the framebuffer so pass
information for standard ega text mode.
Signed-off-by: Friedemann Gerold <cinap_lenrek@felloff.net>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Use the appropriate types for ACPI reclaim and ACPI NVS
ranges in the multiboot memory map.
This allows the kernel to locate ACPI tables on UEFI
systems without having a explicit pointer to the RSD.
Signed-off-by: Friedemann Gerold <cinap_lenrek@felloff.net>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add support for non-elf multiboot kernels (such as Plan 9)
by handling the MULTIBOOT_AOUT_KLUDGE bit.
When the bit is clear then we are dealing with an ELF file
and probe for ELF as before with elf_x86_probe().
When the bit is set then load_addr, load_end_addr, header_addr
and entry_addr from the multiboot header are used load the
memory image.
Signed-off-by: Friedemann Gerold <cinap_lenrek@felloff.net>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
With this patch, kexec_file_load() system call is supported.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Bhupesh Sharma <bhsharma@redhat.com>
Tested-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
available)
On certain arm64 platforms, it has been noticed that due
to a hole at the start of physical ram exposed to kernel
(i.e. it doesn't start from address 0), the kernel still
calculates the 'memstart_addr' kernel variable as 0.
Whereas the SYSTEM_RAM or IOMEM_RESERVED range in '/proc/iomem'
would carry a first entry whose start address is non-zero
(as the physical ram exposed to the kernel starts from a
non-zero address).
In such cases, if we rely on '/proc/iomem' entries to
calculate the phys_offset, then we will have mismatch
between the user-space and kernel space 'PHYS_OFFSET'
value. The present 'kexec-tools' code does the same
in 'get_memory_ranges_iomem_cb()' function when it makes
a call to 'set_phys_offset()'. This can cause the vmcore
generated via 'kexec-tools' to miss the last few bytes as
the first '/proc/iomem' starts from a non-zero address.
Please see [0] for the original bug-report from Yanjiang Jin.
The same can be fixed in the following manner:
1. For newer kernel (>= 4.19, with commit 23c85094fe1895caefdd
["proc/kcore: add vmcoreinfo note to /proc/kcore"] available),
'kcore' contains a new PT_NOTE which carries the VMCOREINFO
information.
If the same is available, one should prefer the same to
retrieve 'PHYS_OFFSET' value exported by the kernel as this
is now the standard interface exposed by kernel for sharing
machine specific details with the user-land as per
the arm64 kernel maintainers (see [1]) .
2. For older kernels, we can try and determine the PHYS_OFFSET
value from PT_LOAD segments inside 'kcore' via some jugglery
of the correct virtual and physical address combinations.
As a fallback, we still support getting the PHYS_OFFSET values
from '/proc/iomem', to maintain backward compatibility.
Testing:
-------
- Tested on my apm-mustang and qualcomm amberwing board with upstream
kernel (4.20.0-rc7) for both KASLR and non-KASLR boot cases.
References:
-----------
[0] https://www.spinics.net/lists/kexec/msg20618.html
[1] https://www.mail-archive.com/kexec@lists.infradead.org/msg20300.html
Reported-by: Yanjiang Jin <yanjiang.jin@hxt-semitech.com>
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
'vmcore-dmesg.c' already implements functionality to read
'vmcoreinfo' from vmcore file. The same can be used in other
features as well (one of which is reading the elf notes from
'kcore' file), so there is merit in moving this to the utility
libraries (util_lib).
Newer kernel versions (>= 4.19, with commit 23c85094fe1895caefdd
["proc/kcore: add vmcoreinfo note to /proc/kcore"], available),
have 'kcore' which now contains a new PT_NOTE which carries
the VMCOREINFO information.
If the same is available, we can benefit by using it in 'kexec-tools'.
This is especially useful for architectures like arm64 as we can
get kernel symbols like 'PHYS_OFFSET' from the '/proc/kcore' itself
and use it to calculate 'phys_offset' before we make a call to
'set_phys_offset()'.
For older kernels, we can try and determine the PHYS_OFFSET
value from PT_LOAD segments inside 'kcore' via some jugglery
of the correct virtual and physical address combinations.
Subsequent patch(es) in this series will use the same feature
to read the 'kcore' file.
This patch also makes some of the functions which were earlier
present in 'vmcore-dmesg.c' as non-static, so as to allow
future patches to use them as library functions.
Also we add the capability to read 'NUMBER(PHYS_OFFSET)' from
vmcoreinfo to the already present 'scan_vmcoreinfo()' code.
Future patches can look at reading more vmcoreinfo information
(for e.g. 'kaslr_offset()' for x86_64 and arm64) by using the
same framework.
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
functions
This patch fixes the incorrect 'chosen' node name being passed to
various fdt helper functions inside 'kexec/dt-ops.c'
As we can see from the Linux kernel usage inside
'drivers/firmware/efi/libstub/fdt.c', we pass '/chosen' node names to
fdt helper function like 'fdt_path_offset()' whereas 'chosen' to the
rest of the fdt helper functions like 'fdt_subnode_offset()'.
We need to replicate the same in 'kexec-tools' to fix issues being
reported when we use --dtb option while invoking 'kexec'.
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
available in dtb passed via --dtb option
While calling 'kexec -l', in case we are passed a .dtb using --dtb
option which doesn't contain a '/chosen' node, we try to create the
'/chosen' node and add bootargs to this node.
Currently the 'dt-ops.c' code is buggy as it passes '-FDT_ERR_NOTFOUND'
to 'fdt_add_subnode()', which leads to the following error:
# kexec -d --load Image --append 'debug' --dtb rk3399-sapphire.dtb
<..snip..>
dtb_set_property: fdt_add_subnode failed: FDT_ERR_NOTFOUND
kexec: Set device tree bootargs failed.
get_cells_size: #address-cells:2 #size-cells:2
cells_size_fitted: 0-0
cells_size_fitted: 0-0
setup_2nd_dtb: no kaslr-seed found
This patch passes the correct nodeoffset value to 'fdt_add_subnode()',
which fixes this issue:
# kexec -d -l Image --append 'debug' --dtb rk3399-sapphire.dtb
<..snip..>
get_cells_size: #address-cells:2 #size-cells:2
cells_size_fitted: 0-0
cells_size_fitted: 0-0
setup_2nd_dtb: no kaslr-seed found
Reported-by: Vicente Bergas <vicencb@gmail.com>
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
'set_bootargs()'
This patch adds missing error handling check against the return value of
'set_bootargs()' in 'kexec-arm64.c'
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Vicenç reported (via [1]) that currently executing kexec with
'--dtb' option and passing a .dtb which doesn't have a '/chosen' node
leads to the following error:
# kexec -d --dtb dtb_without_chosen_node.dtb --append 'cmdline' --load Image
dtb_set_property: fdt_add_subnode failed: <valid offset/length>
kexec: Set device tree bootargs failed.
This happens because currently we check the return value of
'fdt_add_subnode()' function call in 'dt-ops.c' incorrectly:
result = fdt_add_subnode(new_dtb, nodeoffset, node);
if (result) {
dbgprintf("%s: fdt_add_subnode failed: %s\n", _func__,
fdt_strerror(result));
goto on_error;
}
As we can see in 'fdt_rw.c', a positive return value from
'fdt_add_subnode()' function doesn't indicate an error.
We can see that the Linux kernel (see 'drivers/firmware/efi/libstub/fdt.c'
for example) also checks the 'fdt_add_subnode()' function against negative
return values for errors. See an example below from 'update_fdt()' function in
'drivers/firmware/efi/libstub/fdt.c':
node = fdt_add_subnode(fdt, 0, "chosen");
if (node < 0) {
status = node;
<..snip..>
goto fdt_set_fail;
}
This patch fixes the same in 'kexec-tools'.
[1]. http://lists.infradead.org/pipermail/kexec/2018-October/021746.html
Cc: Simon Horman <horms@verge.net.au>
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reported-by: Vicente Bergas <vicencb@gmail.com>
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add .git to version so it doesn't look like a release.
This is just so when people build code from git it can
be identified as such from the version string.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
For calculating the random 'kaslr-seed' value to be passed to the
secondary kernel (kexec or kdump), we invoke the 'getrandom' syscall
inside 'setup_2nd_dtb()' function.
Normally on most arm64 systems this syscall doesn't fail when the
initrd scriptware (which arms kdump service) invokes the same.
However, recently I noticed that on the 'hp-moonshot' arm64 boards,
we have an issue with the newer kernels which causes the same
to fail. As a result, the kdump service fails and we are not able
to use the kdump infrastructure just after boot. As expected, once the
random pool is sufficiently populated and we launch the kdump service
arming scripts again (manually), then the kdump service is properly
enabled.
Lets handle the same, by not error'ing out if 'getrandom' syscall fails.
Rather lets warn the user and proceed further by setting the
'kaslr-seed' value as 0 for the secondary kernel - which implies that it
boots in a 'nokaslr' mode.
Tested on my 'hp-moonshot' and 'qualcomm-amberwing' arm64 boards.
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
If the err_out label is reached, address of a stack variable is passed to
free(). Fix it.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When kexec-tools load the kernel and initramfs for kdump, kexec-tools will
read /proc/iomem and recreate the e820 ranges for kdump kernel. But it fails
to parse the e820 reserved region, because the memcmp() is case sensitive
when comparing the string. In fact, it may be "Reserved" or "reserved" in
the /proc/iomem, so we have to fix these cases.
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
Reviewed-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
In response to a change in binutils, commit b21ebf2fb4c
(x86: Treat R_X86_64_PLT32 as R_X86_64_PC32) was applied to
the linux kernel during the 4.16 development cycle and has
since been backported to earlier stable kernel series. The
change results in the failure message in $SUBJECT when
rebooting via kexec.
Fix this by replicating the change in kexec.
Signed-off-by: Chris Clayton <chris2553@googlemail.com>
Acked-by: Baoquan He <bhe@redhat.com>
Tested-by: Bhupesh Sharma <bhsharma@redhat.com>
Acked-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Currently, in arm64, kexec silently truncates kernel command line longer
than COMMAND_LINE_SIZE - 1. Error out in that case as some other
architectures already do that. The error message is copied from x86_64.
Suggested-by: Tom Kirchner <tjk@amazon.com>
Signed-off-by: Munehisa Kamata <kamatam@amazon.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Otherwise, we can hit the current 512 chars limit before hitting the
Linux kernel's one, where allows 2048 chars in arm64.
Signed-off-by: Munehisa Kamata <kamatam@amazon.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch adds the support to supply 'kaslr-seed' to secondary kernel,
when we do a 'kexec warm reboot to another kernel' (although the
behaviour remains the same for the 'kdump' case as well) on arm64
platforms using the 'kexec_load' invocation method.
Lets consider the case where the primary kernel working on the arm64
platform supports kaslr (i.e 'CONFIG_RANDOMIZE_BASE' was set to y and
we have a compliant EFI firmware which supports EFI_RNG_PROTOCOL and
hence can pass a non-zero (valid) seed to the primary kernel).
Now the primary kernel reads the 'kaslr-seed' and wipes it to 0 and
uses the seed value to randomize for e.g. the module base address
offset.
In the case of 'kexec_load' (or even kdump for brevity),
we rely on the user-space kexec-tools to pass an appropriate dtb to the
secondary kernel and since 'kaslr-seed' is wiped to 0 by the primary
kernel, the secondary will essentially work with *nokaslr* as
'kaslr-seed' is set to 0 when it is passed to the secondary kernel.
This can be true even in case the secondary kernel had
'CONFIG_RANDOMIZE_BASE' and 'CONFIG_RANDOMIZE_MODULE_REGION_FULL' set to
y.
This patch addresses this issue by first checking if the device tree
provided by the firmware to the kernel supports the 'kaslr-seed'
property and verifies that it is really wiped to 0. If this condition is
met, it fixes up the 'kaslr-seed' property by using the getrandom()
syscall to get a suitable random number.
I verified this patch on my Qualcomm arm64 board and here are some test
results:
1. Ensure that the primary kernel is boot'ed with 'kaslr-seed'
dts property and it is really wiped to 0:
[root@qualcomm-amberwing]# dtc -I dtb -O dts /sys/firmware/fdt | grep -A 10 -i chosen
chosen {
kaslr-seed = <0x0 0x0>;
...
}
2. Now issue 'kexec_load' to load the secondary kernel (let's assume
that we are using the same kernel as the secondary kernel):
# kexec -l /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
-r`.img --reuse-cmdline -d
3. Issue 'kexec -e' to warm boot to the secondary:
# kexec -e
4. Now after the secondary boots, confirm that the load address of the
modules is randomized in every successive boot:
[root@qualcomm-amberwing]# cat /proc/modules
sunrpc 524288 1 - Live 0xffff0307db190000
vfat 262144 1 - Live 0xffff0307db110000
fat 262144 1 vfat, Live 0xffff0307db090000
crc32_ce 262144 0 - Live 0xffff0307d8c70000
...
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The kdump tool presently allows one to generate an ELF file containing
the ELF header, PT_NOTE and PT_LOAD segments (which can be analyzed
later by tools like 'readelf') of the crashdump read from memory, when
passed with an appropriate 'elfcorehdr' value(which represents the
physical address of the start of the ELF header).
With the availability of tools like crash/gdb the analysis of the
crashdump core has become rather easy, and it makes the kdump tool
obsolete. Also the same naming convention (man page) causes confusion
when compared to similarly named distribution specific kdump
service/utilities.
Also most distributions (like Fedora for e.g.) now support more
enhanced kdump service and utilities which can be used to analyze the
crashdump core contents better. Taking an example of the Fedora
specific kdump service and utilities, the following sequence of steps
happen when the primary kernel crashes:
1. If the crashkernel is loaded, then the system starts executing the
same.
2. When the boot process gets to the point when kdump service is
started, the crashdump core is usually copied out to disk (for e.g.
inside '/var/crash') using 'cp' command from '/proc/vmcore':
# cp /proc/vmcore <dump-file>
3. Thereafter the system is rebooted back into the normal kernel.
4. Once back to your normal kernel, one can use the crashdump core
available on hard disk in conjunction with the previously installed
kernel (with debuginfo) to perform postmortem analysis with tools like
gdb/crash:
# gdb vmlinux <dump-file>
Accordingly, this patch removes the obsolete kdump tool from
'kexec-tools'.
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Reviewed-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Presently the Makedumpfile.in doesn't include a uninstall rule, which is
useful in case we want to preform a reverse of the install process
done by Makefile.in
This patch adds this rule, thus making it easier to remove installed
executables and man pages in case one needs to uninstall the same.
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
We hit a bug where vmcore-dmesg would get stuck in a loop, and since we
were redirecting the output to a file, it wouldn't stop until it filled
up the disk. This only happened when the dmesg buffer had filled up and
wrapped around. It turns out that when we hit the end of the buffer, we
are looping back to the first record instead of the beginning of the
buffer, which will always loop forever.
Fixes: e08d26b3b7f1 ("vmcore-dmesg: avoid allocating large memory chunk for log buf")
Signed-off-by: Omar Sandoval <osandov@fb.com>
Acked-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Since kernel 4.17-rc2 s390 supports the kexec_file_load system call. Add
the new system call to kexec-tools and provide the -s (--kexec-file-syscall)
option for s390 to support this new feature.
Signed-off-by: Philipp Rudo <prudo@linux.ibm.com>
Acked-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add a new option --no-checks to kexec that allows for a fast
reboot by avoiding the purgatory integrity checks. This option is
intended for use by kexec based bootloaders that load a new
image and then immediately transfer control to it.
Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Fixes warnings like these when building kexec for powerpc (32 bit):
console-ppc64.c: warning: ‘*((void *)&buff+8)’ may be used uninitialized
Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Fixes warnings like these when building kexec for powerpc (32 bit):
kexec-elf-rel-ppc64.c: warning: cast from pointer to integer of different size
Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Fixes warnings like these when building kexec for powerpc (32 bit):
crashdump-ppc64.h: warning: large integer implicitly truncated to unsigned type
Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Fixes warnings like these when building kexec for powerpc (32 bit):
kexec.c: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘uint64_t
Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add .git to version so it doesn't look like a release.
This is just so when people build code from git it can
be identified as such from the version string.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
As seen in GCC's gcc/config/aarch64/aarch64.c, -fPIC with large
code model is unsupported. This fixes the "sorry, unimplemented"
errors when building with compilers defaulting to -fPIC.
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: David Michael <david.michael@coreos.com>
|
|
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Do not fall through to "--mem-min" when "-p" option is parsed. The
break statement was apparently removed by mistake...
Fixes: cb434cbe6f40 ("kexec: Do not special-case the -s option")
Signed-off-by: Petr Tesarik <ptesarik@suse.com>
Tested-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Normally vmlinux for arm64 is of ET_EXEC type, while if built with
CONFIG_RANDAMIZE_BASE (that is KASLR), it will be of ET_DYN type.
Meanwhile, physical address field of segments in vmlinux has actually
the same value as virtual address field.
Accordingly, in this case, it totally makes no sense to check for
validity of segments against physical memory ranges and, if necessary,
relocate them in elf_exec_load() on arm64.
This patch allows to unconditionally skip the check on arm64.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
supported
Not all architectures implement KEXEC_FILE_LOAD. However, on some
archiectures KEXEC_FILE_LOAD is required when secure boot is enabled in
locked-down mode. Previously users had to select the KEXEC_FILE_LOAD
syscall with undocumented -s option. However, if they did pass the
option kexec would fail on architectures that do not support it.
So add an -a option that tries KEXEC_FILE_LOAD and when it is not
supported tries KEXEC_LOAD.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The undocumented -s option selects KEXEC_FILE_LOAD syscall but there is
no option to select KEXEC_LOAD syscall. Add it so -s can be reverted.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
It is parsed separately to save a few CPU cycles when setting up other
options but it just complicates the code. So fold it back and set up all
flags for both KEXEC_LOAD and KEXEC_FILE_LOAD
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When kexec_file_load support was added some sanity checks were not updated.
Some options are set only in the kexec_load flags so cannot be supported
wiht kexec_file_load. On the other hand, reserved memory is needed for
kdump with both kexec_load and kexec_file_load.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When the kernel does not know a syscall number it returns -ENOSYS but
when kexec does not know a syscall number it returns -1. Return -ENOSYS
from kexec as well.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
PPC64 kernel now supports kexec_file_load system call. Leverage it by
enabling that support here. Note that loading crash kernel with this
system call is not yet supported in the kernel and trying to load one
will fail with '-ENOTSUPP' error.
Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
Reviewed-by: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Include the stack and malloc space in our calculation of the zImage
size, both of which must be avoided when locating the dtb.
Signed-off-by: Russell King <rmk@armlinux.org.uk>
|
|
Add further debugging of the kernel size
Signed-off-by: Russell King <rmk@armlinux.org.uk>
|
|
Signed-off-by: Russell King <rmk@armlinux.org.uk>
|
|
Add support to parse the new 'ibm,dynamic-memory-v2' property in the
'ibm,dynamic-reconfiguration-memory' node. This replaces the old
'ibm,dynamic-memory' property and is enabled in the kernel with a
patch series that starts with commit 0c38ed6f6f0b ("powerpc/pseries:
Enable support of ibm,dynamic-memory-v2"). All LMBs that share the same
flags and are adjacent are grouped together in the newer version of the
property making it compact to represent larger memory configurations.
Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
Mahesh Jagannath Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add a helper function for adding ranges to avoid duplicating code.
Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
Reviewed-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
With modern drm/kms graphic driver kexec-tools does not setup screen_info
correctly so one will only see screen output after those drm drivers
reinitializing after rebooting. Copying the old screen info from original
boot_params will help during my test, although it could not work for some
potential cases, but it is not worse than before. This has been used in
the kernel kexec_file_load.
Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch is a follow-on to commit 894bea93 "kexec-tools: Perform
run-time linking of libxenctrl.so". This patch addresses feedback
from Daniel Kiper.
This patch implements Daniel's suggestion to make the
xc_dlhandle variable static, insert missing 'extern'
qualifier for the new __xc() wrappers, and correct some
style issues.
Signed-off-by: Eric DeVolder <eric.devolder@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
