1. 04 3月, 2014 1 次提交
  2. 21 2月, 2014 1 次提交
  3. 22 1月, 2014 1 次提交
  4. 10 5月, 2013 2 次提交
  5. 10 4月, 2013 1 次提交
  6. 04 3月, 2013 7 次提交
  7. 25 2月, 2013 1 次提交
  8. 24 2月, 2013 1 次提交
  9. 04 2月, 2013 8 次提交
  10. 08 1月, 2013 1 次提交
  11. 03 12月, 2012 1 次提交
    • A
      open*(2) compat fixes (s390, arm64) · 9d73fc2d
      Al Viro 提交于
      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: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9d73fc2d
  12. 01 10月, 2012 1 次提交
  13. 26 9月, 2012 2 次提交
    • H
      c0162b07
    • J
      s390: add support for runtime instrumentation · e4b8b3f3
      Jan Glauber 提交于
      Allow user-space threads to use runtime instrumentation (RI). To enable RI
      for a thread there is a new s390 specific system call, sys_s390_runtime_instr,
      that takes as parameter a realtime signal number. If the RI facility is
      available the system call sets up a control block for the calling thread with
      the appropriate permissions for the thread to modify the control block.
      
      The user-space thread can then use the store and modify RI instructions to
      alter the control block and start/stop the instrumentation via RION/RIOFF.
      
      If the user specified program buffer runs full RI triggers an external
      interrupt. The external interrupt is translated to a real-time signal that
      is delivered to the thread that enabled RI on that CPU. The number of
      the real-time signal is the number specified in the RI system call. So,
      user-space can select any available real-time signal number in case the
      application itself uses real-time signals for other purposes.
      
      The kernel saves the RI control blocks on task switch only if the running
      thread was enabled for RI. Therefore, the performance impact on task switch
      should be negligible if RI is not used.
      
      RI is only enabled for user-space mode and is disabled for the supervisor
      state.
      Reviewed-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NJan Glauber <jang@linux.vnet.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      e4b8b3f3
  14. 08 8月, 2012 1 次提交
  15. 20 7月, 2012 1 次提交
    • H
      s390/comments: unify copyright messages and remove file names · a53c8fab
      Heiko Carstens 提交于
      Remove the file name from the comment at top of many files. In most
      cases the file name was wrong anyway, so it's rather pointless.
      
      Also unify the IBM copyright statement. We did have a lot of sightly
      different statements and wanted to change them one after another
      whenever a file gets touched. However that never happened. Instead
      people start to take the old/"wrong" statements to use as a template
      for new files.
      So unify all of them in one go.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      a53c8fab
  16. 22 2月, 2012 1 次提交
    • L
      sys_poll: fix incorrect type for 'timeout' parameter · faf30900
      Linus Torvalds 提交于
      The 'poll()' system call timeout parameter is supposed to be 'int', not
      'long'.
      
      Now, the reason this matters is that right now 32-bit compat mode is
      broken on at least x86-64, because the 32-bit code just calls
      'sys_poll()' directly on x86-64, and the 32-bit argument will have been
      zero-extended, turning a signed 'int' into a large unsigned 'long'
      value.
      
      We could just introduce a 'compat_sys_poll()' function for this, and
      that may eventually be what we have to do, but since the actual standard
      poll() semantics is *supposed* to be 'int', and since at least on x86-64
      glibc sign-extends the argument before invocing the system call (so
      nobody can actually use a 64-bit timeout value in user space _anyway_,
      even in 64-bit binaries), the simpler solution would seem to be to just
      fix the definition of the system call to match what it should have been
      from the very start.
      
      If it turns out that somebody somehow circumvents the user-level libc
      64-bit sign extension and actually uses a large unsigned 64-bit timeout
      despite that not being how poll() is supposed to work, we will need to
      do the compat_sys_poll() approach.
      Reported-by: NThomas Meyer <thomas@m3y3r.de>
      Acked-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      faf30900
  17. 14 11月, 2011 1 次提交
  18. 30 10月, 2011 1 次提交
  19. 27 8月, 2011 1 次提交
  20. 24 7月, 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. 23 3月, 2011 4 次提交