makedumpfile: wrong cyclic buffer size recalculation causes bitmap data corruption

Description of Problem:

In cyclic mode, makedumpfile recalculates cyclic buffer size as the
largest multiple of the largest block size managed by buddy
allocator, i.e. 4MB, smaller than the cyclic buffer size in order to
enable to process each unit of blocks managed by buddy allocator in
each cycle.

However, makedumpfile does two wrong things in the recalculations:

1) While updating size of cyclic buffer, makedumpfile doesn't update
length of range of cycle in page frame numbers, due to which, if
cyclic buffer size is updated, because cyclic buffer size is always
reduced during udpate, some buffer overrun can happen on the cyclic
buffer. This can cause segmentation violation in the worst case.

2) roundup() is used to calculate bitmap size for maximum block size
managed by buddy allocator, here divideup() is correct, due to
which, although memory filtering is not affected, cyclic buffer size
get too much aligned and less efficient.

Fix patches has already been posted and merged in makedumpfile
development devel branch.

git://git.code.sf.net/p/makedumpfile/code
f8c8218856effc43ea01cd9394761cfb8aeaa8df
a785fa7dd7a7bd7dcbb017d0bea8848243b0924f

Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: WANG Chao <chaowang@redhat.com>
This commit is contained in:
Baoquan He 2013-10-22 17:07:07 +08:00 committed by WANG Chao
parent 6a56c56743
commit 55c7158d16
3 changed files with 81 additions and 0 deletions

View File

@ -0,0 +1,33 @@
From a785fa7dd7a7bd7dcbb017d0bea8848243b0924f Mon Sep 17 00:00:00 2001
Message-Id: <a785fa7dd7a7bd7dcbb017d0bea8848243b0924f.1382423400.git.bhe@redhat.com>
From: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
Date: Thu, 12 Sep 2013 08:31:28 +0900
Subject: [PATCH 1/2] [PATCH] Update pfn_cyclic when the cyclic buffer size is
corrected.
When the clearing bit operation for excluding free pages can overrun
the cyclic buffer, the buffer size is changed with
check_cyclic_buffer_overrun().
Then pfn_cyclic should be recalculated.
Reviewed-by: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
Signed-off-by: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
---
makedumpfile.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/makedumpfile-1.5.4/makedumpfile.c b/makedumpfile-1.5.4/makedumpfile.c
index 09c0d4a..164b3f1 100644
--- a/makedumpfile-1.5.4/makedumpfile.c
+++ b/makedumpfile-1.5.4/makedumpfile.c
@@ -4091,6 +4091,7 @@ check_cyclic_buffer_overrun(void)
bufsize = info->bufsize_cyclic;
info->bufsize_cyclic = round(bufsize, max_block_size);
+ info->pfn_cyclic = info->bufsize_cyclic * BITPERBYTE;
MSG("cyclic buffer size has been changed: %lu => %lu\n",
bufsize, info->bufsize_cyclic);
--
1.8.3.1

View File

@ -0,0 +1,44 @@
From f8c8218856effc43ea01cd9394761cfb8aeaa8df Mon Sep 17 00:00:00 2001
Message-Id: <f8c8218856effc43ea01cd9394761cfb8aeaa8df.1382423400.git.bhe@redhat.com>
In-Reply-To: <a785fa7dd7a7bd7dcbb017d0bea8848243b0924f.1382423400.git.bhe@redhat.com>
References: <a785fa7dd7a7bd7dcbb017d0bea8848243b0924f.1382423400.git.bhe@redhat.com>
From: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
Date: Thu, 12 Sep 2013 13:19:00 +0900
Subject: [PATCH 2/2] [PATCH] Use divideup() to calculate maximum required
bitmap size.
Currently, check_cyclic_buffer_overrun() wrongly calculates maximum
bitmap size required to represent maximum block size managed by buddy
allocator with roundup(). Then, max_block_size is BITPERBYTE-time
larger than its correct size. As a result, although the bug never
affect free-page filtering since roundup(max_order_nr_pages,
BITPERBYTE) is a multiple of divideup(max_order_nr_pages, BITPERBYTE),
the following sanity check, (max_block_size > info->bufsize_cyclic),
and recalculation of info->bufsize_cyclic becomes BITPERBYTE-time
conservative and inefficient.
Signed-off-by: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
---
makedumpfile.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/makedumpfile-1.5.4/makedumpfile.c b/makedumpfile-1.5.4/makedumpfile.c
index 164b3f1..1718f88 100644
--- a/makedumpfile-1.5.4/makedumpfile.c
+++ b/makedumpfile-1.5.4/makedumpfile.c
@@ -4078,10 +4078,9 @@ check_cyclic_buffer_overrun(void)
{
int max_order = ARRAY_LENGTH(zone.free_area);
int max_order_nr_pages = 1 << (max_order - 1);
- unsigned long max_block_size = roundup(max_order_nr_pages, BITPERBYTE);
+ unsigned long max_block_size = divideup(max_order_nr_pages, BITPERBYTE);
- if (info->bufsize_cyclic %
- roundup(max_order_nr_pages, BITPERBYTE)) {
+ if (info->bufsize_cyclic % max_block_size) {
unsigned long bufsize;
if (max_block_size > info->bufsize_cyclic) {
--
1.8.3.1

View File

@ -83,6 +83,8 @@ Patch601: kexec-tools-2.0.3-disable-kexec-test.patch
Patch604: kexec-tools-2.0.3-build-makedumpfile-eppic-shared-object.patch
Patch605: kexec-tools-2.0.4-makedumpfile-PATCH-Support-newer-kernels.patch
Patch606: kexec-tools-2.0.4-makedumpfile-Fix-max_mapnr-issue-on-system-has-over-44-b.patch
Patch607: kexec-tools-2.0.4-makedumpfile-Update-pfn_cyclic-when-the-cyclic-buffer-size-.patch
Patch608: kexec-tools-2.0.4-makedumpfile-Use-divideup-to-calculate-maximum-required-bit.patch
%description
kexec-tools provides /sbin/kexec binary that facilitates a new
@ -116,6 +118,8 @@ tar -z -x -v -f %{SOURCE19}
%patch604 -p1
%patch605 -p1
%patch606 -p1
%patch607 -p1
%patch608 -p1
%patch001 -p1
%patch002 -p1
%patch003 -p1