| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
