• Dave Hansen's avatar
    x86-32, mm: Rip out x86_32 NUMA remapping code · f03574f2
    Dave Hansen authored
    This code was an optimization for 32-bit NUMA systems.
    
    It has probably been the cause of a number of subtle bugs over
    the years, although the conditions to excite them would have
    been hard to trigger.  Essentially, we remap part of the kernel
    linear mapping area, and then sometimes part of that area gets
    freed back in to the bootmem allocator.  If those pages get
    used by kernel data structures (say mem_map[] or a dentry),
    there's no big deal.  But, if anyone ever tried to use the
    linear mapping for these pages _and_ cared about their physical
    address, bad things happen.
    
    For instance, say you passed __GFP_ZERO to the page allocator
    and then happened to get handed one of these pages, it zero the
    remapped page, but it would make a pte to the _old_ page.
    There are probably a hundred other ways that it could screw
    with things.
    
    We don't need to hang on to performance optimizations for
    these old boxes any more.  All my 32-bit NUMA systems are long
    dead and buried, and I probably had access to more than most
    people.
    
    This code is causing real things to break today:
    
    	https://lkml.org/lkml/2013/1/9/376
    
    I looked in to actually fixing this, but it requires surgery
    to way too much brittle code, as well as stuff like
    per_cpu_ptr_to_phys().
    
    [ hpa: Cc: this for -stable, since it is a memory corruption issue.
      However, an alternative is to simply mark NUMA as depends BROKEN
      rather than EXPERIMENTAL in the X86_32 subclause... ]
    
    Link: http://lkml.kernel.org/r/20130131005616.1C79F411@kernel.stglabs.ibm.comSigned-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
    Cc: <stable@vger.kernel.org>
    f03574f2
numa_32.c 3.2 KB