| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The vmcore-dmesg utility has been in usage for several years,
and is pretty stable now.
So its useful now to modify its man page to indicate the same.
Also fix some minor formatting issues.
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Running 'cppcheck' static code analyzer (see cppcheck(1))
on 'vmcore-dmesg/vmcore-dmesg.c' shows the following
shifting error:
$ cppcheck --enable=all vmcore-dmesg/vmcore-dmesg.c
Checking vmcore-dmesg/vmcore-dmesg.c ...
[vmcore-dmesg/vmcore-dmesg.c:17]: (error) Shifting signed 32-bit value by 31 bits is undefined behaviour
Fix the same via this patch.
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
With some corrupted vmcore files, the vmcore-dmesg.txt file may grow
forever till the kdump disk becomes full, and also probably causes
the disk error messages as follow:
...
sd 0:0:0:0: [sda] tag#6 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:0:0: [sda] tag#6 CDB: Read(10) 28 00 08 06 4c 98 00 00 08 00
blk_update_request: I/O error, dev sda, sector 134630552
sd 0:0:0:0: [sda] tag#7 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:0:0: [sda] tag#7 CDB: Read(10) 28 00 08 06 4c 98 00 00 08 00
blk_update_request: I/O error, dev sda, sector 134630552
...
If vmcore-dmesg.txt occupies the whole disk, the vmcore can not be
saved, this is also a problem.
Lets limit the size of vmcore-dmesg.txt to avoid such problems.
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
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>
|
|
'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>
|
|
We hit a bug where vmcore-dmesg would get stuck in a loop, and since we
were redirecting the output to a file, it wouldn't stop until it filled
up the disk. This only happened when the dmesg buffer had filled up and
wrapped around. It turns out that when we hit the end of the buffer, we
are looping back to the first record instead of the beginning of the
buffer, which will always loop forever.
Fixes: e08d26b3b7f1 ("vmcore-dmesg: avoid allocating large memory chunk for log buf")
Signed-off-by: Omar Sandoval <osandov@fb.com>
Acked-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
In kdump kernel, we got:
Saving vmcore-dmesg.txt
Failed to malloc 67108864 bytes for the logbuf: Cannot allocate memory
Apparently 64M is too luxury for a kdump kernel which only has 128M
in total.
We can avoid allocating such a large memory chunk, instead just allocate
a smaller chunk inside the loop each time.
Verify the result by comparing the vmcore-dmesg output with and without
this patch.
Cc: Simon Horman <horms@verge.net.au>
Reviewed-by: Dave Young <dyoung@redhat.com>
Reviewed-by: Pratyush Anand <panand@redhat.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
loff_t is guarded with _GNU_SOURCE on some C library implementations
e.g. musl since this type is not defined by POSIX. Define _GNU_SOURCE to
include this define, it should help compiling on musl while nothing
changes for glibc based systems since there _GNU_SOURCE is already
defined
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
logged_chars would be set to 0 by `dmesg -c`, but full dmesg is useful
for debugging. So instead of using logged_chars directly, we calculate
it by ourselves.
Now logged_chars is set to the minimum of log_end and log_buf_len, as
the same logic as crash utility is using.
Signed-off-by: Dangyi Liu <dliu@redhat.com>
Cc: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
vmcore-dmesg has been failing for me for quite some time as struct log
was renamed to struct printk_log.
62e32ac printk: rename struct log to struct printk_log
This patch has been sitting in mailing list for quite some time. It
is time to repost the patch.
I took original patch of Lubomir and modified a bit to take care of
concern of hardcoded string length.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Description
in dump_dmesg_structured() the out_buf size is 4096, and if the
length is less than 4080( 4096-16 ) it won't really write out.
Normally, after writing one or four chars to the out_buf, it will
check the length of out_buf. But in extreme cases, 19 chars was
written to the out_buf before checking the length. This may cause
the stack corruption. If the length was 4079 (won't realy write out),
and then write 19 chars to it. the out_buf will overflow.
Solution
Change 16 to 64 thus can make sure that always have 64bytes before
moving to next records. why using 64 is that a long long int can take
20 bytes. so the length of timestamp can be 44 ('[','.',']',' ') in
extreme case.
Signed-off-by: Arthur Zou <zzou@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Some sort of space like "\t" "\n" are used in kernel log. But we treat
them as non-printables and output "\x20%x" for each non-printable. So
let's fix it.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
It seems gcc doesn't check return type from inline function.
struct_val_u64() should return u64 otherwise upper 32bit is lost.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
A 32bit arch can prepare ELF64 headers. For example for PAE case to
preresent file offsets 64bit but data size at the offset still remains
32bit. If we just base our decision based on EI_CLASS, then we will try
to read 64bit data from file and can run into various issues.
We ran into following issue when we tried to run vmcore-dmesg on a 32bit
PAE system vmcore which had 64bit elf headers.
No program header covering vaddr 0xc0a6a688c0b89100found kexec bug?
Basically we try to read value of log_buf variable from address
log_buf_vaddr. We read in 64bit value and then pass that value again
to vaddr_to_offset() in an attempt to get to actual log_buf start
and get error message.
So determine the machine pointer size based on ELF class and arch and read
the bytes from file accordingly.
v2: Fixed the code as per suggestion from Eric.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
Acked-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Now kernel has made kernel logging structured and exsisting vmcore-dmesg
does not work with this new format. Hence kernel version 3.5 is broken. In
3.6 now a kernel patch has been put which exports relevant fields. This
patch parses those fields and makes vmcore-dmesg work with new logging
format.
Currently it does not display log levels or dictionary. I personally think
that log levels are not very useful and it also requires additional kernel
patches so that log levels are not bitfields and relevant information is
exported to user space properly.
Concept of dictionary is new and relevant information is exported. One can
possibly enahnce vmcore-dmesg to also print dictionary contents based on
a user command line option.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
scan_vmcoreinfo() currently assumes that every vmcoreinfo note line ends
with \n and overwrites new line with \0. But last entry in note, CRASHTIME=
does not end with \n and this leads to corrupting memory as we write beyond
end of buffer.
Normally things were fine but when I added some fields to vmcoreinfo, this
bug started showing and vmcore-dmesg started crashing.
I am planning to send a patch to fix this in kernel but it might be good
idea to handle this case in user space too so that vmcore-dmesg works
fine with cores of older kernels.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Use automatic variables for prerequisites when copying man pages and
include a makefile relative to $(srcdir).
Signed-off-by: Tyler Hall <tylerwhall@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This test appears bogus because the e_phnum element of Elf32_Phdr and
is an unsigned 16bit entity.
This addresses the following warnings:
vmcore-dmesg/vmcore-dmesg.c: In function 'read_elf32':
vmcore-dmesg/vmcore-dmesg.c:116: warning: comparison is always false due to limited range of data type
vmcore-dmesg/vmcore-dmesg.c: In function ‘read_elf64’:
vmcore-dmesg/vmcore-dmesg.c:192: warning: comparison is always false due to limited range of data type
Reviewed-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
vmcore-dmesg is a trivial utility to extract the dmesg from a vmcore.
This was written in reaction to problems I was having building
makedumpfile, and using makedumpfile for extracting dmesg. makedumpfile
does a whole lot of things, uses a whole lot of libraries and which
make it hard to compile and a little bit clunky to remember the command
line switches.
So I have written the trivial vmcore-dmesg program that reads a vmcore
either /proc/vmcore or a saved version vmcore and writes the dmesg to stdout.
There is nothing to vmcore-dmesg and all of the arch dependencies are wrapped
up in generating the core file. Which means a vmcore-dmesg should work with
core files of all architectures without needing a rebuild.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
[ horms@verge.net.au removed trailing white-space ]
Signed-off-by: Simon Horman <horms@verge.net.au>
|
