Age | Commit message (Collapse) | Author |
|
This patch append the position of initrd to dtb when loading arm kernel
and initrd without using atag.
Signed-off-by: Wang Nan <wangnan0@huawei.com>
Acked-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch introduces setup_dtb_prop(), which is used for dtb operations. The
code is extracted from zImage_arm_load, and this patch makes memory grown
computation more accurate.
Signed-off-by: Wang Nan <wangnan0@huawei.com>
Acked-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch introduce fdt_node_len and fdt_prop_len to help for computing
memory requirement when operating dtb.
Signed-off-by: Wang Nan <wangnan0@huawei.com>
Acked-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When kASLR is enabled (CONFIG_RANDOMIZED_BASE=y), kernel text mapping
base is randomized. The max base offset of such randomization is
configured at compile time through CONFIG_RANDOMIZE_MAX_BASE_OFFSET (by
default 1G).
Currently kexec-tools is using hard code macro X86_64__START_KERNEL_map
(0xffffffff80000000) and X86_64_KERNEL_TEXT_SIZE (512M) to determine
kernel text mapping from kcore's PT_LOAD. With kASLR, the mapping is
changed as the following:
ffffffff80000000 - (ffffffff80000000+CONFIG_RANDOMIZE_BASE_MAX_OFFSET)
As Vivek suggested, we can get _stext kernel symbol address from
/proc/kallsyms, and search for kcore's PT_LOAD which contains _stext,
and we can say that this area represents the kernel mapping area.
Let's first use this way to find out kernel text mapping. If failed for
whatever reason, fall back to use the old way.
Suggested-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
On non-EFI systems, efi_info section of boot_params is zero filled resulting
in an erroneous message from kexec regarding "efi memory descriptor" version.
Caused by commit: e1ffc9e9a0769e1f54185003102e9bec428b84e8 "Passing efi related
data via setup_data"
0000700 0000 0000 0000 0000 0000 0000 0000 0000
0000720 0000 0000 0000 0000 0000 0000 0000 0000
0000740
efi memory descriptor version 0 is not supported!
Signed-off-by: Tony Jones <tonyj@suse.de>
Acked-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
In case using crashkernel=xM,high crashkernel memory will be allocated from top to down
Thus the usable memory for kdump kernel could be bigger than 4G. The efi memmap value
is two 32 bit values efi_memmap and efi_memmap_hi, previously I only passed the efi_memmap
so for the high memory address there will be below kernel panic:
[ 0.000000] efi: EFI v2.31 by American Megatrends
[ 0.000000] efi: ACPI 2.0=0xdb752000 SMBIOS=0xdbab4b98 ACPI=0xdb752000 MPS=0xf4bd0
[ 0.000000] efi: mem00: type=4294967295, attr=0xffffffffffffffff, range=[0xffffffffffffffff-0xffffffffffffefff) (72057594037927935)
[ 0.000000] efi: mem01: type=4294967295, attr=0xffffffffffffffff, range=[0xffffffffffffffff-0xffffffffffffefff) (72057594037927935)
[ 0.000000] efi: mem02: type=4294967295, attr=0xffffffffffffffff, range=[0xffffffffffffffff-0xffffffffffffefff) (72057594037927935)
[ 0.000000] efi: mem03: type=4294967295, attr=0xffffffffffffffff, range=[0xffffffffffffffff-0xffffffffffffefff) (72057594037927935)
[ 0.000000] efi: mem04: type=4294967295, attr=0xffffffffffffffff, range=[0xffffffffffffffff-0xffffffffffffefff) (72057594037927935)
[ 0.000000] SMBIOS 2.7 present.
[snip]
[ 0.082451] BUG: unable to handle kernel paging request at ffffa3d0f0000000
[ 0.089467] IP: [<ffffffff810513d1>] native_set_pte+0x1/0x10
[ 0.095157] PGD 0
[ 0.097197] Oops: 0002 [#1] SMP
[ 0.100466] Modules linked in:
[ 0.103554] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.14.0-rc7 #157
[ 0.110001] Hardware name: Hewlett-Packard HP Z420 Workstation/1589, BIOS J61 v03.15 05/09/2013
[ 0.118697] task: ffffffff818e1460 ti: ffffffff818ce000 task.ti: ffffffff818ce000
[ 0.126181] RIP: 0010:[<ffffffff810513d1>] [<ffffffff810513d1>] native_set_pte+0x1/0x10
[ 0.134296] RSP: 0000:ffffffff818cfc80 EFLAGS: 00010287
[ 0.139609] RAX: 0000000000000000 RBX: ffffa3d0f0000000 RCX: 00003ffffffff000
[ 0.146744] RDX: ffff880000000000 RSI: 0000000000000000 RDI: ffffa3d0f0000000
[ 0.153879] RBP: ffffffff818cfcb8 R08: ffffea0010745d20 R09: 0000000000000000
[ 0.161013] R10: ffff88041f731fc0 R11: 000000000000001e R12: 0000000000200000
[ 0.168148] R13: 0000000000000000 R14: 0000000000400000 R15: ffff880000000008
[ 0.175288] FS: 0000000000000000(0000) GS:ffff88041f200000(0000) knlGS:0000000000000000
[ 0.183377] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 0.189125] CR2: ffffa3d0f0000000 CR3: 000000041e8da000 CR4: 00000000000406b0
[ 0.196264] Stack:
[ 0.198283] ffffffff818cfcb8 ffffffff810561d7 ffff880000000008 0000000000400000
[ 0.205746] ffff880000001000 00000000000001ff ffff88041e8de000 ffffffff818cfd00
[ 0.213210] ffffffff8105644e 0000000000200000 0000000040000000 00000000ffffffff
[ 0.220676] Call Trace:
[ 0.223130] [<ffffffff810561d7>] ? unmap_pte_range+0x77/0x110
[ 0.228966] [<ffffffff8105644e>] unmap_pmd_range+0xde/0x210
[ 0.234630] [<ffffffff81056c6b>] __cpa_process_fault+0x48b/0x5e0
[ 0.240730] [<ffffffff81057276>] __change_page_attr_set_clr+0x4b6/0xb10
[ 0.247437] [<ffffffff810557c7>] ? __ioremap_caller+0x277/0x360
[ 0.253454] [<ffffffff810589f1>] kernel_map_pages_in_pgd+0x71/0xa0
[ 0.259736] [<ffffffff81a53361>] __map_region+0x45/0x63
[ 0.265051] [<ffffffff81a535cc>] efi_map_region_fixed+0xd/0xf
[ 0.270886] [<ffffffff81a52f19>] efi_enter_virtual_mode+0x5a/0x3d9
[ 0.277162] [<ffffffff81a77516>] ? acpi_enable_subsystem+0x37/0x90
[ 0.283440] [<ffffffff81a36eb9>] start_kernel+0x386/0x41c
[ 0.288931] [<ffffffff81a3693c>] ? repair_env_string+0x5c/0x5c
[ 0.294852] [<ffffffff81a36120>] ? early_idt_handlers+0x120/0x120
[ 0.301035] [<ffffffff81a365ee>] x86_64_start_reservations+0x2a/0x2c
[ 0.307479] [<ffffffff81a3672e>] x86_64_start_kernel+0x13e/0x14d
[ 0.313572] Code: 66 2e 0f 1f 84 00 00 00 00 00 48 8b 46 18 55 48 89 e5 48 89 47 04 5d c3 66 90 55 48 89 e5 0f 01 f8 5d c3 0f 1f 8
[ 0.333545] RIP [<ffffffff810513d1>] native_set_pte+0x1/0x10
[ 0.339312] RSP <ffffffff818cfc80>
[ 0.342807] CR2: ffffa3d0f0000000
[ 0.346141] ---[ end trace 86088f739725b8c6 ]---
[ 0.350760] Kernel panic - not syncing: Fatal exception
Fix this by passing both efi_memmap and efi_memmap_hi to 2nd kernel.
Reported-by: Linn Crosetto <linn@hp.com>
Signed-off-by: Dave Young <dyoung@redhat.com>
Tested-by: Linn Crosetto <linn@hp.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Before this patch, when no --image-size passed, initrd_base is caculated using
base + len * 4, which is unaligned, and unable to pass check in
add_segment_phys_virt():
if (base & (pagesize -1)) {
die("Base address: 0x%lx is not page aligned\n", base);
}
This patch also uses getpagesize() instead of hard encoded 4096.
Signed-off-by: Wang Nan <wangnan0@huawei.com>
Acked-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
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() 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>
|
|
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>
|
|
All other _probe functions return 0 for probing the kernel
image successfully, so there's no reason to return 1 here.
Fix it to return 0 instead.
Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
At least on our systems, xenctrl.h defines (unguarded) struct e820entry
Move the (guarded) definition in include/x86/x86-linux.h to below.
Signed-off-by: Tony Jones <tonyj@suse.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Commit 9c200a85de2245a850546fded96a1977b84ad24d referenced
'bzImage_support_efi_boot' without matching 32-bit definition.
Signed-off-by: Tony Jones <tonyj@suse.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
strncat() does not want the total size but the maximum length
(without trailing NUL) that can still be added. Switch over
to snprintf which is both more readable and avoids this issue.
Signed-off-by: Dirk Mueller <dmueller@suse.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When the kernel is built with CONFIG_PPC_EARLY_DEBUG_OPAL set, it is
expecting to get r8 and r9 filled respectively with OPAL base address and
OPAL entry address (arc/power/head_64.S).
On the new powernv platform, having these 2 registers set allows the kernel
to perform OPAL calls before it parse the device tree.
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Tested-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When building in PPC64 little endian mode, the compiler is now using the
new ABI v2. Among other changes, this new ABI removes the function
descriptors and changes the way the TOC address is computed when entering a
C function.
The purgatory assembly part where the dot symbols are removed, and ELF
relocation code are impacted in this patch.
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
All the attributes exposed in the device tree are in Big Endian format.
This patch add the byte swap operation for some entries which were not yet
processed, including those fixed by the following kernel's patch :
https://lists.ozlabs.org/pipermail/linuxppc-dev/2014-January/114720.html
To work on PPC64 Little Endian mode, kexec now requires that the kernel's
patch mentioned above is applied on the kexecing kernel.
Tested on ppc64 LPAR (kexec/dump) and ppc64le in a Qemu/KVM guest (kexec)
Changes from v1 :
* add processing of the following entries :
- ibm,dynamic-reconfiguration-memory
- chosen/linux,kernel-end
- chosen/linux,crashkernel-base & size
- chosen/linux,memory-limit
- chosen/linux,htab-base & size
- linux,tce-base & size
- memory@/reg
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
For supporting efi runtime, several efi physical addresses
fw_vendor, runtime, config tables, smbios and the whole runtime
mapping info need to be used in kexec kernel. Thus introduce
setup_data struct for passing these data.
collect the varialbes from /sys/firmware/efi/systab and
/sys/firmware/efi/runtime-map
Signed-off-by: Dave Young <dyoung@redhat.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
For supporting efi runtime on kexec kernel we need to
fill the efi_info struct in setup_header. I just get
the info in kernel exported boot_params data in debugfs.
Signed-off-by: Dave Young <dyoung@redhat.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Not only setup_subarch will get data from debugfs file
boot_params/data, later code for adding efi_info will
also need do same thing. Thus add a common function here
for later use.
Signed-off-by: Dave Young <dyoung@redhat.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
There's build warnings about using struct x86_linux_param_header *
in x86-linux-setup.h, it is declared in x86-linux.h
Fix it by include x86-linux.h in x86-linux-setup.h
Signed-off-by: Dave Young <dyoung@redhat.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
In the multiboot header, there is a field, `mem_lower' that is meant to
contain the size of memory starting at zero and ending below 640k.
If your kernel is compiled with CONFIG_X86_RESERVE_LOW non zero
(the usual case), then a hole is inserted into kernel's physical
memory map at zero, so the test to find the size of this region in
kexec/arch/i386/kexec-multiboot-x86.c never succeeds, so the value is
always zero.
On a PC99 architecture, there is always memory at physycal address zero;
assume that a region that starts below 64k actually starts at zero,
and use it for the mem_lower variable.
Signed-off-by: Peter Chubb <peter.chubb@nicta.com.au>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Currently little-endian ELFDATA is hard-coded in crashdump header.
This lead to a wrong header format if crashdump is generated on BE system.
Set native endianness into ELFDATA field.
Signed-off-by: Taras Kondratiuk <taras.kondratiuk@linaro.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
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>
|
|
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>
|
|
A switchover from /kexec/arch/ppc64/fs2dt.c to common code under
/kexec/fs2dt.c broke the kdump on ppc64. The function add_usable_memory()
assumes that 'memory@*' node exports two 32bit values and fails
to populate mem ranges correctly. On ppc64, 'memory@*' exports two 64bit
values as below:
# hexdump /proc/device-tree/memory\@0/reg
0000000 0000 0000 0000 0000 0000 0000 0800 0000
0000010
#
This patch fixes add_usable_memory() to use buf[2] of type uint64_t.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This typo was introduced in c/s c0b4a3f95dd80256cc6d7084436235e69b4933fb
It prevents a 32bit build of kexec from loading a 32bit crash image.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Remove redundant include of stdlib.h introduced by
commit d01680c28ba7bf1e02f74aa5841247a45738f5d4
(kexec/xen: Correct some compile errors).
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Do not call xc_interface_close() if xc_interface_open() failed.
xc_interface_close() crashes if it gets NULL as an argument.
Relevant fix for libxenctrl will be posted too but kexec-tools
should also behave properly.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Correct various problems introduced by
08cf823704b0fa3b ("kexec/xen: directly load images images into Xen").
These all relate to the case here HAVE_LIBXENCTRL is not set.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Xen 4.4 has an improvided kexec hypercall ABI that allows images to be
loaded and executed without any kernel involvement. Use the API
provided by libxc to load images when running in a Xen guest.
Support for loading images via the kexec_load syscall in non-upstream
("classic") Xen kernels is no longer supported.
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Don Slutz <Don@CloudSwitch.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Use xc_kexec_get_range(KEXEC_RANGE_MA_CPU) instead of parsing
/proc/iomem (which is only populated by non-upstream ("classic") Xen
kernels).
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
libxc from Xen 4.4 added xc_kexec_load() which will be required to
load images into Xen in the future.
Remove all the #ifdef'ery for older versions of libxc.
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch provides support for the new Power PC litte endian (LE) mode. The
LE mode only differs in the way the instructions and data are stored in memory
thus there is no real need to duplicate the ppc64 code.
However some compilation's options, especially for the purgatory, differ
between little and big endian mode's support. A new "SUBARCH" build variable
is introduced which is currently only used for PPC64 to specify the
endianness.
Another set of changes in this patch is fixing minor endianess issues in the
ppc64 code and fix an alignment issue raised on Power7 little endian mode.
Among these fixes, the check on the kernel binary endianess is removed,
since we can imagine kexecing a LE kernel from a BE environment, as far as
the specified root filesystem and initrd file are containing the right
binaries.
This patch depends on the patch "kexec/ppc64: use common architecture
fs2dt.c file" I sent earlier on the kexec mailing list.
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Following the commit 'b3c2962 fs2dt: Add a generic copy of fs2dt' which
introduced a generic fs2dt file, this patch is removing the ppc64
architecture's one.
Tests have been done successfully on Power 7 plateform.
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Currently, kexec on arm assumes that it's safe to place binary images
such as atags, dtb or initrd at an estimated offset after the load
address. That estimated offset is set to 4 times the size of the
compressed image, hence assuming a minimum compression ratio of 1:4.
While that assumption matches what the in-kernel compressors are able to
achive, it doesn't take into account the .bss section the kernel image
carries, and which can grow to arbitrary sizes while not accounting to
the compressed image size.
After decompression, and before the execution of the compressed kernel,
the .bss area is initialized to zeros, trampeling over the binary images
in case they happen to live in that piece of memory.
Unfortunately, determining the full image size is not easiliy possible
at runtime, as it would include doing all possible ways of
decompression and then walk the ELF sections by hand.
For now, allow users to override the static offset with a new, arm
specific command line argument. Users are supposed to set this, and
determine a sane value by using 'arm-linux-size vmlinux'.
Signed-off-by: Daniel Mack <zonque@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
While reviewing fs2dt.c in the common kexec directory, in order to use it to
support little endian ppc64 architecture, I found some endianess
conversion's issues.
In dt_reserve, dt_base is a pointer and thus should not be converted.
In checkprop, values read from the device tree are big endian encoded and
should be converted if CPU is running in little endian mode.
In add_dyn_reconf_usable_mem_property__, fix extraneous endianess conversion
of rlen which should be natively used to increase the dt pointer.
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The putnode() routine in fs2dt.c was not checking for errors
returned from calls to read(). Add checks for these errors
and abort the setup of printing from purgatory if the checks
fail.
Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add a local variable 'result' to the putnode() routine of
ds2dt and use it to hold return values of calls to read().
Fixes build warnings like these:
kexec/fs2dt.c: warning: ignoring return value of ‘read’
Signed-off-by: Geoff Levand <geoff@infradead.org> for Huawei, Linaro
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When calling locate_hole() with "hole_size" equal to the size of an
available memory block, it fails to use that memory block.
"end" and "hole_max" point to the last byte within the range, hence
- "size = end - start" is one less than "hole_size",
- "hole_base + hole_size" is one more than "hole_max".
Subtract one from "hole_size" when doing the comparison (adding 1 to "size"
could overflow in case of one big range covering the whole address space).
But explicitly check if "hole_size" is zero first, to handle this case
without causing underflows.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Initialize a local variable to zero.
Fixes build warnings like these:
kexec/kexec-elf-rel.c: warning: ‘rel.r_offset’ may be used uninitialized in this function
Signed-off-by: Geoff Levand <geoff@infradead.org> for Huawei, Linaro
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The main kexec option code handles the -? option. Remove all the
duplicate -? handlers in the arch code which are never used.
Signed-off-by: Geoff Levand <geoff@infradead.org> for Huawei, Linaro
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add '?' to the short option string. Fixes runtime errors like
these:
kexec: invalid option -- '?'
Signed-off-by: Geoff Levand <geoff@infradead.org> for Huawei, Linaro
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
We should check if the initrd is in uImage format, when
the kernel might be in ELF.
Signed-off-by : Suzuki K Poulose <suzuki@in.ibm.com>
Signed-off-by : Athira Rajeev<atrajeev@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
If the primary kernel doesn't use an initrd,
we may not have linux,initrd-* entries in the
device-tree, and hence the initial flat tree
may not contain them.
Make sure we add the entries in the dtb if the
second kernel needs an initrd.
Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com>
Signed-off-by: Athira Rajeev<atrajeev@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
It's confusing that some pointers are printed as hex numbers prefixed with
0x, while some other values are printed as hex numbers without prefixes.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Cris doesn't have support for crash kernels yet.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|