1. 06 12月, 2010 1 次提交
    • W
      ARM: hw_breakpoint: disable preemption during debug exception handling · 7e202696
      Will Deacon 提交于
      On ARM, debug exceptions occur in the form of data or prefetch aborts.
      One difference is that debug exceptions require access to per-cpu banked
      registers and data structures which are not saved in the low-level exception
      code. For kernels built with CONFIG_PREEMPT, there is an unlikely scenario
      that the debug handler ends up running on a different CPU from the one
      that originally signalled the event, resulting in random data being read
      from the wrong registers.
      
      This patch adds a debug_entry macro to the low-level exception handling
      code which checks whether the taken exception is a debug exception. If
      it is, the preempt count for the faulting process is incremented. After
      the debug handler has finished, the count is decremented.
      Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      7e202696
  2. 05 10月, 2010 1 次提交
    • R
      ARM: Allow SMP kernels to boot on UP systems · f00ec48f
      Russell King 提交于
      UP systems do not implement all the instructions that SMP systems have,
      so in order to boot a SMP kernel on a UP system, we need to rewrite
      parts of the kernel.
      
      Do this using an 'alternatives' scheme, where the kernel code and data
      is modified prior to initialization to replace the SMP instructions,
      thereby rendering the problematical code ineffectual.  We use the linker
      to generate a list of 32-bit word locations and their replacement values,
      and run through these replacements when we detect a UP system.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      f00ec48f
  3. 10 7月, 2010 1 次提交
    • R
      ARM: lockdep: fix unannotated irqs-on · ac78884e
      Russell King 提交于
      CPU: Testing write buffer coherency: ok
      ------------[ cut here ]------------
      WARNING: at kernel/lockdep.c:3145 check_flags+0xcc/0x1dc()
      Modules linked in:
      [<c0035120>] (unwind_backtrace+0x0/0xf8) from [<c0355374>] (dump_stack+0x20/0x24)
      [<c0355374>] (dump_stack+0x20/0x24) from [<c0060c04>] (warn_slowpath_common+0x58/0x70)
      [<c0060c04>] (warn_slowpath_common+0x58/0x70) from [<c0060c3c>] (warn_slowpath_null+0x20/0x24)
      [<c0060c3c>] (warn_slowpath_null+0x20/0x24) from [<c008f224>] (check_flags+0xcc/0x1dc)
      [<c008f224>] (check_flags+0xcc/0x1dc) from [<c00945dc>] (lock_acquire+0x50/0x140)
      [<c00945dc>] (lock_acquire+0x50/0x140) from [<c0358434>] (_raw_spin_lock+0x50/0x88)
      [<c0358434>] (_raw_spin_lock+0x50/0x88) from [<c00fd114>] (set_task_comm+0x2c/0x60)
      [<c00fd114>] (set_task_comm+0x2c/0x60) from [<c007e184>] (kthreadd+0x30/0x108)
      [<c007e184>] (kthreadd+0x30/0x108) from [<c0030104>] (kernel_thread_exit+0x0/0x8)
      ---[ end trace 1b75b31a2719ed1c ]---
      possible reason: unannotated irqs-on.
      irq event stamp: 3
      hardirqs last  enabled at (2): [<c0059bb0>] finish_task_switch+0x48/0xb0
      hardirqs last disabled at (3): [<c002f0b0>] ret_slow_syscall+0xc/0x1c
      softirqs last  enabled at (0): [<c005f3e0>] copy_process+0x394/0xe5c
      softirqs last disabled at (0): [<(null)>] (null)
      
      Fix this by ensuring that the lockdep interrupt state is manipulated in
      the appropriate places.  We essentially treat userspace as an entirely
      separate environment which isn't relevant to lockdep (lockdep doesn't
      monitor userspace.)  We don't tell lockdep that IRQs will be enabled
      in that environment.
      
      Instead, when creating kernel threads (which is a rare event compared
      to entering/leaving userspace) we have to update the lockdep state.  Do
      this by starting threads with IRQs disabled, and in the kthread helper,
      tell lockdep that IRQs are enabled, and enable them.
      
      This provides lockdep with a consistent view of the current IRQ state
      in kernel space.
      
      This also revert portions of 0d928b0b
      which didn't fix the problem.
      Tested-by: NMing Lei <tom.leiming@gmail.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      ac78884e
  4. 09 7月, 2010 1 次提交
  5. 15 6月, 2010 1 次提交
    • N
      ARM: stack protector: change the canary value per task · df0698be
      Nicolas Pitre 提交于
      A new random value for the canary is stored in the task struct whenever
      a new task is forked.  This is meant to allow for different canary values
      per task.  On ARM, GCC expects the canary value to be found in a global
      variable called __stack_chk_guard.  So this variable has to be updated
      with the value stored in the task struct whenever a task switch occurs.
      
      Because the variable GCC expects is global, this cannot work on SMP
      unfortunately.  So, on SMP, the same initial canary value is kept
      throughout, making this feature a bit less effective although it is still
      useful.
      
      One way to overcome this GCC limitation would be to locate the
      __stack_chk_guard variable into a memory page of its own for each CPU,
      and then use TLB locking to have each CPU see its own page at the same
      virtual address for each of them.
      Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
      df0698be
  6. 01 5月, 2010 1 次提交
  7. 21 4月, 2010 1 次提交
    • R
      ARM: fix build error in arch/arm/kernel/process.c · 4260415f
      Russell King 提交于
      /tmp/ccJ3ssZW.s: Assembler messages:
      /tmp/ccJ3ssZW.s:1952: Error: can't resolve `.text' {.text section} - `.LFB1077'
      
      This is caused because:
      
      	.section .data
      	.section .text
      	.section .text
      	.previous
      
      does not return us to the .text section, but the .data section; this
      makes use of .previous dangerous if the ordering of previous sections
      is not known.
      
      Fix up the other users of .previous; .pushsection and .popsection are
      a safer pairing to use than .section and .previous.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      4260415f
  8. 13 1月, 2010 1 次提交
  9. 10 11月, 2009 1 次提交
  10. 14 10月, 2009 1 次提交
  11. 03 10月, 2009 1 次提交
  12. 19 9月, 2009 2 次提交
  13. 14 8月, 2009 1 次提交
  14. 24 7月, 2009 2 次提交
  15. 30 5月, 2009 1 次提交
    • C
      Add core support for ARMv6/v7 big-endian · 26584853
      Catalin Marinas 提交于
      Starting with ARMv6, the CPUs support the BE-8 variant of big-endian
      (byte-invariant). This patch adds the core support:
      
      - setting of the BE-8 mode via the CPSR.E register for both kernel and
        user threads
      - big-endian page table walking
      - REV used to rotate instructions read from memory during fault
        processing as they are still little-endian format
      - Kconfig and Makefile support for BE-8. The --be8 option must be passed
        to the final linking stage to convert the instructions to
        little-endian
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      26584853
  16. 29 5月, 2009 1 次提交
  17. 19 2月, 2009 1 次提交
  18. 28 1月, 2009 1 次提交
  19. 01 9月, 2008 1 次提交
  20. 07 8月, 2008 1 次提交
  21. 19 4月, 2008 3 次提交
  22. 26 1月, 2008 4 次提交
  23. 27 11月, 2007 2 次提交
  24. 17 2月, 2007 1 次提交
  25. 07 2月, 2007 1 次提交
    • R
      [ARM] Move processor_modes[] to .../process.c · ae0a846e
      Russell King 提交于
      bad_mode() currently prints the mode which caused the exception, and
      then causes an oops dump to be printed which again displays this
      information (since the CPSR in the struct pt_regs is correct.)  This
      leads to processor_modes[] being shared between traps.c and process.c
      with a local declaration of it.
      
      We can clean this up by moving processor_modes[] to process.c and
      removing the duplication, resulting in processor_modes[] becoming
      static.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      ae0a846e
  26. 07 1月, 2007 1 次提交
  27. 04 12月, 2006 1 次提交
    • L
      [ARM] 3881/4: xscale: clean up cp0/cp1 handling · afe4b25e
      Lennert Buytenhek 提交于
      XScale cores either have a DSP coprocessor (which contains a single
      40 bit accumulator register), or an iWMMXt coprocessor (which contains
      eight 64 bit registers.)
      
      Because of the small amount of state in the DSP coprocessor, access to
      the DSP coprocessor (CP0) is always enabled, and DSP context switching
      is done unconditionally on every task switch.  Access to the iWMMXt
      coprocessor (CP0/CP1) is enabled only when an iWMMXt instruction is
      first issued, and iWMMXt context switching is done lazily.
      
      CONFIG_IWMMXT is supposed to mean 'the cpu we will be running on will
      have iWMMXt support', but boards are supposed to select this config
      symbol by hand, and at least one pxa27x board doesn't get this right,
      so on that board, proc-xscale.S will incorrectly assume that we have a
      DSP coprocessor, enable CP0 on boot, and we will then only save the
      first iWMMXt register (wR0) on context switches, which is Bad.
      
      This patch redefines CONFIG_IWMMXT as 'the cpu we will be running on
      might have iWMMXt support, and we will enable iWMMXt context switching
      if it does.'  This means that with this patch, running a CONFIG_IWMMXT=n
      kernel on an iWMMXt-capable CPU will no longer potentially corrupt iWMMXt
      state over context switches, and running a CONFIG_IWMMXT=y kernel on a
      non-iWMMXt capable CPU will still do DSP context save/restore.
      
      These changes should make iWMMXt work on PXA3xx, and as a side effect,
      enable proper acc0 save/restore on non-iWMMXt capable xsc3 cores such
      as IOP13xx and IXP23xx (which will not have CONFIG_CPU_XSCALE defined),
      as well as setting and using HWCAP_IWMMXT properly.
      Signed-off-by: NLennert Buytenhek <buytenh@wantstofly.org>
      Acked-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      afe4b25e
  28. 20 9月, 2006 1 次提交
  29. 19 8月, 2006 1 次提交
  30. 02 7月, 2006 1 次提交
  31. 01 7月, 2006 1 次提交
  32. 29 6月, 2006 1 次提交