linux.git/mm, branch v3.17-rc5

mm/mmap.c: use pr_emerg when printing BUG related information

2014-09-10T22:42:12+00:00

Make sure we actually see the output of validate_mm() and browse_rb()
before triggering a BUG().  pr_info isn't shown by default so the reason
for the BUG() isn't obvious.

Signed-off-by: Sasha Levin 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mem-hotplug: let memblock skip the hotpluggable memory regions in __next_mem_range()

2014-09-10T22:42:12+00:00

Let memblock skip the hotpluggable memory regions in __next_mem_range(),
it is used to to prevent memblock from allocating hotpluggable memory
for the kernel at early time. The code is the same as __next_mem_range_rev().

Clear hotpluggable flag before releasing free pages to the buddy
allocator.  If we don't clear hotpluggable flag in
free_low_memory_core_early(), the memory which marked hotpluggable flag
will not free to buddy allocator.  Because __next_mem_range() will skip
them.

free_low_memory_core_early
	for_each_free_mem_range
		for_each_mem_range
			__next_mem_range

[akpm@linux-foundation.org: fix warning]
Signed-off-by: Xishi Qiu 
Cc: Tejun Heo 
Cc: Tang Chen 
Cc: Zhang Yanfei 
Cc: Wen Congyang 
Cc: "Rafael J. Wysocki" 
Cc: "H. Peter Anvin" 
Cc: Wu Fengguang 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Merge branch 'for-3.17-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu

2014-09-08T03:10:06+00:00

Pull percpu fixes from Tejun Heo:
 "One patch to fix a failure path in the alloc path.  The bug is
  dangerous but probably not too likely to actually trigger in the wild
  given that there hasn't been any report yet.

  The other two are low impact fixes"

* 'for-3.17-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu:
  percpu: free percpu allocation info for uniprocessor system
  percpu: perform tlb flush after pcpu_map_pages() failure
  percpu: fix pcpu_alloc_pages() failure path

mm: memcontrol: revert use of root_mem_cgroup res_counter

2014-09-05T15:19:02+00:00

