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 <zzou at redhat.com> > > --- > > 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 at lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/kexec