1. 02 9月, 2010 3 次提交
  2. 18 8月, 2010 1 次提交
    • D
      Make do_execve() take a const filename pointer · d7627467
      David Howells 提交于
      Make do_execve() take a const filename pointer so that kernel_execve() compiles
      correctly on ARM:
      
      arch/arm/kernel/sys_arm.c:88: warning: passing argument 1 of 'do_execve' discards qualifiers from pointer target type
      
      This also requires the argv and envp arguments to be consted twice, once for
      the pointer array and once for the strings the array points to.  This is
      because do_execve() passes a pointer to the filename (now const) to
      copy_strings_kernel().  A simpler alternative would be to cast the filename
      pointer in do_execve() when it's passed to copy_strings_kernel().
      
      do_execve() may not change any of the strings it is passed as part of the argv
      or envp lists as they are some of them in .rodata, so marking these strings as
      const should be fine.
      
      Further kernel_execve() and sys_execve() need to be changed to match.
      
      This has been test built on x86_64, frv, arm and mips.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Tested-by: NRalf Baechle <ralf@linux-mips.org>
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d7627467
  3. 17 8月, 2010 1 次提交
  4. 16 8月, 2010 1 次提交
    • M
      ARM: 6329/1: wire up sys_accept4() on ARM · 21d93e2e
      Mikael Pettersson 提交于
      sys_accept4() was added in kernel 2.6.28, but ARM was not updated
      to include it.  The number and types of parameters is such that
      no ARM-specific processing is needed, so wiring up sys_accept4()
      just requires defining __NR_accept4 and adding a direct call in
      the syscall entry table.
      
      Tested with an EABI 2.6.35 kernel and Ulrich Drepper's original
      accept4() test program, modified to define __NR_accept4 for ARM.
      
      Using the updated unistd.h also eliminates a warning then building
      glibc (2.10.2 and newer) about accept4() being unimplemented.
      Signed-off-by: NMikael Pettersson <mikpe@it.uu.se>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      21d93e2e
  5. 14 8月, 2010 2 次提交
  6. 11 8月, 2010 4 次提交
  7. 05 8月, 2010 5 次提交
  8. 27 7月, 2010 6 次提交
  9. 19 7月, 2010 2 次提交
  10. 16 7月, 2010 1 次提交
  11. 15 7月, 2010 1 次提交
  12. 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
  13. 09 7月, 2010 8 次提交
  14. 07 7月, 2010 1 次提交
  15. 05 7月, 2010 1 次提交
    • W
      ARM: 6205/1: perf: ensure counter delta is treated as unsigned · 446a5a8b
      Will Deacon 提交于
      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: NJamie Iles <jamie.iles@picochip.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      446a5a8b
  16. 15 6月, 2010 2 次提交
    • 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
    • N
      ARM: initial stack protector (-fstack-protector) support · c743f380
      Nicolas Pitre 提交于
      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: NNicolas Pitre <nicolas.pitre@linaro.org>
      c743f380