- May 02, 2021
-
-
Petr Tesarik authored
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>
-
Simon Horman authored
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 authored
Signed-off-by:
-
- Apr 26, 2021
-
-
Simon Horman authored
Signed-off-by:
-
- Apr 17, 2021
-
-
Alexander Egorenkov authored
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:
-
Eric W. Biederman authored
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:
-
- Apr 08, 2021
-
-
Hongyan Xia authored
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:
-
Hongyan Xia authored
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:
-
- Apr 02, 2021
-
-
Simon Horman authored
Initial github workflow which builds kexec on a range of architectures. Signed-off-by: -
Simon Horman authored
Add distcheck target which aims to exercise build, install and uninstall using distribution tarball. Signed-off-by: -
Simon Horman authored
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 authored
For symmetry with the install target, also use DESTDIR in the uninstall target. Signed-off-by: -
Simon Horman authored
kexec_test is installed but not uninstalled. Correct this oversight. Signed-off-by: -
Simon Horman authored
This provides a familiar alias for the existing tarball target. The result is a tar.gz file. Signed-off-by: -
Simon Horman authored
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: -
David Hildenbrand authored
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:
-
David Hildenbrand authored
No need to iterate over empty entries. Cc: Simon Horman <horms@verge.net.au> Signed-off-by:
-
David Hildenbrand authored
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:Dave Hansen <dave.hansen@linux.intel.com> Signed-off-by:
-
Raphael Ning authored
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:
-
Raphael Ning authored
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 authored
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:
-
Geert Uytterhoeven authored
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: 4149df90 ("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:
-
Geert Uytterhoeven authored
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... -
Geert Uytterhoeven authored
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); | ~~^ ~~~~~~~~ | ... -
Youling Tang authored
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: 0eac6405 ("kexec: mips: Fix mem parameters") Signed-off-by:
Youling Tang <tangyouling@loongson.cn> Signed-off-by:
-
Federico Pellegrin authored
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:
-
Youling Tang authored
Fix typo in comment. Signed-off-by:
-
Youling Tang authored
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:
-
- Dec 17, 2020
-
-
Simon Horman authored
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 authored
Signed-off-by:
-
- Dec 09, 2020
-
-
Simon Horman authored
Signed-off-by: -
Jinyang He authored
"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: 7bd25165 ("kexec-tools: mips: Remove commandline parameter "mem"") Signed-off-by:
Jinyang He <hejinyang@loongson.cn> Signed-off-by:
-
qiuguorui1 authored
In function dtb_set_property, when malloc new_node fails, we need to free new_dtb before return. Fixes: f56cbcf4 ("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:
-
- Dec 01, 2020
-
-
qiuguorui1 authored
In function zlib_decompress_file, when gzdirect(fp) fails, we should gzclose fp before return. Fixes: d606837b ("Fix zlib/lzma decompression.") Signed-off-by:
-
John Ogness authored
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:
-
- Nov 16, 2020
-
-
Ahelenia Ziemiańska authored
Signed-off-by:
Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Signed-off-by:
-
Ahelenia Ziemiańska authored
fixed the same way as in 70cca822 "kexec: Fix snprintf related compilation warnings" Signed-off-by:
-
Ahelenia Ziemiańska authored
Signed-off-by:
-
Ahelenia Ziemiańska authored
Signed-off-by:
-
Ahelenia Ziemiańska authored
Signed-off-by:
-
