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

md: avoid dereferencing NULL pointer when accessing suspend_* sysfs attributes.

2009-07-30T23:06:07+00:00

commit b8d966efd9a46a9a35beac50cbff6e30565125ef upstream.

If we try to modify one of the md/ sysfs files
  suspend_lo or suspend_hi
when the array is not active, we dereference a NULL.
Protect against that.

Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman

Revert "dm: sysfs skip output when device is being destroyed"

2009-07-20T03:43:27+00:00

This reverts commit 9fad9f263a7065be94bf77519346d0d854ff3b92.

It is really commit 4d89b7b4e4726893453d0fb4ddbb5b3e16353994 that is
being reverted here, it's a patch that should not have been applied to
the .27 tree.

Signed-off-by: Greg Kroah-Hartman

dm: sysfs skip output when device is being destroyed

2009-07-02T23:32:10+00:00

commit 4d89b7b4e4726893453d0fb4ddbb5b3e16353994 upstream.

Do not process sysfs attributes when device is being destroyed.

Otherwise code can cause
  BUG_ON(test_bit(DMF_FREEING, &md->flags));
in dm_put() call.

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

dm mpath: validate table argument count

2009-07-02T23:32:08+00:00

commit 0e0497c0c017664994819f4602dc07fd95896c52 upstream.

The parser reads the argument count as a number but doesn't check that
sufficient arguments are supplied. This command triggers the bug:

dmsetup create mpath --table "0 `blockdev --getsize /dev/mapper/cr0`
    multipath 0 0 2 1 round-robin 1000 0 1 1 /dev/mapper/cr0
    round-robin 0 1 1 /dev/mapper/cr1 1000"
kernel BUG at drivers/md/dm-mpath.c:530!

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

dm mpath: validate hw_handler argument count

2009-07-02T23:32:07+00:00

commit e094f4f15f5169526c7200b9bde44b900548a81e upstream.

Fix arg count parsing error in hw handlers.

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

md/raid5: add missing call to schedule() after prepare_to_wait()

2009-07-02T23:31:53+00:00

commit 7a3ab908948b6296ee7e81d42f7c176361c51975 upstream.

In the unlikely event that reshape progresses past the current request
while it is waiting for a stripe we need to schedule() before retrying
for 2 reasons:
1/ Prevent list corruption from duplicated list_add() calls without
   intervening list_del().
2/ Give the reshape code a chance to make some progress to resolve the
   conflict.

Signed-off-by: Dan Williams 
Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman

md: remove ability to explicit set an inactive array to 'clean'.

2009-05-20T05:20:07+00:00

commit 5bf295975416f8e97117bbbcfb0191c00bc3e2b4 upstream.

Being able to write 'clean' to an 'array_state' of an inactive array
to activate it in 'clean' mode is both unnecessary and inconvenient.

It is unnecessary because the same can be achieved by writing
'active'.  This activates and array, but it still remains 'clean'
until the first write.

It is inconvenient because writing 'clean' is more often used to
cause an 'active' array to revert to 'clean' mode (thus blocking
any writes until a 'write-pending' is promoted to 'active').

Allowing 'clean' to both activate an array and mark an active array as
clean can lead to races:  One program writes 'clean' to mark the
active array as clean at the same time as another program writes
'inactive' to deactivate (stop) and active array.  Depending on which
writes first, the array could be deactivated and immediately
reactivated which isn't what was desired.

So just disable the use of 'clean' to activate an array.

This avoids a race that can be triggered with mdadm-3.0 and external
metadata, so it suitable for -stable.

Reported-by: Rafal Marszewski 
Acked-by: Dan Williams 
Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman

md/raid10: don't clear bitmap during recovery if array will still be degraded.

2009-05-20T05:20:05+00:00

commit 18055569127253755d01733f6ecc004ed02f88d0 upstream.

If we have a raid10 with multiple missing devices, and we recover just
one of these to a spare, then we risk (depending on the bitmap and
array chunk size) clearing bits of the bitmap for which recovery isn't
complete (because a device is still missing).

This can lead to a subsequent "re-add" being recovered without
any IO happening, which would result in loss of data.

This patch takes the safe approach of not clearing bitmap bits
if the array will still be degraded.

This patch is suitable for all active -stable kernels.

Cc: stable@kernel.org
Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman

md: fix some (more) errors with bitmaps on devices larger than 2TB.

2009-05-20T05:20:05+00:00

commit db305e507d554430a69ede901a6308e6ecb72349 upstream.

If a write intent bitmap covers more than 2TB, we sometimes work with
values beyond 32bit, so these need to be sector_t.  This patches
add the required casts to some unsigned longs that are being shifted
up.

This will affect any raid10 larger than 2TB, or any raid1/4/5/6 with
member devices that are larger than 2TB.

Signed-off-by: NeilBrown 
Reported-by: "Mario 'BitKoenig' Holbe" 
Signed-off-by: Greg Kroah-Hartman

md: fix loading of out-of-date bitmap.

2009-05-20T05:20:05+00:00

commit b74fd2826c5acce20e6f691437b2d19372bc2057 upstream.

When md is loading a bitmap which it knows is out of date, it fills
each page with 1s and writes it back out again.  However the
write_page call makes used of bitmap->file_pages and
bitmap->last_page_size which haven't been set correctly yet.  So this
can sometimes fail.

Move the setting of file_pages and last_page_size to before the call
to write_page.

This bug can cause the assembly on an array to fail, thus making the
data inaccessible.  Hence I think it is a suitable candidate for
-stable.

Reported-by: Vojtech Pavlik 
Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman