1. 20 Aug, 2010 1 commit
  2. 13 Aug, 2010 1 commit
  3. 10 Aug, 2010 4 commits
  4. 05 Aug, 2010 5 commits
  5. 27 Jul, 2010 6 commits
  6. 18 Jul, 2010 2 commits
  7. 16 Jul, 2010 1 commit
  8. 14 Jul, 2010 1 commit
  9. 10 Jul, 2010 1 commit
    • Russell King's avatar
      ARM: lockdep: fix unannotated irqs-on · ac78884e
      Russell King authored
      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: default avatarMing Lei <tom.leiming@gmail.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      ac78884e
  10. 09 Jul, 2010 8 commits
  11. 07 Jul, 2010 1 commit
  12. 04 Jul, 2010 1 commit
    • Will Deacon's avatar
      ARM: 6205/1: perf: ensure counter delta is treated as unsigned · 446a5a8b
      Will Deacon authored
      
      
      Hardware performance counters on ARM are 32-bits wide but atomic64_t
      variables are used to represent counter data in the hw_perf_event structure.
      
      The armpmu_event_update function right-shifts a signed 64-bit delta variable
      and adds the result to the event count. This can lead to shifting in sign-bits
      if the MSB of the 32-bit counter value is set. This results in perf output
      such as:
      
       Performance counter stats for 'sleep 20':
      
       18446744073460670464  cycles             <-- 0xFFFFFFFFF12A6000
              7783773  instructions             #      0.000 IPC
                  465  context-switches
                  161  page-faults
              1172393  branches
      
         20.154242147  seconds time elapsed
      
      This patch ensures that the delta value is treated as unsigned so that the
      right shift sets the upper bits to zero.
      
      Cc: <stable@kernel.org>
      Acked-by: default avatarJamie Iles <jamie.iles@picochip.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      446a5a8b
  13. 15 Jun, 2010 3 commits
    • Nicolas Pitre's avatar
      ARM: stack protector: change the canary value per task · df0698be
      Nicolas Pitre authored
      
      
      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: default avatarNicolas Pitre <nicolas.pitre@linaro.org>
      df0698be
    • Nicolas Pitre's avatar
      ARM: initial stack protector (-fstack-protector) support · c743f380
      Nicolas Pitre authored
      
      
      This is the very basic stuff without the changing canary upon
      task switch yet.  Just the Kconfig option and a constant canary
      value initialized at boot time.
      Signed-off-by: default avatarNicolas Pitre <nicolas.pitre@linaro.org>
      c743f380
    • Nicolas Pitre's avatar
      [ARM] implement arch_randomize_brk() · 990cb8ac
      Nicolas Pitre authored
      
      
      For this feature to take effect, CONFIG_COMPAT_BRK must be turned
      off.  This can safely be turned off for any EABI user space versions.
      Signed-off-by: default avatarNicolas Pitre <nicolas.pitre@linaro.org>
      990cb8ac
  14. 09 Jun, 2010 1 commit
  15. 24 May, 2010 2 commits
  16. 21 May, 2010 1 commit
    • Jason Wessel's avatar
      kgdb: core changes to support kdb · dcc78711
      Jason Wessel authored
      
      
      These are the minimum changes to the kgdb core in order to enable an
      API to connect a new front end (kdb) to the debug core.
      
      This patch introduces the dbg_kdb_mode variable controls where the
      user level I/O is routed.  It will be routed to the gdbstub (kgdb) or
      to the kdb front end which is a simple shell available over the kgdboc
      connection.
      
      You can switch back and forth between kdb or the gdb stub mode of
      operation dynamically.  From gdb stub mode you can blindly type
      "$3#33", or from the kdb mode you can enter "kgdb" to switch to the
      gdb stub.
      
      The logic in the debug core depends on kdb to look for the typical gdb
      connection sequences and return immediately with KGDB_PASS_EVENT if a
      gdb serial command sequence is detected.  That should allow a
      reasonably seamless transition between kdb -> gdb without leaving the
      kernel exception state.  The two gdb serial queries that kdb is
      responsible for detecting are the "?" and "qSupported" packets.
      
      CC: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarJason Wessel <jason.wessel@windriver.com>
      Acked-by: default avatarMartin Hicks <mort@sgi.com>
      dcc78711
  17. 17 May, 2010 1 commit