Hi All,
We came across another failure in makedumpfile when kaslr is enabled. This
failure occurs when we try re-filtering. We try to erase some symbol from a
dumpfile which was copied/compressed from /proc/vmcore using makedumpfile.
We have very limited symbol information in vmcoreinfo. So symbo
If we have to erase a symbol from vmcore whose address is not present in
vmcoreinfo, then we need to pass vmlinux as well to get the symbol
address.
When kaslr is enabled, virtual address of all the kernel symbols are
randomized with an offset. vmlinux always has a static address, but all
the arch
we do not call get_elf_info() in case of refiltering. Therefore, we will
not have any pt_load in that case, and so we get:
get_page_offset_x86_64: Can't get any pt_load to calculate page offset.
However, we will have vmcoreinfo and vmlinux information in case of
re-filtering. So, we are able to f
On 04/27/2017 at 01:44 PM, Dave Young wrote:
> Hi Xunlei,
>
> On 04/27/17 at 01:25pm, Xunlei Pang wrote:
>> On 04/27/2017 at 11:06 AM, Dave Young wrote:
>>> [snip]
>>>
>>> static int __init crash_save_vmcoreinfo_init(void)
>>> {
>>> + /* One page should be enough for VMCOR
Hi Xunlei,
On 04/27/17 at 01:25pm, Xunlei Pang wrote:
> On 04/27/2017 at 11:06 AM, Dave Young wrote:
> > [snip]
> >
> > static int __init crash_save_vmcoreinfo_init(void)
> > {
> > + /* One page should be enough for VMCOREINFO_BYTES under all
> > archs */
> Can
On 04/27/2017 at 11:06 AM, Dave Young wrote:
> [snip]
>
> static int __init crash_save_vmcoreinfo_init(void)
> {
> + /* One page should be enough for VMCOREINFO_BYTES under all archs */
Can we add a comment in the VMCOREINFO_BYTES header file about the one
page assumpt
[snip]
> >>>
> >>> static int __init crash_save_vmcoreinfo_init(void)
> >>> {
> >>> + /* One page should be enough for VMCOREINFO_BYTES under all archs */
> >> Can we add a comment in the VMCOREINFO_BYTES header file about the one
> >> page assumption?
> >>
> >> Or just define the VMCOREINFO_BY
[snip]
> >> index 43cdb00..a29e9ad 100644
> >> --- a/kernel/crash_core.c
> >> +++ b/kernel/crash_core.c
> >> @@ -15,9 +15,12 @@
> >>
> >> /* vmcoreinfo stuff */
> >> static unsigned char *vmcoreinfo_data;
> >> -size_t vmcoreinfo_size;
> >> +static size_t vmcoreinfo_size;
> >> u32 *vmcoreinfo_n
On Fri, Apr 21, 2017 at 6:27 AM, Pratyush Anand wrote:
> Hi Kristian,
>
> Sorry, I missed this mail.
> Are you still on it, or it is solved?
No problem, I'm still experiencing the issue but I haven't
investigated it further.
>
>
> How does kexec-tools see above memory ranges?
> As per your /pr
On Wed, Apr 26, 2017 at 03:31:48PM +0800, Dave Young wrote:
> On 04/26/17 at 03:28pm, Dave Young wrote:
> > On 04/26/17 at 08:22am, Ingo Molnar wrote:
> > >
> > > * Yinghai Lu wrote:
> > >
> > > > For x86 with recent kernel after
> > > > commit 640e1b38b0 ("x86/boot/e820: Basic cleanup of e820.
On 04/26/2017 at 05:51 PM, Xunlei Pang wrote:
> On 04/26/2017 at 03:19 PM, Dave Young wrote:
>> Add ia64i list, and s390 list although Michael has tested it
>>
>> On 04/20/17 at 07:39pm, Xunlei Pang wrote:
>>> As Eric said,
>>> "what we need to do is move the variable vmcoreinfo_note out
>>> of th
On 04/26/2017 at 03:19 PM, Dave Young wrote:
> Add ia64i list, and s390 list although Michael has tested it
>
> On 04/20/17 at 07:39pm, Xunlei Pang wrote:
>> As Eric said,
>> "what we need to do is move the variable vmcoreinfo_note out
>> of the kernel's .bss section. And modify the code to regen
On 04/26/2017 at 03:09 PM, Dave Young wrote:
> On 04/20/17 at 07:39pm, Xunlei Pang wrote:
>> Currently vmcoreinfo data is updated at boot time subsys_initcall(),
>> it has the risk of being modified by some wrong code during system
>> is running.
>>
>> As a result, vmcore dumped may contain the wro
On 04/26/2017 at 04:09 PM, Ingo Molnar wrote:
> * Xunlei Pang wrote:
>
>> The current kernel_ident_mapping_init() creates the identity
>> mapping using 2MB page(PMD level), this patch adds the 1GB
>> page(PUD level) support.
>>
>> This is useful on large machines to save some reserved memory
>> (a
The current kexec_locate_mem_hole(kbuf.top_down == 1) stops searching at
the first memory region that has enough space for requested size even if
some of higher regions may also have.
This behavior is not consistent with locate_hole(hole_end == -1) function
of kexec-tools.
This patch fixes the bug
* Xunlei Pang wrote:
> The current kernel_ident_mapping_init() creates the identity
> mapping using 2MB page(PMD level), this patch adds the 1GB
> page(PUD level) support.
>
> This is useful on large machines to save some reserved memory
> (as paging structures) in the kdump case when kexec set
The current kernel_ident_mapping_init() creates the identity
mapping using 2MB page(PMD level), this patch adds the 1GB
page(PUD level) support.
This is useful on large machines to save some reserved memory
(as paging structures) in the kdump case when kexec setups up
identity mappings before boot
Kexec setups all identity mappings before booting into the new
kernel, and this will cause extra memory consumption for paging
structures which is quite considerable on modern machines with
huge memory.
E.g. On one 32TB machine, in kdump case, it could waste around
128MB (around 4MB/TB) from the r
On 04/26/17 at 03:28pm, Dave Young wrote:
> On 04/26/17 at 08:22am, Ingo Molnar wrote:
> >
> > * Yinghai Lu wrote:
> >
> > > For x86 with recent kernel after
> > > commit 640e1b38b0 ("x86/boot/e820: Basic cleanup of e820.c")
> > > change "reserved" to "Reserved" in /sys firmware memmap and /pro
On 04/26/17 at 08:22am, Ingo Molnar wrote:
>
> * Yinghai Lu wrote:
>
> > For x86 with recent kernel after
> > commit 640e1b38b0 ("x86/boot/e820: Basic cleanup of e820.c")
> > change "reserved" to "Reserved" in /sys firmware memmap and /proc/iomem.
> >
> > So here, we add handling for that too.
Add ia64i list, and s390 list although Michael has tested it
On 04/20/17 at 07:39pm, Xunlei Pang wrote:
> As Eric said,
> "what we need to do is move the variable vmcoreinfo_note out
> of the kernel's .bss section. And modify the code to regenerate
> and keep this information in something like t
Ccing ppc list
On 04/20/17 at 07:39pm, Xunlei Pang wrote:
> vmcoreinfo_max_size stands for the vmcoreinfo_data, the
> correct one we should use is vmcoreinfo_note whose total
> size is VMCOREINFO_NOTE_SIZE.
>
> Like explained in commit 77019967f06b ("kdump: fix exported
> size of vmcoreinfo note")
On 04/20/17 at 07:39pm, Xunlei Pang wrote:
> Currently vmcoreinfo data is updated at boot time subsys_initcall(),
> it has the risk of being modified by some wrong code during system
> is running.
>
> As a result, vmcore dumped may contain the wrong vmcoreinfo. Later on,
> when using "crash", "mak
23 matches
Mail list logo
