1. 14 Feb, 2013 2 commits
  2. 15 Jan, 2013 1 commit
  3. 10 Jan, 2013 2 commits
  4. 02 Jan, 2013 1 commit
  5. 19 Dec, 2012 2 commits
    • Al Viro's avatar
      new helper: compat_user_stack_pointer() · 9b064fc3
      Al Viro authored
      Compat counterpart of current_user_stack_pointer(); for most of the biarch
      architectures those two are identical, but e.g. arm64 and arm use different
      registers for stack pointer...
      Note that amd64 variants of current_user_stack_pointer/compat_user_stack_pointer
      do *not* rely on pt_regs having been through FIXUP_TOP_OF_STACK.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
    • Al Viro's avatar
      Bury the conditionals from kernel_thread/kernel_execve series · ae903caa
      Al Viro authored
      All architectures have
      None of them have __ARCH_WANT_KERNEL_EXECVE and there are only two callers
      of kernel_execve() (which is a trivial wrapper for do_execve() now) left.
      Kill the conditionals and make both callers use do_execve().
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
  6. 17 Dec, 2012 1 commit
  7. 05 Dec, 2012 8 commits
  8. 02 Dec, 2012 1 commit
    • Al Viro's avatar
      open*(2) compat fixes (s390, arm64) · 9d73fc2d
      Al Viro authored
      The usual rules for open()/openat()/open_by_handle_at() are
       1) native 32bit - don't force O_LARGEFILE in flags
       2) native 64bit - force O_LARGEFILE in flags
       3) compat on 64bit host - as for native 32bit
       4) native 32bit ABI for 64bit system (mips/n32, x86/x32) - as for
          native 64bit
      There are only two exceptions - s390 compat has open() forcing
      O_LARGEFILE and arm64 compat has open_by_handle_at() doing the same
      thing.  The same binaries on native host (s390/31 and arm resp.) will
      *not* force O_LARGEFILE, so IMO both are emulation bugs.
      Objections? The fix is obvious...
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  9. 29 Nov, 2012 1 commit
  10. 28 Nov, 2012 3 commits
  11. 23 Nov, 2012 2 commits
  12. 16 Nov, 2012 1 commit
  13. 13 Nov, 2012 1 commit
  14. 08 Nov, 2012 3 commits
  15. 23 Oct, 2012 2 commits
  16. 22 Oct, 2012 1 commit
  17. 20 Oct, 2012 1 commit
    • Marc Zyngier's avatar
      arm64: fix alignment padding in assembly code · aeed41a9
      Marc Zyngier authored
      An interesting effect of using the generic version of linkage.h
      is that the padding is defined in terms of x86 NOPs, which can have
      even more interesting effects when the assembly code looks like this:
      	mov	x0, xzr
      	// fall through
      	mov	x0, #1
      Admittedly, the code is not very nice. But having code from another
      architecture doesn't look completely sane either.
      The fix is to add arm64's version of linkage.h, which causes the insertion
      of proper AArch64 NOPs.
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
  18. 18 Oct, 2012 1 commit
    • Catalin Marinas's avatar
      arm64: No need to set the x0-x2 registers in start_thread() · 16dd46bb
      Catalin Marinas authored
      For historical reasons, ARM used to set r0-r2 in start_thread() to the
      first values on the user stack when starting a new user application. The
      same logic has been inherited in AArch64. The x0 register is overridden
      by the sys_execve() return value so it's always zero on success. The x1
      and x2 registers are ignored by AArch64 and EABI AArch32 applications,
      so we can safely remove the register setting for both native and compat
      user space.
      This also fixes a potential fault with the kernel accessing user space
      stack directly.
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Reported-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
  19. 17 Oct, 2012 2 commits
  20. 11 Oct, 2012 4 commits