linux-stable.git/drivers/md, branch linux-2.6.34.y

dm: do not forward ioctls from logical volumes to the underlying device

2014-02-10T21:10:44+00:00

commit ec8013beddd717d1740cfefb1a9b900deef85462 upstream.

A logical volume can map to just part of underlying physical volume.
In this case, it must be treated like a partition.

Based on a patch from Alasdair G Kergon.

Cc: Alasdair G Kergon 
Cc: dm-devel@redhat.com
Signed-off-by: Paolo Bonzini 
Signed-off-by: Linus Torvalds 
[PG: drop drivers/md/dm-flakey.c chunk; file not present in 2.6.34]
Signed-off-by: Paul Gortmaker

md: Don't truncate size at 4TB for RAID0 and Linear

2013-01-16T21:44:55+00:00

commit 667a5313ecd7308d79629c0738b0db588b0b0a4e upstream.

commit 27a7b260f71439c40546b43588448faac01adb93
   md: Fix handling for devices from 2TB to 4TB in 0.90 metadata.

changed 0.90 metadata handling to truncated size to 4TB as that is
all that 0.90 can record.
However for RAID0 and Linear, 0.90 doesn't need to record the size, so
this truncation is not needed and causes working arrays to become too small.

So avoid the truncation for RAID0 and Linear

This bug was introduced in 3.1 and is suitable for any stable kernels
from then onwards.
As the offending commit was tagged for 'stable', any stable kernel
that it was applied to should also get this patch.  That includes
at least 2.6.32, 2.6.33 and 3.0. (Thanks to Ben Hutchings for
providing that list).

Signed-off-by: Neil Brown 
Signed-off-by: Paul Gortmaker

md: Fix handling for devices from 2TB to 4TB in 0.90 metadata.

2013-01-16T21:44:55+00:00

commit 27a7b260f71439c40546b43588448faac01adb93 upstream.

0.90 metadata uses an unsigned 32bit number to count the number of
kilobytes used from each device.
This should allow up to 4TB per device.
However we multiply this by 2 (to get sectors) before casting to a
larger type, so sizes above 2TB get truncated.

Also we allow rdev->sectors to be larger than 4TB, so it is possible
for the array to be resized larger than the metadata can handle.
So make sure rdev->sectors never exceeds 4TB when 0.90 metadata is in
used.

Also the sanity check at the end of super_90_load should include level
1 as it used ->size too. (RAID0 and Linear don't use ->size at all).

Reported-by: Pim Zandbergen 
Signed-off-by: NeilBrown 
Signed-off-by: Paul Gortmaker

md/raid5: abort any pending parity operations when array fails.

2012-08-17T19:35:54+00:00

commit 9a3f530f39f4490eaa18b02719fb74ce5f4d2d86 upstream.

When the number of failed devices exceeds the allowed number
we must abort any active parity operations (checks or updates) as they
are no longer meaningful, and can lead to a BUG_ON in
handle_parity_checks6.

This bug was introduce by commit 6c0069c0ae9659e3a91b68eaed06a5c6c37f45c8
in 2.6.29.

Reported-by: Manish Katiyar 
Tested-by: Manish Katiyar 
Acked-by: Dan Williams 
Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman 
[PG: use 2.6.32.49 backport since raid5.c @ 9a3f530f/v3.2 differs more]
Signed-off-by: Paul Gortmaker

md/linear: avoid corrupting structure while waiting for rcu_free to complete.

2012-08-17T19:35:10+00:00

commit 1b6afa17581027218088a18a9ceda600e0ddba7a upstream.

I don't know what I was thinking putting 'rcu' after a dynamically
sized array!  The array could still be in use when we call rcu_free()
(That is the point) so we mustn't corrupt it.

Signed-off-by: NeilBrown 
Signed-off-by: Paul Gortmaker

dm: fix idr leak on module removal

2012-05-17T15:21:25+00:00

commit d15b774c2920d55e3d58275c97fbe3adc3afde38 upstream.

Destroy _minor_idr when unloading the core dm module.  (Found by kmemleak.)

Signed-off-by: Alasdair G Kergon 
Signed-off-by: Paul Gortmaker

dm mpath: fix potential NULL pointer in feature arg processing

2012-05-17T15:21:25+00:00

commit 286f367dad40beb3234a18c17391d03ba939a7f3 upstream.

Avoid dereferencing a NULL pointer if the number of feature arguments
supplied is fewer than indicated.

Signed-off-by: Mike Snitzer 
Signed-off-by: Alasdair G Kergon 
Signed-off-by: Paul Gortmaker

md: avoid endless recovery loop when waiting for fail device to complete.

2012-05-17T15:21:01+00:00

commit 4274215d24633df7302069e51426659d4759c5ed upstream.

If a device fails in a way that causes pending request to take a while
to complete, md will not be able to immediately remove it from the
array in remove_and_add_spares.
It will then incorrectly look like a spare device and md will try to
recover it even though it is failed.
This leads to a recovery process starting and instantly aborting over
and over again.

We should check if the device is faulty before considering it to be a
spare.  This will avoid trying to start a recovery that cannot
proceed.

This bug was introduced in 2.6.26 so that patch is suitable for any
kernel since then.

Reported-by: Jim Paradis 
Signed-off-by: NeilBrown 
Signed-off-by: Paul Gortmaker

md/raid5: fix FUA request handling in ops_run_io()

2012-05-17T15:20:51+00:00

commit b062962edb086011e94ec4d9eb3f6a6d814f2a8f upstream.

Commit e9c7469bb4f5 ("md: implment REQ_FLUSH/FUA support")
introduced R5_WantFUA flag and set rw to WRITE_FUA in that case.
However remaining code still checks whether rw is exactly same
as WRITE or not, so FUAed-write ends up with being treated as
READ. Fix it.

This bug has been present since 2.6.37 and the fix is suitable for any
-stable kernel since then.  It is not clear why this has not caused
more problems.

Cc: Tejun Heo 
Signed-off-by: Namhyung Kim 
Signed-off-by: NeilBrown 
Signed-off-by: Paul Gortmaker

md/raid5: fix raid5_set_bi_hw_segments

2012-05-17T15:20:50+00:00

commit 9b2dc8b665932a8e681a7ab3237f60475e75e161 upstream.

The @bio->bi_phys_segments consists of active stripes count in the
lower 16 bits and processed stripes count in the upper 16 bits. So
logical-OR operator should be bitwise one.

This bug has been present since 2.6.27 and the fix is suitable for any
-stable kernel since then.  Fortunately the bad code is only used on
error paths and is relatively unlikely to be hit.

Signed-off-by: Namhyung Kim 
Signed-off-by: NeilBrown 
Signed-off-by: Paul Gortmaker