1. 12 10月, 2010 1 次提交
  2. 08 10月, 2010 2 次提交
  3. 07 10月, 2010 5 次提交
  4. 06 10月, 2010 9 次提交
    • Y
      x86, memblock: Remove __memblock_x86_find_in_range_size() · 16c36f74
      Yinghai Lu 提交于
      Fold it into memblock_x86_find_in_range(), and change bad_addr_size()
      to check_reserve_memblock().
      
      So whole memblock_x86_find_in_range_size() code is more readable.
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      LKML-Reference: <4CAA4DEC.4000401@kernel.org>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      16c36f74
    • 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
    • Y
      x86-32, memblock: Make add_highpages honor early reserved ranges · 1d931264
      Yinghai Lu 提交于
      Originally the only early reserved range that is overlapped with high
      pages is "KVA RAM", but we already do remove that from the active ranges.
      
      However, It turns out Xen could have that kind of overlapping to support memory
      ballooning.x
      
      So we need to make add_highpage_with_active_regions() to subtract
      memblock reserved just like low ram; this is the proper design anyway.
      
      In this patch, refactering get_freel_all_memory_range() to make it can
      be used by add_highpage_with_active_regions().  Also we don't need to
      remove "KVA RAM" from active ranges.
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      LKML-Reference: <4CABB183.1040607@kernel.org>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      1d931264
    • Y
      x86, memblock: Fix crashkernel allocation · 9f4c1396
      Yinghai Lu 提交于
      Cai Qian found crashkernel is broken with the x86 memblock changes.
      
      1. crashkernel=128M@32M always reported that range is used, even if
         the first kernel is small and does not usethat range
      
      2. we always got following report when using "kexec -p"
      	Could not find a free area of memory of a000 bytes...
      	locate_hole failed
      
      The root cause is that generic memblock_find_in_range() will try to
      allocate from the top of the range, whereas the kexec code was written
      assuming that allocation was always near the bottom and that it could
      blindly extend memory upward.  Unfortunately the kexec code doesn't
      have a system for requesting the range that it really needs, so this
      is subject to probabilistic failures.
      
      This patch hacks around the problem by limiting the target range
      heuristically to below the traditional bzImage max range.  This number
      is arbitrary and not always correct, and a much better result would be
      obtained by having kexec communicate this number based on the kernel
      header information and any appropriate command line options.
      Reported-and-Bisected-by: NCAI Qian <caiqian@redhat.com>
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      LKML-Reference: <4CABAF2A.5090501@kernel.org>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      9f4c1396
    • S
      powerpc: remove unused variable · 7c6d45e6
      Stephen Rothwell 提交于
      Since powerpc uses -Werror on arch powerpc, the build was broken like
      this:
      
        cc1: warnings being treated as errors
        arch/powerpc/kernel/module.c: In function 'module_finalize':
        arch/powerpc/kernel/module.c:66: error: unused variable 'err'
      Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7c6d45e6
    • L
      Merge branch 'core-fixes-for-linus' of... · e1d9694c
      Linus Torvalds 提交于
      Merge branch 'core-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
      
      * 'core-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
        rcu: rcu_read_lock_bh_held(): disabling irqs also disables bh
        generic-ipi: Fix deadlock in __smp_call_function_single
      e1d9694c
    • L
      Merge branch 'perf-fixes-for-linus' of... · 39c12be8
      Linus Torvalds 提交于
      Merge branch 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
      
      * 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
        perf trace scripting: Fix extern struct definitions
        perf ui hist browser: Fix segfault on 'a' for annotate
        perf tools: Fix build breakage
        perf, x86: Handle in flight NMIs on P4 platform
        oprofile, ARM: Release resources on failure
        oprofile: Add Support for Intel CPU Family 6 / Model 29
      39c12be8
    • E
      wait: using uninitialized member of wait queue · 231d0aef
      Evgeny Kuznetsov 提交于
      The "flags" member of "struct wait_queue_t" is used in several places in
      the kernel code without beeing initialized by init_wait().  "flags" is
      used in bitwise operations.
      
      If "flags" not initialized then unexpected behaviour may take place.
      Incorrect flags might used later in code.
      
      Added initialization of "wait_queue_t.flags" with zero value into
      "init_wait".
      Signed-off-by: NEvgeny Kuznetsov <EXT-Eugeny.Kuznetsov@nokia.com>
      [ The bit we care about does end up being initialized by both
         prepare_to_wait() and add_to_wait_queue(), so this doesn't seem to
         cause actual bugs, but is definitely the right thing to do -Linus ]
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      231d0aef
    • L
      modules: Fix module_bug_list list corruption race · 5336377d
      Linus Torvalds 提交于
      With all the recent module loading cleanups, we've minimized the code
      that sits under module_mutex, fixing various deadlocks and making it
      possible to do most of the module loading in parallel.
      
      However, that whole conversion totally missed the rather obscure code
      that adds a new module to the list for BUG() handling.  That code was
      doubly obscure because (a) the code itself lives in lib/bugs.c (for
      dubious reasons) and (b) it gets called from the architecture-specific
      "module_finalize()" rather than from generic code.
      
      Calling it from arch-specific code makes no sense what-so-ever to begin
      with, and is now actively wrong since that code isn't protected by the
      module loading lock any more.
      
      So this commit moves the "module_bug_{finalize,cleanup}()" calls away
      from the arch-specific code, and into the generic code - and in the
      process protects it with the module_mutex so that the list operations
      are now safe.
      
      Future fixups:
       - move the module list handling code into kernel/module.c where it
         belongs.
       - get rid of 'module_bug_list' and just use the regular list of modules
         (called 'modules' - imagine that) that we already create and maintain
         for other reasons.
      Reported-and-tested-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Adrian Bunk <bunk@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: stable@kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5336377d
  5. 05 10月, 2010 23 次提交