tree 1a74746444c0dd50b9dfe3e90a64c90202020bb0
parent 155b89771a1d9172c77b2ff3f2a30ce7f38d3de8
author Laura Abbott <lauraa@codeaurora.org> 1394069842 -0800
committer Laura Abbott <lauraa@codeaurora.org> 1394671773 -0700

mm/compaction: Break out of loop on !PageBuddy in isolate_freepages_block

We received several reports of bad page state when freeing CMA pages
previously allocated with alloc_contig_range:

 BUG: Bad page state in process Binder_A  pfn:63202
 page:d21130b0 count:0 mapcount:1 mapping:  (null) index:0x7dfbf
 page flags: 0x40080068(uptodate|lru|active|swapbacked)

Based on the page state, it looks like the page was still in use. The page
flags do not make sense for the use case though. Further debugging showed
that despite alloc_contig_range returning success, at least one page in the
range still remained in the buddy allocator.

There is an issue with isolate_freepages_block. In strict mode (which CMA
uses), if any pages in the range cannot be isolated,
isolate_freepages_block should return failure 0. The current check keeps
track of the total number of isolated pages and compares against the size
of the range:

        if (strict && nr_strict_required > total_isolated)
                total_isolated = 0;

After taking the zone lock, if one of the pages in the range is not
in the buddy allocator, we continue through the loop and do not
increment total_isolated. If in the last iteration of the loop we isolate
more than one page (e.g. last page needed is a higher order page), the
check for total_isolated may pass and we fail to detect that a page was
skipped. The fix is to bail out if the loop immediately if we are in
strict mode. There's no benfit to continuing anyway since we need all
pages to be isolated. Additionally, drop the error checking based on
nr_strict_required and just check the pfn ranges. This matches with
what isolate_freepages_range does.

Change-Id: I2a8bc4d381ae35aa15a4d2a2424f0c2de801d9ba
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>