linux-stable.git/mm, branch v3.18.40

mm/hugetlb: avoid soft lockup in set_max_huge_pages()

2016-08-22T16:23:27+00:00

[ Upstream commit 649920c6ab93429b94bc7c1aa7c0e8395351be32 ]

In powerpc servers with large memory(32TB), we watched several soft
lockups for hugepage under stress tests.

The call traces are as follows:
1.
get_page_from_freelist+0x2d8/0xd50
__alloc_pages_nodemask+0x180/0xc20
alloc_fresh_huge_page+0xb0/0x190
set_max_huge_pages+0x164/0x3b0

2.
prep_new_huge_page+0x5c/0x100
alloc_fresh_huge_page+0xc8/0x190
set_max_huge_pages+0x164/0x3b0

This patch fixes such soft lockups.  It is safe to call cond_resched()
there because it is out of spin_lock/unlock section.

Link: http://lkml.kernel.org/r/1469674442-14848-1-git-send-email-hejianet@gmail.com
Signed-off-by: Jia He 
Reviewed-by: Naoya Horiguchi 
Acked-by: Michal Hocko 
Acked-by: Dave Hansen 
Cc: Mike Kravetz 
Cc: "Kirill A. Shutemov" 
Cc: Paul Gortmaker 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

4.1.28 Fix bad backport of 8f182270dfec "mm/swap.c: flush lru pvecs on compound page arrival"

2016-07-20T15:35:52+00:00

When I pulled in 4.1.28 into my stable 4.1-rt tree and ran the tests,
it crashed with a severe OOM killing everything. I then tested 4.1.28
without -rt and it had the same issue. I did a bisect between 4.1.27
and 4.1.28 and found that the bug started at:

commit 8f182270dfec "mm/swap.c: flush lru pvecs on compound page
arrival"

Looking at that patch and what's in mainline, I see that there's a
mismatch in one of the hunks:

Mainline:

@@ -391,9 +391,8 @@ static void __lru_cache_add(struct page *page)
        struct pagevec *pvec = &get_cpu_var(lru_add_pvec);

        get_page(page);
-       if (!pagevec_space(pvec))
+       if (!pagevec_add(pvec, page) || PageCompound(page))
                __pagevec_lru_add(pvec);
-       pagevec_add(pvec, page);
        put_cpu_var(lru_add_pvec);
 }

Stable 4.1.28:

@@ -631,9 +631,8 @@ static void __lru_cache_add(struct page *page)
        struct pagevec *pvec = &get_cpu_var(lru_add_pvec);

        page_cache_get(page);
-       if (!pagevec_space(pvec))
+       if (!pagevec_space(pvec) || PageCompound(page))
                __pagevec_lru_add(pvec);
-       pagevec_add(pvec, page);
        put_cpu_var(lru_add_pvec);
 }

Where mainline replace pagevec_space() with pagevec_add, and stable did
not.

Fixing this makes the OOM go away.

Note, 3.18 has the same bug.

Signed-off-by: Steven Rostedt 
Signed-off-by: Sasha Levin

tmpfs: fix regression hang in fallocate undo

2016-07-12T12:48:38+00:00

[ Upstream commit 7f556567036cb7f89aabe2f0954b08566b4efb53 ]

The well-spotted fallocate undo fix is good in most cases, but not when
fallocate failed on the very first page.  index 0 then passes lend -1
to shmem_undo_range(), and that has two bad effects: (a) that it will
undo every fallocation throughout the file, unrestricted by the current
range; but more importantly (b) it can cause the undo to hang, because
lend -1 is treated as truncation, which makes it keep on retrying until
every page has gone, but those already fully instantiated will never go
away.  Big thank you to xfstests generic/269 which demonstrates this.

Fixes: b9b4bb26af01 ("tmpfs: don't undo fallocate past its last page")
Cc: stable@vger.kernel.org
Signed-off-by: Hugh Dickins 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

mm: fix invalid node in alloc_migrate_target()

2016-07-12T12:47:24+00:00

[ Upstream commit 6f25a14a7053b69917e2ebea0d31dd444cd31fd5 ]

It is incorrect to use next_node to find a target node, it will return
MAX_NUMNODES or invalid node.  This will lead to crash in buddy system
allocation.

Fixes: c8721bbbdd36 ("mm: memory-hotplug: enable memory hotplug to handle hugepage")
Signed-off-by: Xishi Qiu 
Acked-by: Vlastimil Babka 
Acked-by: Naoya Horiguchi 
Cc: Joonsoo Kim 
Cc: David Rientjes 
Cc: "Laura Abbott" 
Cc: Hui Zhu 
Cc: Wang Xiaoqiang 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

mm, compaction: abort free scanner if split fails

2016-07-12T12:47:12+00:00

[ Upstream commit 284f69fb49e2e385203f52441b324b9a68461d6b ]

[ Upstream commit a4f04f2c6955aff5e2c08dcb40aca247ff4d7370 ]

If the memory compaction free scanner cannot successfully split a free
page (only possible due to per-zone low watermark), terminate the free
scanner rather than continuing to scan memory needlessly.  If the
watermark is insufficient for a free page of order <= cc->order, then
terminate the scanner since all future splits will also likely fail.

This prevents the compaction freeing scanner from scanning all memory on
very large zones (very noticeable for zones > 128GB, for instance) when
all splits will likely fail while holding zone->lock.

compaction_alloc() iterating a 128GB zone has been benchmarked to take
over 400ms on some systems whereas any free page isolated and ready to
be split ends up failing in split_free_page() because of the low
watermark check and thus the iteration continues.

The next time compaction occurs, the freeing scanner will likely start
at the end of the zone again since no success was made previously and we
get the same lengthy iteration until the zone is brought above the low
watermark.  All thp page faults can take >400ms in such a state without
this fix.