Dave Hansen reports a massive scalability regression in an uncontained
page fault benchmark with more than 30 concurrent threads, which he
bisected down to 05b843012335 ("mm: memcontrol: use root_mem_cgroup
res_counter") and pin-pointed on res_counter spinlock contention.

That change relied on the per-cpu charge caches to mostly swallow the
res_counter costs, but it's apparent that the caches don't scale yet.

Revert memcg back to bypassing res_counters on the root level in order
to restore performance for uncontained workloads.

Reported-by: Dave Hansen 
Signed-off-by: Johannes Weiner 
Tested-by: Dave Hansen 
Acked-by: Michal Hocko 
Acked-by: Vladimir Davydov 
Signed-off-by: Linus Torvalds

x86,mm: fix pte_special versus pte_numa

2014-08-29T23:28:16+00:00

Sasha Levin has shown oopses on ffffea0003480048 and ffffea0003480008 at
mm/memory.c:1132, running Trinity on different 3.16-rc-next kernels:
where zap_pte_range() checks page->mapping to see if PageAnon(page).

Those addresses fit struct pages for pfns d2001 and d2000, and in each
dump a register or a stack slot showed d2001730 or d2000730: pte flags
0x730 are PCD ACCESSED PROTNONE SPECIAL IOMAP; and Sasha's e820 map has
a hole between cfffffff and 100000000, which would need special access.

Commit c46a7c817e66 ("x86: define _PAGE_NUMA by reusing software bits on
the PMD and PTE levels") has broken vm_normal_page(): a PROTNONE SPECIAL
pte no longer passes the pte_special() test, so zap_pte_range() goes on
to try to access a non-existent struct page.

Fix this by refining pte_special() (SPECIAL with PRESENT or PROTNONE) to
complement pte_numa() (SPECIAL with neither PRESENT nor PROTNONE).  A
hint that this was a problem was that c46a7c817e66 added pte_numa() test
to vm_normal_page(), and moved its is_zero_pfn() test from slow to fast
path: This was papering over a pte_special() snag when the zero page was
encountered during zap.  This patch reverts vm_normal_page() to how it
was before, relying on pte_special().

It still appears that this patch may be incomplete: aren't there other
places which need to be handling PROTNONE along with PRESENT?  For
example, pte_mknuma() clears _PAGE_PRESENT and sets _PAGE_NUMA, but on a
PROT_NONE area, that would make it pte_special().  This is side-stepped
by the fact that NUMA hinting faults skipped PROT_NONE VMAs and there
are no grounds where a NUMA hinting fault on a PROT_NONE VMA would be
interesting.

Fixes: c46a7c817e66 ("x86: define _PAGE_NUMA by reusing software bits on the PMD and PTE levels")
Reported-by: Sasha Levin 
Tested-by: Sasha Levin 
Signed-off-by: Hugh Dickins 
Signed-off-by: Mel Gorman 
Cc: "Kirill A. Shutemov" 
Cc: Peter Zijlstra 
Cc: Rik van Riel 
Cc: Johannes Weiner 
Cc: Cyrill Gorcunov 
Cc: Matthew Wilcox 
Cc: 	[3.16]
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

hugetlb_cgroup: use lockdep_assert_held rather than spin_is_locked

2014-08-29T23:28:16+00:00

spin_lock may be an empty struct for !SMP configurations and so
arch_spin_is_locked may return unconditional 0 and trigger the VM_BUG_ON
even when the lock is held.

Replace spin_is_locked by lockdep_assert_held.  We will not BUG anymore
but it is questionable whether crashing makes a lot of sense in the
uncharge path.  Uncharge happens after the last page reference was
released so nobody should touch the page and the function doesn't update
any shared state except for res counter which uses synchronization of
its own.

Signed-off-by: Michal Hocko 
Reviewed-by: Aneesh Kumar K.V 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm/zpool: use prefixed module loading

2014-08-29T23:28:16+00:00

To avoid potential format string expansion via module parameters, do not
use the zpool type directly in request_module() without a format string.
Additionally, to avoid arbitrary modules being loaded via zpool API
(e.g.  via the zswap_zpool_type module parameter) add a "zpool-" prefix
to the requested module, as well as module aliases for the existing
zpool types (zbud and zsmalloc).

Signed-off-by: Kees Cook 
Cc: Seth Jennings 
Cc: Minchan Kim 
Cc: Nitin Gupta 
Acked-by: Dan Streetman 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm: actually clear pmd_numa before invalidating

2014-08-29T23:28:15+00:00

Commit 67f87463d3a3 ("mm: clear pmd_numa before invalidating") cleared
the NUMA bit in a copy of the PMD entry, but then wrote back the
original

Signed-off-by: Matthew Wilcox 
Acked-by: Mel Gorman 
Reviewed-by: Rik van Riel 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

memblock, memhotplug: fix wrong type in memblock_find_in_range_node().

2014-08-29T23:28:15+00:00

In memblock_find_in_range_node(), we defined ret as int.  But it should
be phys_addr_t because it is used to store the return value from
__memblock_find_range_bottom_up().

The bug has not been triggered because when allocating low memory near
the kernel end, the "int ret" won't turn out to be negative.  When we
started to allocate memory on other nodes, and the "int ret" could be
minus.  Then the kernel will panic.

A simple way to reproduce this: comment out the following code in
numa_init(),

        memblock_set_bottom_up(false);

and the kernel won't boot.

Reported-by: Xishi Qiu 
Signed-off-by: Tang Chen 
Tested-by: Xishi Qiu 
Cc: 	[3.13+]
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

percpu: free percpu allocation info for uniprocessor system

2014-08-16T12:59:02+00:00

Currently, only SMP system free the percpu allocation info.
Uniprocessor system should free it too. For example, one x86 UML
virtual machine with 256MB memory, UML kernel wastes one page memory.

Signed-off-by: Honggang Li 
Signed-off-by: Tejun Heo 
Cc: stable@vger.kernel.org