summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2013-03-27kexec: fix a minor mistake in an error messageZhang Yanfei
when specified a wrong --entry option, it outputs the error message: "Bad option value in --load-jump-back-helper=%s\n" which is obviously wrong, it should be: "Bad option value in --entry=%s\n" Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-27kexec: x86_64: elf: fix possible memory leak in elf_x86_64_loadZhang Yanfei
In elf_x86_64_load, allocated memory may not be free'd if the code exits abnormally, by calling die() or return. So the patch fixes the possible memory leak. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-27kexec: x86_64: elf: fix memory leak caused by get_command_lineZhang Yanfei
Since get_command_line returns dynamically allocated memory, it is easy for the caller to forget freeing the memory. Here fixes a memory leak caused by this function. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-27kexec: x86_64: bzImage64: fix memory leak caused by get_command_lineZhang Yanfei
Since get_command_line returns dynamically allocated memory, it is easy for the caller to forget freeing the memory. Here fixes a memory leak caused by this function. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-27kexec: ppc: uImage: fix memory leak caused by get_command_lineZhang Yanfei
Since get_command_line returns dynamically allocated memory, it is easy for the caller to forget freeing the memory. Here fixes a memory leak caused by this function. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-27kexec: ppc: uImage: fix possible memory leak in ppc_load_bare_bitsZhang Yanfei
In ppc_load_bare_bits, allocated memory may not be free'd if the code exits abnormally, by calling die() or return. So the patch fixes the possible memory leak. This patch is also a preparation for patch10. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-27kexec: ppc: elf: fix memory leak caused by get_command_lineZhang Yanfei
Since get_command_line returns dynamically allocated memory, it is easy for the caller to forget freeing the memory. Here fixes a memory leak caused by this function. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-27kexec: ppc: elf: fix possible memory leak in elf_ppc_loadZhang Yanfei
In elf_ppc_load, allocated memory may not be free'd if the code exits abnormally, by calling die() or return. So the patch fixes the possible memory leak. This patch is also a preparation for patch08. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-27kexec: i386: multiboot: fix memory leak caused by get_command_lineZhang Yanfei
Since get_command_line returns dynamically allocated memory, it is easy for the caller to forget freeing the memory. Here fixes a memory leak caused by this function. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-27kexec: i386: multiboot: fix possible memory leak in multiboot_x86_loadZhang Yanfei
In multiboot_x86_load, allocated memory may not be free'd if the code exits abnormally, by calling return. So the patch fixes the possible memory leak. Besides, remove some extra blank lines. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-27kexec: i386: elf: fix memory leak caused by get_command_lineZhang Yanfei
Since get_command_line returns dynamically allocated memory, it is easy for the caller to forget freeing the memory. Here fixes a memory leak caused by this function. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-27kexec: i386: elf: fix possible memory leak in elf_x86_loadZhang Yanfei
In elf_x86_load, allocated memory may not be free'd if the code exits abnormally, by calling die() or return. So the patch fixes the possible memory leak. This patch is also a preparation for patch04. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-27kexec: i386: bzImage: fix memory leak caused by get_command_lineZhang Yanfei
Since get_command_line returns dynamically allocated memory, it is easy for the caller to forget freeing the memory. Here fixes a memory leak caused by this function. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-27kexec: fix possible memory leak in check_reuse_initrdZhang Yanfei
If the if test is ok, then it will call die() to exit the process, so freeing line will not be reached, causing memory leak. Fix this. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-27kexec: Fix Makefile of linking kdump fileLi Haifeng
When make kdump object file, the expression of linking kdump ignores LDFLAGS. If someone want to build kdump with static links, it won't product object file with static attributes. So, fix it. Signed-off-by: Haifeng Li <omycle@gmail.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-27kexec-tools 2.0.4.gitSimon Horman
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>
2013-03-19kexec-tools 2.0.4Simon Horman
Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-15s390: Replace clgfi with cghiMichael Holzheu
The clgfi instruction needs at least z9 machine level. To allow kexec-tools compiled also with z900, this patch replaces clgfi with the older cghi instruction. Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-15kexec: use _ALIGN* to make the logic clearZhang Yanfei
By replacing all the explicit align opertion with marco _ALIGN*, the code logic could more clear. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-14kexec: ppc64: use _ALIGN* to make the logic clearZhang Yanfei
By replacing all the explicit align opertion with marco _ALIGN*, the code logic could be more clear. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-14kexec: ppc: use _ALIGN* to make the logic clearZhang Yanfei
By replacing all the explicit align opertion with marco _ALIGN*, the code logic could be more clear. Besides, remove the duplicate _ALIGN_* definition in file kexec/arch/ppc/crashdump-powerpc.h. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-14kexec: x86_64: use _ALIGN* to make the logic clearZhang Yanfei
By replacing all the explicit align opertion with marco _ALIGN*, the code logic could be more clear. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-14kexec: sh: use _ALIGN* to make the logic clearZhang Yanfei
By replacing all the explicit align opertion with marco _ALIGN*, the code logic could be more clear. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-14kexec: s390: remove ALIGN_UP and use _ALIGN_UPZhang Yanfei
We have _ALIGN_UP now, so remove ALIGN_UP and use _ALIGN_UP instead of it. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-14kexec: mips: use _ALIGN* to make the logic clearZhang Yanfei
By replacing all the explicit align opertion with marco _ALIGN*, the code logic could be more clear. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-14kexec: ia64: use _ALIGN* to make the logic clearZhang Yanfei
By replacing all the explicit align opertion with marco _ALIGN*, the code logic could be simplified. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-14kexec: arm: use _ALIGN* to make the logic clearZhang Yanfei
By replacing all the explicit align opertion with marco _ALIGN*, the code logic could be more clear. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-14kexec: i386: use _ALIGN* to make the logic clearZhang Yanfei
By replacing all the explicit align opertion with marco _ALIGN*, the code logic could be more clear. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-14kexec: ppc: remove duplicated _ALIGN_* macrosZhang Yanfei
We have defined the global align macros for use, so remove the duplicated macros here. And in file kexec/arch/ppc/include/page.h, we directly expand the align operation for marco PAGE_ALIGN since we have removed marco _ALIGN in this file. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-14kexec: use _ALIGN() instead of align()Zhang Yanfei
Since we have imported macro _ALIGN() for global use, replace the call of function align() with _ALIGN() and remove align(). Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-14kexec: add _ALIGN* marcos for align operationZhang Yanfei
This patch imports Macros for align operation: - _ALIGN_UP(addr, size): align addr up on a size boundary - _ALIGN_DOWN(addr, size): align addr down on a size boundary - _ALIGN(addr, size): align addr up on a size boundary Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-14kexec: check size before trying the mallocZhang Yanfei
If size is zero, it is unnecessary to do the malloc operation. So checking size first is better than doing malloc first. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-13Correct build failure in init_linux_parameters()Simon Horman
This fixes a build failure introduced by "kexec x86: drop truncation warning for crash kernel". Reported-by: CAI Qian <caiqian@redhat.com> Cc: Cliff Wickman <cpw@sgi.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-08ppc/uImage: Add support for RAM DisksSuzuki K. Poulose
Handle the RAM Disks in uImage format Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-08kexec/uImage: Recognize uImage RAM DisksSuzuki K. Poulose
Add IH_TYPE_RAMDISK as a recognized image type. uImage_load shouldn't decompress the RAMDISK type images, since uboot doesn't do it. Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-08kexec/uImage: Fix the payload length in uImage_loadSuzuki K. Poulose
For payloads without any compression, the image->len is set to the length of the entire uImage which includes the uImage header. This should be filled in from ih_size field of the uImage header. This can cause a buffer overflow, leading the sha256_process to overrun the initrd buffer. Also, prevents a vulnerability where the image has been appended with additional data. The crc check is performed only when compiled with zlib. TODO: Implement CRC check if ZLIB is not compiled in. Reported-by: Nathan Miller <nathanm2@us.ibm.com> Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-08kexec/uImage: Introduce uImage_probe_kernelSuzuki K. Poulose
uImage supports different types of payloads, including kernel, ramdisks etc. uImage_probe() as of now checks whether the supplied payload is of type KERNEL ( i.e, IH_TYPE_KERNEL or IH_TYPE_KERNEL_NOLOAD ). Change this behaviour to return the image type, if it is one of the supported payloads. This change is in prepartion to support ramdisks in uImage format. Introduce a uImage_probe_kernel() which can be used by the archs to check if the supplied payload is one of the KERNEL types. Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-05kexec: use dbgprintf instead of #if 0 for debug printingZhang Yanfei
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> [ horms@verge.net.au: Applied manually due to conflict ] Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-05kexec: fix some compiler warningsZhang Yanfei
I got the following warnings when I compiled kexec-tools: kexec/kexec-elf-rel.c: In function 'elf_rel_load': kexec/kexec-elf-rel.c:367: warning: format '%lx' expects type 'long unsigned int', but argument 6 has type 'unsigned int' kexec/kexec-elf-rel.c:367: warning: format '%lx' expects type 'long unsigned int', but argument 7 has type 'long long unsigned int' kexec/kexec-elf-rel.c:367: warning: format '%lx' expects type 'long unsigned int', but argument 8 has type 'long long unsigned int' kexec/arch/i386/crashdump-x86.c: In function 'get_kernel_paddr': kexec/arch/i386/crashdump-x86.c:99: warning: format '%016Lx' expects type 'long long unsigned int', but argument 3 has type 'uint64_t' kexec/arch/i386/crashdump-x86.c: In function 'get_kernel_vaddr_and_size': kexec/arch/i386/crashdump-x86.c:171: warning: format '%lx' expects type 'long unsigned int', but argument 3 has type 'long long unsigned int' kexec/arch/i386/crashdump-x86.c: In function 'get_crash_notes': kexec/arch/i386/crashdump-x86.c:781: warning: format '%Lx' expects type 'long long unsigned int', but argument 3 has type 'uint64_t' kexec/arch/i386/crashdump-x86.c: In function 'load_crashdump_segments': kexec/arch/i386/crashdump-x86.c:905: warning: 'nr_ranges' may be used uninitialized in this function The patch fix above warnings. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-05kexec: Respect memory limit while building crash memory ranges on ppc64Mahesh Salgaonkar
Fix it on ppc64 also. This patch now reads the memory limit information from device-tree file and limits the crash memory ranges accordingly. Tested this patch on ppc64 with upstream kernel version 3.8.0-rc4 Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-05kexec: Respect memory limit while building crash memory ranges on ppc32.Mahesh Salgaonkar
So far powerpc kernel never exported memory limit information which is reflected by mem= kernel cmdline option. Hence, kexec-tools always used to build ELF header for entire system RAM generating a dump bigger than the actual memory used by the first kernel. This patch now reads the memory limit information from device-tree file and limits the crash memory ranges accordingly. Suzuki tested this patch on ppc32(ppc440) with a kernel patch by Suzuki. The following are the upstream kernel commits that exports memory limit information through /proc/device-tree file: 4bc77a5ed - powerpc: Export memory limit via device tree a84fcd468 - powerpc: Change memory_limit from phys_addr_t to unsigned long long Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Tested-by: Suzuki K. Poulose <suzuki@in.ibm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-05kexec: include reserved e820 sections in crash kernelCliff Wickman
The crash kernel is not able to find its root device if that device is not on PCI 0. This is because it is booted with the command line option memmap=exactmap which currently clears the e820 table and does not restore reserved spaces. This works for a device on PCI 0 because ACPI falls back to a legacy mode. But the error message " [Firmware Bug]: PCI: MMCONFIG at [mem 0x80000000-0x80cfffff] not reserved in ACPI motherboard resources" is written to the log even in this functioning case. It fails for some devices on UV2, and only for UV2, because SGI seems to be the only manufacturer currently using the extended PCI(>0). The fix is simple, as long as the command line is long enough to include all the reserved spaces. The command line may have to be lengthened. See [PATCH] kexec: lengthen the kernel command line image Signed-off-by: Cliff Wickman <cpw@sgi.com> [ horms@verge.net.au: Manually applied due to conflicts ] Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-05kexec: lengthen the kernel command line imageCliff Wickman
The crash kernel's boot command line is not long enough to contain the necessary memmap= options for a large memory. The fix is simple, as long as the boot loader's command line is also long enough. I'm not sure about boot loader or kernel restrictions to this length. Signed-off-by: Cliff Wickman <cpw@sgi.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-05kexec x86: drop truncation warning for crash kernelCliff Wickman
On kexec set-up of a crash kernel on a very large memory machine we sometimes see the worrisome warning: Too many memory ranges, truncating... meaning that the total count of e820 ram, reserved and ACPI spaces is over 128. Per the comment in do_bzImage_load(): /* If using bzImage for capture kernel, then we will not be * executing real mode code. setup segment can be loaded * anywhere as we will be just reading command line. */ So if I understand, the e820 table built here and added to the 'real_mode' area is not going to be used. So the warning message can be omitted. Signed-off-by: Cliff Wickman <cpw@sgi.com> [ horms@verge.net.au manually applied due to conflict ] Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-05kexec,x86: Use macro CRASH_MAX_MEMMAP_NR for clarificationZhang Yanfei
For the allocation, using CRASH_MAX_MEMMAP_NR instead of KEXEC_MAX_SEGMENTS + 1 seems more understandable. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> [horms@verge.net.au: Applied by hand due to conflict] Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-05kexec/ppc: Fix kernel program entry point while changing the load addrSuzuki K. Poulose
uImage probe fills the entry point (ep) based on the load_addr from the uImage headers. If we change the load_addr, we should accordingly update the entry point. For ELF, calculate the offset of e_entry from the virtual start address and add it to the physical start address to find the physical address of kernel entry. i.e, pa (e_entry) = pa(phdr[0].p_vaddr) + (e_entry - phdr[0].p_vaddr) = kernel_addr + (e_entry - phdr[0].p_vaddr) Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: Matthew McClintock <msm@freescale.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-05kexec, x86: handle Crash low kernel rangeYinghai Lu
kernel could have that in /proc/iomem, will use it for kdump kernel for dma32 Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-05kexec, x86_64: Load bzImage64 above 4GYinghai Lu
need to check xloadflags to see the bzImage is for 64bit relocatable. -v2: add kexec-bzImage64.c according to Eric. -v3: don't need to purgatory under 2g after Eric's change to purgatory code. -v4: use locate_hole find position first then add_buffer... suggested by Eric add buffer for kernel image at last to make kexec-load faster. use xloadflags in setup_header to tell if is bzImage64. remove not cross GB boundary searching. add --entry-32bit and --real-mode for skipping bzImage64. -v5: add buffer with runtime size instead, so kernel could use BRK early and safely. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-05kexec, x86: put ramdisk/cmd_line above 4G for 64bit bzImageYinghai Lu
We could put ramdisk/cmdline above for bzImage on 64bit for protocol 2.12. -v2: change ext_... handling to way that eric like. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-05kexec, x86: Fix bzImage real-mode bootingYinghai Lu
We need to keep space for bss, heap/stack before command line. otherwise command_line will be cleared by kernel 16bit init code. also need to set 32bit start in real_mode header, kernel 16bit code need to jump there. Also don't touch regs16 if --real-mode is not specified. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Simon Horman <horms@verge.net.au>
generated by cgit (git 2.34.1) at 2025-07-16 19:31:25 +0000