1. 13 12月, 2008 1 次提交
    • R
      cpumask: centralize cpu_online_map and cpu_possible_map · 98a79d6a
      Rusty Russell 提交于
      Impact: cleanup
      
      Each SMP arch defines these themselves.  Move them to a central
      location.
      
      Twists:
      1) Some archs (m32, parisc, s390) set possible_map to all 1, so we add a
         CONFIG_INIT_ALL_POSSIBLE for this rather than break them.
      
      2) mips and sparc32 '#define cpu_possible_map phys_cpu_present_map'.
         Those archs simply have phys_cpu_present_map replaced everywhere.
      
      3) Alpha defined cpu_possible_map to cpu_present_map; this is tricky
         so I just manipulate them both in sync.
      
      4) IA64, cris and m32r have gratuitous 'extern cpumask_t cpu_possible_map'
         declarations.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Reviewed-by: NGrant Grundler <grundler@parisc-linux.org>
      Tested-by: NTony Luck <tony.luck@intel.com>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Cc: Mike Travis <travis@sgi.com>
      Cc: ink@jurassic.park.msu.ru
      Cc: rmk@arm.linux.org.uk
      Cc: starvik@axis.com
      Cc: tony.luck@intel.com
      Cc: takata@linux-m32r.org
      Cc: ralf@linux-mips.org
      Cc: grundler@parisc-linux.org
      Cc: paulus@samba.org
      Cc: schwidefsky@de.ibm.com
      Cc: lethal@linux-sh.org
      Cc: wli@holomorphy.com
      Cc: davem@davemloft.net
      Cc: jdike@addtoit.com
      Cc: mingo@redhat.com
      98a79d6a
  2. 07 11月, 2008 1 次提交
    • R
      [ARM] fix naming of MODULE_START / MODULE_END · ab4f2ee1
      Russell King 提交于
      As of 73bdf0a6, the kernel needs
      to know where modules are located in the virtual address space.
      On ARM, we located this region between MODULE_START and MODULE_END.
      Unfortunately, everyone else calls it MODULES_VADDR and MODULES_END.
      Update ARM to use the same naming, so is_vmalloc_or_module_addr()
      can work properly.  Also update the comment on mm/vmalloc.c to
      reflect that ARM also places modules in a separate region from the
      vmalloc space.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      ab4f2ee1
  3. 04 11月, 2008 1 次提交
  4. 23 10月, 2008 1 次提交
  5. 21 10月, 2008 1 次提交
  6. 10 10月, 2008 1 次提交
  7. 09 10月, 2008 1 次提交
  8. 03 10月, 2008 1 次提交
  9. 01 10月, 2008 2 次提交
  10. 26 9月, 2008 1 次提交
    • J
      kgdb, x86, arm, mips, powerpc: ignore user space single stepping · d7161a65
      Jason Wessel 提交于
      On the x86 arch, user space single step exceptions should be ignored
      if they occur in the kernel space, such as ptrace stepping through a
      system call.
      
      First check if it is kgdb that is executing a single step, then ensure
      it is not an accidental traversal into the user space, while in kgdb,
      any other time the TIF_SINGLESTEP is set, kgdb should ignore the
      exception.
      
      On x86, arm, mips and powerpc, the kgdb_contthread usage was
      inconsistent with the way single stepping is implemented in the kgdb
      core.  The arch specific stub should always set the
      kgdb_cpu_doing_single_step correctly if it is single stepping.  This
      allows kgdb to correctly process an instruction steps if ptrace
      happens to be requesting an instruction step over a system call.
      Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
      d7161a65
  11. 25 9月, 2008 3 次提交
    • R
      [ARM] Print details relevant to how we handle the cache · 2b4ae1f1
      Russell King 提交于
      This replaces the original cache type decoding printks.  We now
      indicate how we're treating the cache which we found, rather
      than what we found.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      2b4ae1f1
    • R
      [ARM] Introduce new bitmask based cache type macros · c0e95878
      Russell King 提交于
      Rather than trying to (inaccurately) decode the cache type from the
      registers each time we need to decide what type of cache we have,
      use a bitmask initialized early during boot.
      
      Since the setup is a one-off initialization, we can be a little more
      clever and take account of the CPU architecture as well.
      
      Note that we continue to achieve the compactness on optimised kernels
      by forcing tests to always-false or always-true as appropriate, thereby
      allowing the compiler to do build-time code elimination.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      c0e95878
    • R
      [ARM] Remove cache type printks · 90f1e084
      Russell King 提交于
      The cache type register found in ARMv5 and later CPUs changes format
      and meaning depending on the CPU architecture version.  Currently,
      this code:
      a) doesn't work for everything - Xscale's are identified as
         'unknown 5'.
      b) is not able to tell whether the caches are VIVT or VIPT from the
         cache type.
      c) prints rubbish on some ARMv6 and ARMv7+ CPUs.
      
      The two solutions to this are:
      1. Add yet more code to decode and print the various different register
         formats.
      2. Remove the code altogther.
      
      The code only exists to decode and print the cache parameters.
      Increasing the complexity of it just for the sake of a few prinks
      isn't worth it.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      90f1e084
  12. 09 9月, 2008 1 次提交
    • M
      kernel/cpu.c: create a CPU_STARTING cpu_chain notifier · e545a614
      Manfred Spraul 提交于
      Right now, there is no notifier that is called on a new cpu, before the new
      cpu begins processing interrupts/softirqs.
      Various kernel function would need that notification, e.g. kvm works around
      by calling smp_call_function_single(), rcu polls cpu_online_map.
      
      The patch adds a CPU_STARTING notification. It also adds a helper function
      that sends the message to all cpu_chain handlers.
      
      Tested on x86-64.
      All other archs are untested. Especially on sparc, I'm not sure if I got
      it right.
      Signed-off-by: NManfred Spraul <manfred@colorfullife.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e545a614
  13. 06 9月, 2008 5 次提交
  14. 05 9月, 2008 1 次提交
    • R
      [ARM] sparse: fix several warnings · 09d9bae0
      Russell King 提交于
      arch/arm/kernel/process.c:270:6: warning: symbol 'show_fpregs' was not declared. Should it be static?
      
      This function isn't used, so can be removed.
      
      arch/arm/kernel/setup.c:532:9: warning: symbol 'len' shadows an earlier one
      arch/arm/kernel/setup.c:524:6: originally declared here
      
      A function containing two 'len's.
      
      arch/arm/mm/fault-armv.c:188:13: warning: symbol 'check_writebuffer_bugs' was not declared. Should it be static?
      arch/arm/mm/mmap.c:122:5: warning: symbol 'valid_phys_addr_range' was not declared. Should it be static?
      arch/arm/mm/mmap.c:137:5: warning: symbol 'valid_mmap_phys_addr_range' was not declared. Should it be static?
      
      Missing includes.
      
      arch/arm/kernel/traps.c:71:77: warning: Using plain integer as NULL pointer
      arch/arm/mm/ioremap.c:355:46: error: incompatible types in comparison expression (different address spaces)
      
      Sillies.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      09d9bae0
  15. 01 9月, 2008 5 次提交
  16. 15 8月, 2008 1 次提交
  17. 13 8月, 2008 3 次提交
  18. 09 8月, 2008 1 次提交
    • L
      [ARM] prevent crashing when too much RAM installed · 60296c71
      Lennert Buytenhek 提交于
      This patch will truncate and/or ignore memory banks if their kernel
      direct mappings would (partially) overlap with the vmalloc area or
      the mappings between the vmalloc area and the address space top, to
      prevent crashing during early boot if there happens to be more RAM
      installed than we are expecting.
      
      Since the start of the vmalloc area is not at a fixed address (but
      the vmalloc end address is, via the per-platform VMALLOC_END define),
      a default area of 128M is reserved for vmalloc mappings, which can
      be shrunk or enlarged by passing an appropriate vmalloc= command line
      option as it is done on x86.
      
      On a board with a 3:1 user:kernel split, VMALLOC_END at 0xfe000000,
      two 512M RAM banks and vmalloc=128M (the default), this patch gives:
      
      	Truncating RAM at 20000000-3fffffff to -35ffffff (vmalloc region overlap).
      	Memory: 512MB 352MB = 864MB total
      
      On a board with a 3:1 user:kernel split, VMALLOC_END at 0xfe800000,
      two 256M RAM banks and vmalloc=768M, this patch gives:
      
      	Truncating RAM at 00000000-0fffffff to -0e7fffff (vmalloc region overlap).
      	Ignoring RAM at 10000000-1fffffff (vmalloc region overlap).
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      Tested-by: NRiku Voipio <riku.voipio@iki.fi>
      60296c71
  19. 08 8月, 2008 1 次提交
    • R
      [ARM] Fix SMP booting with non-zero PHYS_OFFSET · 058ddee5
      Russell King 提交于
      The existing code tries to get the pmd for the temporary page table
      by doing:
      
              pgd = pgd_alloc(&init_mm);
              pmd = pmd_offset(pgd, PHYS_OFFSET);
      
      Since we have a two level page table, pmd_offset() is a no-op, so
      this just has a casting effect from a pgd to a pmd - the address
      argument is unused.  So this can't work.
      
      Normally, we'd do:
      
      	pgd = pgd_offset(&init_mm, PHYS_OFFSET);
      	...
      	pmd = pmd_offset(pgd, PHYS_OFFSET);
      
      to get the pmd you want.  However, pgd_offset() takes the mm_struct,
      not the (unattached) pgd we just allocated.  So, instead use:
      
              pgd = pgd_alloc(&init_mm);
              pmd = pmd_offset(pgd + pgd_index(PHYS_OFFSET), PHYS_OFFSET);
      Reported-by: NAntti P Miettinen <ananaza@iki.fi>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      058ddee5
  20. 07 8月, 2008 4 次提交
  21. 03 8月, 2008 1 次提交
  22. 26 7月, 2008 1 次提交
    • S
      kprobes: improve kretprobe scalability with hashed locking · ef53d9c5
      Srinivasa D S 提交于
      Currently list of kretprobe instances are stored in kretprobe object (as
      used_instances,free_instances) and in kretprobe hash table.  We have one
      global kretprobe lock to serialise the access to these lists.  This causes
      only one kretprobe handler to execute at a time.  Hence affects system
      performance, particularly on SMP systems and when return probe is set on
      lot of functions (like on all systemcalls).
      
      Solution proposed here gives fine-grain locks that performs better on SMP
      system compared to present kretprobe implementation.
      
      Solution:
      
       1) Instead of having one global lock to protect kretprobe instances
          present in kretprobe object and kretprobe hash table.  We will have
          two locks, one lock for protecting kretprobe hash table and another
          lock for kretporbe object.
      
       2) We hold lock present in kretprobe object while we modify kretprobe
          instance in kretprobe object and we hold per-hash-list lock while
          modifying kretprobe instances present in that hash list.  To prevent
          deadlock, we never grab a per-hash-list lock while holding a kretprobe
          lock.
      
       3) We can remove used_instances from struct kretprobe, as we can
          track used instances of kretprobe instances using kretprobe hash
          table.
      
      Time duration for kernel compilation ("make -j 8") on a 8-way ppc64 system
      with return probes set on all systemcalls looks like this.
      
      cacheline              non-cacheline             Un-patched kernel
      aligned patch 	       aligned patch
      ===============================================================================
      real    9m46.784s       9m54.412s                  10m2.450s
      user    40m5.715s       40m7.142s                  40m4.273s
      sys     2m57.754s       2m58.583s                  3m17.430s
      ===========================================================
      
      Time duration for kernel compilation ("make -j 8) on the same system, when
      kernel is not probed.
      =========================
      real    9m26.389s
      user    40m8.775s
      sys     2m7.283s
      =========================
      Signed-off-by: NSrinivasa DS <srinivasa@in.ibm.com>
      Signed-off-by: NJim Keniston <jkenisto@us.ibm.com>
      Acked-by: NAnanth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Masami Hiramatsu <mhiramat@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ef53d9c5
  23. 25 7月, 2008 1 次提交
    • A
      PAGE_ALIGN(): correctly handle 64-bit values on 32-bit architectures · 27ac792c
      Andrea Righi 提交于
      On 32-bit architectures PAGE_ALIGN() truncates 64-bit values to the 32-bit
      boundary. For example:
      
      	u64 val = PAGE_ALIGN(size);
      
      always returns a value < 4GB even if size is greater than 4GB.
      
      The problem resides in PAGE_MASK definition (from include/asm-x86/page.h for
      example):
      
      #define PAGE_SHIFT      12
      #define PAGE_SIZE       (_AC(1,UL) << PAGE_SHIFT)
      #define PAGE_MASK       (~(PAGE_SIZE-1))
      ...
      #define PAGE_ALIGN(addr)       (((addr)+PAGE_SIZE-1)&PAGE_MASK)
      
      The "~" is performed on a 32-bit value, so everything in "and" with
      PAGE_MASK greater than 4GB will be truncated to the 32-bit boundary.
      Using the ALIGN() macro seems to be the right way, because it uses
      typeof(addr) for the mask.
      
      Also move the PAGE_ALIGN() definitions out of include/asm-*/page.h in
      include/linux/mm.h.
      
      See also lkml discussion: http://lkml.org/lkml/2008/6/11/237
      
      [akpm@linux-foundation.org: fix drivers/media/video/uvc/uvc_queue.c]
      [akpm@linux-foundation.org: fix v850]
      [akpm@linux-foundation.org: fix powerpc]
      [akpm@linux-foundation.org: fix arm]
      [akpm@linux-foundation.org: fix mips]
      [akpm@linux-foundation.org: fix drivers/media/video/pvrusb2/pvrusb2-dvb.c]
      [akpm@linux-foundation.org: fix drivers/mtd/maps/uclinux.c]
      [akpm@linux-foundation.org: fix powerpc]
      Signed-off-by: NAndrea Righi <righi.andrea@gmail.com>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      27ac792c
  24. 24 7月, 2008 1 次提交
    • J
      kgdb: support for ARCH=arm · 5cbad0eb
      Jason Wessel 提交于
      This patch adds the ARCH=arm specific a kgdb backend, originally
      written by Deepak Saxena <dsaxena@plexity.net> and George Davis
      <gdavis@mvista.com>.  Geoff Levand <geoffrey.levand@am.sony.com>,
      Nicolas Pitre, Manish Lachwani, and Jason Wessel have contributed
      various fixups here as well.
      
      The KGDB patch makes one change to the core ARM architecture such that
      the traps are initialized early for use with the debugger or other
      subsystems.
      
      [ mingo@elte.hu: small cleanups. ]
      [ ben-linux@fluff.org: fixed early_trap_init ]
      Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
      Acked-by: NDeepak Saxena <dsaxena@plexity.net>
      5cbad0eb