• Mel Gorman's avatar
    mm, page-allocator: do not check the state of a non-existant buddy during free · b7f50cfa
    Mel Gorman authored
    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: default avatarMel Gorman <mel@csn.ul.ie>
    Cc: Corrado Zoccolo <czoccolo@gmail.com>
    Reported-by: default avatarAlan Curry <pacman@kosh.dhis.org>
    Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Cc: Christoph Lameter <cl@linux-foundation.org>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: <stable@kernel.org>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    b7f50cfa
page_alloc.c 151 KB