[PATCH] makedumpfile: change the wrong code to calculate bufsize_cyclic for elf dump

[bhe at redhat.com]

On 04/17/14 at 12:52pm, Baoquan He wrote:
> On 04/17/14 at 04:01am, Atsushi Kumagai wrote:
> > Hello Baoquan,
> > 
> > >Hi Atsushi,
> > >
> > >I have got the test machine where bug reported and did a test. The
> > >changed code can make elf dump successful.
> > 
> > Great, thanks for your help!
> > However, I still have questions.
> > 
> > First, what is the difference between yours and mine?
> > 
> > http://lists.infradead.org/pipermail/kexec/2014-April/011535.html
> 
> Yeah, you are right, it's the same on changing the code bug. I mush
> haven't read your patch carefully. 
                                                          must<--
> 
> > 
> > My patch includes renaming some values, but the purpose looks
> > the same as yours.
> > Further, you described as below, 
> > 
> > >On 04/14/14 at 04:02pm, Baoquan He wrote:
> > but I still don't think this bug causes OOM.
> > Even if needed_size is calculated as so much size wrongly, bufsize_cyclic
> > will not exceed 40% of free memory by the check below:
> > 
> >     info->bufsize_cyclic = (free_size <= needed_size) ? free_size : needed_size;
> > 
> > So it looks that bitmap1(40%) and bitmap2(40%) will fit in 80% of free
> > memory in any case.
> > 
> > I may misunderstand something since your patch has an effect on this
> > issue in practice, could you correct me?
> 
> It definitely will cause OOM. On my test machine, it has 100G memory. So
> per old code, its needed_size is 3200K*2 == 6.4M, if currently free
> memory is only 15M left, the free_size will be 15M*0.4 which is 6M. So
> info->bufsize_cyclic is assigned to be 6M. and only 3M is left for other
> use, e.g page cache, dynamic allocation. OOM will happen.
> 

BTW, in our case, there's about 30M free memory when we started saving
dump. It should be caused by my coarse estimation above.