patch-2.6.22.y/chlog-v2.6.22.23-op1

   1 commit 709915d2d0f78971857d71020f068085d22490a4
   2 Author: Oliver Pinter <oliver.pntr@gmail.com>
   3 Date:   Wed May 7 16:03:20 2008 +0200
   4
   5     v2.6.22.23-op1
   6
   7     Signed-off-by: Oliver Pinter <oliver.pntr@gmail.com>
   8
   9 commit 6cf85cf29543cff81a66e402f7eef60bfae8659b
  10 Author: Al Viro <viro@zeniv.linux.org.uk>
  11 Date:   Tue May 6 13:58:34 2008 -0400
  12
  13     fix SMP ordering hole in fcntl_setlk() (CVE-2008-1669)
  14
  15     commit 0b2bac2f1ea0d33a3621b27ca68b9ae760fca2e9 upstream.
  16
  17     fcntl_setlk()/close() race prevention has a subtle hole - we need to
  18     make sure that if we *do* have an fcntl/close race on SMP box, the
  19     access to descriptor table and inode->i_flock won't get reordered.
  20
  21     As it is, we get STORE inode->i_flock, LOAD descriptor table entry vs.
  22     STORE descriptor table entry, LOAD inode->i_flock with not a single
  23     lock in common on both sides.  We do have BKL around the first STORE,
  24     but check in locks_remove_posix() is outside of BKL and for a good
  25     reason - we don't want BKL on common path of close(2).
  26
  27     Solution is to hold ->file_lock around fcheck() in there; that orders
  28     us wrt removal from descriptor table that preceded locks_remove_posix()
  29     on close path and we either come first (in which case eviction will be
  30     handled by the close side) or we'll see the effect of close and do
  31     eviction ourselves.  Note that even though it's read-only access,
  32     we do need ->file_lock here - rcu_read_lock() won't be enough to
  33     order the things.
  34
  35     Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
  36     Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  37     Signed-off-by: Oliver Pinter <oliver.pntr@gmail.com>
  38
  39 commit fa641adb014dea46e1758ceb0e068d8d90927df3
  40 Author: Jeff Moyer <jmoyer@redhat.com>
  41 Date:   Tue Dec 4 23:45:02 2007 -0800
  42
  43     aio: only account I/O wait time in read_events if there are active requests
  44
  45     On 2.6.24, top started showing 100% iowait on one CPU when a UML instance was
  46     running (but completely idle).  The UML code sits in io_getevents waiting for
  47     an event to be submitted and completed.
  48
  49     Fix this by checking ctx->reqs_active before scheduling to determine whether
  50     or not we are waiting for I/O.
  51
  52     Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
  53     Cc: Zach Brown <zach.brown@oracle.com>
  54     Cc: Miklos Szeredi <miklos@szeredi.hu>
  55     Cc: Jeff Dike <jdike@addtoit.com>
  56     Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
  57     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
  58     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
  59     Signed-off-by: Oliver Pinter <oliver.pntr@gmail.com>