55c7158d16
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>
45 lines
1.9 KiB
Diff
45 lines
1.9 KiB
Diff
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
|
|
|