Link: http://lkml.kernel.org/r/alpine.DEB.2.10.1606211820350.97086@chino.kir.corp.google.com
Signed-off-by: David Rientjes 
Acked-by: Vlastimil Babka 
Cc: Minchan Kim 
Cc: Joonsoo Kim 
Cc: Mel Gorman 
Cc: Hugh Dickins 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

mm, compaction: skip compound pages by order in free scanner

2016-07-12T12:47:12+00:00

[ Upstream commit 683854270f84daa09baffe2b21d64ec88c614fa9 ]

[ Upstream commit 9fcd6d2e052eef525e94a9ae58dbe7ed4df4f5a7 ]

The compaction free scanner is looking for PageBuddy() pages and
skipping all others.  For large compound pages such as THP or hugetlbfs,
we can save a lot of iterations if we skip them at once using their
compound_order().  This is generally unsafe and we can read a bogus
value of order due to a race, but if we are careful, the only danger is
skipping too much.

When tested with stress-highalloc from mmtests on 4GB system with 1GB
hugetlbfs pages, the vmstat compact_free_scanned count decreased by at
least 15%.

Signed-off-by: Vlastimil Babka 
Cc: Minchan Kim 
Cc: Mel Gorman 
Acked-by: Joonsoo Kim 
Acked-by: Michal Nazarewicz 
Cc: Naoya Horiguchi 
Cc: Christoph Lameter 
Cc: Rik van Riel 
Cc: David Rientjes 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

mm/swap.c: flush lru pvecs on compound page arrival

2016-07-12T12:47:11+00:00

[ Upstream commit 8f182270dfec432e93fae14f9208a6b9af01009f ]

Currently we can have compound pages held on per cpu pagevecs, which
leads to a lot of memory unavailable for reclaim when needed.  In the
systems with hundreads of processors it can be GBs of memory.

On of the way of reproducing the problem is to not call munmap
explicitly on all mapped regions (i.e.  after receiving SIGTERM).  After
that some pages (with THP enabled also huge pages) may end up on
lru_add_pvec, example below.

  void main() {
  #pragma omp parallel
  {
	size_t size = 55 * 1000 * 1000; // smaller than  MEM/CPUS
	void *p = mmap(NULL, size, PROT_READ | PROT_WRITE,
		MAP_PRIVATE | MAP_ANONYMOUS , -1, 0);
	if (p != MAP_FAILED)
		memset(p, 0, size);
	//munmap(p, size); // uncomment to make the problem go away
  }
  }

When we run it with THP enabled it will leave significant amount of
memory on lru_add_pvec.  This memory will be not reclaimed if we hit
OOM, so when we run above program in a loop:

	for i in `seq 100`; do ./a.out; done

many processes (95% in my case) will be killed by OOM.

The primary point of the LRU add cache is to save the zone lru_lock
contention with a hope that more pages will belong to the same zone and
so their addition can be batched.  The huge page is already a form of
batched addition (it will add 512 worth of memory in one go) so skipping
the batching seems like a safer option when compared to a potential
excess in the caching which can be quite large and much harder to fix
because lru_add_drain_all is way to expensive and it is not really clear
what would be a good moment to call it.

Similarly we can reproduce the problem on lru_deactivate_pvec by adding:
madvise(p, size, MADV_FREE); after memset.

This patch flushes lru pvecs on compound page arrival making the problem
less severe - after applying it kill rate of above example drops to 0%,
due to reducing maximum amount of memory held on pvec from 28MB (with
THP) to 56kB per CPU.

Suggested-by: Michal Hocko 
Link: http://lkml.kernel.org/r/1466180198-18854-1-git-send-email-lukasz.odzioba@intel.com
Signed-off-by: Lukasz Odzioba 
Acked-by: Michal Hocko 
Cc: Kirill Shutemov 
Cc: Andrea Arcangeli 
Cc: Vladimir Davydov 
Cc: Ming Li 
Cc: Minchan Kim 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

mm: rename deactivate_page to deactivate_file_page

2016-07-12T12:47:10+00:00

[ Upstream commit cc5993bd7b8cff4a3e37042ee1358d1d5eafa70c ]

"deactivate_page" was created for file invalidation so it has too
specific logic for file-backed pages.  So, let's change the name of the
function and date to a file-specific one and yield the generic name.

Signed-off-by: Minchan Kim 
Cc: Michal Hocko 
Cc: Johannes Weiner 
Cc: Mel Gorman 
Cc: Rik van Riel 
Cc: Shaohua Li 
Cc: Wang, Yalin 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

tmpfs: don't undo fallocate past its last page

2016-07-12T12:47:10+00:00

[ Upstream commit b9b4bb26af017dbe930cd4df7f9b2fc3a0497bfe ]

When fallocate is interrupted it will undo a range that extends one byte
past its range of allocated pages.  This can corrupt an in-use page by
zeroing out its first byte.  Instead, undo using the inclusive byte
range.

Fixes: 1635f6a74152f1d ("tmpfs: undo fallocation on failure")
Link: http://lkml.kernel.org/r/1462713387-16724-1-git-send-email-anthony.romano@coreos.com
Signed-off-by: Anthony Romano 
Cc: Vlastimil Babka 
Cc: Hugh Dickins 
Cc: Brandon Philips 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

mm: Export migrate_page_move_mapping and migrate_page_copy

2016-07-12T12:47:00+00:00

[ Upstream commit 1118dce773d84f39ebd51a9fe7261f9169cb056e ]

Export these symbols such that UBIFS can implement
->migratepage.

Cc: stable@vger.kernel.org
Signed-off-by: Richard Weinberger 
Acked-by: Christoph Hellwig 
Signed-off-by: Sasha Levin