Re: [Crash-utility] Kernel Crash Analysis on Android
by Shankar, AmarX
Hi Dave,
Thanks for your info regarding kexec tool.
I am unable to download kexec from below link.
http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/kexec-too...
It says HTTP 404 Page Not Found.
Could you please guide me on this?
Thanks & Regards,
Amar Shankar
> On Wed, Mar 21, 2012 at 06:00:00PM +0000, Shankar, AmarX wrote:
>
> > I want to do kernel crash Analysis on Android Merrifield Target.
> >
> > Could someone please help me how to do it?
>
> Merrifield is pretty much similar than Medfield, e.g it has x86 core. So I
> guess you can follow the instructions how to setup kdump on x86 (see
> Documentation/kdump/kdump.txt) unless you already have that configured.
>
> crash should support this directly presuming you have vmlinux/vmcore files to
> feed it. You can configure crash to support x86 on x86_64 host by running:
>
> % make target=X86
> & make
>
> (or something along those lines).
Right -- just the first make command will suffice, i.e., when running
on an x86_64 host:
$ wget http://people.redhat.com/anderson/crash-6.0.4.tar.gz
$ tar xzf crash-6.0.4.tar.gz
...
$ cd crash-6.0.4
$ make target=X86
...
$ ./crash <path-to>/vmlinux <path-to>/vmcore
Dave
From: Shankar, AmarX
Sent: Wednesday, March 21, 2012 11:30 PM
To: 'crash-utility(a)redhat.com'
Subject: Kernel Crash Analysis on Android
Hi,
I want to do kernel crash Analysis on Android Merrifield Target.
Could someone please help me how to do it?
Thanks & Regards,
Amar Shankar
8 months, 2 weeks
[PATCH] kmem, snap: iomem/ioport display and vmcore snapshot support
by HATAYAMA Daisuke
Some days ago I was in a situation that I had to convert vmcore in
kvmdump format into ELF since some extension module we have locally
can be used only on relatively old crash utility, around version 4,
but such old crash utility cannot handle kvmdump format.
To do the conversion in handy, I used snap command with some modifications
so that it tries to use iomem information in vmcore instead of host's
/proc/iomem. This patch is its cleaned-up version.
In this development, I naturally got down to also making an interface
for an access to resource objects, and so together with the snap
command's patch, I also extended kmem command for iomem/ioport
support. Actually:
kmem -r displays /proc/iomem
crash> kmem -r
00000000-0000ffff : reserved
00010000-0009dbff : System RAM
0009dc00-0009ffff : reserved
000c0000-000c7fff : Video ROM
...
and kmem -R displays /proc/ioport
crash> kmem -R
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
...
Looking into old version of kernel source code back, resource structure
has been unchanged since linux-2.4.0. I borrowed the way of walking on
resouce tree in this patch from the lastest v3.3-rc series, but I
guess the logic is also applicable to old kernels. I expect Dave's
regression testsuite.
Also, there would be another command more sutable for iomem/ioport.
If necessay, I'll repost the patch.
---
HATAYAMA Daisuke (4):
Add vmcore snapshot support
Add kmem -r and -R options
Add dump iomem/ioport functions; a helper for resource objects
Add a helper function for iterating resource objects
defs.h | 9 ++++
extensions/snap.c | 54 ++++++++++++++++++++++-
help.c | 2 +
memory.c | 122 +++++++++++++++++++++++++++++++++++++++++++++++++++--
4 files changed, 180 insertions(+), 7 deletions(-)
--
Thanks.
HATAYAMA Daisuke
8 months, 2 weeks
Re: [Crash-utility] question about phys_base
by Dave Anderson
----- Original Message -----
> >
> > OK, so then I don't understand what you mean by "may be the same"?
> >
> > You didn't answer my original question, but if I understand you correctly,
> > it would be impossible for the qemu host to create a PT_LOAD segment that
> > describes an x86_64 guest's __START_KERNEL_map region, because the host
> > doesn't know that what kind of kernel the guest is running.
>
> Yes. Even if the guest is linux, it is still impossible to do it. Because
> the guest maybe in the second kernel.
>
> qemu-dump walks all guest's page table and collect virtual address and
> physical address mapping. If the page is not used by guest, the virtual is set
> to 0. I create PT_LOAD according to such mapping. So if the guest is linux,
> there may be a PT_LOAD segment that describes __START_KERNEL_map region.
> But the information stored in PT_LOAD maybe for the second kernel. If crash
> uses it, crash will see the second kernel, not the first kernel.
Just to be clear -- what do you mean by the "second" kernel? Do you
mean that a guest kernel crashed guest, and did a kdump operation,
and that second kdump kernel failed somehow, and now you're trying
to do a "virsh dump" on the kdump kernel?
Dave
8 months, 2 weeks
question about phys_base
by Wen Congyang
Hi, Dave
I am implementing a new dump command in the qemu. The vmcore's
format is elf(like kdump). And I try to provide phys_base in
the PT_LOAD. But if the os uses the first vcpu do kdump, the
value of phys_base is wrong.
I find a function x86_64_virt_phys_base() in crash's code.
Is it OK to call this function first? If the function
successes, we do not calculate phys_base according to PT_LOAD.
Thanks
Wen Congyang
8 months, 2 weeks
[PATCH] runq: search current task's runqueue explicitly
by HATAYAMA Daisuke
Currently, runq sub-command doesn't consider CFS runqueue's current
task removed from CFS runqueue. Due to this, the remaining CFS
runqueus that follow the current task's is not displayed. This patch
fixes this by making runq sub-command search current task's runqueue
explicitly.
Note that CFS runqueue exists for each task group, and so does CFS
runqueue's current task, and the above search needs to be done
recursively.
Test
====
On vmcore I made 7 task groups:
root group --- A --- AA --- AAA
+ +- AAB
|
+- AB --- ABA
+- ABB
and then I ran three CPU bound tasks, which is exactly the same as
int main(void) { for (;;) continue; return 0; }
for each task group, including root group; so total 24 tasks. For
readability, I annotated each task name with its belonging group name.
For example, loop.ABA belongs to task group ABA.
Look at CPU0 collumn below. [before] lacks 8 tasks and [after]
successfully shows all tasks on the runqueue, which is identical to
the result of [sched debug] that is expected to ouput correct result.
I'll send this vmcore later.
[before]
crash> runq | cat
CPU 0 RUNQUEUE: ffff88000a215f80
CURRENT: PID: 28263 TASK: ffff880037aaa040 COMMAND: "loop.ABA"
RT PRIO_ARRAY: ffff88000a216098
[no tasks queued]
CFS RB_ROOT: ffff88000a216010
[120] PID: 28262 TASK: ffff880037cc40c0 COMMAND: "loop.ABA"
<cut>
[after]
crash_fix> runq
CPU 0 RUNQUEUE: ffff88000a215f80
CURRENT: PID: 28263 TASK: ffff880037aaa040 COMMAND: "loop.ABA"
RT PRIO_ARRAY: ffff88000a216098
[no tasks queued]
CFS RB_ROOT: ffff88000a216010
[120] PID: 28262 TASK: ffff880037cc40c0 COMMAND: "loop.ABA"
[120] PID: 28271 TASK: ffff8800787a8b40 COMMAND: "loop.ABB"
[120] PID: 28272 TASK: ffff880037afd580 COMMAND: "loop.ABB"
[120] PID: 28245 TASK: ffff8800785e8b00 COMMAND: "loop.AB"
[120] PID: 28246 TASK: ffff880078628ac0 COMMAND: "loop.AB"
[120] PID: 28241 TASK: ffff880078616b40 COMMAND: "loop.AA"
[120] PID: 28239 TASK: ffff8800785774c0 COMMAND: "loop.AA"
[120] PID: 28240 TASK: ffff880078617580 COMMAND: "loop.AA"
[120] PID: 28232 TASK: ffff880079b5d4c0 COMMAND: "loop.A"
<cut>
[sched debug]
crash> runq -d
CPU 0
[120] PID: 28232 TASK: ffff880079b5d4c0 COMMAND: "loop.A"
[120] PID: 28239 TASK: ffff8800785774c0 COMMAND: "loop.AA"
[120] PID: 28240 TASK: ffff880078617580 COMMAND: "loop.AA"
[120] PID: 28241 TASK: ffff880078616b40 COMMAND: "loop.AA"
[120] PID: 28245 TASK: ffff8800785e8b00 COMMAND: "loop.AB"
[120] PID: 28246 TASK: ffff880078628ac0 COMMAND: "loop.AB"
[120] PID: 28262 TASK: ffff880037cc40c0 COMMAND: "loop.ABA"
[120] PID: 28263 TASK: ffff880037aaa040 COMMAND: "loop.ABA"
[120] PID: 28271 TASK: ffff8800787a8b40 COMMAND: "loop.ABB"
[120] PID: 28272 TASK: ffff880037afd580 COMMAND: "loop.ABB"
<cut>
Diff stat
=========
defs.h | 1 +
task.c | 37 +++++++++++++++++--------------------
2 files changed, 18 insertions(+), 20 deletions(-)
Thanks.
HATAYAMA, Daisuke
8 months, 2 weeks
[RFC] makedumpfile, crash: LZO compression support
by HATAYAMA Daisuke
Hello,
This is a RFC patch set that adds LZO compression support to
makedumpfile and crash utility. LZO is as good as in size but by far
better in speed than ZLIB, leading to reducing down time during
generation of crash dump and refiltering.
How to build:
1. Get LZO library, which is provided as lzo-devel package on recent
linux distributions, and is also available on author's website:
http://www.oberhumer.com/opensource/lzo/.
2. Apply the patch set to makedumpfile v1.4.0 and crash v6.0.0.
3. Build both using make. But for crash, do the following now:
$ make CFLAGS="-llzo2"
How to use:
I've newly used -l option for lzo compression in this patch. So for
example, do as follows:
$ makedumpfile -l vmcore dumpfile
$ crash vmlinux dumpfile
Request of configure-like feature for crash utility:
I would like configure-like feature on crash utility for users to
select wheather to add LZO feature actually or not in build-time,
that is: ./configure --enable-lzo or ./configure --disable-lzo.
The reason is that support staff often downloads and installs the
latest version of crash utility on machines where lzo library is not
provided.
Looking at the source code, it looks to me that crash does some kind
of configuration processing in a local manner, around configure.c,
and I guess it's difficult to use autoconf tools directly.
Or is there another better way?
Performance Comparison:
Sample Data
Ideally, I must have measured the performance for many enough
vmcores generated from machines that was actually running, but now
I don't have enough sample vmcores, I couldn't do so. So this
comparison doesn't answer question on I/O time improvement. This
is TODO for now.
Instead, I choosed worst and best cases regarding compression
ratio and speed only. Specifically, the former is /dev/urandom and
the latter is /dev/zero.
I get the sample data of 10MB, 100MB and 1GB by doing like this:
$ dd bs=4096 count=$((1024*1024*1024/4096)) if=/dev/urandom of=urandom.1GB
How to measure
Then I performed compression for each block, 4096 bytes, and
measured total compression time and output size. See attached
mycompress.c.
Result
See attached file result.txt.
Discussion
For both kinds of data, lzo's compression was considerably quicker
than zlib's. Compression ratio is about 37% for urandom data, and
about 8.5% for zero data. Actual situation of physical memory
would be in between the two cases, and so I guess average
compression time ratio is between 37% and 8.5%.
Although beyond the topic of this patch set, we can estimate worst
compression time on more data size since compression is performed
block size wise and the compression time increases
linearly. Estimated worst time on 2TB memory is about 15 hours for
lzo and about 40 hours for zlib. In this case, compressed data
size is larger than the original, so they are really not used,
compression time is fully meaningless. I think compression must be
done in parallel, and I'll post such patch later.
Diffstat
* makedumpfile
diskdump_mod.h | 3 +-
makedumpfile.c | 98 +++++++++++++++++++++++++++++++++++++++++++++++++------
makedumpfile.h | 12 +++++++
3 files changed, 101 insertions(+), 12 deletions(-)
* crash
defs.h | 1 +
diskdump.c | 20 +++++++++++++++++++-
diskdump.h | 3 ++-
3 files changed, 22 insertions(+), 2 deletions(-)
TODO
* evaluation including I/O time using actual vmcores
Thanks.
HATAYAMA, Daisuke
8 months, 2 weeks
Re: [Crash-utility] [RFI] Support Fujitsu's sadump dump format
by tachibana＠mxm.nes.nec.co.jp
Hi Hatayama-san,
On 2011/06/29 12:12:18 +0900, HATAYAMA Daisuke <d.hatayama(a)jp.fujitsu.com> wrote:
> From: Dave Anderson <anderson(a)redhat.com>
> Subject: Re: [Crash-utility] [RFI] Support Fujitsu's sadump dump format
> Date: Tue, 28 Jun 2011 08:57:42 -0400 (EDT)
>
> >
> >
> > ----- Original Message -----
> >> Fujitsu has stand-alone dump mechanism based on firmware level
> >> functionality, which we call SADUMP, in short.
> >>
> >> We've maintained utility tools internally but now we're thinking that
> >> the best is crash utility and makedumpfile supports the sadump format
> >> for the viewpoint of both portability and maintainability.
> >>
> >> We'll be of course responsible for its maintainance in a continuous
> >> manner. The sadump dump format is very similar to diskdump format and
> >> so kdump (compressed) format, so we estimate patch set would be a
> >> relatively small size.
> >>
> >> Could you tell me whether crash utility and makedumpfile can support
> >> the sadump format? If OK, we'll start to make patchset.
I think it's not bad to support sadump by makedumpfile. However I have
several questions.
- Do you want to use makedumpfile to make an existing file that sadump has
dumped small?
- It isn't possible to support the same form as kdump-compressed format
now, is it?
- When the information that makedumpfile reads from a note of /proc/vmcore
(or a header of kdump-compressed format) is added by an extension of
makedumpfile, do you need to modify sadump?
Thanks
tachibana
> >
> > Sure, yes, the crash utility can always support another dumpfile format.
> >
>
> Thanks. It helps a lot.
>
> > It's unclear to me how similar SADUMP is to diskdump/compressed-kdump.
> > Does your internal version patch diskdump.c, or do you maintain your
> > own "sadump.c"? I ask because if your patchset is at all intrusive,
> > I'd prefer it be kept in its own file, primarily for maintainability,
> > but also because SADUMP is essentially a black-box to anybody outside
> > Fujitsu.
>
> What I meant when I used ``similar'' is both literally and
> logically. The format consists of diskdump header-like header, two
> kinds of bitmaps used for the same purpose as those in diskump format,
> and memory data. They can be handled in common with the existing data
> structure, diskdump_data, non-intrusively, so I hope they are placed
> in diskdump.c.
>
> On the other hand, there's a code to be placed at such specific
> area. sadump is triggered depending on kdump's progress and so
> register values to be contained in vmcore varies according to the
> progress: If crash_notes has been initialized when sadump is
> triggered, sadump packs the register values in crash_notes; if not
> yet, packs registers gathered by firmware. This is sadump specific
> processing, so I think putting it in specific sadump.c file is a
> natural and reasonable choise.
>
> Anyway, I have not made any patch set for this. I'll post a patch set
> when I complete.
>
> Again, thanks a lot for the positive answer.
>
> Thanks.
> HATAYAMA, Daisuke
>
>
> _______________________________________________
> kexec mailing list
> kexec(a)lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
8 months, 2 weeks
[ANNOUNCE] crash-7.2.8 is available
by Dave Anderson
Download from: http://people.redhat.com/anderson
or
https://github.com/crash-utility/crash/releases
The github master branch serves as a development branch that will contain
all patches that are queued for the next release:
$ git clone git://github.com/crash-utility/crash.git
Changelog:
- Fix for Linux 5.4-rc1 and later kernels that contain commit
688fcbfc06e4fdfbb7e1d5a942a1460fe6379d2d, titled "mm/vmalloc:
modify struct vmap_area to reduce its size". Without the
patch "kmem -v" will display nothing; other architectures
that utilize the vmap_area_list to determine the base of
mapped/vmalloc address space will fail.
(anderson(a)redhat.com)
- Fix for Linux 5.4-rc1 and later kernels that contain commit/merge
e0703556644a531e50b5dc61b9f6ea83af5f6604, titled "Merge tag 'modules-
for-v5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux
which introduces symbol namespaces. Without the patch, and depending
upon the architecture:
(1) the kernel module symbol list will contain garbage entries
(2) the session fails during session initialization with a dump of
the internal buffer allocation stats followed by the message
"crash: cannot allocate any more memory!"
(3) the session fails during session initialization with a
segmentation violation.
(anderson(a)redhat.com)
- Fix for the "timer -r" option on Linux 5.4-rc1 and later kernels
that contain commit 511885d7061eda3eb1faf3f57dcc936ff75863f1, titled
"lib/timerqueue: Rely on rbtree semantics for next timer". Without
the patch, the option fails with the following error "timer: invalid
structure member offset: timerqueue_head_next".
(k-hagio(a)ab.jp.nec.com)
- Fix for a "[-Wstringop-truncation]" compiler warning emitted when
symbols.c is built in a Fedora Rawhide environment with gcc-9.0.1
or later.
(anderson(a)redhat.com)
- Fix for the "kmem -n" option on Linux-5.4-rc1 and later kernels that
contain commit b6c88d3b9d38f9448e0fcf44847a075ea81d5ca2, titled
"drivers/base/memory.c: don't store end_section_nr in memory blocks".
Without the patch, the command option fails with the error message
"kmem: invalid structure member offset: memory_block_end_section_nr".
(msys.mizuma(a)gmail.com)
- Fix for Linux 4.19.5 and later 4.19-based x86_64 kernels which
are NOT configured with CONFIG_RANDOMIZE_BASE and have backported
kernel commit d52888aa2753e3063a9d3a0c9f72f94aa9809c15, titled
"x86/mm: Move LDT remap out of KASLR region on 5-level paging",
which modified the 4-level and 5-level paging PAGE_OFFSET values.
Without this patch, the crash session fails during initialization
with the error message "crash: seek error: kernel virtual address:
<address> type: "tss_struct ist array".
(anderson(a)redhat.com)
- Additional fix for the "kmem -n" option on Linux-5.4-rc1 and later
kernels that contain commit b6c88d3b9d38f9448e0fcf44847a075ea81d5ca2,
titled "drivers/base/memory.c: don't store end_section_nr in memory
blocks". The initial fix only addressed the x86_64 architecture;
this incremental patch addresses the other architectures.
(msys.mizuma(a)gmail.com)
- In the unlikely event that the panic task in a dumpfile cannot be
determined by the normal means, scan the kernel log buffer for panic
keywords, and if found, generate the panic task from the CPU number
that is specified following the panic message.
(chenqiwu(a)xiaomi.com)
- Adjust a crash-7.1.8 patch for support of /proc/kcore as the live
memory source in Linux 4.8 and later x86_64 kernels configured with
CONFIG_RANDOMIZE_BASE, which randomizes the unity-mapping PAGE_OFFSET
value. Since the problem only arises before the determination of the
randomized PAGE_OFFSET value, restrict the patch such that it only
takes effect during session initialization.
(anderson(a)redhat.com)
- Add support for extended numbering support in ELF dumpfiles to handle
more than PN_XNUM (0xffff) program headers. If the real number of
program header table entries is equal to or greater than PN_XNUM, the
e_phnum field of the ELF header is set to PN_XNUM, and the actual
number is set in the sh_info field of the section header at index 0.
(k-hagio(a)ab.jp.nec.com)
- Fix for a "warning: large integer implicitly truncated to unsigned
type [-Woverflow]" compiler message generated on 32-bit architectures
as a result of the "Additional fix for the kmem -n option" patch
above.
(anderson(a)redhat.com)
- Add support for handling openSUSE vmlinux files which will be shipped
in .xz compressed format. Without the patch, only gzip and bzip2
formats are supported.
(jirislaby(a)gmail.com)
- Fix for the determination of the ARM64 page size on Linux 4.4 and
earlier kernels that do not have vmcoreinfo data. Without the patch,
the crash session fails during initialization with the error message
"crash: "cannot determine page size".
(chenqiwu(a)xiaomi.com)
- Determine the ARM64 kernel's "vabits_actual" value by reading the
new TCR_EL1.T1SZ vmcoreinfo entry.
(bhsharma(a)redhat.com)
- Fix to determine the ARM64 kernel's "vabits_actual" value from the
ELF header of a dumpfile created with the "snap.so" extension module.
(anderson(a)redhat.com)
- Fix two typos in the examples section of the "help bt" display, which
mistakenly show "bf -f" and "bf -FF" instead of "bt -f" and "bt -FF".
(austindh.kim(a)gmail.com)
- Similar to ARM64, the X86_64, PPC64 and S390x architectures will use
the exported value of MAX_PHYSMEM_BITS from the vmcoreinfo data as
the preferred method if it is available.
(anderson(a)redhat.com)
- If an S390X kernel crashes before vmcoreinfo initialization, there is
no way to extract the KASLR offset for such early dumps. In a new
S390X kernel patch, the KASLR offset will be stored in the lowcore
memory during early boot and then overwritten after vmcoreinfo is
initialized. This patch allows crash to identify the KASLR offset
that is stored in the lowcore memory.
(zaslonko(a)linux.ibm.com)
- Fix for a crash-7.2.7 regression that determined the value of the
ARM64 kernel SECTION_SIZE_BITS by reading the in-kernel configuration
data if there is no VMCOREINFO data available. In that case, without
the patch, a double-free exception may occur.
(anderson(a)redhat.com)
- Fix for segmentation violation if the gdb_readmem_callback() function
gets called from other than a crash command, such as from an epython
command from the mypkdump.so extension module.
(anderson(a)redhat.com)
- Fix for the "dis -s" option when running against kernels that have
been configured with CONFIG_RANDOMIZE_BASE=y (KASLR). Without the
patch, the command option indicates that the FILE and LINE numbers
are "(unknown)", and that "source code is not available".
(anderson(a)redhat.com)
- Fix for newer Xen hypervisors, which fail during initialization with
the error message "crash: cannot resolve init_tss". This is caused
by a change in the Xen hypervisor with commit 78884406256, from
4.12.0-rc5-763-g7888440625. In that patch the tss_struct structure
was renamed to tss64 and the tss_page structure was introduced,
which contains a single tss64. Now tss information is accessible
via the symbol "per_cpu__tss_page".
(dietmar.hahn(a)ts.fujitsu.com)
- When accessing the ARM64 kernel's "crash_notes" array, continue to
read the per-cpu NT_PRSTATUS note contents if an invalid note is
encountered. Without the patch, if an invalid note is found, all
other notes were ignored, and subsequent "bt" attempts on the active
tasks would fail.
(chenqiwu(a)xiaomi.com, anderson(a)redhat.com)
- When accessing the 32-bit ARM kernel's "crash_notes" array, continue
to read the per-cpu NT_PRSTATUS note contents if an invalid note is
encountered. Without the patch, if an invalid note is found, all
other notes were ignored, and subsequent "bt" attempts on the active
tasks would fail.
(chenqiwu(a)xiaomi.com, anderson(a)redhat.com)
- Fix for the "log -a" option. The kernel's sk_buff.len field is a
32-bit unsigned int, but crash was reading its 32-bit value into a
64-bit unsigned long stack variable. All extra bits that pre-existed
in the upper 32-bits of the stack variable were passed along as part
of a buffer size request; if the upper 32-bit bits were non-zero,
then the command would fail with a dump of the internal buffer
allocation stats followed by the message "log: cannot allocate any
more memory!".
(anderson(a)redhat.com)
- When determining the ARM64 kernel's "vabits_actual" value by reading
the new TCR_EL1.T1SZ vmcoreinfo entry, display its value during
session initialization only when invoking crash with "-d1" or larger
-d debug value.
(anderson(a)redhat.com)
- Update copyright to 2020 in crash version output.
(anderson(a)redhat.com)
- Fix for ARM64 when running against Linux 5.5-rc1 and later kernels
that contain commit b6e43c0e3129ffe87e65c85f20fcbdf0eb86fba0, titled
"arm64: remove __exception annotations". Without the patch, the
ARM64 crash session fails during initialization with the error
message "crash: cannot resolve __exception_text_start".
(anderson(a)redhat.com)
- Fix for support of ELF format kdump vmcores from S390X KASLR kernels.
Without the patch, the crash session fails during initialization with
the error message "crash: vmlinux and vmcore do not match!".
(anderson(a)redhat.com)
- Fix for support of S390X standalone dumpfiles and LKCD dumpfiles that
were taken from S390X KASLR kernels.
(zaslonko(a)linux.ibm.com)
- Rework the previous patch for support of S390X standalone dumpfiles
and LKCD dumpfiles that were taken from S390X KASLR kernels to avoid
calling an s390x-specific function from generic code.
(zaslonko(a)linux.ibm.com)
- Fix for a gcc-10 compilation error. Without the patch, the build of
the crash library fails with a stream of error messages indicating
"multiple definition of 'diskdump_flags'"
(anderson(a)redhat.com)
4 years, 4 months
[PATCH 0/1] arm64: Fix missing offset for modules_vaddr with aarch64 guest dump
by Masayoshi Mizuma
From: Masayoshi Mizuma <m.mizuma(a)jp.fujitsu.com>
Fix for aarch64 with Linux v5.0 and later kernels that
contains commit 91fc957c9b1d ("arm64/bpf: don't allocate
BPF JIT programs in module memory") and the memory dump
is captured by virsh dump.
Note: Another two issues remain for the memory dump captured by
virsh dump with aarch64.
1. KASLR
crash doesn't work in case KASLR is enabled on the guest.
That is because the memory dump doesn't have vmcoreinfo, so we
cannot get the relocation position.
I suppose we need to implement calc_kaslr_offset() for aarch64.
nokaslr with the guest kernel parameter is a workaround.
2. VA_BITS
crash doesn't work in case the guest kernel is v5.4 and later.
That is because the memory dump doesn't have vmcoreinfo, so we
cannot get vabits_actual.
I think there's no workaround so far...
Masayoshi Mizuma (1):
arm64: Fix missing offset for modules_vaddr with aarch64 guest dump
arm64.c | 2 ++
defs.h | 3 +++
2 files changed, 5 insertions(+)
--
2.18.1
4 years, 6 months
