1. 12 10月, 2010 1 次提交
  2. 08 10月, 2010 1 次提交
  3. 06 10月, 2010 5 次提交
    • 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
      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
      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
  4. 05 10月, 2010 21 次提交
  5. 02 10月, 2010 2 次提交
    • D
      MN10300: Fix flush_icache_range() · 57cf4f78
      David Howells 提交于
      flush_icache_range() is given virtual addresses to describe the region.  It
      deals with these by attempting to translate them through the current set of
      page tables.
      
      This is fine for userspace memory and vmalloc()'d areas as they are governed by
      page tables.  However, since the regions above 0x80000000 aren't translated
      through the page tables by the MMU, the kernel doesn't bother to set up page
      tables for them (see paging_init()).
      
      This means flush_icache_range() as it stands cannot be used to flush regions of
      the VM area between 0x80000000 and 0x9fffffff where the kernel resides if the
      data cache is operating in WriteBack mode.
      
      To fix this, make flush_icache_range() first check for addresses in the upper
      half of VM space and deal with them appropriately, before dealing with any
      range in the page table mapped area.
      
      Ordinarily, this is not a problem, but it has the capacity to make kprobes and
      kgdb malfunction.  It should not affect gdbstub, signal frame setup or module
      loading as gdb has its own flush functions, and the others take place in the
      page table mapped area only.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Acked-by: NAkira Takeuchi <takeuchi.akr@jp.panasonic.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      57cf4f78
    • A
      arch/m68k/mac/macboing.c: use unsigned long for irqflags · e53ced1b
      Andrew Morton 提交于
      Fix the warnings
      
        arch/m68k/mac/macboing.c: In function 'mac_mksound':
        arch/m68k/mac/macboing.c:189: warning: comparison of distinct pointer types lacks a cast
        arch/m68k/mac/macboing.c:211: warning: comparison of distinct pointer types lacks a cast
        arch/m68k/mac/macboing.c: In function 'mac_quadra_start_bell':
        arch/m68k/mac/macboing.c:241: warning: comparison of distinct pointer types lacks a cast
        arch/m68k/mac/macboing.c:263: warning: comparison of distinct pointer types lacks a cast
        arch/m68k/mac/macboing.c: In function 'mac_quadra_ring_bell':
        arch/m68k/mac/macboing.c:283: warning: comparison of distinct pointer types lacks a cast
      
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e53ced1b
  6. 01 10月, 2010 4 次提交
  7. 30 9月, 2010 4 次提交
  8. 29 9月, 2010 2 次提交