linux-toradex.git/drivers/md, branch v2.6.25.12

md: ensure all blocks are uptodate or locked when syncing

2008-07-24T16:14:07+00:00

commit 7a1fc53c5adb910751a9b212af90302eb4ffb527 upstream

Remove the dubious attempt to prefer 'compute' over 'read'.  Not only is it
wrong given commit c337869d (md: do not compute parity unless it is on a failed
drive), but it can trigger a BUG_ON in handle_parity_checks5().

Signed-off-by: Dan Williams 
Signed-off-by: Neil Brown 
Signed-off-by: Greg Kroah-Hartman

md: Ensure interrupted recovery completed properly (v1 metadata plus bitmap)

2008-07-24T16:14:03+00:00

commit 8c2e870a625bd336b2e7a65a97c1836acef07322 upstream

If, while assembling an array, we find a device which is not fully
in-sync with the array, it is important to set the "fullsync" flags.
This is an exact analog to the setting of this flag in hot_add_disk
methods.

Currently, only v1.x metadata supports having devices in an array
which are not fully in-sync (it keep track of how in sync they are).
The 'fullsync' flag only makes a difference when a write-intent bitmap
is being used.  In this case it tells recovery to ignore the bitmap
and recovery all blocks.

This fix is already in place for raid1, but not raid5/6 or raid10.

So without this fix, a raid1 ir raid4/5/6 array with version 1.x
metadata and a write intent bitmaps, that is stopped in the middle
of a recovery, will appear to complete the recovery instantly
after it is reassembled, but the recovery will not be correct.

If you might have an array like that, issueing
   echo repair > /sys/block/mdXX/md/sync_action

will make sure recovery completes properly.

Signed-off-by: Neil Brown 
Signed-off-by: Greg Kroah-Hartman

md: Don't acknowlege that stripe-expand is complete until it really is.

2008-07-24T16:14:03+00:00

commit efe311431869b40d67911820a309f9a1a41306f3 upstream

We shouldn't acknowledge that a stripe has been expanded (When
reshaping a raid5 by adding a device) until the moved data has
actually been written out.  However we are currently
acknowledging (by calling md_done_sync) when the POST_XOR
is complete and before the write.

So track in s.locked whether there are pending writes, and don't
call md_done_sync yet if there are.

Note: we all set R5_LOCKED on devices which are are about to
read from.  This probably isn't technically necessary, but is
usually done when writing a block, and justifies the use of
s.locked here.

This bug can lead to a crash if an array is stopped while an reshape
is in progress.

Signed-off-by: Neil Brown 
Signed-off-by: Greg Kroah-Hartman

md: Fix error paths if md_probe fails.

2008-07-24T16:14:02+00:00

commit 9bbbca3a0ee09293108b67835c6bdf6196d7bcb3 upstream

md_probe can fail (e.g. alloc_disk could fail) without
returning an error (as it alway returns NULL).
So when we call mddev_find immediately afterwards, we need
to check that md_probe actually succeeded.  This means checking
that mdev->gendisk is non-NULL.

Cc: Dave Jones 
Signed-off-by: Neil Brown 
Signed-off-by: Greg Kroah-Hartman

md: fix prexor vs sync_request race

2008-06-09T18:27:06+00:00

upstream commit: e0a115e5aa554b93150a8dc1c3fe15467708abb2

During the initial array synchronization process there is a window between
when a prexor operation is scheduled to a specific stripe and when it
completes for a sync_request to be scheduled to the same stripe.  When
this happens the prexor completes and the stripe is unconditionally marked
"insync", effectively canceling the sync_request for the stripe.  Prior to
2.6.23 this was not a problem because the prexor operation was done under
sh->lock.  The effect in older kernels being that the prexor would still
erroneously mark the stripe "insync", but sync_request would be held off
and re-mark the stripe as "!in_sync".

Change the write completion logic to not mark the stripe "in_sync" if a
prexor was performed.  The effect of the change is to sometimes not set
STRIPE_INSYNC.  The worst this can do is cause the resync to stall waiting
for STRIPE_INSYNC to be set.  If this were happening, then STRIPE_SYNCING
would be set and handle_issuing_new_read_requests would cause all
available blocks to eventually be read, at which point prexor would never
be used on that stripe any more and STRIPE_INSYNC would eventually be set.

echo repair > /sys/block/mdN/md/sync_action will correct arrays that may
have lost this race.

Cc: 
Signed-off-by: Dan Williams 
Signed-off-by: Neil Brown 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[chrisw: backport to 2.6.25.5]
Signed-off-by: Chris Wright

md: fix uninitialized use of mddev->recovery_wait

2008-06-09T18:27:05+00:00

upstream commit: a6d8113a986c66aeb379a26b6e0062488b3e59e1

If an array was created with --assume-clean we will oops when trying to
set ->resync_max.

Fix this by initializing ->recovery_wait in mddev_find.

Cc: 
Signed-off-by: Dan Williams 
Signed-off-by: Neil Brown 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Chris Wright

md: do not compute parity unless it is on a failed drive

2008-06-09T18:27:05+00:00

upstream commit: c337869d95011495fa181536786e74aa2d7ff031

If a block is computed (rather than read) then a check/repair operation
may be lead to believe that the data on disk is correct, when infact it
isn't.  So only compute blocks for failed devices.

This issue has been around since at least 2.6.12, but has become harder to
hit in recent kernels since most reads bypass the cache.

echo repair > /sys/block/mdN/md/sync_action will set the parity blocks to the
correct state.

Cc: 
Signed-off-by: Dan Williams 
Signed-off-by: Neil Brown 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Chris Wright

md: fix raid5 'repair' operations

2008-05-15T14:50:08+00:00

commit c8894419acf5e56851de9741c5047bebd78acd1f upstream
Date: Mon, 12 May 2008 14:02:12 -0700
Subject: md: fix raid5 'repair' operations

commit bd2ab67030e9116f1e4aae1289220255412b37fd "md: close a livelock window
in handle_parity_checks5" introduced a bug in handling 'repair' operations.
After a repair operation completes we clear the state bits tracking this
operation.  However, they are cleared too early and this results in the code
deciding to re-run the parity check operation.  Since we have done the repair
in memory the second check does not find a mismatch and thus does not do a
writeback.

Test results:
$ echo repair > /sys/block/md0/md/sync_action
$ cat /sys/block/md0/md/mismatch_cnt
51072
$ echo repair > /sys/block/md0/md/sync_action
$ cat /sys/block/md0/md/mismatch_cnt
0

(also fix incorrect indentation)

Tested-by: George Spelvin 
Acked-by: NeilBrown 
Signed-off-by: Dan Williams 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

md: fix use after free when removing rdev via sysfs

2008-05-10T04:40:43+00:00

commit: 6a51830e14529063cb2685921e1177d9af50e49a upstream

rdev->mddev is no longer valid upon return from entry->store() when the
'remove' command is given.

Signed-off-by: Dan Williams 
Signed-off-by: Neil Brown 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

dm snapshot: fix chunksize sector conversion

2008-05-01T21:44:33+00:00

commit: 924362629bf5645aee5f49f8a0d0d5b193e65997

If a snapshot has a smaller chunksize than the page size the
conversion to pages currently returns 0 instead of 1, causing:
kernel BUG in mempool_resize.

Signed-off-by: Mikulas Patocka 
Signed-off-by: Milan Broz 
Signed-off-by: Alasdair G Kergon 
Signed-off-by: Greg Kroah-Hartman