1. 09 12月, 2011 8 次提交
    • T
      memblock: Make memblock functions handle overflowing range @size · eb18f1b5
      Tejun Heo 提交于
      Allow memblock users to specify range where @base + @size overflows
      and automatically cap it at maximum.  This makes the interface more
      robust and specifying till-the-end-of-memory easier.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      eb18f1b5
    • T
      memblock: Reimplement __memblock_remove() using memblock_isolate_range() · 71936180
      Tejun Heo 提交于
      __memblock_remove()'s open coded region manipulation can be trivially
      replaced with memblock_islate_range().  This increases code sharing
      and eases improving region tracking.
      
      This pulls memblock_isolate_range() out of HAVE_MEMBLOCK_NODE_MAP.
      Make it use memblock_get_region_node() instead of assuming rgn->nid is
      available.
      
      -v2: Fixed build failure on !HAVE_MEMBLOCK_NODE_MAP caused by direct
           rgn->nid access.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      71936180
    • T
      memblock: Separate out memblock_isolate_range() from memblock_set_node() · 6a9ceb31
      Tejun Heo 提交于
      memblock_set_node() operates in three steps - break regions crossing
      boundaries, set nid and merge back regions.  This patch separates the
      first part into a separate function - memblock_isolate_range(), which
      breaks regions crossing range boundaries and returns range index range
      for regions properly contained in the specified memory range.
      
      This doesn't introduce any behavior change and will be used to further
      unify region handling.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      6a9ceb31
    • T
      memblock: Kill memblock_init() · fe091c20
      Tejun Heo 提交于
      memblock_init() initializes arrays for regions and memblock itself;
      however, all these can be done with struct initializers and
      memblock_init() can be removed.  This patch kills memblock_init() and
      initializes memblock with struct initializer.
      
      The only difference is that the first dummy entries don't have .nid
      set to MAX_NUMNODES initially.  This doesn't cause any behavior
      difference.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      fe091c20
    • T
      memblock: Kill sentinel entries at the end of static region arrays · c5a1cb28
      Tejun Heo 提交于
      memblock no longer depends on having one more entry at the end during
      addition making the sentinel entries at the end of region arrays not
      too useful.  Remove the sentinels.  This eases further updates.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      c5a1cb28
    • T
      memblock: Add __memblock_dump_all() · 4ff7b82f
      Tejun Heo 提交于
      Add __memblock_dump_all() which dumps memblock configuration whether
      memblock_debug is enabled or not.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      4ff7b82f
    • T
      memblock: Use memblock_reserve() in memblock internal functions · 9c8c27e2
      Tejun Heo 提交于
      Make memblock_double_array(), __memblock_alloc_base() and
      memblock_alloc_nid() use memblock_reserve() instead of calling
      memblock_add_region() with reserved array directly.  This eases
      debugging and updates to memblock_add_region().
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      9c8c27e2
    • T
      memblock: Make memblock_{add|remove|free|reserve}() return int and update prototypes · 581adcbe
      Tejun Heo 提交于
      memblock_{add|remove|free|reserve}() return either 0 or -errno but had
      long as return type.  Chage it to int.  Also, drop 'extern' from all
      prototypes in memblock.h - they are unnecessary and used
      inconsistently (especially if mm.h is included in the picture).
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      581adcbe
  2. 01 11月, 2011 3 次提交
  3. 26 7月, 2011 1 次提交
  4. 15 7月, 2011 11 次提交
  5. 14 7月, 2011 4 次提交
  6. 23 3月, 2011 1 次提交
    • B
      mm/memblock: properly handle overlaps and fix error path · 8f7a6605
      Benjamin Herrenschmidt 提交于
      Currently memblock_reserve() or memblock_free() don't handle overlaps of
      any kind.  There is some special casing for coalescing exactly adjacent
      regions but that's about it.
      
      This is annoying because typically memblock_reserve() is used to mark
      regions passed by the firmware as reserved and we all know how much we can
      trust our firmwares...
      
      Also, with the current code, if we do something it doesn't handle right
      such as trying to memblock_reserve() a large range spanning multiple
      existing smaller reserved regions for example, or doing overlapping
      reservations, it can silently corrupt the internal region array, causing
      odd errors much later on, such as allocations returning reserved regions
      etc...
      
      This patch rewrites the underlying functions that add or remove a region
      to the arrays.  The new code is a lot more robust as it fully handles
      overlapping regions.  It's also, imho, simpler than the previous
      implementation.
      
      In addition, while doing so, I found a bug where if we fail to double the
      array while adding a region, we would remove the last region of the array
      rather than the region we just allocated.  This fixes it too.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8f7a6605
  7. 12 2月, 2011 1 次提交
    • Y
      memblock: don't adjust size in memblock_find_base() · e6d2e2b2
      Yinghai Lu 提交于
      While applying patch to use memblock to find aperture for 64bit x86.
      Ingo found system with 1g + force_iommu
      
      > No AGP bridge found
      > Node 0: aperture @ 38000000 size 32 MB
      > Aperture pointing to e820 RAM. Ignoring.
      > Your BIOS doesn't leave a aperture memory hole
      > Please enable the IOMMU option in the BIOS setup
      > This costs you 64 MB of RAM
      > Cannot allocate aperture memory hole (0,65536K)
      
      the corresponding code:
      
      	addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<20);
      	if (addr == MEMBLOCK_ERROR || addr + aper_size > 0xffffffff) {
      		printk(KERN_ERR
      			"Cannot allocate aperture memory hole (%lx,%uK)\n",
      				addr, aper_size>>10);
      		return 0;
      	}
      	memblock_x86_reserve_range(addr, addr + aper_size, "aperture64")
      
      fails because memblock core code align the size with 512M.  That could
      make size way too big.
      
      So don't align the size in that case.
      
      actually __memblock_alloc_base, the another caller already align that
      before calling that function.
      
      BTW. x86 does not use __memblock_alloc_base...
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: David Miller <davem@davemloft.net>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Dave Airlie <airlied@linux.ie>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e6d2e2b2
  8. 21 1月, 2011 1 次提交
  9. 12 10月, 2010 2 次提交
  10. 06 10月, 2010 1 次提交
    • Y
      memblock: Fix wraparound in find_region() · f1af98c7
      Yinghai Lu 提交于
      When trying to find huge range for crashkernel, get
      
      [    0.000000] ------------[ cut here ]------------
      [    0.000000] WARNING: at arch/x86/mm/memblock.c:248 memblock_x86_reserve_range+0x40/0x7a()
      [    0.000000] Hardware name: Sun Fire x4800
      [    0.000000] memblock_x86_reserve_range: wrong range [0xffffffff37000000, 0x137000000)
      [    0.000000] Modules linked in:
      [    0.000000] Pid: 0, comm: swapper Not tainted 2.6.36-rc5-tip-yh-01876-g1cac214-dirty #59
      [    0.000000] Call Trace:
      [    0.000000]  [<ffffffff82816f7e>] ? memblock_x86_reserve_range+0x40/0x7a
      [    0.000000]  [<ffffffff81078c2d>] warn_slowpath_common+0x85/0x9e
      [    0.000000]  [<ffffffff81078d38>] warn_slowpath_fmt+0x6e/0x70
      [    0.000000]  [<ffffffff8281e77c>] ? memblock_find_region+0x40/0x78
      [    0.000000]  [<ffffffff8281eb1f>] ? memblock_find_base+0x9a/0xb9
      [    0.000000]  [<ffffffff82816f7e>] memblock_x86_reserve_range+0x40/0x7a
      [    0.000000]  [<ffffffff8280452c>] setup_arch+0x99d/0xb2a
      [    0.000000]  [<ffffffff810a3e02>] ? trace_hardirqs_off+0xd/0xf
      [    0.000000]  [<ffffffff81cec7d8>] ? _raw_spin_unlock_irqrestore+0x3d/0x4c
      [    0.000000]  [<ffffffff827ffcec>] start_kernel+0xde/0x3f1
      [    0.000000]  [<ffffffff827ff2d4>] x86_64_start_reservations+0xa0/0xa4
      [    0.000000]  [<ffffffff827ff3de>] x86_64_start_kernel+0x106/0x10d
      [    0.000000] ---[ end trace a7919e7f17c0a725 ]---
      [    0.000000] Reserving 8192MB of memory at 17592186041200MB for crashkernel (System RAM: 526336MB)
      
      This is caused by a wraparound in the test due to size > end;
      explicitly check for this condition and fail.
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      LKML-Reference: <4CAA4DD3.1080401@kernel.org>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      f1af98c7
  11. 16 9月, 2010 1 次提交
  12. 28 8月, 2010 1 次提交
  13. 09 8月, 2010 1 次提交
  14. 05 8月, 2010 4 次提交