1. 07 2月, 2011 3 次提交
  2. 14 1月, 2011 1 次提交
  3. 12 1月, 2011 1 次提交
  4. 11 1月, 2011 1 次提交
    • J
      powerpc/pseries: Fix VPHN build errors on non-SMP systems · 39bf990e
      Jesse Larrew 提交于
      The header asm/hvcall.h was previously included indirectly via
      smp.h. On non-SMP systems, however, these declarations are excluded
      and the build breaks. This is easily fixed by including asm/hvcall.h
      directly.
      
      The VPHN feature is only meaningful on NUMA systems that implement
      the SPLPAR option, so exclude the VPHN code on systems without
      SPLPAR enabled.
      
      Also, expose unmap_cpu_from_node() on systems with SPLPAR enabled,
      even if CONFIG_HOTPLUG_CPU is disabled.
      
      Lastly, map_cpu_to_node() is now needed by VPHN to manipulate the
      node masks after boot time, so remove the __cpuinit annotation to
      fix a section mismatch.
      Signed-off-by: NJesse Larrew <jlarrew@linux.vnet.ibm.com>
      39bf990e
  5. 09 12月, 2010 3 次提交
  6. 30 11月, 2010 1 次提交
  7. 29 11月, 2010 3 次提交
    • M
      powerpc/mm: Avoid avoidable void* pointer · 0b97fee0
      Michael Neuling 提交于
      Change pgdir from a void to real type.  Having this as a void is
      stupid and has already caused 1 bug.
      Signed-off-by: NMichael Neuling <mikey@neuling.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      0b97fee0
    • N
      powerpc: Add memory_hotplug_max() · cd34206e
      Nishanth Aravamudan 提交于
      Add a function to get the maximum address that can be hotplug added.
      This is needed to calculate the size of the tce table needed to cover
      all memory in 1:1 mode.
      Signed-off-by: NMilton Miller <miltonm@bga.com>
      Signed-off-by: NNishanth Aravamudan <nacc@us.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      cd34206e
    • V
      powerpc: Cleanup APIs for cpu/thread/core mappings · 99d86705
      Vaidyanathan Srinivasan 提交于
      These APIs take logical cpu number as input
      Change cpu_first_thread_in_core() to cpu_first_thread_sibling()
      Change cpu_last_thread_in_core() to cpu_last_thread_sibling()
      
      These APIs convert core number (index) to logical cpu/thread numbers
      Add cpu_first_thread_of_core(int core)
      Changed cpu_thread_to_core() to cpu_core_index_of_thread(int cpu)
      
      The goal is to make 'threads_per_core' accessible to the
      pseries_energy module.  Instead of making an API to read
      threads_per_core, this is a higher level wrapper function to
      convert from logical cpu number to core number.
      
      The current APIs cpu_first_thread_in_core() and
      cpu_last_thread_in_core() returns logical CPU number while
      cpu_thread_to_core() returns core number or index which is
      not a logical CPU number.  The new APIs are now clearly named to
      distinguish 'core number' versus first and last 'logical cpu
      number' in that core.
      
      The new APIs cpu_{first,last}_thread_sibling() work on
      logical cpu numbers.  While cpu_first_thread_of_core() and
      cpu_core_index_of_thread() work on core index.
      
      Example usage:  (4 threads per core system)
      
      cpu_first_thread_sibling(5) = 4
      cpu_last_thread_sibling(5) = 7
      cpu_core_index_of_thread(5) = 1
      cpu_first_thread_of_core(1) = 4
      
      cpu_core_index_of_thread() is used in cpu_to_drc_index() in the
      module and cpu_first_thread_of_core() is used in
      drc_index_to_cpu() in the module.
      
      Make API changes to few callers.  Export symbols for use in modules.
      Signed-off-by: NVaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      99d86705
  8. 18 11月, 2010 3 次提交
    • K
      powerpc/mm: Fix module instruction tlb fault handling on Book-E 64 · 82ae5eaf
      Kumar Gala 提交于
      We were seeing oops like the following when we did an rmmod on a module:
      
      Unable to handle kernel paging request for instruction fetch
      Faulting instruction address: 0x8000000000008010
      Oops: Kernel access of bad area, sig: 11 [#1]
      SMP NR_CPUS=2 P5020 DS
      last sysfs file: /sys/devices/qman-portals.2/qman-pool.9/uevent
      Modules linked in: qman_tester(-)
      NIP: 8000000000008010 LR: c000000000074858 CTR: 8000000000008010
      REGS: c00000002e29bab0 TRAP: 0400   Not tainted
      (2.6.34.6-00744-g2d21f14)
      MSR: 0000000080029000 <EE,ME,CE>  CR: 24000448  XER: 00000000
      TASK = c00000007a8be600[4987] 'rmmod' THREAD: c00000002e298000 CPU: 1
      GPR00: 8000000000008010 c00000002e29bd30 8000000000012798 c00000000035fb28
      GPR04: 0000000000000002 0000000000000002 0000000024022428 c000000000009108
      GPR08: fffffffffffffffe 800000000000a618 c0000000003c13c8 0000000000000000
      GPR12: 0000000022000444 c00000000fffed00 0000000000000000 0000000000000000
      GPR16: 00000000100c0000 0000000000000000 00000000100dabc8 0000000010099688
      GPR20: 0000000000000000 00000000100cfc28 0000000000000000 0000000010011a44
      GPR24: 00000000100017b2 0000000000000000 0000000000000000 0000000000000880
      GPR28: c00000000035fb28 800000000000a7b8 c000000000376d80 c0000000003cce50
      NIP [8000000000008010] .test_exit+0x0/0x10 [qman_tester]
      LR [c000000000074858] .SyS_delete_module+0x1f8/0x2f0
      Call Trace:
      [c00000002e29bd30] [c0000000000748b4] .SyS_delete_module+0x254/0x2f0 (unreliable)
      [c00000002e29be30] [c000000000000580] syscall_exit+0x0/0x2c
      Instruction dump:
      XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
      38600000 4e800020 60000000 60000000 <4e800020> 60000000 60000000 60000000
      ---[ end trace 4f57124939a84dc8 ]---
      
      This appears to be due to checking the wrong permission bits in the
      instruction_tlb_miss handling if the address that faulted was in vmalloc
      space.  We need to look at the supervisor execute (_PAGE_BAP_SX) bit and
      not the user bit (_PAGE_BAP_UX/_PAGE_EXEC).
      
      Also removed a branch level since it did not appear to be used.
      Reported-by: NJeffrey Ladouceur <Jeffrey.Ladouceur@freescale.com>
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      82ae5eaf
    • M
      powerpc: Fix call to subpage_protection() · 1c2c25c7
      Michael Neuling 提交于
      In:
        powerpc/mm: Fix pgtable cache cleanup with CONFIG_PPC_SUBPAGE_PROT
        commit d28513bc
        Author: David Gibson <david@gibson.dropbear.id.au>
      
      subpage_protection() was changed to to take an mm rather a pgdir but it
      didn't change calling site in hashpage_preload().  The change wasn't
      noticed at compile time since hashpage_preload() used a void* as the
      parameter to subpage_protection().
      
      This is obviously wrong and can trigger the following crash when
      CONFIG_SLAB, CONFIG_DEBUG_SLAB, CONFIG_PPC_64K_PAGES
      CONFIG_PPC_SUBPAGE_PROT are enabled.
      
      Freeing unused kernel memory: 704k freed
      Unable to handle kernel paging request for data at address 0x6b6b6b6b6b6c49b7
      Faulting instruction address: 0xc0000000000410f4
      cpu 0x2: Vector: 300 (Data Access) at [c00000004233f590]
          pc: c0000000000410f4: .hash_preload+0x258/0x338
          lr: c000000000041054: .hash_preload+0x1b8/0x338
          sp: c00000004233f810
         msr: 8000000000009032
         dar: 6b6b6b6b6b6c49b7
       dsisr: 40000000
        current = 0xc00000007e2c0070
        paca    = 0xc000000007fe0500
          pid   = 1, comm = init
      enter ? for help
      [c00000004233f810] c000000000041020 .hash_preload+0x184/0x338 (unreliable)
      [c00000004233f8f0] c00000000003ed98 .update_mmu_cache+0xb0/0xd0
      [c00000004233f990] c000000000157754 .__do_fault+0x48c/0x5dc
      [c00000004233faa0] c000000000158fd0 .handle_mm_fault+0x508/0xa8c
      [c00000004233fb90] c0000000006acdd4 .do_page_fault+0x428/0x6ac
      [c00000004233fe30] c000000000005260 handle_page_fault+0x20/0x74
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      1c2c25c7
    • K
      powerpc/mm: Fix build error in setup_initial_memory_limit · 4a89261b
      Kumar Gala 提交于
      arch/powerpc/mm/tlb_nohash.c: In function 'setup_initial_memory_limit':
      arch/powerpc/mm/tlb_nohash.c:588:29: error: 'ppc64_memblock_base' undeclared (first use in this function)
      arch/powerpc/mm/tlb_nohash.c:588:29: note: each undeclared identifier is reported only once for each function it appears in
      
      Due to a copy/paste typo with the following commit:
      
      	commit cd3db0c4
      	Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      	Date:   Tue Jul 6 15:39:02 2010 -0700
      
      	    memblock: Remove rmo_size, burry it in arch/powerpc where it belongs
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      4a89261b
  9. 28 10月, 2010 1 次提交
  10. 27 10月, 2010 1 次提交
    • P
      mm: stack based kmap_atomic() · 3e4d3af5
      Peter Zijlstra 提交于
      Keep the current interface but ignore the KM_type and use a stack based
      approach.
      
      The advantage is that we get rid of crappy code like:
      
      	#define __KM_PTE			\
      		(in_nmi() ? KM_NMI_PTE : 	\
      		 in_irq() ? KM_IRQ_PTE :	\
      		 KM_PTE0)
      
      and in general can stop worrying about what context we're in and what kmap
      slots might be appropriate for that.
      
      The downside is that FRV kmap_atomic() gets more expensive.
      
      For now we use a CPP trick suggested by Andrew:
      
        #define kmap_atomic(page, args...) __kmap_atomic(page)
      
      to avoid having to touch all kmap_atomic() users in a single patch.
      
      [ not compiled on:
        - mn10300: the arch doesn't actually build with highmem to begin with ]
      
      [akpm@linux-foundation.org: coding-style fixes]
      [akpm@linux-foundation.org: fix up drivers/gpu/drm/i915/intel_overlay.c]
      Acked-by: NRik van Riel <riel@redhat.com>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Acked-by: NChris Metcalf <cmetcalf@tilera.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: David Miller <davem@davemloft.net>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Dave Airlie <airlied@linux.ie>
      Cc: Li Zefan <lizf@cn.fujitsu.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3e4d3af5
  11. 14 10月, 2010 3 次提交
    • K
      powerpc/fsl-booke64: Use TLB CAMs to cover linear mapping on FSL 64-bit chips · 55fd766b
      Kumar Gala 提交于
      On Freescale parts typically have TLB array for large mappings that we can
      bolt the linear mapping into.  We utilize the code that already exists
      on PPC32 on the 64-bit side to setup the linear mapping to be cover by
      bolted TLB entries.  We utilize a quarter of the variable size TLB array
      for this purpose.
      
      Additionally, we limit the amount of memory to what we can cover via
      bolted entries so we don't get secondary faults in the TLB miss
      handlers.  We should fix this limitation in the future.
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      55fd766b
    • K
      powerpc/fsl-booke: Add support for FSL Arch v1.0 MMU in setup_page_sizes · 988cf86d
      Kumar Gala 提交于
      Update setup_page_sizes() to support for a MMU v1.0 FSL style MMU
      implementation.  In such a processor, we don't have TLB0PS or EPTCFG
      registers (and access to these registers may cause exceptions).  We need
      to parse the older format of TLBnCFG for page size support.  Additionaly,
      assume since we are an FSL implementation that we have 2 TLB arrays and
      the second array contains the variable size pages.
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      988cf86d
    • P
      powerpc: Fix invalid page flags in create TLB CAM path for PTE_64BIT · 92437d41
      Paul Gortmaker 提交于
      There exists a four line chunk of code, which when configured for
      64 bit address space, can incorrectly set certain page flags during
      the TLB creation.  It turns out that this is code which isn't used,
      but might still serve a purpose.  Since it isn't obvious why it exists
      or why it causes problems, the below description covers both in detail.
      
      For powerpc bootstrap, the physical memory (at most 768M), is mapped
      into the kernel space via the following path:
      
      MMU_init()
          |
          + adjust_total_lowmem()
                  |
                  + map_mem_in_cams()
                          |
                          + settlbcam(i, virt, phys, cam_sz, PAGE_KERNEL_X, 0);
      
      On settlbcam(), the kernel will create TLB entries according to the flag,
      PAGE_KERNEL_X.
      
      settlbcam()
      {
              ...
              TLBCAM[index].MAS1 = MAS1_VALID
                              | MAS1_IPROT | MAS1_TSIZE(tsize) | MAS1_TID(pid);
                                      ^
      			These entries cannot be invalidated by the
      			kernel since MAS1_IPROT is set on TLB property.
              ...
              if (flags & _PAGE_USER) {
                 TLBCAM[index].MAS3 |= MAS3_UX | MAS3_UR;
                 TLBCAM[index].MAS3 |= ((flags & _PAGE_RW) ? MAS3_UW : 0);
              }
      
      For classic BookE (flags & _PAGE_USER) is 'zero' so it's fine.
      But on boards like the the Freescale P4080, we want to support 36-bit
      physical address on it. So the following options may be set:
      
      CONFIG_FSL_BOOKE=y
      CONFIG_PTE_64BIT=y
      CONFIG_PHYS_64BIT=y
      
      As a result, boards like the P4080 will introduce PTE format as Book3E.
      As per the file: arch/powerpc/include/asm/pgtable-ppc32.h
      
        * #elif defined(CONFIG_FSL_BOOKE) && defined(CONFIG_PTE_64BIT)
        * #include <asm/pte-book3e.h>
      
      So PAGE_KERNEL_X is __pgprot(_PAGE_BASE | _PAGE_KERNEL_RWX) and the
      book3E version of _PAGE_KERNEL_RWX is defined with:
      
        (_PAGE_BAP_SW | _PAGE_BAP_SR | _PAGE_DIRTY | _PAGE_BAP_SX)
      
      Note the _PAGE_BAP_SR, which is also defined in the book3E _PAGE_USER:
      
        #define _PAGE_USER        (_PAGE_BAP_UR | _PAGE_BAP_SR) /* Can be read */
      
      So the possibility exists to wrongly assign the user MAS3_U<RWX> bits
      to kernel (PAGE_KERNEL_X) address space via the following code fragment:
      
              if (flags & _PAGE_USER) {
                 TLBCAM[index].MAS3 |= MAS3_UX | MAS3_UR;
                 TLBCAM[index].MAS3 |= ((flags & _PAGE_RW) ? MAS3_UW : 0);
              }
      
      Here is a dump of the TLB info from Simics with the above code present:
      ------
      L2 TLB1
                                                  GT                   SSS UUU V I
       Row  Logical           Physical            SS TLPID  TID  WIMGE XWR XWR F P   V
      ----- ----------------- ------------------- -- ----- ----- ----- --- --- - -   -
        0   c0000000-cfffffff 000000000-00fffffff 00     0     0   M   XWR XWR 0 1   1
        1   d0000000-dfffffff 010000000-01fffffff 00     0     0   M   XWR XWR 0 1   1
        2   e0000000-efffffff 020000000-02fffffff 00     0     0   M   XWR XWR 0 1   1
      
      Actually this conditional code was used for two legacy functions:
      
        1: support KGDB to set break point.
           KGDB already dropped this; now uses its core write to set break point.
      
        2: io_block_mapping() to create TLB in segmentation size (not PAGE_SIZE)
           for device IO space.
           This use case is also removed from the latest PowerPC kernel.
      
      However, there may still be a use case for it in the future, like
      large user pages, so we can't remove it entirely.  As an alternative,
      we match on all bits of _PAGE_USER instead of just any bits, so the
      case where just _PAGE_BAP_SR is set can't sneak through.
      
      With this done, the TLB appears without U having XWR as below:
      
      -------
      L2 TLB1
                                                  GT                   SSS UUU V I
       Row  Logical           Physical            SS TLPID  TID  WIMGE XWR XWR F P   V
      ----- ----------------- ------------------- -- ----- ----- ----- --- --- - -   -
        0   c0000000-cfffffff 000000000-00fffffff 00     0     0   M   XWR     0 1   1
        1   d0000000-dfffffff 010000000-01fffffff 00     0     0   M   XWR     0 1   1
        2   e0000000-efffffff 020000000-02fffffff 00     0     0   M   XWR     0 1   1
      Signed-off-by: NTiejun Chen <tiejun.chen@windriver.com>
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      92437d41
  12. 13 10月, 2010 2 次提交
  13. 02 9月, 2010 2 次提交
  14. 24 8月, 2010 1 次提交
  15. 23 8月, 2010 1 次提交
  16. 10 8月, 2010 1 次提交
    • C
      kmap_atomic: make kunmap_atomic() harder to misuse · 597781f3
      Cesar Eduardo Barros 提交于
      kunmap_atomic() is currently at level -4 on Rusty's "Hard To Misuse"
      list[1] ("Follow common convention and you'll get it wrong"), except in
      some architectures when CONFIG_DEBUG_HIGHMEM is set[2][3].
      
      kunmap() takes a pointer to a struct page; kunmap_atomic(), however, takes
      takes a pointer to within the page itself.  This seems to once in a while
      trip people up (the convention they are following is the one from
      kunmap()).
      
      Make it much harder to misuse, by moving it to level 9 on Rusty's list[4]
      ("The compiler/linker won't let you get it wrong").  This is done by
      refusing to build if the type of its first argument is a pointer to a
      struct page.
      
      The real kunmap_atomic() is renamed to kunmap_atomic_notypecheck()
      (which is what you would call in case for some strange reason calling it
      with a pointer to a struct page is not incorrect in your code).
      
      The previous version of this patch was compile tested on x86-64.
      
      [1] http://ozlabs.org/~rusty/index.cgi/tech/2008-04-01.html
      [2] In these cases, it is at level 5, "Do it right or it will always
          break at runtime."
      [3] At least mips and powerpc look very similar, and sparc also seems to
          share a common ancestor with both; there seems to be quite some
          degree of copy-and-paste coding here. The include/asm/highmem.h file
          for these three archs mention x86 CPUs at its top.
      [4] http://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html
      [5] As an aside, could someone tell me why mn10300 uses unsigned long as
          the first parameter of kunmap_atomic() instead of void *?
      Signed-off-by: NCesar Eduardo Barros <cesarb@cesarb.net>
      Cc: Russell King <linux@arm.linux.org.uk> (arch/arm)
      Cc: Ralf Baechle <ralf@linux-mips.org> (arch/mips)
      Cc: David Howells <dhowells@redhat.com> (arch/frv, arch/mn10300)
      Cc: Koichi Yasutake <yasutake.koichi@jp.panasonic.com> (arch/mn10300)
      Cc: Kyle McMartin <kyle@mcmartin.ca> (arch/parisc)
      Cc: Helge Deller <deller@gmx.de> (arch/parisc)
      Cc: "James E.J. Bottomley" <jejb@parisc-linux.org> (arch/parisc)
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> (arch/powerpc)
      Cc: Paul Mackerras <paulus@samba.org> (arch/powerpc)
      Cc: "David S. Miller" <davem@davemloft.net> (arch/sparc)
      Cc: Thomas Gleixner <tglx@linutronix.de> (arch/x86)
      Cc: Ingo Molnar <mingo@redhat.com> (arch/x86)
      Cc: "H. Peter Anvin" <hpa@zytor.com> (arch/x86)
      Cc: Arnd Bergmann <arnd@arndb.de> (include/asm-generic)
      Cc: Rusty Russell <rusty@rustcorp.com.au> ("Hard To Misuse" list)
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      597781f3
  17. 05 8月, 2010 4 次提交
  18. 04 8月, 2010 2 次提交
  19. 23 7月, 2010 5 次提交
  20. 14 7月, 2010 1 次提交