From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mx1.redhat.com ([209.132.183.28]) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1WefLW-000544-2B for kexec@lists.infradead.org; Mon, 28 Apr 2014 06:47:22 +0000 Date: Mon, 28 Apr 2014 14:29:21 +0800 From: Baoquan He Subject: Re: [PATCH] makedumpfile: fix free partial_bitmap2 error Message-ID: <20140428062921.GC1625@dhcp-16-105.nay.redhat.com> References: <1398390182-8480-1-git-send-email-zzou@redhat.com> <20140428062146.GB1625@dhcp-16-105.nay.redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20140428062146.GB1625@dhcp-16-105.nay.redhat.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: Arthur Zou Cc: kumagai-atsushi@mxc.nes.nec.co.jp, kexec@lists.infradead.org On 04/28/14 at 02:21pm, Baoquan He wrote: > On 04/25/14 at 09:43am, Arthur Zou wrote: > > Description: > > In create_dump_bitmap, after prepare_bitmap2_buffer_cyclic was invoked, > > info->partial_bitmap2 will pointed to a block of contiguous memory. But > > free it in a wrong way because what free_bitmap2_buffer() free is > > info->bitmap2 not info->partial_bitmap2. > > > > Signed-off-by: Arthur Zou > > --- > > makedumpfile.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/makedumpfile.c b/makedumpfile.c > > index ce4a866..f0d2997 100644 > > --- a/makedumpfile.c > > +++ b/makedumpfile.c > > @@ -5143,7 +5143,8 @@ create_dump_bitmap(void) > > > > info->num_dumpable = get_num_dumpable_cyclic(); > > > > - free_bitmap2_buffer(); > > + if (info->partial_bitmap2 != NULL) > > + free(info->partial_bitmap2); > > ACK > > Hi Atsushi, > > Maybe in my case which the lzo dump random failure triggered by this > one. Because for elf dump, since the wrong calculation of > cyclic_bufsize is corrected, OOM never happened. For this bug, it didn't > happen either after the fix applied in this patch. > Well, I was wrong. It can't prove 80% of free memory is a safe value, espeically for my case. Please ignore below paragraph, it's not clear in my head. > So I guess the 80% of free memory is a safe value, though it's very > close to the OOM threshold. > > Thanks > Baoquan > > > > } > > > > } else { > > -- > > 1.8.4.2 > > > > > > _______________________________________________ > > kexec mailing list > > kexec@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/kexec _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec