1. 28 10月, 2010 4 次提交
    • M
      ARM: 6466/1: implement flush_icache_all for the rest of the CPUs · c8c90860
      Mika Westerberg 提交于
      Commit 81d11955 ("ARM: 6405/1: Handle __flush_icache_all for
      CONFIG_SMP_ON_UP") added a new function to struct cpu_cache_fns:
      flush_icache_all(). It also implemented this for v6 and v7 but not
      for v5 and backwards. Without the function pointer in place, we
      will be calling wrong cache functions.
      
      For example with ep93xx we get following:
      
          Unable to handle kernel paging request at virtual address ee070f38
          pgd = c0004000
          [ee070f38] *pgd=00000000
          Internal error: Oops: 80000005 [#1] PREEMPT
          last sysfs file:
          Modules linked in:
          CPU: 0    Not tainted  (2.6.36+ #1)
          PC is at 0xee070f38
          LR is at __dma_alloc+0x11c/0x2d0
          pc : [<ee070f38>]    lr : [<c0032c8c>]    psr: 60000013
          sp : c581bde0  ip : 00000000  fp : c0472000
          r10: c0472000  r9 : 000000d0  r8 : 00020000
          r7 : 0001ffff  r6 : 00000000  r5 : c0472400  r4 : c5980000
          r3 : c03ab7e0  r2 : 00000000  r1 : c59a0000  r0 : c5980000
          Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
          Control: c000717f  Table: c0004000  DAC: 00000017
          Process swapper (pid: 1, stack limit = 0xc581a270)
          [<c0032c8c>] (__dma_alloc+0x11c/0x2d0)
          [<c0032e5c>] (dma_alloc_writecombine+0x1c/0x24)
          [<c0204148>] (ep93xx_pcm_preallocate_dma_buffer+0x44/0x60)
          [<c02041c0>] (ep93xx_pcm_new+0x5c/0x88)
          [<c01ff188>] (snd_soc_instantiate_cards+0x8a8/0xbc0)
          [<c01ff59c>] (soc_probe+0xfc/0x134)
          [<c01adafc>] (platform_drv_probe+0x18/0x1c)
          [<c01acca4>] (driver_probe_device+0xb0/0x16c)
          [<c01ac284>] (bus_for_each_drv+0x48/0x84)
          [<c01ace90>] (device_attach+0x50/0x68)
          [<c01ac0f8>] (bus_probe_device+0x24/0x44)
          [<c01aad7c>] (device_add+0x2fc/0x44c)
          [<c01adfa8>] (platform_device_add+0x104/0x15c)
          [<c0015eb8>] (simone_init+0x60/0x94)
          [<c0021410>] (do_one_initcall+0xd0/0x1a4)
      
      __dma_alloc() calls (inlined) __dma_alloc_buffer() which ends up
      calling dmac_flush_range(). Now since the entries in the
      arm920_cache_fns are shifted by one, we jump into address 0xee070f38
      which is actually next instruction after the arm920_cache_fns
      structure.
      
      So implement flush_icache_all() for the rest of the supported CPUs
      using a generic 'invalidate I cache' instruction.
      Signed-off-by: NMika Westerberg <mika.westerberg@iki.fi>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      c8c90860
    • M
      ARM: 6464/2: fix spinlock recursion in adjust_pte() · 4e54d93d
      Mika Westerberg 提交于
      When running following code in a machine which has VIVT caches and
      USE_SPLIT_PTLOCKS is not defined:
      
        fd = open("/etc/passwd", O_RDONLY);
        addr = mmap(NULL, 4096, PROT_READ, MAP_SHARED, fd, 0);
        addr2 = mmap(NULL, 4096, PROT_READ, MAP_SHARED, fd, 0);
      
        v = *((int *)addr);
      
      we will hang in spinlock recursion in the page fault handler:
      
        BUG: spinlock recursion on CPU#0, mmap_test/717
        lock: c5e295d8, .magic: dead4ead, .owner: mmap_test/717,
                        .owner_cpu: 0
        [<c0026604>] (unwind_backtrace+0x0/0xec)
        [<c014ee48>] (do_raw_spin_lock+0x40/0x140)
        [<c0027f68>] (update_mmu_cache+0x208/0x250)
        [<c0079db4>] (__do_fault+0x320/0x3ec)
        [<c007af7c>] (handle_mm_fault+0x2f0/0x6d8)
        [<c0027834>] (do_page_fault+0xdc/0x1cc)
        [<c00202d0>] (do_DataAbort+0x34/0x94)
      
      This comes from the fact that when USE_SPLIT_PTLOCKS is not defined,
      the only lock protecting the page tables is mm->page_table_lock
      which is already locked before update_mmu_cache() is called.
      Signed-off-by: NMika Westerberg <mika.westerberg@iki.fi>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      4e54d93d
    • R
      ARM: fix memblock breakage · 4e929d2b
      Russell King 提交于
      Will says:
      | Commit e63075a3 removed the explicit MEMBLOCK_REAL_LIMIT #define
      | and introduced the requirement that arch code calls
      | memblock_set_current_limit to ensure that the __va macro can
      | be used on physical addresses returned from memblock_alloc.
      
      Unfortunately, ARM was missed out of this change.  Fix this.
      Reported-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      4e929d2b
    • L
      ARM: 6445/1: fixup TCM memory types · f444fce3
      Linus Walleij 提交于
      After Santosh's fixup of the generic MT_MEMORY and
      MT_MEMORY_NONCACHED I add this fix to the TCM memory types.
      The main change is that the ITCM memory is L_PTE_WRITE and
      DOMAIN_KERNEL which works just fine. The changed to the DTCM
      is just cosmetic to fit with surrounding code.
      
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Rickard Andersson <rickard.andersson@stericsson.com>
      Signed-off-by: NLinus Walleij <linus.walleij@stericsson.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      f444fce3
  2. 27 10月, 2010 2 次提交
    • P
      mm: remove pte_*map_nested() · ece0e2b6
      Peter Zijlstra 提交于
      Since we no longer need to provide KM_type, the whole pte_*map_nested()
      API is now redundant, remove it.
      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: Rik van Riel <riel@redhat.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>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ece0e2b6
    • 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
  3. 13 10月, 2010 2 次提交
  4. 08 10月, 2010 3 次提交
  5. 05 10月, 2010 5 次提交
  6. 02 10月, 2010 1 次提交
  7. 25 9月, 2010 1 次提交
  8. 23 9月, 2010 1 次提交
    • N
      ARM: 6401/1: plug a race in the alignment trap handler · 2f27bf83
      Nicolas Pitre 提交于
      When the policy for user space is to ignore misaligned accesses from user
      space, the processor then performs a documented rotation on the accessed
      data.  This is the result of the access being trapped, and the kernel
      disabling the alignment trap before returning to user space again.
      
      In kernel space we always want misaligned accesses to be fixed up.  This
      is enforced by always re-enabling the alignment trap on every entry into
      kernel space from user space.  No such re-enabling is performed when an
      exception occurs while already in kernel space as the alignment trap is
      always supposed to be enabled in that case.
      
      There is however a small race window when a misaligned access in user
      space is trapped and the alignment trap disabled, but the CPU didn't
      return to user space just yet.  Any exception would be entered from kernel
      space at that point and the kernel would then execute with the alignment
      trap disabled.
      
      Thanks to Maxime Bizon <mbizon@freebox.fr> for providing a test module
      that made this issue reproducible.
      Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      2f27bf83
  9. 19 9月, 2010 5 次提交
  10. 17 9月, 2010 4 次提交
  11. 16 9月, 2010 1 次提交
    • Y
      arm, memblock: Fix the sparsemem build · 7c996361
      Yinghai Lu 提交于
      Stephen Rothwell reported this build failure:
      
        arch/arm/mm/init.c: In function 'arm_memory_present':
        arch/arm/mm/init.c:260: warning: ISO C90 forbids mixed declarations and code
      
      Caused by commit 719c1514 ("memblock/arm: Use new accessors")
      which forgot a closing brace on a new for_each_memblock() in
      arm_memory_present().
      Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Russell King <linux@arm.linux.org.uk>
      LKML-Reference: <4C91C544.5050907@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      7c996361
  12. 08 9月, 2010 2 次提交
    • R
      ARM: Ensure PTE modifications via dma_alloc_coherent are visible · 2be23c47
      Russell King 提交于
      Dave Hylands reports:
      | We've observed a problem with dma_alloc_writecombine when the system
      | is under heavy load (heavy bus traffic).  We've managed to reduce the
      | problem to the following snippet, which is run from a kthread in a
      | continuous loop:
      |
      |   void *virtAddr;
      |   dma_addr_t physAddr;
      |   unsigned int numBytes = 256;
      |
      |   for (;;) {
      |       virtAddr = dma_alloc_writecombine(NULL,
      |             numBytes, &physAddr, GFP_KERNEL);
      |       if (virtAddr == NULL) {
      |          printk(KERN_ERR "Running out of memory\n");
      |          break;
      |       }
      |
      |       /* access DMA memory allocated */
      |       tmp = virtAddr;
      |       *tmp = 0x77;
      |
      |       /* free DMA memory */
      |       dma_free_writecombine(NULL,
      |             numBytes, virtAddr, physAddr);
      |
      |         ...sleep here...
      |     }
      |
      | By itself, the code will run forever with no issues. However, as we
      | increase our bus traffic (typically using DMA) then the *tmp = 0x77
      | line will eventually cause a page fault. If we add a small delay (a
      | few microseconds) before the *tmp = 0x77, then we don't see a page
      | fault, even under heavy load.
      
      A dsb() is required after modifying the PTE entries to ensure that they
      will always be visible.  Add this dsb().
      Reported-by: NDave Hylands <dhylands@gmail.com>
      Tested-by: NDave Hylands <dhylands@gmail.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      2be23c47
    • W
      ARM: 6355/1: hw-breakpoint: add mechanism for hooking into prefetch aborts · 3a4b5dca
      Will Deacon 提交于
      On ARM processors with hardware breakpoint and watchpoint support,
      triggering these events results in a debug exception. These manifest
      as prefetch and data aborts respectively.
      
      arch/arm/mm/fault.c already provides hook_fault_code for hooking
      into data aborts dependent on the DFSR. This patch adds a new function,
      hook_ifault_code for hooking into prefetch aborts in the same manner.
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: S. Karthikeyan <informkarthik@gmail.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      3a4b5dca
  13. 02 9月, 2010 1 次提交
  14. 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
  15. 06 8月, 2010 1 次提交
  16. 05 8月, 2010 2 次提交
  17. 04 8月, 2010 2 次提交
  18. 31 7月, 2010 1 次提交
  19. 29 7月, 2010 1 次提交