[PATCH] makedumpfile: change the wrong code to calculate bufsize_cyclic for elf dump
bhe at redhat.com
bhe at redhat.com
Wed Apr 16 22:02:19 PDT 2014
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.
> > 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.
More information about the kexec