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>
      9b064fc3
    • Al Viro's avatar
      Bury the conditionals from kernel_thread/kernel_execve series · ae903caa
      Al Viro authored
      All architectures have
      	CONFIG_GENERIC_KERNEL_THREAD
      	CONFIG_GENERIC_KERNEL_EXECVE
      	__ARCH_WANT_SYS_EXECVE
      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>
      ae903caa
  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>
      9d73fc2d
  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:
      
      ENTRY(func1)
      	mov	x0, xzr
      ENDPROC(func1)
      	// fall through
      ENTRY(func2)
      	mov	x0, #1
      	ret
      ENDPROC(func2)
      
      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>
      aeed41a9
  18. 18 Oct, 2012 2 commits
  19. 17 Oct, 2012 2 commits
  20. 11 Oct, 2012 3 commits