summaryrefslogtreecommitdiff
path: root/kexec
AgeCommit message (Collapse)Author
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-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 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>
2013-03-05kexec, x86: clean boot_params area for entry-32bit pathYinghai Lu
kexec bzImage path setup data is shared with real-mode path, and setup_header is copied together with setup_code. Later 32bit just use whole area as boot_params for real_mode_data. but those area for boot_params around setup_header is not cleaned that will leave some field in boot_param as non-zero value. So clean whole buffer at first, and only copy setup_header for non real-mode entry path. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-05kexec, x86: set booloader id in setup_headerYinghai Lu
set LOADER_TYPE_KEXEC Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-01-30kexec: add additional check when getting memory infoZhang Yanfei
This check makes sure that we indeed get the memory information. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-01-30kexec,x86: remove duplicate get_memory_rangesZhang Yanfei
At first, we have already filled the kexec_info.memory_ranges by calling my_load() -> get_memory_ranges(). So if we want to get the memory information, we could just use the existing one instead of calling get_memory_ranges again. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-01-11kexec,i386: Remove unnecessary if condition checkZhang Yanfei
If we load the relocatable bzImage, the boot protocol must >= 2.05, So the if condition check is unnecessary. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2012-12-23build: Restrict scope of per-arch compiler flagsSimon Horman
Restrict the scope of compiler flags set in per-arch Makefiles to the architecture the Makefile belongs to. Signed-off-by: Simon Horman <horms@verge.net.au>
2012-12-23die: Use const for fmtSimon Horman
Signed-off-by: Simon Horman <horms@verge.net.au>
2012-12-23kexec-zImage-arm: simply cmdline-related DTB resizingStephen Warren
When resizing a dtb to add the command-line, only resize the DTB once, rather than once to add the /chosen node, and once to add the bootargs property. Also, simply add 1K of overhead (beyond strlen(cmdline)) to the buffer, to avoid requiring precise knowledge of the size impact of the requested FTB changes. In particular, some padding is performed when setting property values, which was not accounted for in the current code, which caused failures to set the bootargs values in some cases. Cc: Daniel Mack <zonque@gmail.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2012-12-18kexec-elf-ppc: Fix crashkernel region overflow checkAnders Hedlund
Signed-off-by: Anders Hedlund <anders.j.hedlund@gmail.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2012-12-14kexec-zImage-arm: add code to support --command-line along with --dtbDaniel Mack
If --dtb is called together with --command-line, we need to modify the binary dtb buffer. Luckily, we have libfdt functions available, so this is straight forward. Signed-off-by: Daniel Mack <zonque@gmail.com> Tested-by: Sven Neumann <s.neumann@raumfeld.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2012-12-14fix message and indenting in putnode in ppc64Olaf Hering
Signed-off-by: Olaf Hering <olaf@aepfle.de> Signed-off-by: Simon Horman <horms@verge.net.au>
generated by cgit (git 2.34.1) at 2025-07-16 20:05:45 +0000