Re: [PATCH v3 1/2] Generic handling of multi-page exclusions

[Petr Tesarik <ptesarik@suse.cz>]

On Fri, 16 May 2014 07:24:02 +0000
Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp> wrote:

> >On Wed, 14 May 2014 19:54:28 +0900 (JST)
> >HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> wrote:
> >
> >> From: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
> >> Subject: Re: [PATCH v3 1/2] Generic handling of multi-page exclusions
> >> Date: Wed, 14 May 2014 19:37:23 +0900
> >>
> >> > From: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
> >> > Subject: RE: [PATCH v3 1/2] Generic handling of multi-page exclusions
> >> > Date: Wed, 14 May 2014 07:54:17 +0000
> >> >
> >> >> Hello Petr,
> >> >>
> >> >>>When multiple pages are excluded from the dump, store the extents in
> >> >>>struct cycle and check if anything is still pending on the next invocation
> >> >>>of __exclude_unnecessary_pages. This assumes that:
> >> >>>
> >> >>>  1. after __exclude_unnecessary_pages is called for a struct mem_map_data
> >> >>>     that extends beyond the current cycle, it is not called again during
> >> >>>     that cycle,
> >> >>>  2. in the next cycle, __exclude_unnecessary_pages is not called before
> >> >>>     this final struct mem_map_data.
> >> >>>
> >> >>>Both assumptions are met if struct mem_map_data segments:
> >> >>>
> >> >>>  1. do not overlap,
> >> >>>  2. are sorted by physical address in ascending order.
> >> >>
> >> >> In ELF case, write_elf_pages_cyclic() processes PT_LOAD entries from
> >> >> PT_LOAD(0), this can break both assumptions unluckily.
>[...]
> 
> I thought it's better to keep the original PT_LOAD list at first, but the
> current code can split it already. So I think we shouldn't worry about
> modification to PT_LOAD entries now.
> If crash doesn't use virt_start and virt_end too, your idea sounds good to me.

I'm not sure how to continue here.

First, crash does not use virt_start and virt_end from the ELF headers.
It uses the same algorithm as makedumpfile to convert virtual addresses
to physical addresses (in fact, I believe makedumpfile initially copied
the code from crash).

Second, I understand that this change has a high risk of introducing
regressions, so I would rather keep the well-tested code path. It is,
of course, possible to fix the multi-page exclusions in ELF files.

Let me explain:

Every PT_LOAD segment behaves as an isolated run through this portion
of physical RAM. I mean, makedumpfile has never coped with page
exclusions that start in one segment and continue in another segment.
So, if we accept this limitation, then exclude_pfn_start and
exclude_pfn_end can be reset in each iteration of the PT_LOAD main
cycle. This adds only two lines to my previous patch.

Petr T

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec