[PATCH] makedumpfile: Fix a bug found during regression testing for v1.5.6

Petr Tesarik ptesarik at suse.cz
Thu Apr 17 01:48:19 PDT 2014

On Thu, 17 Apr 2014 08:33:19 +0000
Atsushi Kumagai <kumagai-atsushi at mxc.nes.nec.co.jp> wrote:

> >> From: Atsushi Kumagai <kumagai-atsushi at mxc.nes.nec.co.jp>
> >> Date: Wed, 16 Apr 2014 14:56:01 +0900
> >> Subject: [PATCH] Exclude small cycle regions wrongly.
> >>
> >> In bitmap initialization, if a cycle region is smaller than 8 pages
> >> and its start_pfn is aligned to multiple of 8 pages, it will be
> >> excluded wrongly.
> >>
> >>   Example case:
> >>     pfn_start=0x103ff80, pfn_start_roundup=0x103ff80
> >>     pfn_end=0x103ff84, pfn_end_round=0x103ff80
> >>
> >> This case doesn't meet any conditions to set bits in
> >> create_1st_bitmap_cyclic() and initialize_2nd_bitmap_cyclic().
> >> We should admit the case where pfn_start is equal to pfn_end_round
> >> like above.
> >
> >Hello Kumagai-san,
> >
> >FWIW I cleaned up these bit operations in makedumpfile, completely
> >removing this code and instead adding functions for efficient setting
> >and clearing of a range of bits in a bitmap:
> >
> >set_bits(char *buf, size_t start, size_t end);
> >clear_bits(char *buf, size_t start, size_t end);
> >
> >The whole branch is still sitting on my disk, because I based it on
> >my other patch series (generic handling of multi-page exclusions), and
> >there were quite some conflicts when I tried to rebase it on devel.
> >
> >But if you include it in v1.5.6, I will do the rebase nevertheless,
> >so it doesn't have to wait for your decision about the other series.
> >
> >Can we do it that way?
> Yes. If you can rebase your local branch on the current devel branch,
> reviewing them for v1.5.7 will go on smoothly.

Hm, I'm not sure I know what to do. So, let me make a summary of my
local makedumpfile branches:

1. pfn_t: introduce the mdf_pfn_t type
2. cycle_align: make cycle alignment unnecessary
3. bitmap_ops: helpers to set/clear range of bits (not yet sent)
4. hugepage: handling of compound pages (not yet sent)

Most branches are independent, (except hugepage depends on
cycle_align), but since they often change the same lines of code, I
must send them in some order, or they won't apply cleanly.

Now, do I understand you correctly that you want me to postpone all of
them _AFTER_ v1.5.6 is released?

Petr T

More information about the kexec mailing list