Commit: 334b8bd4137e9954494b2c5f625b8e7528b372df Author: Adrian Bunk Tue, 25 Sep 2007 00:24:51 +0200 Linux 2.6.16.54 Commit: eaf1071e85b31f5bb6c06196544eb21334cbd20d Author: Adrian Bunk Thu, 30 Aug 2007 06:26:15 +0200 Linux 2.6.16.54-rc1 Commit: 3198d0f16dec0c87071cf26f3f11af9c8f0a009b Author: Ilpo Järvinen Thu, 30 Aug 2007 06:21:05 +0200 TCP: Fix TCP handling of SACK in bidirectional flows It's possible that new SACK blocks that should trigger new LOST markings arrive with new data (which previously made is_dupack false). In addition, I think this fixes a case where we get a cumulative ACK with enough SACK blocks to trigger the fast recovery (is_dupack would be false there too). I'm not completely pleased with this solution because readability of the code is somewhat questionable as 'is_dupack' in SACK case is no longer about dupacks only but would mean something like 'lost_marker_work_todo' too... But because of Eifel stuff done in CA_Recovery, the FLAG_DATA_SACKED check cannot be placed to the if statement which seems attractive solution. Nevertheless, I didn't like adding another variable just for that either... :-) Signed-off-by: Ilpo Järvinen Signed-off-by: David S. Miller Signed-off-by: Adrian Bunk Commit: 725ad2a8f1358bff885414f5e91d253c99921ddc Author: Konstantin Sharlaimov Thu, 30 Aug 2007 06:17:37 +0200 [PPP]: Fix output buffer size in ppp_decompress_frame(). This patch addresses the issue with "osize too small" errors in mppe encryption. The patch fixes the issue with wrong output buffer size being passed to ppp decompression routine. -------------------- As pointed out by Suresh Mahalingam, the issue addressed by ppp-fix-osize-too-small-errors-when-decoding patch is not fully resolved yet. The size of allocated output buffer is correct, however it size passed to ppp->rcomp->decompress in ppp_generic.c if wrong. The patch fixes that. -------------------- Signed-off-by: Konstantin Sharlaimov Signed-off-by: David S. Miller Signed-off-by: Adrian Bunk Commit: 44315cc76567e2d911d56091665637e305af182d Author: Konstantin Sharlaimov Mon, 24 Sep 2007 23:01:54 +0200 [PPP]: Fix osize too small errors when decoding mppe. The mppe_decompress() function required a buffer that is 1 byte too small when receiving a message of mru size. This fixes buffer allocation to prevent this from occurring. Signed-off-by: Konstantin Sharlaimov Signed-off-by: David S. Miller Signed-off-by: Adrian Bunk Commit: 648409668700fb5cc3a9454b042952a996c53c8b Author: David S. Miller Thu, 30 Aug 2007 06:14:37 +0200 [MATH-EMU]: Fix underflow exception reporting. The underflow exception cases were wrong. This is one weird area of ieee1754 handling in that the underflow behavior changes based upon whether underflow is enabled in the trap enable mask of the FPU control register. As a specific case the Sparc V9 manual gives us the following description: -------------------- If UFM = 0: Underflow occurs if a nonzero result is tiny and a loss of accuracy occurs. Tininess may be detected before or after rounding. Loss of accuracy may be either a denormalization loss or an inexact result. If UFM = 1: Underflow occurs if a nonzero result is tiny. Tininess may be detected before or after rounding. -------------------- What this amounts to in the packing case is if we go subnormal, we set underflow if any of the following are true: 1) rounding sets inexact 2) we ended up rounding back up to normal (this is the case where we set the exponent to 1 and set the fraction to zero), this should set inexact too 3) underflow is set in FPU control register trap-enable mask The initially discovered example was "DBL_MIN / 16.0" which incorrectly generated an underflow. It should not, unless underflow is set in the trap-enable mask of the FPU csr. Another example, "0x0.0000000000001p-1022 / 16.0", should signal both inexact and underflow. The cpu implementations and ieee1754 literature is very clear about this. This is case #2 above. However, if underflow is set in the trap enable mask, only underflow should be set and reported as a trap. That is handled properly by the prioritization logic in arch/sparc{,64}/math-emu/math.c:record_exception(). Based upon a report and test case from Jakub Jelinek. Signed-off-by: David S. Miller Signed-off-by: Adrian Bunk Commit: eb845a0bad412b7caa04383715d59399de8b5c11 Author: Mark Fortescue Thu, 30 Aug 2007 06:07:11 +0200 [SPARC32]: Fix rounding errors in ndelay/udelay implementation. __ndelay and __udelay have not been delayung >= specified time. The problem with __ndelay has been tacked down to the rounding of the multiplier constant. By changing this, delays > app 18us are correctly calculated. The problem with __udelay has also been tracked down to rounding issues. Changing the multiplier constant (to match that used in sparc64) corrects for large delays and adding in a rounding constant corrects for trunctaion errors in the claculations. Many short delays will return without looping. This is not an error as there is the fixed delay of doing all the maths to calculate the loop count. Signed-off-by: Mark Fortescue Signed-off-by: David S. Miller Signed-off-by: Adrian Bunk Commit: 7380487e55320420da6277820f2825ec456406eb Author: Alexander Shmelev Thu, 30 Aug 2007 06:05:29 +0200 [SPARC32]: Fix bug in sparc optimized memset. Sparc optimized memset (arch/sparc/lib/memset.S) does not fill last byte of the memory area, if area size is less than 8 bytes and start address is not word (4-bytes) aligned. Here is code chunk where bug located: /* %o0 - memory address, %o1 - size, %g3 - value */ 8: add %o0, 1, %o0 subcc %o1, 1, %o1 bne,a 8b stb %g3, [%o0 - 1] This code should write byte every loop iteration, but last time delay instruction stb is not executed because branch instruction sets "annul" bit. Patch replaces bne,a by bne instruction. Error can be reproduced by simple kernel module: -------------------- #include #include #include #include #include static void do_memset(void **p, int size) { memset(p, 0x00, size); } static int __init memset_test_init(void) { char fooc[8]; int *fooi; memset(fooc, 0xba, sizeof(fooc)); do_memset((void**)(fooc + 3), 1); fooi = (int*) fooc; printk("%08X %08X\n", fooi[0], fooi[1]); return -1; } static void __exit memset_test_cleanup(void) { return; } module_init(memset_test_init); module_exit(memset_test_cleanup); MODULE_LICENSE("GPL"); EXPORT_NO_SYMBOLS; -------------------- Signed-off-by: Alexander Shmelev Signed-off-by: David S. Miller Signed-off-by: Adrian Bunk Commit: 646edb4b5b9c472944af7d6016722fa4895f3bca Author: Neil Brown Thu, 23 Aug 2007 02:13:17 +0200 md: avoid possible BUG_ON in md bitmap handling md/bitmap tracks how many active write requests are pending on blocks associated with each bit in the bitmap, so that it knows when it can clear the bit (when count hits zero). The counter has 14 bits of space, so if there are ever more than 16383, we cannot cope. Currently the code just calles BUG_ON as "all" drivers have request queue limits much smaller than this. However is seems that some don't. Apparently some multipath configurations can allow more than 16383 concurrent write requests. So, in this unlikely situation, instead of calling BUG_ON we now wait for the count to drop down a bit. This requires a new wait_queue_head, some waiting code, and a wakeup call. Tested by limiting the counter to 20 instead of 16383 (writes go a lot slower in that case...). Signed-off-by: Neil Brown Signed-off-by: Adrian Bunk Commit: 4d5eb09cab94fac8cfb767617a4799220f1874ab Author: Neil Brown Thu, 23 Aug 2007 01:39:24 +0200 md: fix a few problems with the interface (sysfs and ioctl) to md While developing more functionality in mdadm I found some bugs in md... - When we remove a device from an inactive array (write 'remove' to the 'state' sysfs file - see 'state_store') would should not update the superblock information - as we may not have read and processed it all properly yet. - initialise all raid_disk entries to '-1' else the 'slot sysfs file will claim '0' for all devices in an array before the array is started. - all '\n' not to be present at the end of words written to sysfs files - when we use SET_ARRAY_INFO to set the md metadata version, set the flag to say that there is persistant metadata. - allow GET_BITMAP_FILE to be called on an array that hasn't been started yet. Signed-off-by: Neil Brown Signed-off-by: Adrian Bunk Commit: b3188291b5c6a9f9c2d6da21ef3f6d02f47d6c2e Author: Neil Brown Thu, 23 Aug 2007 01:38:42 +0200 md: assorted md and raid1 one-liners Fix few bugs that meant that: - superblocks weren't alway written at exactly the right time (this could show up if the array was not written to - writting to the array causes lots of superblock updates and so hides these errors). - restarting device recovery after a clean shutdown (version-1 metadata only) didn't work as intended (or at all). 1/ Ensure superblock is updated when a new device is added. 2/ Remove an inappropriate test on MD_RECOVERY_SYNC in md_do_sync. The body of this if takes one of two branches depending on whether MD_RECOVERY_SYNC is set, so testing it in the clause of the if is wrong. 3/ Flag superblock for updating after a resync/recovery finishes. 4/ If we find the neeed to restart a recovery in the middle (version-1 metadata only) make sure a full recovery (not just as guided by bitmaps) does get done. Signed-off-by: Neil Brown Signed-off-by: Adrian Bunk Commit: 7524619e58de4fba43d4b5c56997c54109799e91 Author: Neil Brown Thu, 23 Aug 2007 01:37:54 +0200 md: allow SET_BITMAP_FILE to work on 64bit kernel with 32bit userspace .. so that you can use bitmaps with 32bit userspace on a 64 bit kernel. Signed-off-by: Neil Brown Signed-off-by: Adrian Bunk Commit: 5405a10ecb16e5bfe696643cea821c49e99c4bbb Author: Neil Brown Thu, 23 Aug 2007 01:06:28 +0200 md: fix some small races in bitmap plugging in raid5 The comment gives more details, but I didn't quite have the sequencing write, so there was room for races to leave bits unset in the on-disk bitmap for short periods of time. Signed-off-by: Neil Brown Signed-off-by: Adrian Bunk Commit: cc49f09942ea753b8587d3f01362ffd311c98a00 Author: Neil Brown Thu, 23 Aug 2007 01:02:57 +0200 md: fix a plug/unplug race in raid5 When a device is unplugged, requests are moved from one or two (depending on whether a bitmap is in use) queues to the main request queue. So whenever requests are put on either of those queues, we should make sure the raid5 array is 'plugged'. However we don't. We currently plug the raid5 queue just before putting requests on queues, so there is room for a race. If something unplugs the queue at just the wrong time, requests will be left on the queue and nothing will want to unplug them. Normally something else will plug and unplug the queue fairly soon, but there is a risk that nothing will. Signed-off-by: Neil Brown Signed-off-by: Adrian Bunk Commit: 26d0764d2bf7f6b8dcd5a99d85cc6b1c02b65da6 Author: Neil Brown Thu, 23 Aug 2007 00:57:45 +0200 md: fix resync speed calculation for restarted resyncs We introduced 'io_sectors' recently so we could count the sectors that causes io during resync separate from sectors which didn't cause IO - there can be a difference if a bitmap is being used to accelerate resync. However when a speed is reported, we find the number of sectors processed recently by subtracting an oldish io_sectors count from a current 'curr_resync' count. This is wrong because curr_resync counts all sectors, not just io sectors. So, add a field to mddev to store the curren io_sectors separately from curr_resync, and use that in the calculations. Signed-off-by: Neil Brown Signed-off-by: Adrian Bunk Commit: 32b268195c968892eec3cdb328e2594e379a658b Author: Neil Brown Thu, 23 Aug 2007 00:56:48 +0200 md: Allow re-add to work on array without bitmaps When an array has a bitmap, a device can be removed and re-added and only blocks changes since the removal (as recorded in the bitmap) will be resynced. It should be possible to do a similar thing to arrays without bitmaps. i.e. if a device is removed and re-added and *no* changes have been made in the interim, then the add should not require a resync. This patch allows that option. This means that when assembling an array one device at a time (e.g. during device discovery) the array can be enabled read-only as soon as enough devices are available, but extra devices can still be added without causing a resync. Signed-off-by: Neil Brown Signed-off-by: Adrian Bunk Commit: 287440c90e8bf967622072c0766d1c680d3c16ae Author: Neil Brown Sun, 12 Aug 2007 01:09:29 +0200 md/bitmap: tidy up i_writecount handling in md/bitmap md/bitmap modifies i_writecount of a bitmap file to make sure that no-one else writes to it. The reverting of the change is sometimes done twice, and there is one error path where it is omitted. This patch tidies that up. Signed-off-by: Neil Brown Signed-off-by: Adrian Bunk Commit: c6be40c9f51529d66e6b66910aa49693da795603 Author: Neil Brown Sun, 12 Aug 2007 01:07:37 +0200 md/bitmap: remove dead code from md/bitmap bitmap_active is never called, and the BITMAP_ACTIVE flag is never users or tested, so discard them both. Also remove some out-of-date 'todo' comments. Signed-off-by: Neil Brown Signed-off-by: Adrian Bunk Commit: b852d1f6463c5a9bf25ac324eac32e9cb1a2eaf7 Author: Neil Brown Sun, 12 Aug 2007 01:05:36 +0200 md/bitmap: remove unnecessary page reference manipulations from md/bitmap code md/bitmap gets a collection of pages representing the bitmap when it initialises the bitmap, and puts all the references when discarding the bitmap. It also occasionally takes extra references without any good reason, and sometimes drops them ... though it doesn't always drop them, which can result in a memory leak. This patch removes the unnecessary 'get_page' calls, and the corresponding 'put_page' calls. Signed-off-by: Neil Brown Signed-off-by: Adrian Bunk Commit: 6964d1bb2773643018889c8518f95f279d93737b Author: Neil Brown Sun, 12 Aug 2007 01:04:41 +0200 md/bitmap: use set_bit etc for bitmap page attributes In particular, this means that we use 4 bits per page instead of a whole unsigned long. Signed-off-by: Neil Brown Signed-off-by: Adrian Bunk Commit: 65d3f3569815bda6f390244825f046ed8248d3e0 Author: Neil Brown Sun, 12 Aug 2007 01:03:48 +0200 md/bitmap: cleaner separation of page attribute handlers in md/bitmap md/bitmap has some attributes per-page. Handling of these attributes in largely abstracted in set_page_attr and clear_page_attr. However get_page_attr exposes the format used to store them. So prior to changing that format, introduce test_page_attr instead of get_page_attr, and make appropriate usage changes. Signed-off-by: Neil Brown Signed-off-by: Adrian Bunk Commit: ddd0593c7408afa9dcc29db6a80669761107ee3c Author: Neil Brown Sun, 12 Aug 2007 00:18:08 +0200 md/bitmap: fix online removal of file-backed bitmaps When "mdadm --grow /dev/mdX --bitmap=none" is used to remove a filebacked bitmap, the bitmap was disconnected from the array, but the file wasn't closed (until the array was stopped). The file also wasn't closed if adding the bitmap file failed. Signed-off-by: Neil Brown Signed-off-by: Adrian Bunk Commit: 1da6843b983e8bebefa78f15e433320c56c27477 Author: Neil Brown Sun, 12 Aug 2007 00:17:07 +0200 md: Don't clear bits in bitmap when writing to one device fails during recovery Currently a device failure during recovery leaves bits set in the bitmap. This normally isn't a problem as the offending device will be rejected because of errors. However if device re-adding is being used with non-persistent bitmaps, this can be a problem. Signed-off-by: Neil Brown Signed-off-by: Adrian Bunk Commit: b331e968763e6509255a26dcf8b40aaa17c9d02a Author: Neil Brown Sun, 12 Aug 2007 00:15:55 +0200 md: Add '4' to the list of levels for which bitmaps are supported I really should make this a function of the personality.... Signed-off-by: Neil Brown Signed-off-by: Adrian Bunk Commit: b53bff31b95ef18d7568b805d459eb28b32767ee Author: James Bottomley Sun, 12 Aug 2007 00:03:39 +0200 [MCA] fix bus matching There's a bug in the MCA bus matching algorithm in that it promotes from signed short to int before comparing with the actual id and does sign extension on anything > 0x7fff (which means that pos ids > 0x7fff never get correctly matched). Signed-off-by: James Bottomley Signed-off-by: Adrian Bunk