linux.git/mm/page_alloc.c, branch v2.6.37

PM / Hibernate: Fix memory corruption related to swap

2010-12-06T22:52:08+00:00

There is a problem that swap pages allocated before the creation of
a hibernation image can be released and used for storing the contents
of different memory pages while the image is being saved.  Since the
kernel stored in the image doesn't know of that, it causes memory
corruption to occur after resume from hibernation, especially on
systems with relatively small RAM that need to swap often.

This issue can be addressed by keeping the GFP_IOFS bits clear
in gfp_allowed_mask during the entire hibernation, including the
saving of the image, until the system is finally turned off or
the hibernation is aborted.  Unfortunately, for this purpose
it's necessary to rework the way in which the hibernate and
suspend code manipulates gfp_allowed_mask.

This change is based on an earlier patch from Hugh Dickins.

Signed-off-by: Rafael J. Wysocki 
Reported-by: Ondrej Zary 
Acked-by: Hugh Dickins 
Reviewed-by: KAMEZAWA Hiroyuki 
Cc: stable@kernel.org

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

mm: add casts to/from gfp_t in gfp_to_alloc_flags()

2010-10-26T23:52:09+00:00

This removes following warning from sparse:

 mm/page_alloc.c:1934:9: warning: restricted gfp_t degrades to integer

Signed-off-by: Namhyung Kim 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

writeback: do not sleep on the congestion queue if there are no congested BDIs or if significant congestion is not being encountered in the current zone

2010-10-26T23:52:07+00:00

If congestion_wait() is called with no BDI congested, the caller will
sleep for the full timeout and this may be an unnecessary sleep.  This
patch adds a wait_iff_congested() that checks congestion and only sleeps
if a BDI is congested else, it calls cond_resched() to ensure the caller
is not hogging the CPU longer than its quota but otherwise will not sleep.

This is aimed at reducing some of the major desktop stalls reported during
IO.  For example, while kswapd is operating, it calls congestion_wait()
but it could just have been reclaiming clean page cache pages with no
congestion.  Without this patch, it would sleep for a full timeout but
after this patch, it'll just call schedule() if it has been on the CPU too
long.  Similar logic applies to direct reclaimers that are not making
enough progress.

Signed-off-by: Mel Gorman 
Cc: Johannes Weiner 
Cc: Minchan Kim 
Cc: Wu Fengguang 
Cc: KAMEZAWA Hiroyuki 
Cc: KOSAKI Motohiro 
Cc: Rik van Riel 
Cc: Jens Axboe 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

memory hotplug: unify is_removable and offline detection code

2010-10-26T23:52:06+00:00

Now, sysfs interface of memory hotplug shows whether the section is
removable or not.  But it checks only migrateype of pages and doesn't
check details of cluster of pages.

Next, memory hotplug's set_migratetype_isolate() has the same kind of
check, too.

This patch adds the function __count_unmovable_pages() and makes above 2
checks to use the same logic.  Then, is_removable and hotremove code uses
the same logic.  No changes in the hotremove logic itself.

TODO: need to find a way to check RECLAMABLE. But, considering bit,
      calling shrink_slab() against a range before starting memory hotremove
      sounds better. If so, this patch's logic doesn't need to be changed.

[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: KAMEZAWA Hiroyuki 
Reported-by: Michal Hocko 
Cc: Wu Fengguang 
Cc: Mel Gorman 
Cc: KAMEZAWA Hiroyuki 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

memory hotplug: fix notifier's return value check

2010-10-26T23:52:06+00:00

Even if notifier cannot find any pages, it doesn't mean no pages are
available...And, if there are no notifiers registered, this condition will
be always true and memory hotplug will show -EBUSY.

This is a bug but not critical.

In most case, a pageblock which will be offlined is MIGRATE_MOVABLE This
"notifier" is called only when the pageblock is _not_ MIGRATE_MOVABLE.
But if not MIGRATE_MOVABLE, it's common case that memory hotplug will
fail.  So, no one notice this bug.

Signed-off-by: KAMEZAWA Hiroyuki 
Cc: Michal Hocko 
Cc: Wu Fengguang 
Cc: Mel Gorman 
Cc: KAMEZAWA Hiroyuki 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm, page-allocator: do not check the state of a non-existant buddy during free

2010-10-26T23:52:03+00:00

There is a bug in commit 6dda9d55 ("page allocator: reduce fragmentation
in buddy allocator by adding buddies that are merging to the tail of the
free lists") that means a buddy at order MAX_ORDER is checked for merging.
 A page of this order never exists so at times, an effectively random
piece of memory is being checked.

Alan Curry has reported that this is causing memory corruption in
userspace data on a PPC32 platform (http://lkml.org/lkml/2010/10/9/32).
It is not clear why this is happening.  It could be a cache coherency
problem where pages mapped in both user and kernel space are getting
different cache lines due to the bad read from kernel space
(http://lkml.org/lkml/2010/10/13/179).  It could also be that there are
some special registers being io-remapped at the end of the memmap array
and that a read has special meaning on them.  Compiler bugs have been
ruled out because the assembly before and after the patch looks relatively
harmless.

This patch fixes the problem by ensuring we are not reading a possibly
invalid location of memory.  It's not clear why the read causes corruption
but one way or the other it is a buggy read.

Signed-off-by: Mel Gorman 
Cc: Corrado Zoccolo 
Reported-by: Alan Curry 
Cc: KOSAKI Motohiro 
Cc: Christoph Lameter 
Cc: Rik van Riel 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Merge branch 'x86/urgent' into core/memblock

2010-10-12T00:05:11+00:00

Reason for merge:

Forward-port urgent change to arch/x86/mm/srat_64.c to the memblock tree.

Resolved Conflicts:
	arch/x86/mm/srat_64.c

Originally-by: Yinghai Lu 
Signed-off-by: H. Peter Anvin

Merge commit 'v2.6.36-rc7' into core/memblock

2010-10-08T07:15:00+00:00

Merge reason: Update from -rc3 to -rc7.

Signed-off-by: Ingo Molnar

mm: alloc_large_system_hash() printk overflow on 16TB boot

2010-10-07T20:31:21+00:00

During boot of a 16TB system, the following is printed:
Dentry cache hash table entries: -2147483648 (order: 22, 17179869184 bytes)

Signed-off-by: Robin Holt 
Reviewed-by: WANG Cong 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds