[PATCH] makedumpfile: fix free partial_bitmap2 error

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux