| 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>
|
