[PATCH] makedumpfile: fix free partial_bitmap2 error
Baoquan He
bhe at redhat.com
Sun Apr 27 23:29:21 PDT 2014
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
More information about the kexec
mailing list