| Age | Commit message (Collapse) | Author |
|---|
|
Currently, all the p_paddr of PT_LOAD headers are assigned to 0, which
is not correct and could be misleading, since 0 is a valid physical
address.
Upstream kernel commit "464920104bf7 /proc/kcore: update physical
address for kcore ram and text" fixed it and now invalid PT_LOAD is
assigned as -1.
kexec/arch/i386/crashdump-x86.c:get_kernel_vaddr_and_size() uses kcore
interface and so calls build_mem_phdrs() for kcore PT_LOAD headers.
This patch fixes build_mem_phdrs() to check if p_paddr is invalid.
Signed-off-by: Pratyush Anand <panand@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The name[hdr.n_namesz -1] check below can segfault if the header
is garbage. So we check the computed header side fits within
the expected area before going further.
Signed-off-by: Sylvain Munaut <s.munaut@whatever-company.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
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>
|
|
- Widen some types. Why did I use unsigned long? I guess this
code predates the decision to support biarch.
- Since I have made the types wider fix the statements that
print those types out.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Don't print uncondintionally print an error message about
KCORE_ELF_HEADERS_SIZE being wrong when the elf headers
are truncated when build_mem_phdrs fails because there
are other reasons we could be truncated (like an
actual damaged elf file).
Instead only print an error message when either probe_debug
is true or we are skipping the total file size checks for
some reason. When we do print an error message limit the
message to the fact that we are truncated and how many
bytes we have and how many bytes we need. The context
of the failure should be able to provide the rest of
the information.
For now add a comment in crashdump-x86_64.c to direct people
to KCORE_ELF_HEADERS_SIZE so that if someone finds the
code things can be adjusted.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
A customer has seen the kexec command exhaust its buffer for the ELF headers
from /proc/kcore. It found 147 program headers, which requires a buffer of
over 8k.
(This overflow was on an SGI UV with an extremely large memory, hence
many ram ranges.)
The default buffer size of 4k is configured in KCORE_ELF_HEADERS_SIZE.
The easy solution would probably be to increase the buffer to 16k.
That is room for 291 entries, on x86_64.
You might want to make the command dynamically enlarge the buffer when
it is found to be too small, but I don't think this command's use of a
little more memory is of concern. So there is probably no reason to
change the program logic in this area.
Diffed against kexec-tools-2.0.2
Signed-off-by: Cliff Wickman <cpw@sgi.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
There is a binutils bug which causes PT_NOTE segments to have an offset of
zero (http://sourceware.org/bugzilla/show_bug.cgi?id=594). The fix has not
made it into any release binutils, although several distributions have
backported it.
Signed-off-by: Ian Campbell <ian.campbell@xensource.com>
Acked-by: Magnus Damm <magnus@valinux.co.jp>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Broken out from "Don't create hardcoded PT_LOAD header (x86_64)" patch.
Signed off-by: Simon Horman <horms@verge.net.au>
|
|
o In kernels 2.6.18 and older, /proc/kcore elf note name length does not
take into the picture the null character size. Kexec-tools very religiously
checks for it and fails parsing /proc/kcore in older kernels. In newer
kernels (2.6.19-rc) this problem has been fixed.
o This is not a very serious condition and instead of failing we can simply
warn user about this condition and continue processing. This ensures
backward compatibility with older kernels.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Moved a whites pace change, and a fix for assumptions of a 2Mb start address
to a separate patch.
Signed-off-by: Simon Horman <horms@verge.net.au.
|
|
o With relocatable kernel in picture, the kernel text map offset
(__START_KERNEL_map) is no longer constant. It depends on where kernel
is loaded.
o Now /proc/kcore is read to determine the virtual address the kernel
is mapped at and /porc/iomem is read for determining the physical
address where kernel is loaded at. This information is enough to
create to fill virtual address and phy addr info for elf header
mapping kernel text and data.
o Virtual address for kernel text are needed by gdb as well as crash to
retrieve the meaningful data from core file.
o This patch requires "elf note memsz" fix in the kernel. Currently
that fix is in -mm tree. It will still work with older kernels. It will
display the warning messages (/proc/kcore could not be parsed) and hardcode
the kernel virtual address and size.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
o Adding a new parameter to elf functions. This flag can be used to alter
the function behaviour. Currently only one bit is being used for skipping
the elf file len check while builing the elf info.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Cleanup the warnings generated in GCC 4.1.0 compilation of kexec-tools.
This patch is created on top of the following level of
kexec-tools:
- kexec-tools-1.101.tar.gz (from eric biederman's site or
from lse site)
- kexec-tools-1.101-kdump6.patch (consolidated patch posted
on
http://lse.sourceforge.net/kdump/patches/1.101-kdump6/kexec-tools-1.101-kdump6.patch)
Review and suggestions are welcome.
Note:
Resending the patch since its not delivered to both fastboot and
linuxppc64-dev mailing list.
Regards,
Mohan.
Signed-off-by: Mohan <mohan@in.ibm.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
This patch implements the purgatory support to take backup
of the first 32KB of the first kernel
- Modified the v2wrap code to make the secondary cpus spin
directly in the v2wrap after pulling them out of kexec_wait
- Use the elf_rel function support to set the various
symbols used in purgatory
- load device-tree as a separate segment
- other miscellaneous compiler warnings cleanup
- add purgatory code support for backup
- build purgatory as relocatable for ppc64
Signed-off-by: R Sharada <sharada@in.ibm.com>
Signed-off-by: Mohan Kumar M <mohan@in.ibm.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
- Initial import into git
- initial nbi image formage support
- ppc32 initial register setting fixes.
- gzipped multiboot file support
|
