| Age | Commit message (Collapse) | Author |
|---|
|
The old printk mechanism (> v3.5.0 and < v5.10.0) had a fixed size
buffer (log_buf) that contains all messages. The location for the next
message is stored in log_next_idx. In case the log_buf runs full
log_next_idx wraps around and starts overwriting old messages at the
beginning of the buffer. The wraparound is denoted by a message with
msg->len == 0.
Following the behavior described above blindly is dangerous as e.g. a
memory corruption could overwrite (parts of) the log_buf. If the
corruption adds a message with msg->len == 0 this leads to an endless
loop when dumping the dmesg. Fix this by verifying that not wrapped
around before when it encounters a message with msg->len == 0.
While at it also verify that the index is within the log_buf and thus
guard against corruptions with msg->len != 0.
The same bug has been reported and fixed in makedumpfile [1].
[1] http://lists.infradead.org/pipermail/kexec/2022-March/024272.html
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
phys_to_virt() calculates virtual address. As a important factor,
page_offset is excepted to be accurate.
Since arm64 kernel exposes va_bits through vmcore, using it.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
After kernel commit 7bc1a0f9e176 ("arm64: mm: use single quantity to
represent the PA to VA translation"), phys_offset can be negative if
running 52-bits kernel on 48-bits hardware.
So changing phys_offset from unsigned to signed.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
free should be called before the function exit abnormally.
Signed-off-by: Kai Song <songkai01@inspur.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When compiling for 32-bit:
util_lib/elf_info.c: In function ‘dump_dmesg_lockless’:
util_lib/elf_info.c:1095:39: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘size_t’ {aka ‘unsigned int’} [-Wformat=]
1095 | fprintf(stderr, "Failed to malloc %lu bytes for prb: %s\n",
| ~~^
| |
| long unsigned int
| %u
1096 | printk_ringbuffer_sz, strerror(errno));
| ~~~~~~~~~~~~~~~~~~~~
| |
| size_t {aka unsigned int}
util_lib/elf_info.c:1101:49: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘size_t’ {aka ‘unsigned int’} [-Wformat=]
1101 | fprintf(stderr, "Failed to read prb of size %lu bytes: %s\n",
| ~~^
| |
| long unsigned int
| %u
1102 | printk_ringbuffer_sz, strerror(errno));
| ~~~~~~~~~~~~~~~~~~~~
| |
| size_t {aka unsigned int}
Indeed, "size_t" is "unsigned int" on 32-bit platforms, and "unsigned
long" on 64-bit platforms.
Fix this by formatting using "%zu".
Fixes: 4149df9005f2cdd2 ("printk: add support for lockless ringbuffer")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When compiling for 32-bit:
util_lib/elf_info.c: In function ‘get_desc_state’:
util_lib/elf_info.c:923:31: warning: left shift count >= width of type [-Wshift-count-overflow]
923 | #define DESC_FLAGS_MASK (3UL << DESC_FLAGS_SHIFT)
| ^~
util_lib/elf_info.c:925:25: note: in expansion of macro ‘DESC_FLAGS_MASK’
925 | #define DESC_ID_MASK (~DESC_FLAGS_MASK)
| ^~~~~~~~~~~~~~~
util_lib/elf_info.c:926:30: note: in expansion of macro ‘DESC_ID_MASK’
926 | #define DESC_ID(sv) ((sv) & DESC_ID_MASK)
| ^~~~~~~~~~~~
util_lib/elf_info.c:947:12: note: in expansion of macro ‘DESC_ID’
947 | if (id != DESC_ID(state_val))
| ^~~~~~~
util_lib/elf_info.c: In function ‘id_inc’:
util_lib/elf_info.c:923:31: warning: left shift count >= width of type [-Wshift-count-overflow]
923 | #define DESC_FLAGS_MASK (3UL << DESC_FLAGS_SHIFT)
| ^~
util_lib/elf_info.c:925:25: note: in expansion of macro ‘DESC_FLAGS_MASK’
925 | #define DESC_ID_MASK (~DESC_FLAGS_MASK)
| ^~~~~~~~~~~~~~~
util_lib/elf_info.c:981:15: note: in expansion of macro ‘DESC_ID_MASK’
981 | return (id & DESC_ID_MASK);
| ^~~~~~~~~~~~
Indeed, "unsigned long" constants are 32-bit on 32-bit platforms, and
64-bit on 64-bit platforms.
Fix this by using a "ULL" suffix instead.
Fixes: 4149df9005f2cdd2 ("printk: add support for lockless ringbuffer")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Linux 5.10 moved to a new lockless ringbuffer. The new ringbuffer
is structured completely different to the previous iterations.
Add support for retrieving the ringbuffer using vmcoreinfo. The
new ringbuffer is detected based on the availability of the
"prb" symbol.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When compiling kexec-tools on a 32-bit platform, assigning an
(unsigned long long) value to an (unsigned long) variable creates
this warning:
elf_info.c: In function 'read_phys_offset_elf_kcore':
elf_info.c:805:14: warning: conversion from 'long long unsigned int' to
'long unsigned int' changes value from '18446744073709551615' to '4294967295'
805 | *phys_off = UINT64_MAX;
Fix it by using ULONG_MAX instead of UINT64_MAX.
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Some code related to vmcore-dmesg.c is put into the util_lib, which
is not very reasonable, so lets move it back and tidy up those code.
In addition, that will also help to limit the size of vmcore-dmesg.txt
in vmcore-dmesg.c instead of elf_info.c.
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The variable 'fname' is mistakenly defined two twice, the first definition
is in the vmcore-dmesg.c, and the second definition is in the elf_info.c.
That is confused and incorrect although it's a static type, because the
value of variable 'fname' is not assigned(set) in elf_info.c. Anyway, its
value will be always 'null' when printing an error information.
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Here, no need to wrap the read_elf() again, lets invoke it directly.
So remove the read_elf_kcore() and clean up redundant code.
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
'vmcore-dmesg.c' already implements functionality to read
'vmcoreinfo' from vmcore file. The same can be used in other
features as well (one of which is reading the elf notes from
'kcore' file), so there is merit in moving this to the utility
libraries (util_lib).
Newer kernel versions (>= 4.19, with commit 23c85094fe1895caefdd
["proc/kcore: add vmcoreinfo note to /proc/kcore"], available),
have 'kcore' which now contains a new PT_NOTE which carries
the VMCOREINFO information.
If the same is available, we can benefit by using it in 'kexec-tools'.
This is especially useful for architectures like arm64 as we can
get kernel symbols like 'PHYS_OFFSET' from the '/proc/kcore' itself
and use it to calculate 'phys_offset' before we make a call to
'set_phys_offset()'.
For older kernels, we can try and determine the PHYS_OFFSET
value from PT_LOAD segments inside 'kcore' via some jugglery
of the correct virtual and physical address combinations.
Subsequent patch(es) in this series will use the same feature
to read the 'kcore' file.
This patch also makes some of the functions which were earlier
present in 'vmcore-dmesg.c' as non-static, so as to allow
future patches to use them as library functions.
Also we add the capability to read 'NUMBER(PHYS_OFFSET)' from
vmcoreinfo to the already present 'scan_vmcoreinfo()' code.
Future patches can look at reading more vmcoreinfo information
(for e.g. 'kaslr_offset()' for x86_64 and arm64) by using the
same framework.
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
With the recent build changes a number of unneded files
crept into tarballs, including .o and .d files.
This patch is farily verbose, but hopefully in the long
run this system will be obvious enough to be maintainable.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Use a $(clean) variable to store all items that need to be removed on
'make clean' (eg, .o files).
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
Conflicts:
Makefile.in
|
|
Since we use the implicit ruls for .c and .S, just colelct all sources
in the one variable.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Purgatory seems to partially duplicate system headers.
It seems a log cleaner not to do so.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This change makes kexec-tools work more like a standard configure-make-
make-install-type project:
* Remove $(OBJDIR) stuff. To do an out-of-tree build, just configure
from a different directory.
* Use the implicit Makefile rules more, and just edit the compiler
flags for specific targets.
* Simplify compiler/linker flags - no need for EXTRA_*
* Add TARGET_CC, and improve checks for BUILD_CC too.
* Set arch-specific flags in arch-specific makefiles, not conditional
on $(ARCH).
* Generate dependency files in the main compile, rather than as a
separate step.
* Don't #include sha256.c, but re-build it into the purgatory.
Still a work-in-progress.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
[BUILD] Make sure sha256.c is compiled without optimisation
sha256.c needs to be compiled without optimization, else
purgatory fails to execute (on ia64 at least).
By placing -O0 after $(CFLAGS), which is provided by
the prevailing environment, it overrides any other -O flags
provided.
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
[BUILD] CPPFLAGS, CFLAGS and LDFLAGS fixes
* Set internal CPPFLAGS as EXTRA_CPPFLAGS, CFLAGS as EXTRA_CFLAGS,
and LDFLAGS as EXTRA_LDFLAGS
- Don't overwrite CPPFLAGS, LDLFAGS or CFLAGS from the environment
- They are irrelevant for BUILD_CC
- When cross-compiling for a ppc64 host on a non-ppc64 host,
EXTRA_CFLAGS, which is included in BUILD_CPPFLAGS contains
-mcall-aixdesc, which does not work on i386 at least
* Use LDFLAGS when linking kexec
- Append rather than overwrite in purgatory/Makefile
The purpose of these changes is three-fold.
* CPPFLAGS, CFLAGS and LDFLAGS from the environment really ought
to be honoured. For one thing;
* Without these changes, the confgiure taget in
the toplevel makefile can't work
* Without these changes, cross compiling does not work -
well, I can't work out how to get it to work anyway.
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
- Initial import into git
- initial nbi image formage support
- ppc32 initial register setting fixes.
- gzipped multiboot file support
|
