patch-2.6.22.y/chlog-v2.6.22.21-op1-rc2

   1 commit 5651fadddd81ecbab1e4fa33878cc8d0b1ddae6c
   2 Author: Oliver Pinter <oliver.pntr@gmail.com>
   3 Date:   Sat Mar 29 16:20:25 2008 +0100
   4
   5     v2.6.22.21-op1-rc2
   6
   7     Signed-off-by: Oliver Pinter <oliver.pntr@gmail.com>
   8
   9 commit 1ee0bb06edf100344d5b940f58439575863a6187
  10 Author: andrew.patterson@hp.com <andrew.patterson@hp.com>
  11 Date:   Sat Mar 29 16:18:53 2008 +0100
  12
  13     MCA when shutting down tulip quad-NIC
  14
  15     Shutting down the network causes an MCA because of an IO TLB error when
  16     a DEC quad 10/100 card is in any slot.  This problem was originally seen
  17     on an HP rx4640.
  18
  19     Acked-by: Olaf Kirch <okir@suse.de>
  20     Signed-off-by: Oliver Pinter <oliver.pntr@gmail.com>
  21
  22      drivers/net/tulip/tulip_core.c |    4 ++++
  23      1 file changed, 4 insertions(+)
  24
  25 commit b362b7edb1a3b9ba69eecb0cbd95fd4c4ba96994
  26 Author: Joe Korty <joe.korty@ccur.com>
  27 Date:   Wed Mar 5 15:04:59 2008 -0800
  28
  29     slab: NUMA slab allocator migration bugfix
  30
  31     NUMA slab allocator cpu migration bugfix
  32
  33     The NUMA slab allocator (specifically, cache_alloc_refill)
  34     is not refreshing its local copies of what cpu and what
  35     numa node it is on, when it drops and reacquires the irq
  36     block that it inherited from its caller.  As a result
  37     those values become invalid if an attempt to migrate the
  38     process to another numa node occured while the irq block
  39     had been dropped.
  40
  41     The solution is to make cache_alloc_refill reload these
  42     variables whenever it drops and reacquires the irq block.
  43
  44     The error is very difficult to hit.  When it does occur,
  45     one gets the following oops + stack traceback bits in
  46     check_spinlock_acquired:
  47
  48         kernel BUG at mm/slab.c:2417
  49         cache_alloc_refill+0xe6
  50         kmem_cache_alloc+0xd0
  51         ...
  52
  53     This patch was developed against 2.6.23, ported to and
  54     compiled-tested only against 2.6.25-rc4.
  55
  56     Signed-off-by: Joe Korty <joe.korty@ccur.com>
  57     Signed-off-by: Christoph Lameter <clameter@sgi.com>
  58     Signed-off-by: Oliver Pinter <oliver.pntr@gmail.com>
  59
  60 commit 078288fc83e496c7965fa10b694353125c349ef7
  61 Author: NeilBrown <neilb@suse.de>
  62 Date:   Wed Feb 6 01:40:00 2008 -0800
  63
  64     md: fix an occasional deadlock in raid5
  65
  66     raid5's 'make_request' function calls generic_make_request on underlying
  67     devices and if we run out of stripe heads, it could end up waiting for one of
  68     those requests to complete.  This is bad as recursive calls to
  69     generic_make_request go on a queue and are not even attempted until
  70     make_request completes.
  71
  72     So: don't make any generic_make_request calls in raid5 make_request until all
  73     waiting has been done.  We do this by simply setting STRIPE_HANDLE instead of
  74     calling handle_stripe().
  75
  76     If we need more stripe_heads, raid5d will get called to process the pending
  77     stripe_heads which will call generic_make_request from a
  78
  79     This change by itself causes a performance hit.  So add a change so that
  80     raid5_activate_delayed is only called at unplug time, never in raid5.  This
  81     seems to bring back the performance numbers.  Calling it in raid5d was
  82     sometimes too soon...
  83
  84     Neil said:
  85
  86       How about we queue it for 2.6.25-rc1 and then about when -rc2 comes out,
  87       we queue it for 2.6.24.y?
  88
  89     Acked-by: Dan Williams <dan.j.williams@intel.com>
  90     Signed-off-by: Neil Brown <neilb@suse.de>
  91     Tested-by: dean gaudet <dean@arctic.org>
  92     Cc: <stable@kernel.org>
  93     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
  94     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
  95     Signed-off-by: Oliver Pinter <oliver.pntr@gmail.com>
  96
  97 commit 70a7cd1e8fbe736b854f39efd98528b7dfd64ee1
  98 Author: Suresh Jayaraman <sjayaraman@suse.de>
  99 Date:   Sat Mar 29 16:18:51 2008 +0100
 100
 101     Fix sign mount option and sign proc config setting
 102
 103     Patch mainline: 2.6.23-rc1
 104
 105     Backported the fix (2.6.23-rc1) from Steve French. The original patch removes
 106     few commented functions (which are not required) as part of this fix, backport
 107     also does the same to retain compatibility.
 108
 109     We were checking the wrong (old) global variable to determine
 110     whether to override server and force signing on the SMB
 111     connection.
 112
 113     Acked-by: Dave Kleikamp <shaggy@austin.ibm.com>
 114     Signed-off-by: Steve French <sfrench@us.ibm.com>
 115     Signed-off-by: Suresh Jayaraman <sjayaraman@suse.de>
 116     Signed-off-by: Oliver Pinter <oliver.pntr@gmail.com>
 117
 118 commit 982b92285ec9f45e1658c95376f9e1a47ba47090
 119 Author: Steve French <sfrench@us.ibm.com>
 120 Date:   Tue Nov 13 22:41:37 2007 +0000
 121
 122     Fix buffer overflow if server sends corrupt response to small
 123
 124     [CIFS] Fix buffer overflow if server sends corrupt response to small
 125     request
 126
 127     In SendReceive() function in transport.c - it memcpy's
 128     message payload into a buffer passed via out_buf param. The function
 129     assumes that all buffers are of size (CIFSMaxBufSize +
 130     MAX_CIFS_HDR_SIZE) , unfortunately it is also called with smaller
 131     (MAX_CIFS_SMALL_BUFFER_SIZE) buffers.  There are eight callers
 132     (SMB worker functions) which are primarily affected by this change:
 133
 134     TreeDisconnect, uLogoff, Close, findClose, SetFileSize, SetFileTimes,
 135     Lock and PosixLock
 136
 137     CC: Dave Kleikamp <shaggy@austin.ibm.com>
 138     CC: Przemyslaw Wegrzyn <czajnik@czajsoft.pl>
 139     Acked-by: Jeff Layton <jlayton@redhat.com>
 140     Signed-off-by: Steve French <sfrench@us.ibm.com>
 141     Acked-by: Jeff Mahoney <jeffm@suse.com>
 142     Signed-off-by: Oliver Pinter <oliver.pntr@gmail.com>
 143
 144 commit 54ddb8eee828607fb70a553b9473fe671fc2c87e
 145 Author: Oliver Pinter <oliver.pntr@gmail.com>
 146 Date:   Tue Feb 26 17:06:12 2008 +0100
 147
 148     linux v2.6.22.20-op1-rc1
 149
 150     Signed-off-by: Oliver Pinter <oliver.pntr@gmail.com>
 151
 152 commit dbd68c840f69fe6721fb609d0eb8a5d548e76a99
 153 Author: Kurt Garloff <garloff@suse.de>
 154 Date:   Mon Feb 18 21:16:27 2008 +0100
 155
 156     make (low) swappiness safer to use
 157
 158     The patch titled
 159          make swappiness safer to use
 160     has been added to the -mm tree.  Its filename is
 161          make-swappiness-safer-to-use.patch
 162
 163     See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
 164     out what to do about this
 165
 166     #Subject: make swappiness safer to use
 167     #From: Andrea Arcangeli <andrea@suse.de>
 168
 169     Swappiness isn't a safe sysctl.  Setting it to 0 for example can hang a
 170     system.  That's a corner case but even setting it to 10 or lower can waste
 171     enormous amounts of cpu without making much progress.  We've customers who
 172     wants to use swappiness but they can't because of the current
 173     implementation (if you change it so the system stops swapping it really
 174     stops swapping and nothing works sane anymore if you really had to swap
 175     something to make progress).
 176
 177     This patch from Kurt Garloff makes swappiness safer to use (no more huge
 178     cpu usage or hangs with low swappiness values).
 179
 180     I think the prev_priority can also be nuked since it wastes 4 bytes per
 181     zone (that would be an incremental patch but I wait the nr_scan_[in]active
 182     to be nuked first for similar reasons).  Clearly somebody at some point
 183     noticed how broken that thing was and they had to add min(priority,
 184     prev_priority) to give it some reliability, but they didn't go the last
 185     mile to nuke prev_priority too.  Calculating distress only in function of
 186     not-racy priority is correct and sure more than enough without having to
 187     add randomness into the equation.
 188
 189     Patch is tested on older kernels but it compiles and it's quite simple
 190     so...
 191
 192     Overall I'm not very satisified by the swappiness tweak, since it doesn't
 193     rally do anything with the dirty pagecache that may be inactive.  We need
 194     another kind of tweak that controls the inactive scan and tunes the
 195     can_writepage feature (not yet in mainline despite having submitted it a
 196     few times), not only the active one.  That new tweak will tell the kernel
 197     how hard to scan the inactive list for pure clean pagecache (something the
 198     mainline kernel isn't capable of yet).  We already have that feature
 199     working in all our enterprise kernels with the default reasonable tune, or
 200     they can't even run a readonly backup with tar without triggering huge
 201     write I/O.  I think it should be available also in mainline later.
 202
 203     Cc: Nick Piggin <npiggin@suse.de>
 204     Signed-off-by: Kurt Garloff <garloff@suse.de>
 205     Signed-off-by: Andrea Arcangeli <andrea@suse.de>
 206     Signed-off-by: Fengguang Wu <wfg@mail.ustc.edu.cn>
 207     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
 208     Signed-off-by: Oliver Pinter <oliver.pntr@gmail.com>
 209
 210 commit eef55466b00265cfe843ae58edd608a29ad0fc5e
 211 Author: David Howells <dhowells@redhat.com>
 212 Date:   Thu Feb 21 16:12:45 2008 +0000
 213
 214     MM: Fix macro argument substitution in PageHead() and PageTail()
 215
 216     Fix macro argument substitution in PageHead() and PageTail() - 'page' should
 217     have brackets surrounding it (commit 6d7779538f765963ced45a3fa4bed7ba8d2c277d).
 218
 219     Signed-off-by: David Howells <dhowells@redhat.com>
 220     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
 221     Signed-off-by: Oliver Pinter <oliver.pntr@gmail.com>
 222
 223 commit 2cd082a9a5860afa64b032fc6df230e25d913289
 224 Author: Thomas Gleixner <tglx@linutronix.de>
 225 Date:   Wed Feb 20 00:29:02 2008 +0100
 226
 227     genirq: do not leave interupts enabled on free_irq
 228
 229     commit 89d694b9dbe769ca1004e01db0ca43964806a611
 230
 231     The default_disable() function was changed in commit:
 232
 233      76d2160147f43f982dfe881404cfde9fd0a9da21
 234      genirq: do not mask interrupts by default
 235
 236     It removed the mask function in favour of the default delayed
 237     interrupt disabling. Unfortunately this also broke the shutdown in
 238     free_irq() when the last handler is removed from the interrupt for
 239     those architectures which rely on the default implementations. Now we
 240     can end up with a enabled interrupt line after the last handler was
 241     removed, which can result in spurious interrupts.
 242
 243     Fix this by adding a default_shutdown function, which is only
 244     installed, when the irqchip implementation does provide neither a
 245     shutdown nor a disable function.
 246
 247     Pointed-out-by: Michael Hennerich <Michael.Hennerich@analog.com>
 248     Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
 249     Acked-by: Ingo Molnar <mingo@elte.hu>
 250     Tested-by: Michael Hennerich <Michael.Hennerich@analog.com>
 251     Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
 252     Signed-off-by: Oliver Pinter <oliver.pntr@gmail.com>
 253
 254 commit c3bec7bc563415560734d190f33083716bb1cb68
 255 Author: Ingo Molnar <mingo@elte.hu>
 256 Date:   Fri Feb 15 20:58:22 2008 +0100
 257
 258     x86_64: CPA, fix cache attribute inconsistency bug, v2.6.22 backport
 259
 260     fix CPA cache attribute bug in v2.6.2[234]. When phys_base is nonzero
 261     (when CONFIG_RELOCATABLE=y) then change_page_attr_addr() miscalculates
 262     the secondary alias address by -14 MB (depending on the configured
 263     offset).
 264
 265     The default 64-bit kernels of Fedora and Ubuntu are affected:
 266
 267        $ grep RELOCA /boot/config-2.6.23.9-85.fc8
 268          CONFIG_RELOCATABLE=y
 269
 270        $ grep RELOC /boot/config-2.6.22-14-generic
 271          CONFIG_RELOCATABLE=y
 272
 273     and probably on many other distros as well.
 274
 275     the bug affects all pages in the first 40 MB of physical RAM that
 276     are allocated by some subsystem that does ioremap_nocache() on them:
 277
 278            if (__pa(address) < KERNEL_TEXT_SIZE) {
 279
 280     Hence we might leave page table entries with inconsistent cache
 281     attributes around (pages mapped at both UnCacheable and Write-Back),
 282     and we can also set the wrong kernel text pages to UnCacheable.
 283
 284     the effects of this bug can be random slowdowns and other misbehavior.
 285     If for example AGP allocates its aperture pages into the first 40 MB
 286     of physical RAM, then the -14 MB bug might mark random kernel texto
 287     pages as uncacheable, slowing down a random portion of the 64-bit
 288     kernel until the AGP driver is unloaded.
 289
 290     Signed-off-by: Ingo Molnar <mingo@elte.hu>
 291     Acked-by: Thomas Gleixner <tglx@linutronix.de>
 292     Signed-off-by: Oliver Pinter <oliver.pntr@gmail.com>