1. 31 Jan, 2018 1 commit
    • Jiri Slaby's avatar
      fs/fcntl: f_setown, avoid undefined behaviour · 7b50205c
      Jiri Slaby authored
      commit fc3dc674 upstream.
      
      fcntl(0, F_SETOWN, 0x80000000) triggers:
      UBSAN: Undefined behaviour in fs/fcntl.c:118:7
      negation of -2147483648 cannot be represented in type 'int':
      CPU: 1 PID: 18261 Comm: syz-executor Not tainted 4.8.1-0-syzkaller #1
      ...
      Call Trace:
      ...
       [<ffffffffad8f0868>] ? f_setown+0x1d8/0x200
       [<ffffffffad8f19a9>] ? SyS_fcntl+0x999/0xf30
       [<ffffffffaed1fb00>] ? entry_SYSCALL_64_fastpath+0x23/0xc1
      
      Fix that by checking the arg parameter properly (against INT_MAX) before
      "who = -who". And return immediatelly with -EINVAL in case it is wrong.
      Note that according to POSIX we can return EINVAL:
          http://pubs.opengroup.org/onlinepubs/9699919799/functions/fcntl.html
      
          [EINVAL]
              The cmd argument is F_SETOWN and the value of the argument
              is not valid as a process or process group identifier.
      
      [v2] returns an error, v1 used to fail silently
      [v3] implement proper check for the bad value INT_MIN
      Signed-off-by: 's avatarJiri Slaby <jslaby@suse.cz>
      Cc: Jeff Layton <jlayton@poochiereds.net>
      Cc: "J. Bruce Fields" <bfields@fieldses.org>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: linux-fsdevel@vger.kernel.org
      Signed-off-by: 's avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7b50205c
  2. 12 Jul, 2017 1 commit
  3. 09 Jan, 2016 1 commit
  4. 08 Jan, 2015 1 commit
    • David Drysdale's avatar
      vfs: renumber FMODE_NONOTIFY and add to uniqueness check · 75069f2b
      David Drysdale authored
      Fix clashing values for O_PATH and FMODE_NONOTIFY on sparc.  The
      clashing O_PATH value was added in commit 5229645b ("vfs: add
      nonconflicting values for O_PATH") but this can't be changed as it is
      user-visible.
      
      FMODE_NONOTIFY is only used internally in the kernel, but it is in the
      same numbering space as the other O_* flags, as indicated by the comment
      at the top of include/uapi/asm-generic/fcntl.h (and its use in
      fs/notify/fanotify/fanotify_user.c).  So renumber it to avoid the clash.
      
      All of this has happened before (commit 12ed2e36: "fanotify:
      FMODE_NONOTIFY and __O_SYNC in sparc conflict"), and all of this will
      happen again -- so update the uniqueness check in fcntl_init() to
      include __FMODE_NONOTIFY.
      Signed-off-by: 's avatarDavid Drysdale <drysdale@google.com>
      Acked-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Acked-by: 's avatarJan Kara <jack@suse.cz>
      Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: Eric Paris <eparis@redhat.com>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      75069f2b
  5. 09 Sep, 2014 1 commit
  6. 08 Aug, 2014 1 commit
    • David Herrmann's avatar
      shm: add sealing API · 40e041a2
      David Herrmann authored
      If two processes share a common memory region, they usually want some
      guarantees to allow safe access. This often includes:
        - one side cannot overwrite data while the other reads it
        - one side cannot shrink the buffer while the other accesses it
        - one side cannot grow the buffer beyond previously set boundaries
      
      If there is a trust-relationship between both parties, there is no need
      for policy enforcement.  However, if there's no trust relationship (eg.,
      for general-purpose IPC) sharing memory-regions is highly fragile and
      often not possible without local copies.  Look at the following two
      use-cases:
      
        1) A graphics client wants to share its rendering-buffer with a
           graphics-server. The memory-region is allocated by the client for
           read/write access and a second FD is passed to the server. While
           scanning out from the memory region, the server has no guarantee that
           the client doesn't shrink the buffer at any time, requiring rather
           cumbersome SIGBUS handling.
        2) A process wants to perform an RPC on another process. To avoid huge
           bandwidth consumption, zero-copy is preferred. After a message is
           assembled in-memory and a FD is passed to the remote side, both sides
           want to be sure that neither modifies this shared copy, anymore. The
           source may have put sensible data into the message without a separate
           copy and the target may want to parse the message inline, to avoid a
           local copy.
      
      While SIGBUS handling, POSIX mandatory locking and MAP_DENYWRITE provide
      ways to achieve most of this, the first one is unproportionally ugly to
      use in libraries and the latter two are broken/racy or even disabled due
      to denial of service attacks.
      
      This patch introduces the concept of SEALING.  If you seal a file, a
      specific set of operations is blocked on that file forever.  Unlike locks,
      seals can only be set, never removed.  Hence, once you verified a specific
      set of seals is set, you're guaranteed that no-one can perform the blocked
      operations on this file, anymore.
      
      An initial set of SEALS is introduced by this patch:
        - SHRINK: If SEAL_SHRINK is set, the file in question cannot be reduced
                  in size. This affects ftruncate() and open(O_TRUNC).
        - GROW: If SEAL_GROW is set, the file in question cannot be increased
                in size. This affects ftruncate(), fallocate() and write().
        - WRITE: If SEAL_WRITE is set, no write operations (besides resizing)
                 are possible. This affects fallocate(PUNCH_HOLE), mmap() and
                 write().
        - SEAL: If SEAL_SEAL is set, no further seals can be added to a file.
                This basically prevents the F_ADD_SEAL operation on a file and
                can be set to prevent others from adding further seals that you
                don't want.
      
      The described use-cases can easily use these seals to provide safe use
      without any trust-relationship:
      
        1) The graphics server can verify that a passed file-descriptor has
           SEAL_SHRINK set. This allows safe scanout, while the client is
           allowed to increase buffer size for window-resizing on-the-fly.
           Concurrent writes are explicitly allowed.
        2) For general-purpose IPC, both processes can verify that SEAL_SHRINK,
           SEAL_GROW and SEAL_WRITE are set. This guarantees that neither
           process can modify the data while the other side parses it.
           Furthermore, it guarantees that even with writable FDs passed to the
           peer, it cannot increase the size to hit memory-limits of the source
           process (in case the file-storage is accounted to the source).
      
      The new API is an extension to fcntl(), adding two new commands:
        F_GET_SEALS: Return a bitset describing the seals on the file. This
                     can be called on any FD if the underlying file supports
                     sealing.
        F_ADD_SEALS: Change the seals of a given file. This requires WRITE
                     access to the file and F_SEAL_SEAL may not already be set.
                     Furthermore, the underlying file must support sealing and
                     there may not be any existing shared mapping of that file.
                     Otherwise, EBADF/EPERM is returned.
                     The given seals are _added_ to the existing set of seals
                     on the file. You cannot remove seals again.
      
      The fcntl() handler is currently specific to shmem and disabled on all
      files. A file needs to explicitly support sealing for this interface to
      work. A separate syscall is added in a follow-up, which creates files that
      support sealing. There is no intention to support this on other
      file-systems. Semantics are unclear for non-volatile files and we lack any
      use-case right now. Therefore, the implementation is specific to shmem.
      Signed-off-by: 's avatarDavid Herrmann <dh.herrmann@gmail.com>
      Acked-by: 's avatarHugh Dickins <hughd@google.com>
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Cc: Ryan Lortie <desrt@desrt.ca>
      Cc: Lennart Poettering <lennart@poettering.net>
      Cc: Daniel Mack <zonque@gmail.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      40e041a2
  7. 22 Apr, 2014 1 commit
    • Jeff Layton's avatar
      locks: rename file-private locks to "open file description locks" · 0d3f7a2d
      Jeff Layton authored
      File-private locks have been merged into Linux for v3.15, and *now*
      people are commenting that the name and macro definitions for the new
      file-private locks suck.
      
      ...and I can't even disagree. The names and command macros do suck.
      
      We're going to have to live with these for a long time, so it's
      important that we be happy with the names before we're stuck with them.
      The consensus on the lists so far is that they should be rechristened as
      "open file description locks".
      
      The name isn't a big deal for the kernel, but the command macros are not
      visually distinct enough from the traditional POSIX lock macros. The
      glibc and documentation folks are recommending that we change them to
      look like F_OFD_{GETLK|SETLK|SETLKW}. That lessens the chance that a
      programmer will typo one of the commands wrong, and also makes it easier
      to spot this difference when reading code.
      
      This patch makes the following changes that I think are necessary before
      v3.15 ships:
      
      1) rename the command macros to their new names. These end up in the uapi
         headers and so are part of the external-facing API. It turns out that
         glibc doesn't actually use the fcntl.h uapi header, but it's hard to
         be sure that something else won't. Changing it now is safest.
      
      2) make the the /proc/locks output display these as type "OFDLCK"
      
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Carlos O'Donell <carlos@redhat.com>
      Cc: Stefan Metzmacher <metze@samba.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Frank Filz <ffilzlnx@mindspring.com>
      Cc: Theodore Ts'o <tytso@mit.edu>
      Signed-off-by: 's avatarJeff Layton <jlayton@redhat.com>
      0d3f7a2d
  8. 31 Mar, 2014 2 commits
    • Jeff Layton's avatar
      locks: add new fcntl cmd values for handling file private locks · 5d50ffd7
      Jeff Layton authored
      Due to some unfortunate history, POSIX locks have very strange and
      unhelpful semantics. The thing that usually catches people by surprise
      is that they are dropped whenever the process closes any file descriptor
      associated with the inode.
      
      This is extremely problematic for people developing file servers that
      need to implement byte-range locks. Developers often need a "lock
      management" facility to ensure that file descriptors are not closed
      until all of the locks associated with the inode are finished.
      
      Additionally, "classic" POSIX locks are owned by the process. Locks
      taken between threads within the same process won't conflict with one
      another, which renders them useless for synchronization between threads.
      
      This patchset adds a new type of lock that attempts to address these
      issues. These locks conflict with classic POSIX read/write locks, but
      have semantics that are more like BSD locks with respect to inheritance
      and behavior on close.
      
      This is implemented primarily by changing how fl_owner field is set for
      these locks. Instead of having them owned by the files_struct of the
      process, they are instead owned by the filp on which they were acquired.
      Thus, they are inherited across fork() and are only released when the
      last reference to a filp is put.
      
      These new semantics prevent them from being merged with classic POSIX
      locks, even if they are acquired by the same process. These locks will
      also conflict with classic POSIX locks even if they are acquired by
      the same process or on the same file descriptor.
      
      The new locks are managed using a new set of cmd values to the fcntl()
      syscall. The initial implementation of this converts these values to
      "classic" cmd values at a fairly high level, and the details are not
      exposed to the underlying filesystem. We may eventually want to push
      this handing out to the lower filesystem code but for now I don't
      see any need for it.
      
      Also, note that with this implementation the new cmd values are only
      available via fcntl64() on 32-bit arches. There's little need to
      add support for legacy apps on a new interface like this.
      Signed-off-by: 's avatarJeff Layton <jlayton@redhat.com>
      5d50ffd7
    • Jeff Layton's avatar
      locks: pass the cmd value to fcntl_getlk/getlk64 · c1e62b8f
      Jeff Layton authored
      Once we introduce file private locks, we'll need to know what cmd value
      was used, as that affects the ownership and whether a conflict would
      arise.
      Signed-off-by: 's avatarJeff Layton <jlayton@redhat.com>
      c1e62b8f
  9. 25 Oct, 2013 1 commit
  10. 05 Aug, 2013 1 commit
  11. 23 Feb, 2013 1 commit
  12. 09 Oct, 2012 1 commit
  13. 27 Sep, 2012 4 commits
  14. 31 Jul, 2012 1 commit
  15. 30 May, 2012 1 commit
  16. 03 May, 2012 1 commit
  17. 19 Feb, 2012 1 commit
    • David Howells's avatar
      Wrap accesses to the fd_sets in struct fdtable · 1dce27c5
      David Howells authored
      Wrap accesses to the fd_sets in struct fdtable (for recording open files and
      close-on-exec flags) so that we can move away from using fd_sets since we
      abuse the fd_set structs by not allocating the full-sized structure under
      normal circumstances and by non-core code looking at the internals of the
      fd_sets.
      
      The first abuse means that use of FD_ZERO() on these fd_sets is not permitted,
      since that cannot be told about their abnormal lengths.
      
      This introduces six wrapper functions for setting, clearing and testing
      close-on-exec flags and fd-is-open flags:
      
      	void __set_close_on_exec(int fd, struct fdtable *fdt);
      	void __clear_close_on_exec(int fd, struct fdtable *fdt);
      	bool close_on_exec(int fd, const struct fdtable *fdt);
      	void __set_open_fd(int fd, struct fdtable *fdt);
      	void __clear_open_fd(int fd, struct fdtable *fdt);
      	bool fd_is_open(int fd, const struct fdtable *fdt);
      
      Note that I've prepended '__' to the names of the set/clear functions because
      they require the caller to hold a lock to use them.
      
      Note also that I haven't added wrappers for looking behind the scenes at the
      the array.  Possibly that should exist too.
      Signed-off-by: 's avatarDavid Howells <dhowells@redhat.com>
      Link: http://lkml.kernel.org/r/20120216174942.23314.1364.stgit@warthog.procyon.org.ukSigned-off-by: 's avatarH. Peter Anvin <hpa@zytor.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      1dce27c5
  18. 24 Mar, 2011 1 commit
  19. 15 Mar, 2011 1 commit
    • Al Viro's avatar
      New kind of open files - "location only". · 1abf0c71
      Al Viro authored
      New flag for open(2) - O_PATH.  Semantics:
      	* pathname is resolved, but the file itself is _NOT_ opened
      as far as filesystem is concerned.
      	* almost all operations on the resulting descriptors shall
      fail with -EBADF.  Exceptions are:
      	1) operations on descriptors themselves (i.e.
      		close(), dup(), dup2(), dup3(), fcntl(fd, F_DUPFD),
      		fcntl(fd, F_DUPFD_CLOEXEC, ...), fcntl(fd, F_GETFD),
      		fcntl(fd, F_SETFD, ...))
      	2) fcntl(fd, F_GETFL), for a common non-destructive way to
      		check if descriptor is open
      	3) "dfd" arguments of ...at(2) syscalls, i.e. the starting
      		points of pathname resolution
      	* closing such descriptor does *NOT* affect dnotify or
      posix locks.
      	* permissions are checked as usual along the way to file;
      no permission checks are applied to the file itself.  Of course,
      giving such thing to syscall will result in permission checks (at
      the moment it means checking that starting point of ....at() is
      a directory and caller has exec permissions on it).
      
      fget() and fget_light() return NULL on such descriptors; use of
      fget_raw() and fget_raw_light() is needed to get them.  That protects
      existing code from dealing with those things.
      
      There are two things still missing (they come in the next commits):
      one is handling of symlinks (right now we refuse to open them that
      way; see the next commit for semantics related to those) and another
      is descriptor passing via SCM_RIGHTS datagrams.
      Signed-off-by: 's avatarAl Viro <viro@zeniv.linux.org.uk>
      1abf0c71
  20. 03 Feb, 2011 1 commit
  21. 28 Oct, 2010 1 commit
    • Linus Torvalds's avatar
      fasync: Fix placement of FASYNC flag comment · 55f335a8
      Linus Torvalds authored
      In commit f7347ce4 ("fasync: re-organize fasync entry insertion to
      allow it under a spinlock") Arnd took an earlier patch of mine that had
      the comment about the FASYNC flag above the wrong function.
      
      When the fasync_add_entry() function was split to introduce the new
      fasync_insert_entry() helper function, the code that actually cares
      about the FASYNC bit moved to that new helper.
      
      So just move the comment to the right point.
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      55f335a8
  22. 27 Oct, 2010 1 commit
  23. 10 Sep, 2010 1 commit
  24. 11 Aug, 2010 1 commit
  25. 29 Jun, 2010 1 commit
  26. 04 Jun, 2010 1 commit
  27. 21 May, 2010 1 commit
  28. 21 Apr, 2010 1 commit
    • Eric Dumazet's avatar
      fasync: RCU and fine grained locking · 989a2979
      Eric Dumazet authored
      kill_fasync() uses a central rwlock, candidate for RCU conversion, to
      avoid cache line ping pongs on SMP.
      
      fasync_remove_entry() and fasync_add_entry() can disable IRQS on a short
      section instead during whole list scan.
      
      Use a spinlock per fasync_struct to synchronize kill_fasync_rcu() and
      fasync_{remove|add}_entry(). This spinlock is IRQ safe, so sock_fasync()
      doesnt need its own implementation and can use fasync_helper(), to
      reduce code size and complexity.
      
      We can remove __kill_fasync() direct use in net/socket.c, and rename it
      to kill_fasync_rcu().
      Signed-off-by: 's avatarEric Dumazet <eric.dumazet@gmail.com>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      989a2979
  29. 06 Mar, 2010 1 commit
  30. 07 Feb, 2010 1 commit
    • Linus Torvalds's avatar
      Fix race in tty_fasync() properly · 80e1e823
      Linus Torvalds authored
      This reverts commit 70362511 ("tty: fix race in tty_fasync") and
      commit b04da8bf ("fnctl: f_modown should call write_lock_irqsave/
      restore") that tried to fix up some of the fallout but was incomplete.
      
      It turns out that we really cannot hold 'tty->ctrl_lock' over calling
      __f_setown, because not only did that cause problems with interrupt
      disables (which the second commit fixed), it also causes a potential
      ABBA deadlock due to lock ordering.
      
      Thanks to Tetsuo Handa for following up on the issue, and running
      lockdep to show the problem.  It goes roughly like this:
      
       - f_getown gets filp->f_owner.lock for reading without interrupts
         disabled, so an interrupt that happens while that lock is held can
         cause a lockdep chain from f_owner.lock -> sighand->siglock.
      
       - at the same time, the tty->ctrl_lock -> f_owner.lock chain that
         commit 70362511 introduced, together with the pre-existing
         sighand->siglock -> tty->ctrl_lock chain means that we have a lock
         dependency the other way too.
      
      So instead of extending tty->ctrl_lock over the whole __f_setown() call,
      we now just take a reference to the 'pid' structure while holding the
      lock, and then release it after having done the __f_setown.  That still
      guarantees that 'struct pid' won't go away from under us, which is all
      we really ever needed.
      Reported-and-tested-by: 's avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Acked-by: 's avatarGreg Kroah-Hartman <gregkh@suse.de>
      Acked-by: 's avatarAmérico Wang <xiyou.wangcong@gmail.com>
      Cc: stable@kernel.org
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      80e1e823
  31. 27 Jan, 2010 1 commit
  32. 16 Dec, 2009 1 commit
    • Linus Torvalds's avatar
      fasync: split 'fasync_helper()' into separate add/remove functions · 53281b6d
      Linus Torvalds authored
      Yes, the add and remove cases do share the same basic loop and the
      locking, but the compiler can inline and then CSE some of the end result
      anyway.  And splitting it up makes the code way easier to follow,
      and makes it clearer exactly what the semantics are.
      
      In particular, we must make sure that the FASYNC flag in file->f_flags
      exactly matches the state of "is this file on any fasync list", since
      not only is that flag visible to user space (F_GETFL), but we also use
      that flag to check whether we need to remove any fasync entries on file
      close.
      
      We got that wrong for the case of a mixed use of file locking (which
      tries to remove any fasync entries for file leases) and fasync.
      
      Splitting the function up also makes it possible to do some future
      optimizations without making the function even messier.  In particular,
      since the FASYNC flag has to match the state of "is this on a list", we
      can do the following future optimizations:
      
       - on remove, we don't even need to get the locks and traverse the list
         if FASYNC isn't set, since we can know a priori that there is no
         point (this is effectively the same optimization that we already do
         in __fput() wrt removing fasync on file close)
      
       - on add, we can use the FASYNC flag to decide whether we are changing
         an existing entry or need to allocate a new one.
      
      but this is just the cleanup + fix for the FASYNC flag.
      Acked-by: 's avatarAl Viro <viro@ZenIV.linux.org.uk>
      Tested-by: 's avatarTavis Ormandy <taviso@google.com>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Matt Mackall <mpm@selenic.com>
      Cc: stable@kernel.org
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      53281b6d
  33. 18 Nov, 2009 1 commit
  34. 24 Sep, 2009 2 commits
    • Peter Zijlstra's avatar
      fcntl: add F_[SG]ETOWN_EX · ba0a6c9f
      Peter Zijlstra authored
      In order to direct the SIGIO signal to a particular thread of a
      multi-threaded application we cannot, like suggested by the manpage, put a
      TID into the regular fcntl(F_SETOWN) call.  It will still be send to the
      whole process of which that thread is part.
      
      Since people do want to properly direct SIGIO we introduce F_SETOWN_EX.
      
      The need to direct SIGIO comes from self-monitoring profiling such as with
      perf-counters.  Perf-counters uses SIGIO to notify that new sample data is
      available.  If the signal is delivered to the same task that generated the
      new sample it can augment that data by inspecting the task's user-space
      state right after it returns from the kernel.  This is esp.  convenient
      for interpreted or virtual machine driven environments.
      
      Both F_SETOWN_EX and F_GETOWN_EX take a pointer to a struct f_owner_ex
      as argument:
      
      struct f_owner_ex {
      	int   type;
      	pid_t pid;
      };
      
      Where type is one of F_OWNER_TID, F_OWNER_PID or F_OWNER_GID.
      Signed-off-by: 's avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Reviewed-by: 's avatarOleg Nesterov <oleg@redhat.com>
      Tested-by: 's avatarstephane eranian <eranian@googlemail.com>
      Cc: Michael Kerrisk <mtk.manpages@googlemail.com>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Christoph Hellwig <hch@lst.de>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      ba0a6c9f
    • Oleg Nesterov's avatar
      signals: send_sigio: use do_send_sig_info() to avoid check_kill_permission() · 06f1631a
      Oleg Nesterov authored
      group_send_sig_info()->check_kill_permission() assumes that current is the
      sender and uses current_cred().
      
      This is not true in send_sigio_to_task() case.  From the security pov the
      sender is not current, but the task which did fcntl(F_SETOWN), that is why
      we have sigio_perm() which uses the right creds to check.
      
      Fortunately, send_sigio() always sends either SEND_SIG_PRIV or
      SI_FROMKERNEL() signal, so check_kill_permission() does nothing.  But
      still it would be tidier to avoid this bogus security check and save a
      couple of cycles.
      Signed-off-by: 's avatarOleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: stephane eranian <eranian@googlemail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Roland McGrath <roland@redhat.com>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      06f1631a
  35. 12 Jul, 2009 1 commit