summaryrefslogtreecommitdiff
path: root/kexec/kexec.c
Commit message (Collapse)AuthorAgeFilesLines
* kexec: make -a the defaultAhelenia Ziemiańska2023-02-071-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | AFAICT, there's no downside to this, and running into this each time I want to kexec (and, presumably, a significant chunk of the population, since lockdown is quite popular) on some machines, then going to the manual, then finding out I want the /auto/ flag(!) is quite annoying: # kexec -l /boot/vmlinuz-6.1.0-3-amd64 --initrd /boot/initrd.img-6.1.0-3-amd64 --reuse-cmdline kexec_load failed: Operation not permitted entry = 0x46eff7760 flags = 0x3e0000 nr_segments = 7 segment[0].buf = 0x557cd303efa0 segment[0].bufsz = 0x70 segment[0].mem = 0x100000 segment[0].memsz = 0x1000 segment[1].buf = 0x557cd3046fe0 segment[1].bufsz = 0x190 segment[1].mem = 0x101000 segment[1].memsz = 0x1000 segment[2].buf = 0x557cd303f6e0 segment[2].bufsz = 0x30 segment[2].mem = 0x102000 segment[2].memsz = 0x1000 segment[3].buf = 0x7f658fa37010 segment[3].bufsz = 0x12a51b5 segment[3].mem = 0x46a55a000 segment[3].memsz = 0x12a6000 segment[4].buf = 0x7f6590ce1210 segment[4].bufsz = 0x7e99e0 segment[4].mem = 0x46b800000 segment[4].memsz = 0x377c000 segment[5].buf = 0x557cd3039350 segment[5].bufsz = 0x42fa segment[5].mem = 0x46eff2000 segment[5].memsz = 0x5000 segment[6].buf = 0x557cd3032000 segment[6].bufsz = 0x70e0 segment[6].mem = 0x46eff7000 segment[6].memsz = 0x9000 Closes: https://bugs.debian.org/1030248 Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Signed-off-by: Simon Horman <horms@kernel.org>
* LoongArch: Remove redundant cmdline parameters when using --reuse-cmdline optionYouling Tang2022-10-101-1/+1
| | | | | | | | | | | In LoongArch, when using the --reuse-cmdline option to reuse the current command line, it may lead to redundancy (like kexec, initrd command line arguments). In order to avoid the possible impact of initrd removal on other architectures, remove_parameter will be called in a specific architecture for processing. Signed-off-by: Youling Tang <tangyouling@loongson.cn> Signed-off-by: Simon Horman <horms@kernel.org>
* kexec-xen: Allow xen_kexec_exec() to return in case of Live UpdateRaphael Ning2022-03-231-4/+19
| | | | | | | | | | | | | | | | | 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>
* kexec-tools: print error if kexec_file_load failsHari Bathini2022-03-231-0/+1
| | | | | | | | | | | | | | | | | 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 slurp_proc_file() in get_command_line()Sven Schnelle2022-01-141-16/+10
| | | | | | | | 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>
* add slurp_proc_file()Sven Schnelle2022-01-141-0/+51
| | | | | | | | | | 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: Make --status work with normal kexec imagesRaphael Ning2021-04-021-1/+3
| | | | | | | | | | | | | | | | 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>
* kexec: Fix description of --status exit codeRaphael Ning2021-04-021-1/+2
| | | | | | | | | 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>
* kexec: Use %llu/%llx and casts to format uint64_tGeert Uytterhoeven2021-04-021-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* kexec-tools: Fix a prompt message when crashkernel is not reservedYouling Tang2020-09-291-1/+1
| | | | | | | | | | 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>
* kexec/kexec.c: Add missing close() callYouling Tang2020-09-021-0/+3
| | | | | | | | 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>
* kexec-tools: fix the unintended fallthrough when '-d' option is usedHari Bathini2020-06-061-0/+1
| | | | | | | 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>
* kexec-xen: Introduce --exec-live-update to trigger a live updateVarad Gautam2020-04-071-1/+10
| | | | | | | 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>
* kexec: Introduce --load-live-update for xenVarad Gautam2020-04-071-1/+30
| | | | | | | | | | | | | 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>
* kexec-tools: Reset getopt before falling back to legacy syscallPetr Tesarik2020-04-011-2/+10
| | | | | | | | | | | | 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>
* kexec-tools: Fix kexec_file_load(2) error handlingPetr Tesarik2020-04-011-54/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* kexec/arm64: Add support for handling zlib compressed (Image.gz) imageBhupesh Sharma2019-07-161-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* kexec/kexec.c: Add the missing close() for fd used for kexec_file_load()Bhupesh Sharma2019-07-161-0/+2
| | | | | | | | | | | 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>
* kexec: Add --no-checks optionGeoff Levand2018-04-191-2/+17
| | | | | | | | | | 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>
* kexec: Fix printf warningGeoff Levand2018-04-191-1/+2
| | | | | | | | | 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>
* Fix a segmentation fault when trying to run "kexec -p"Petr Tesarik2018-04-101-0/+1
| | | | | | | | | | 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>
* kexec: Add option to fall back to KEXEC_LOAD when KEXEC_FILE_LOAD is not ↵Michal Suchanek2018-03-301-5/+60
| | | | | | | | | | | | | | | | 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>
* kexec: Add option to revert -sMichal Suchanek2018-03-301-0/+5
| | | | | | | | 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>
* kexec: Do not special-case the -s optionMichal Suchanek2018-03-301-21/+4
| | | | | | | | | 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>
* kexec: Fix option checks to take KEXEC_FILE_LOAD into accountMichal Suchanek2018-03-301-1/+9
| | | | | | | | | | | 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>
* kexec: Return -ENOSYS when kexec does not know how to call KEXEC_FILE_LOADMichal Suchanek2018-03-301-1/+1
| | | | | | | | | 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>
* kexec: Add option to get crash kernel region sizeDaniel Kiper2017-03-021-0/+16
| | | | | | | | | | | | | | | | | | | | | | Crash kernel region size is available via sysfs on Linux running on bare metal. However, this does not work when Linux runs as Xen dom0. In this case Xen crash kernel region size should be established using __HYPERVISOR_kexec_op hypercall (Linux kernel kexec functionality does not make a lot of sense in Xen dom0). Sadly hypercalls are not easily accessible using shell scripts or something like that. Potentially we can check "xl dmesg" output for crashkernel option but this is not nice. So, let's add this functionality, for Linux running on bare metal and as Xen dom0, to kexec-tools. This way kdump scripts may establish crash kernel region size in one way regardless of platform. All burden of platform detection lies on kexec-tools. Figure (and unit) displayed by this new kexec-tools functionality is the same as one taken from /sys/kernel/kexec_crash_size. Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com> 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>
* kexec: Remove redundant space from help messageDaniel Kiper2017-01-311-1/+1
| | | | | | Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com> Signed-off-by: Eric DeVolder <eric.devolder@oracle.com> Signed-off-by: Simon Horman <horms@verge.net.au>
* kexec: implemented XEN KEXEC STATUS to determine if an image is loadedEric DeVolder2017-01-261-33/+79
| | | | | | | | | | | | | | | | | | | | | Instead of the scripts having to poke at various fields we can provide that functionality via the -S parameter. kexec_loaded/kexec_crash_loaded exposes Linux kernel kexec/crash state. It does not say anything about Xen kexec/crash state. So, we need a special approach to get the latter. Though for compatibility we provide similar functionality in kexec-tools for the former. This change enables the --status or -S option to work either with or without Xen. Returns 0 if the payload is loaded. Can be used in combination with -l or -p to get the state of the proper kexec image. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Eric DeVolder <eric.devolder@oracle.com> Signed-off-by: Simon Horman <horms@verge.net.au>
* kexec: fix warnings caused by selecting 64-bit file IO on 32-bit platformsRussell King2016-06-081-2/+2
| | | | | | | | | | | | | Fix warnings caused by selecting 64-bit file IO on 32-bit platforms. kexec/kexec.c:710:2: warning: format '%lx' expects argument of type 'long unsigned int', but argument 4 has type 'off_t' [-Wformat] kexec/zlib.c:63:4: warning: format '%ld' expects argument of type 'long int', but argument 4 has type 'off_t' [-Wformat] kexec/kexec-uImage.c:85:3: warning: format '%ld' expects argument of type 'long int', but argument 2 has type 'off_t' [-Wformat] Acked-by: Baoquan He <bhe@redhat.com> Signed-off-by: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Simon Horman <horms@verge.net.au>
* Revert "crashdump/x86: Add option to get crash kernel region size"Simon Horman2015-12-011-4/+0
| | | | This reverts commit 8a1aa35a1077b42bc2a2afb05d24b637e1edf2a1.
* crashdump/x86: Add option to get crash kernel region sizeDaniel Kiper2015-11-301-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | Crash kernel region size is available via sysfs on Linux running on bare metal. However, this does not work when Linux runs as Xen dom0. In this case Xen crash kernel region size should be established using __HYPERVISOR_kexec_op hypercall (Linux kernel kexec functionality does not make a lot of sense in Xen dom0). Sadly hypercalls are not easily accessible using shell scripts or something like that. Potentially we can check "xl dmesg" output for crashkernel option but this is not nice. So, let's add this functionality, for Linux running on bare metal and as Xen dom0, to kexec-tools. This way kdump scripts may establish crash kernel region size in one way regardless of platform. All burden of platform detection lies on kexec-tools. Figure (and unit) displayed by this new kexec-tools functionality is the same as one taken from /sys/kernel/kexec_crash_size. This functionality is available on x86 platform only. If idea is acceptable then I can prepare patches for other platforms (if it is possible and make sense) and repost them as fully flagged patch series. Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com> Signed-off-by: Simon Horman <horms@verge.net.au>
* kexec: fix mmap return code handlingMichael Holzheu2015-11-271-1/+1
| | | | | | | | | When mmap fails, MAP_FAILED (that is, (void *) -1) is returned. Currently we assume that NULL is returned. Fix this and add the MAP_FAILED check. Fixes: 95741713e790 ("kexec/s390x: use mmap instead of read for slurp_file") Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
* kexec: determine size of block deviceAndreas Fenkart2015-11-111-0/+8
| | | | | | | | starting 'kexec -l /dev/mmcblk0p1' fails since the size of a block device can not be determined with stat Signed-off-by: Andreas Fenkart <andreas.fenkart@dev.digitalstrom.org> Signed-off-by: Simon Horman <horms@verge.net.au>
* kexec/s390x: use mmap instead of read for slurp_file()Michael Holzheu2015-11-091-3/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The slurp_fd() function allocates memory and uses the read() system call. This results in double memory consumption for image and initrd: 1) Memory allocated in user space by the kexec tool 2) Memory allocated in kernel by the kexec() system call The following illustrates the use case that we have on s390x: 1) Boot a 4 GB Linux system 2) Copy kernel and 1,5 GB ramdisk from external source into tmpfs (ram) 3) Use kexec to boot kernel with ramdisk Therefore for kexec runtime we need: 1,5 GB (tmpfs) + 1,5 GB (kexec malloc) + 1,5 GB (kernel memory) = 4,5 GB This patch introduces slurp_file_mmap() which for "normal" files uses mmap() instead of malloc()/read(). This reduces the runtime memory consumption of the kexec tool as follows: 1,5 GB (tmpfs) + 1,5 GB (kernel memory) = 3 GB Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com> Reviewed-by: Dave Young <dyoung@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
* Revert "kexec: use mmap instead of read for slurp_file()"Dave Young2015-10-261-5/+3
| | | | | | | | | | This reverts commit 7ab842d8a004f6cd75a9d7b3528e4a70819ce4ef. using mmap by default in slurp_file cause segment fault while later reallocing dtb_buf during my arm kexec test. Signed-off-by: Dave Young <dyoung@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
* kexec: use mmap instead of read for slurp_file()Michael Holzheu2015-09-071-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | The slurp_fd() function allocates memory and uses the read() system call. This results in double memory consumption for image and initrd: 1) Memory allocated in user space by the kexec tool 2) Memory allocated in kernel by the kexec() system call Therefore use mmap() for non-character devices to reduce the runtime memory consumption of the kexec tool. The following use case illustrates the usefulness of this patch a bit more: 1) Boot a 4 GB Linux system 2) Read kernel and 1,5 GB ramdisk from external source into local tmpfs (ram) 3) kexec the kernel and ramdisk Without this patch for the kexec runtime we need: 1,5 GB (tmpfs) + 1,5 GB (kexec malloc) + 1,5 GB (kernel memory) = 4,5 GB Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
* Drop release date from kexec-tools version outputDave Young2015-09-021-1/+1
| | | | | | | | | | | | | | | | | kexec --version reports like below: kexec-tools 2.0.7 released 05 February 2015 The date string is generated when one run bootstrap script, thus it is more like a build date instead of release date. Even for distribution like Fedora it will make more sense if it can report something like "kexec-tools 2.0.7-1 released 05 February 2015" In case building from git tree, the date cause more confusion. So let's remove it from version string unless there is better idea to resolve the issue. Signed-off-by: Dave Young <dyoung@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
* kexec: remove ordering constraints from -x (--no-ifdown) and -y (--no-sync)Tejun Heo2015-04-151-8/+9
| | | | | | | | | | | | | | Currently, the two options must be the last ones to be honored; otherwise, they can get silently ignored and both the manpage and help text point it out. This is error-prone and trivial to fix. There isn't much point in pointing something out in documentation when the peculiarity can be removed with four lines of extra code. Update option handling so that the two arguments are honored regardless of their positions. Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Simon Horman <horms@verge.net.au>
* kexec: implement -y (--no-sync) optionTejun Heo2015-04-151-1/+7
| | | | | | | | | | | | | | | During kernel develoment, kexec can be used to get out of sticky situations without going through possibly lenghty reboot; however, there are situations where the filesystem and/or storage stack are known to be misbehaving and performing sync before kexecing is dangerous or just never finishes. This patch implement -y (--no-sync) option which makes kexec skip syncing in the similar way as -x (--no-ifdown). Signed-off-by: Tejun Heo <tj@kernel.org> Suggested-by: Chris Mason <clm@fb.com> Signed-off-by: Simon Horman <horms@verge.net.au>
* Revert "kexec, remove panic_on_warn kernel parameter from kdump situations"Simon Horman2015-01-051-3/+1
| | | | This reverts commit 930f0c3734c223433e74037601cbfd1bc9df7bad.
* kexec, remove panic_on_warn kernel parameter from kdump situationsPrarit Bhargava2015-01-011-1/+3
| | | | | | | | | | | | | | | | panic_on_warn kernel parameter will cause the kernel to panic when a WARN() is hit in the kernel. This is not a good situation for the kdump kernel because then it would be possible for the kdump kernel to panic in a non-fatal WARN(). This patch removes panic_on_warn as a kernel parameter for the kdump kernel. Signed-off-by: Prarit Bhargava <prarit@redhat.com> Cc: Dave Young <dyoung@redhat.com> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: WANG Chao <chaowang@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
* kexec: remove some re zero-assignmentHuKeping2014-12-021-4/+0
| | | | | | | | since we have already cleared kexec_info with memset, there is no need to do that again to the struct members. Signed-off-by: Hu Keping <hukeping@huawei.com> Signed-off-by: Simon Horman <horms@verge.net.au>
* Return error code in case of invalid command line optionVivek Goyal2014-09-041-0/+2
| | | | | | | | | | | | Currently kexec returns success even if an invalid command line option is encountered. Kexec currently prints usage message and then returns 0. That's not right. It is an error and error code 1 should be returned. Due to this wrapper script thinks that kdump succeeded but that's not the case. Signed-off-by: Vivek Goyal <vgoyal@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
* kexec: Provide an option to use new kexec system callVivek Goyal2014-08-271-3/+129
| | | | | | | | | | | | | | | | | | | | | | | | | | | Hi, This is v2 of the patch. Since v1, I moved syscall implemented check littler earlier in the function as per the feedback. Now a new kexec syscall (kexec_file_load()) has been merged in upstream kernel. This system call takes file descriptors of kernel and initramfs as input (as opposed to list of segments to be loaded). This new system call allows for signature verification of the kernel being loaded. One use of signature verification of kernel is secureboot systems where we want to allow kexec into a kernel only if it is validly signed by a key system trusts. This patch provides and option --kexec-file-syscall (-s), to force use of new system call for kexec. Default is to continue to use old syscall. Currently only bzImage64 on x86_64 can be loaded using this system call. As kernel adds support for more arches and for more image types, kexec-tools can be modified accordingly. Signed-off-by: Vivek Goyal <vgoyal@redhat.com> Acked-by: Baoquan He <bhe@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
* cleanup: add dbgprint_mem_range functionWANG Chao2014-03-201-0/+10
| | | | | | | | | dbgprint_mem_range is used for printing the given memory range under debugging mode. Signed-off-by: WANG Chao <chaowang@redhat.com> Tested-by: Linn Crosetto <linn@hp.com> Signed-off-by: Simon Horman <horms@verge.net.au>
* Fix an off-by-one in locate_hole()Matthew Fleming2014-03-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Fix an off-by-one in locate_hole() that can cause it to return a range that was previously allocated. In upgrading to kexec-tools 2.0.5 I first got the error "Overlapping memory segments at 0xbeff000" Adding some debugging I found locate_hole was returning incorrect values. The below is from the debug I added: XXXMDF: look for hole size 100000, cur range [52b3000, bffffff] size 6d4cfff XXXMDF: look for hole memsz=100000, found beff000 Hmm, if we wanted 0x100000 bytes ending at 0xbffffff, that should be 0xbf00000, not 0xbef000. Continuing to the second invocation: XXXMDF: look for hole size 1000, cur range [52b3000, befefff] size 6c4bfff XXXMDF: look for hole size 1000, cur range [bfff000, bffffff] size fff XXXMDF: look for hole memsz=1000, found bffe000 Now we die with overlapping ranges, since the 0x100000 bytes at 0xbeff000 overlaps 0x1000 bytes at 0xbffe000. Signed-off-by: Matthew Fleming <mdf356@gmail.com> Signed-off-by: Simon Horman <horms@verge.net.au>
* kernel image probe function return value checking fixDave Young2014-02-061-1/+1
| | | | | | | | | | | | | | | | | | Currently kexec will use the kernel image type when probe function return value >=0. It looks odd, but previously it works. Since commit bf06cf2095 it does not work anymore. During my testing for arm zImage, in 2nd kernel the atags pointer and the machine_id are not valid, I did a lot of debugging in kernel, finally I found this is caused by a kexec tools bug instead. Because uImage will be probed before zImage, also the uImage probe return 1 instead of -1 since bf06cf2095, thus kexec will mistakenly think it is uImage. Fix this issue by regarding it's valid only when probe return 0. Signed-off-by: Dave Young <dyoung@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
* kexec: Extract slurp_fd()Geert Uytterhoeven2013-12-131-49/+43
| | | | | | | | | Factor out the common part of slurp_file() and slurp_file_len() into a new helper function slurp_fd(). Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Dave Young <dyoung@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
* kexec: Let slurp_file_len() return the number of bytes readGeert Uytterhoeven2013-12-131-1/+3
| | | | | | | | | Add an optional output parameter to slurp_file_len() so it can return the actual number of bytes read. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Dave Young <dyoung@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
View Lorry Controller Status