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

   1 commit 9d1fb599033713e8804c84c51005bacbb561ce4b
   2 Author: Oliver Pinter <oliver.pntr@gmail.com>
   3 Date:   Thu May 1 15:40:47 2008 +0200
   4
   5     v2.6.22.22-op1
   6
   7     Signed-off-by: Oliver Pinter <oliver.pntr@gmail.com>
   8
   9 commit 7b313aa2790eafb810fd3eeabee48ff600d9fd6d
  10 Author: Patrick McHardy <kaber@trash.net>
  11 Date:   Sun Apr 6 23:43:18 2008 -0700
  12
  13     TCP: Fix shrinking windows with window scaling
  14
  15     Upstream commit: 607bfbf2d55dd1cfe5368b41c2a81a8c9ccf4723
  16
  17     When selecting a new window, tcp_select_window() tries not to shrink
  18     the offered window by using the maximum of the remaining offered window
  19     size and the newly calculated window size. The newly calculated window
  20     size is always a multiple of the window scaling factor, the remaining
  21     window size however might not be since it depends on rcv_wup/rcv_nxt.
  22     This means we're effectively shrinking the window when scaling it down.
  23
  24     The dump below shows the problem (scaling factor 2^7):
  25
  26     - Window size of 557 (71296) is advertised, up to 3111907257:
  27
  28     IP 172.2.2.3.33000 > 172.2.2.2.33000: . ack 3111835961 win 557 <...>
  29
  30     - New window size of 514 (65792) is advertised, up to 3111907217, 40 bytes
  31       below the last end:
  32
  33     IP 172.2.2.3.33000 > 172.2.2.2.33000: . 3113575668:3113577116(1448) ack 3111841425 win 514 <...>
  34
  35     The number 40 results from downscaling the remaining window:
  36
  37     3111907257 - 3111841425 = 65832
  38     65832 / 2^7 = 514
  39     65832 % 2^7 = 40
  40
  41     If the sender uses up the entire window before it is shrunk, this can have
  42     chaotic effects on the connection. When sending ACKs, tcp_acceptable_seq()
  43     will notice that the window has been shrunk since tcp_wnd_end() is before
  44     tp->snd_nxt, which makes it choose tcp_wnd_end() as sequence number.
  45     This will fail the receivers checks in tcp_sequence() however since it
  46     is before it's tp->rcv_wup, making it respond with a dupack.
  47
  48     If both sides are in this condition, this leads to a constant flood of
  49     ACKs until the connection times out.
  50
  51     Make sure the window is never shrunk by aligning the remaining window to
  52     the window scaling factor.
  53
  54     Signed-off-by: Patrick McHardy <kaber@trash.net>
  55     Signed-off-by: David S. Miller <davem@davemloft.net>
  56     Signed-off-by: Chris Wright <chrisw@sous-sol.org>
  57     Signed-off-by: Oliver Pinter <oliver.pntr@gmail.com>
  58
  59 commit 4cb505f532419351d81703e8818c2ef0f9a6e980
  60 Author: James Morris <jmorris@namei.org>
  61 Date:   Fri Jul 13 11:44:32 2007 +0200
  62
  63     security: revalidate rw permissions for sys_splice and sys_vmsplice
  64
  65     git id: 29ce20586be54ceba49c55ae049541398cd2c416
  66
  67     Revalidate read/write permissions for splice(2) and vmslice(2), in case
  68     security policy has changed since the files were opened.
  69
  70     Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
  71     Signed-off-by: James Morris <jmorris@namei.org>
  72     Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
  73     Backported-by: Oliver Pinter <oliver.pntr@gmail.com>
  74     Signed-off-by: Oliver Pinter <oliver.pntr@gmail.com>
  75
  76 commit 540add1b55bcae67e16feede0a5f0a0163db3c12
  77 Author: Jens Axboe <jens.axboe@oracle.com>
  78 Date:   Wed Feb 20 10:34:51 2008 +0100
  79
  80     splice: only return -EAGAIN if there's hope of more data
  81
  82     sys_tee() currently is a bit eager in returning -EAGAIN, it may do so
  83     even if we don't have a chance of anymore data becoming available. So
  84     improve the logic and only return -EAGAIN if we have an attached writer
  85     to the input pipe.
  86
  87     Reported by Johann Felix Soden <johfel@gmx.de> and
  88     Patrick McManus <mcmanus@ducksong.com>.
  89
  90     Tested-by: Johann Felix Soden <johfel@users.sourceforge.net>
  91     Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
  92     Signed-off-by: Oliver Pinter <oliver.pntr@gmail.com>
  93
  94 commit 4f38274e8346ef5748c667c3f1f73067e7f57e75
  95 Author: Davide Libenzi <davidel@xmailserver.org>
  96 Date:   Thu Apr 10 21:29:19 2008 -0700
  97
  98     eventfd/kaio integration fix
  99
 100     Jeff Roberson discovered a race when using kaio eventfd based notifications.
 101     When it occurs it can lead tomissed wakeups and hung userspace.
 102
 103     This patch fixes the race by moving the notification inside the spinlocked
 104     section of kaio.  The operation is safe since eventfd spinlock and kaio one
 105     are unrelated.
 106
 107     Signed-off-by: Davide Libenzi <davidel@xmailserver.org>
 108     Cc: Zach Brown <zach.brown@oracle.com>
 109     Cc: Jeff Roberson <jroberson@chesapeake.net>
 110     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
 111     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
 112     Signed-off-by: Oliver Pinter <oliver.pntr@gmail.com>
 113
 114 commit deeb6e2b9e9841a67aa08ad5142d2ec03a460445
 115 Author: Jeff Moyer <jmoyer@redhat.com>
 116 Date:   Tue Oct 16 23:27:20 2007 -0700
 117
 118     aio: account I/O wait time properly
 119
 120     Some months back I proposed changing the schedule() call in
 121     read_events to an io_schedule():
 122         http://osdir.com/ml/linux.kernel.aio.general/2006-10/msg00024.html
 123     This was rejected as there are AIO operations that do not initiate
 124     disk I/O.  I've had another look at the problem, and the only AIO
 125     operation that will not initiate disk I/O is IOCB_CMD_NOOP.  However,
 126     this command isn't even wired up!
 127
 128     Given that it doesn't work, and hasn't for *years*, I'm going to
 129     suggest again that we do proper I/O accounting when using AIO.
 130
 131     Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
 132     Acked-by: Zach Brown <zach.brown@oracle.com>
 133     Cc: Benjamin LaHaise <bcrl@kvack.org>
 134     Cc: Suparna Bhattacharya <suparna@in.ibm.com>
 135     Cc: Badari Pulavarty <pbadari@us.ibm.com>
 136     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
 137     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
 138     Signed-off-by: Oliver Pinter <oliver.pntr@gmail.com>
 139
 140 commit ffd834ab862bae9a45f86bc6818fcf1d77178641
 141 Author: Hugh Dickins <hugh@veritas.com>
 142 Date:   Thu Apr 3 23:35:22 2008 +0100
 143
 144     splice: use mapping_gfp_mask
 145
 146     The loop block driver is careful to mask __GFP_IO|__GFP_FS out of its
 147     mapping_gfp_mask, to avoid hangs under memory pressure.  But nowadays
 148     it uses splice, usually going through __generic_file_splice_read.  That
 149     must use mapping_gfp_mask instead of GFP_KERNEL to avoid those hangs.
 150
 151     Signed-off-by: Hugh Dickins <hugh@veritas.com>
 152     Cc: Jens Axboe <jens.axboe@oracle.com>
 153     Cc: Andrew Morton <akpm@linux-foundation.org>
 154     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
 155     Signed-off-by: Oliver Pinter <oliver.pntr@gmail.com>
 156
 157 commit 003ee38ed3d5194eaed86e5639a58fbdc60097cc
 158 Author: Nick Piggin <npiggin@suse.de>
 159 Date:   Wed Feb 6 01:37:29 2008 -0800
 160
 161     inotify: remove debug code
 162
 163     The inotify debugging code is supposed to verify that the
 164     DCACHE_INOTIFY_PARENT_WATCHED scalability optimisation does not result in
 165     notifications getting lost nor extra needless locking generated.
 166
 167     Unfortunately there are also some races in the debugging code.  And it isn't
 168     very good at finding problems anyway.  So remove it for now.
 169
 170     Signed-off-by: Nick Piggin <npiggin@suse.de>
 171     Cc: Robert Love <rlove@google.com>
 172     Cc: John McCutchan <ttb@tentacle.dhs.org>
 173     Cc: Jan Kara <jack@ucw.cz>
 174     Cc: Yan Zheng <yanzheng@21cn.com>
 175     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
 176     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
 177     Signed-off-by: Oliver Pinter <oliver.pntr@gmail.com>
 178
 179 commit 42ee9a96ef6c3b5ac691357737e44fe494070527
 180 Author: Nick Piggin <npiggin@suse.de>
 181 Date:   Wed Feb 6 01:37:28 2008 -0800
 182
 183     inotify: fix race
 184
 185     There is a race between setting an inode's children's "parent watched" flag
 186     when placing the first watch on a parent, and instantiating new children of
 187     that parent: a child could miss having its flags set by
 188     set_dentry_child_flags, but then inotify_d_instantiate might still see
 189     !inotify_inode_watched.
 190
 191     The solution is to set_dentry_child_flags after adding the watch.  Locking is
 192     taken care of, because both set_dentry_child_flags and inotify_d_instantiate
 193     hold dcache_lock and child->d_locks.
 194
 195     Signed-off-by: Nick Piggin <npiggin@suse.de>
 196     Cc: Robert Love <rlove@google.com>
 197     Cc: John McCutchan <ttb@tentacle.dhs.org>
 198     Cc: Jan Kara <jack@ucw.cz>
 199     Cc: Yan Zheng <yanzheng@21cn.com>
 200     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
 201     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
 202     Signed-off-by: Oliver Pinter <oliver.pntr@gmail.com>
 203
 204 commit 25021d23a79c9d7746f20645a9e260af6ac32879
 205 Author: Grant Grundler <grundler@parisc-linux.org>
 206 Date:   Sat Mar 8 18:33:16 2008 -0700
 207
 208     2.6.25-rc4 de_stop_rxtx polling wrong
 209
 210     backported to 2.6.22.y
 211
 212     mainline: 69cac988f2d8506d0b479c5ae7903b9067d7641d
 213
 214     This untested patch _should_ fix:
 215         "(net de2104x) Kernel panic with de2104x tulip driver on boot"
 216         http://bugzilla.kernel.org/show_bug.cgi?id=3156
 217
 218     But the bug submitter isn't responding.  Same fix has been applied
 219     to tulip.c (several years ago) and uli526x.c (Feb 2008) drivers.
 220
 221     [ The panic reported in the bug report was removed in a recently
 222       (march 2008) accepted patch from Ondrej Zary. ]
 223
 224     Signed-off-by: Grant Grundler <grundler@parisc-linux.org>
 225     Signed-off-by: Jeff Garzik <jeff@garzik.org>
 226     Signed-off-by: Oliver Pinter <oliver.pntr@gmail.com>