1. 17 2月, 2015 1 次提交
  2. 11 11月, 2014 2 次提交
    • H
      parisc: Use compat layer for msgctl, shmat, shmctl and semtimedop syscalls · 2fe749f5
      Helge Deller 提交于
      Switch over the msgctl, shmat, shmctl and semtimedop syscalls to use the compat
      layer. The problem was found with the debian procenv package, which called
      	shmctl(0, SHM_INFO, &info);
      in which the shmctl syscall then overwrote parts of the surrounding areas on
      the stack on which the info variable was stored and thus lead to a segfault
      later on.
      
      Additionally fix the definition of struct shminfo64 to use unsigned longs like
      the other architectures. This has no impact on userspace since we only have a
      32bit userspace up to now.
      Signed-off-by: NHelge Deller <deller@gmx.de>
      Cc: John David Anglin <dave.anglin@bell.net>
      Cc: <stable@vger.kernel.org> # v3.10+
      2fe749f5
    • H
      parisc: Wire up bpf syscall · e6be7bb8
      Helge Deller 提交于
      Signed-off-by: NHelge Deller <deller@gmx.de>
      e6be7bb8
  3. 27 8月, 2014 1 次提交
  4. 13 7月, 2014 1 次提交
    • H
      parisc: fix fanotify_mark() syscall on 32bit compat kernel · ab8a261b
      Helge Deller 提交于
      On parisc we can not use the existing compat implementation for fanotify_mark()
      because for the 64bit mask parameter the higher and lower 32bits are ordered
      differently than what the compat function expects from big endian
      architectures.
      
      Specifically:
      It finally turned out, that on hppa we end up with different assignments
      of parameters to kernel arguments depending on if we call the glibc
      wrapper function
       int fanotify_mark (int __fanotify_fd, unsigned int __flags,
                          uint64_t __mask, int __dfd, const char *__pathname);
      or directly calling the syscall manually
       syscall(__NR_fanotify_mark, ...)
      
      Reason is, that the syscall() function is implemented as C-function and
      because we now have the sysno as first parameter in front of the other
      parameters the compiler will unexpectedly add an empty paramenter in
      front of the u64 value to ensure the correct calling alignment for 64bit
      values.
      This means, on hppa you can't simply use syscall() to call the kernel
      fanotify_mark() function directly, but you have to use the glibc
      function instead.
      
      This patch fixes the kernel in the hppa-arch specifc coding to adjust
      the parameters in a way as if userspace calls the glibc wrapper function
      fanotify_mark().
      Signed-off-by: NHelge Deller <deller@gmx.de>
      Cc: stable@vger.kernel.org # 3.13+
      ab8a261b
  5. 24 5月, 2014 1 次提交
  6. 20 5月, 2014 1 次提交
  7. 13 4月, 2014 1 次提交
  8. 23 3月, 2014 1 次提交
    • H
      parisc: wire up sys_utimes · e9af8b7a
      Helge Deller 提交于
      We seem to be nearly the only platform which does not provide the
      sys_utimes syscall.  Adding it now makes our life much easier with
      userspace applications (like dietlibc and e2fsprogs) since we then
      behave like all other platforms too and don't need extra patches which
      are hard to get upstream anyway because we are not a mainstream
      architecture.
      Signed-off-by: NHelge Deller <deller@gmx.de>
      Cc: stable@vger.kernel.org # v3.13
      e9af8b7a
  9. 03 2月, 2014 1 次提交
  10. 06 3月, 2013 1 次提交
  11. 04 3月, 2013 2 次提交
  12. 03 3月, 2013 1 次提交
  13. 25 2月, 2013 1 次提交
  14. 24 2月, 2013 1 次提交
  15. 21 2月, 2013 6 次提交
  16. 04 2月, 2013 5 次提交
  17. 04 12月, 2012 1 次提交
    • A
      [parisc] open(2) compat bug · 25a3bc6b
      Al Viro 提交于
      In commit 9d73fc2d ("open*(2) compat fixes (s390, arm64)") I said:
      >
      > 	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.
      
      Three exceptions, actually - parisc open() is another case like that.
      Native 32bit won't force O_LARGEFILE, the same binary on parisc64 will.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      25a3bc6b
  18. 15 10月, 2012 1 次提交
  19. 30 8月, 2011 1 次提交
  20. 01 8月, 2011 1 次提交
  21. 29 5月, 2011 1 次提交
    • E
      ns: Wire up the setns system call · 7b21fddd
      Eric W. Biederman 提交于
      32bit and 64bit on x86 are tested and working.  The rest I have looked
      at closely and I can't find any problems.
      
      setns is an easy system call to wire up.  It just takes two ints so I
      don't expect any weird architecture porting problems.
      
      While doing this I have noticed that we have some architectures that are
      very slow to get new system calls.  cris seems to be the slowest where
      the last system calls wired up were preadv and pwritev.  avr32 is weird
      in that recvmmsg was wired up but never declared in unistd.h.  frv is
      behind with perf_event_open being the last syscall wired up.  On h8300
      the last system call wired up was epoll_wait.  On m32r the last system
      call wired up was fallocate.  mn10300 has recvmmsg as the last system
      call wired up.  The rest seem to at least have syncfs wired up which was
      new in the 2.6.39.
      
      v2: Most of the architecture support added by Daniel Lezcano <dlezcano@fr.ibm.com>
      v3: ported to v2.6.36-rc4 by: Eric W. Biederman <ebiederm@xmission.com>
      v4: Moved wiring up of the system call to another patch
      v5: ported to v2.6.39-rc6
      v6: rebased onto parisc-next and net-next to avoid syscall  conflicts.
      v7: ported to Linus's latest post 2.6.39 tree.
      
      >  arch/blackfin/include/asm/unistd.h     |    3 ++-
      >  arch/blackfin/mach-common/entry.S      |    1 +
      Acked-by: NMike Frysinger <vapier@gentoo.org>
      
      Oh - ia64 wiring looks good.
      Acked-by: NTony Luck <tony.luck@intel.com>
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7b21fddd
  22. 16 4月, 2011 4 次提交
  23. 31 3月, 2011 1 次提交
  24. 14 10月, 2010 1 次提交
  25. 13 3月, 2010 1 次提交
    • C
      improve sys_newuname() for compat architectures · e28cbf22
      Christoph Hellwig 提交于
      On an architecture that supports 32-bit compat we need to override the
      reported machine in uname with the 32-bit value.  Instead of doing this
      separately in every architecture introduce a COMPAT_UTS_MACHINE define in
      <asm/compat.h> and apply it directly in sys_newuname().
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Hirokazu Takata <takata@linux-m32r.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: James Morris <jmorris@namei.org>
      Cc: Andreas Schwab <schwab@linux-m68k.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e28cbf22
  26. 07 3月, 2010 1 次提交