litmus-rt.git/mm, branch linux-tip

Merge branch 'slab/urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6

2010-12-06T00:45:02+00:00

* 'slab/urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6:
  slub: Fix a crash during slabinfo -v

slub: Fix a crash during slabinfo -v

2010-12-04T07:53:49+00:00

Commit f7cb1933621bce66a77f690776a16fe3ebbc4d58 ("SLUB: Pass active
and inactive redzone flags instead of boolean to debug functions")
missed two instances of check_object(). This caused a lot of warnings
during 'slabinfo -v' finally leading to a crash:

  BUG ext4_xattr: Freepointer corrupt
  ...
  BUG buffer_head: Freepointer corrupt
  ...
  BUG ext4_alloc_context: Freepointer corrupt
  ...
  ...
  BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
  IP: [] file_sb_list_del+0x1c/0x35
  PGD 79d78067 PUD 79e67067 PMD 0
  Oops: 0002 [#1] SMP
  last sysfs file: /sys/kernel/slab/:t-0000192/validate

This patch fixes the problem by converting the two missed instances.

Acked-by: Christoph Lameter 
Signed-off-by: Tero Roponen 
Signed-off-by: Pekka Enberg

ksm: annotate ksm_thread_mutex is no deadlock source

2010-12-02T22:51:15+00:00

commit 62b61f611e ("ksm: memory hotremove migration only") caused the
following new lockdep warning.

  =======================================================
  [ INFO: possible circular locking dependency detected ]
  -------------------------------------------------------
  bash/1621 is trying to acquire lock:
   ((memory_chain).rwsem){.+.+.+}, at: []
  __blocking_notifier_call_chain+0x69/0xc0

  but task is already holding lock:
   (ksm_thread_mutex){+.+.+.}, at: []
  ksm_memory_callback+0x3a/0xc0

  which lock already depends on the new lock.

  the existing dependency chain (in reverse order) is:

  -> #1 (ksm_thread_mutex){+.+.+.}:
       [] lock_acquire+0xaa/0x140
       [] __mutex_lock_common+0x44/0x3f0
       [] mutex_lock_nested+0x48/0x60
       [] ksm_memory_callback+0x3a/0xc0
       [] notifier_call_chain+0x8c/0xe0
       [] __blocking_notifier_call_chain+0x7e/0xc0
       [] blocking_notifier_call_chain+0x16/0x20
       [] memory_notify+0x1b/0x20
       [] remove_memory+0x1cc/0x5f0
       [] memory_block_change_state+0xfd/0x1a0
       [] store_mem_state+0xe2/0xf0
       [] sysdev_store+0x20/0x30
       [] sysfs_write_file+0xe6/0x170
       [] vfs_write+0xc8/0x190
       [] sys_write+0x54/0x90
       [] system_call_fastpath+0x16/0x1b

  -> #0 ((memory_chain).rwsem){.+.+.+}:
       [] __lock_acquire+0x155a/0x1600
       [] lock_acquire+0xaa/0x140
       [] down_read+0x51/0xa0
       [] __blocking_notifier_call_chain+0x69/0xc0
       [] blocking_notifier_call_chain+0x16/0x20
       [] memory_notify+0x1b/0x20
       [] remove_memory+0x56e/0x5f0
       [] memory_block_change_state+0xfd/0x1a0
       [] store_mem_state+0xe2/0xf0
       [] sysdev_store+0x20/0x30
       [] sysfs_write_file+0xe6/0x170
       [] vfs_write+0xc8/0x190
       [] sys_write+0x54/0x90
       [] system_call_fastpath+0x16/0x1b

But it's a false positive.  Both memory_chain.rwsem and ksm_thread_mutex
have an outer lock (mem_hotplug_mutex).  So they cannot deadlock.

Thus, This patch annotate ksm_thread_mutex is not deadlock source.

[akpm@linux-foundation.org: update comment, from Hugh]
Signed-off-by: KOSAKI Motohiro 
Acked-by: Hugh Dickins 
Cc: Andrea Arcangeli 
Cc: Andi Kleen 
Cc: KAMEZAWA Hiroyuki 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mem-hotplug: introduce {un}lock_memory_hotplug()

2010-12-02T22:51:15+00:00

Presently hwpoison is using lock_system_sleep() to prevent a race with
memory hotplug.  However lock_system_sleep() is a no-op if
CONFIG_HIBERNATION=n.  Therefore we need a new lock.

Signed-off-by: KOSAKI Motohiro 
Cc: Andi Kleen 
Cc: Kamezawa Hiroyuki 
Suggested-by: Hugh Dickins 
Acked-by: Hugh Dickins 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

vmalloc: eagerly clear ptes on vunmap

2010-12-02T22:51:15+00:00

On stock 2.6.37-rc4, running:

  # mount lilith:/export /mnt/lilith
  # find  /mnt/lilith/ -type f -print0 | xargs -0 file

crashes the machine fairly quickly under Xen.  Often it results in oops
messages, but the couple of times I tried just now, it just hung quietly
and made Xen print some rude messages:

    (XEN) mm.c:2389:d80 Bad type (saw 7400000000000001 != exp
    3000000000000000) for mfn 1d7058 (pfn 18fa7)
    (XEN) mm.c:964:d80 Attempt to create linear p.t. with write perms
    (XEN) mm.c:2389:d80 Bad type (saw 7400000000000010 != exp
    1000000000000000) for mfn 1d2e04 (pfn 1d1fb)
    (XEN) mm.c:2965:d80 Error while pinning mfn 1d2e04

Which means the domain tried to map a pagetable page RW, which would
allow it to map arbitrary memory, so Xen stopped it.  This is because
vm_unmap_ram() left some pages mapped in the vmalloc area after NFS had
finished with them, and those pages got recycled as pagetable pages
while still having these RW aliases.

Removing those mappings immediately removes the Xen-visible aliases, and
so it has no problem with those pages being reused as pagetable pages.
Deferring the TLB flush doesn't upset Xen because it can flush the TLB
itself as needed to maintain its invariants.

When unmapping a region in the vmalloc space, clear the ptes
immediately.  There's no point in deferring this because there's no
amortization benefit.

The TLBs are left dirty, and they are flushed lazily to amortize the
cost of the IPIs.

This specific motivation for this patch is an oops-causing regression
since 2.6.36 when using NFS under Xen, triggered by the NFS client's use
of vm_map_ram() introduced in 56e4ebf877b60 ("NFS: readdir with vmapped
pages") .  XFS also uses vm_map_ram() and could cause similar problems.

Signed-off-by: Jeremy Fitzhardinge 
Cc: Nick Piggin 
Cc: Bryan Schumaker 
Cc: Trond Myklebust 
Cc: Alex Elder 
Cc: Dave Chinner 
Cc: Christoph Hellwig 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

vmstat: fix dirty threshold ordering

2010-12-02T22:51:14+00:00

The nr_dirty_[background_]threshold fields are misplaced before the
numa_* fields, and users will read strange values.

This is the right order.  Before patch, nr_dirty_background_threshold
will read as 0 (the value from numa_miss).

	numa_hit 128501
	numa_miss 0
	numa_foreign 0
	numa_interleave 7388
	numa_local 128501
	numa_other 0
	nr_dirty_threshold 144291
	nr_dirty_background_threshold 72145

Signed-off-by: Wu Fengguang 
Cc: Michael Rubin 
Reviewed-by: KOSAKI Motohiro 
Reviewed-by: Minchan Kim 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm/mempolicy.c: add rcu read lock to protect pid structure

2010-12-02T22:51:14+00:00

find_task_by_vpid() should be protected by rcu_read_lock(), to prevent
free_pid() reclaiming pid.

Signed-off-by: Zeng Zhaoming 
Cc: "Paul E. McKenney" 
Cc: KOSAKI Motohiro 
Cc: Christoph Lameter 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm/hugetlb.c: avoid double unlock_page() in hugetlb_fault()

2010-12-02T22:51:14+00:00

Have hugetlb_fault() call unlock_page(page) only if it had previously
called lock_page(page).

Setting CONFIG_DEBUG_VM=y and then running the libhugetlbfs test suite,
resulted in the tripping of VM_BUG_ON(!PageLocked(page)) in
unlock_page() having been called by hugetlb_fault() when page ==
pagecache_page.  This patch remedied the problem.

Signed-off-by: Dean Nelson 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm: remove call to find_vma in pagewalk for non-hugetlbfs

2010-11-24T21:50:46+00:00

Commit d33b9f45 ("mm: hugetlb: fix hugepage memory leak in
walk_page_range()") introduces a check if a vma is a hugetlbfs one and
later in 5dc37642 ("mm hugetlb: add hugepage support to pagemap") it is
moved under #ifdef CONFIG_HUGETLB_PAGE but a needless find_vma call is
left behind and its result is not used anywhere else in the function.

The side-effect of caching vma for @addr inside walk->mm is neither
utilized in walk_page_range() nor in called functions.

Signed-off-by: David Sterba 
Reviewed-by: Naoya Horiguchi 
Acked-by: Andi Kleen 
Cc: Andy Whitcroft 
Cc: David Rientjes 
Cc: Hugh Dickins 
Cc: Lee Schermerhorn 
Cc: Matt Mackall 
Acked-by: Mel Gorman 
Cc: Wu Fengguang 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm/page_alloc.c: fix build_all_zonelist() where percpu_alloc() is wrongly called under stop_machine_run()

2010-11-24T21:50:45+00:00

During memory hotplug, build_allzonelists() may be called under
stop_machine_run().  In this function, setup_zone_pageset() is called.
But it's bug because it will do page allocation under stop_machine_run().

Here is a report from Alok Kataria.

  BUG: sleeping function called from invalid context at kernel/mutex.c:94
  in_atomic(): 0, irqs_disabled(): 1, pid: 4, name: migration/0
  Pid: 4, comm: migration/0 Not tainted 2.6.35.6-45.fc14.x86_64 #1
  Call Trace:
   [] __might_sleep+0xeb/0xf0
   [] mutex_lock+0x24/0x50
   [] pcpu_alloc+0x6d/0x7ee
   [] ? load_balance+0xbe/0x60e
   [] ? rt_se_boosted+0x21/0x2f
   [] ? dequeue_rt_stack+0x18b/0x1ed
   [] __alloc_percpu+0x10/0x12
   [] setup_zone_pageset+0x38/0xbe
   [] ? build_zonelists_node.clone.58+0x79/0x8c
   [] __build_all_zonelists+0x419/0x46c
   [] ? cpu_stopper_thread+0xb2/0x198
   [] stop_machine_cpu_stop+0x8e/0xc5
   [] ? stop_machine_cpu_stop+0x0/0xc5
   [] cpu_stopper_thread+0x108/0x198
   [] ? schedule+0x5b2/0x5cc
   [] ? cpu_stopper_thread+0x0/0x198
   [] kthread+0x7f/0x87
   [] kernel_thread_helper+0x4/0x10
   [] ? kthread+0x0/0x87
   [] ? kernel_thread_helper+0x0/0x10
  Built 5 zonelists in Node order, mobility grouping on.  Total pages: 289456
  Policy zone: Normal

This patch tries to fix the issue by moving setup_zone_pageset() out from
stop_machine_run(). It's obviously not necessary to be called under
stop_machine_run().

[akpm@linux-foundation.org: remove unneeded local]
Reported-by: Alok Kataria 
Signed-off-by: KAMEZAWA Hiroyuki 
Cc: Tejun Heo 
Cc: Petr Vandrovec 
Cc: Pekka Enberg 
Reviewed-by: Christoph Lameter 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds