linux-toradex.git/drivers/md, branch v3.0.26

dm raid: fix flush support

2012-03-12T17:33:01+00:00

commit 0ca93de9b789e0eb05e103f0c04de72df13da73a upstream.

Fix dm-raid flush support.

Both md and dm have support for flush, but the dm-raid target
forgot to set the flag to indicate that flushes should be
passed on.  (Important for data integrity e.g. with writeback cache
enabled.)

Signed-off-by: Jonathan Brassow 
Acked-by: Mike Snitzer 
Signed-off-by: Alasdair G Kergon 
Signed-off-by: Greg Kroah-Hartman

dm io: fix discard support

2012-03-12T17:33:01+00:00

commit 0c535e0d6f463365c29623350dbd91642363c39b upstream.

This patch fixes a crash by recognising discards in dm_io.

Currently dm_mirror can send REQ_DISCARD bios if running over a
discard-enabled device and without support in dm_io the system
crashes badly.

BUG: unable to handle kernel paging request at 00800000
IP:  __bio_add_page.part.17+0xf5/0x1e0
...
 bio_add_page+0x56/0x70
 dispatch_io+0x1cf/0x240 [dm_mod]
 ? km_get_page+0x50/0x50 [dm_mod]
 ? vm_next_page+0x20/0x20 [dm_mod]
 ? mirror_flush+0x130/0x130 [dm_mirror]
 dm_io+0xdc/0x2b0 [dm_mod]
...

Introduced in 2.6.38-rc1 by commit 5fc2ffeabb9ee0fc0e71ff16b49f34f0ed3d05b4
(dm raid1: support discard).

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

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

2012-01-26T01:24:54+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 
Signed-off-by: Greg Kroah-Hartman

md/raid5: fix bug that could result in reads from a failed device.

2011-12-21T20:57:42+00:00

commit 355840e7a7e56bb2834fd3b0da64da5465f8aeaa upstream.

commit a847627709b3402163d99f7c6fda4a77bcd6b51b in linux-3.0.9
attempted to backport this to 3.0 but only made one change were two
were necessary.  This add the second change.

This bug was introduced in 415e72d034c50520ddb7ff79e7d1792c1306f0c9
which was in 2.6.36.

There is a small window of time between when a device fails and when
it is removed from the array.  During this time we might still read
from it, but we won't write to it - so it is possible that we could
read stale data.

We didn't need the test of 'Faulty' before because the test on
In_sync is sufficient.  Since we started allowing reads from the early
part of non-In_sync devices we need a test on Faulty too.

This is suitable for any kernel from 2.6.36 onwards, though the patch
might need a bit of tweaking in 3.0 and earlier.

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

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

2011-11-21T22:31:22+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

md/raid5: fix bug that could result in reads from a failed device.

2011-11-11T17:35:53+00:00

commit 355840e7a7e56bb2834fd3b0da64da5465f8aeaa upstream.

This bug was introduced in 415e72d034c50520ddb7ff79e7d1792c1306f0c9
which was in 2.6.36.

There is a small window of time between when a device fails and when
it is removed from the array.  During this time we might still read
from it, but we won't write to it - so it is possible that we could
read stale data.

We didn't need the test of 'Faulty' before because the test on
In_sync is sufficient.  Since we started allowing reads from the early
part of non-In_sync devices we need a test on Faulty too.

This is suitable for any kernel from 2.6.36 onwards, though the patch
might need a bit of tweaking in 3.0 and earlier.

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

dm table: avoid crash if integrity profile changes

2011-10-16T21:14:53+00:00

commit 876fbba1db4a377f050a2bb49b474c7527b2995d upstream.

Commit a63a5cf (dm: improve block integrity support) introduced a
two-phase initialization of a DM device's integrity profile.  This
patch avoids dereferencing a NULL 'template_disk' pointer in
blk_integrity_register() if there is an integrity profile mismatch in
dm_table_set_integrity().

This can occur if the integrity profiles for stacked devices in a DM
table are changed between the call to dm_table_prealloc_integrity() and
dm_table_set_integrity().

Reported-by: Zdenek Kabelac 
Signed-off-by: Mike Snitzer 
Signed-off-by: Alasdair G Kergon 
Signed-off-by: Greg Kroah-Hartman

md: Avoid waking up a thread after it has been freed.

2011-10-16T21:14:53+00:00

commit 01f96c0a9922cd9919baf9d16febdf7016177a12 upstream.

Two related problems:

1/ some error paths call "md_unregister_thread(mddev->thread)"
   without subsequently clearing ->thread.  A subsequent call
   to mddev_unlock will try to wake the thread, and crash.

2/ Most calls to md_wakeup_thread are protected against the thread
   disappeared either by:
      - holding the ->mutex
      - having an active request, so something else must be keeping
        the array active.
   However mddev_unlock calls md_wakeup_thread after dropping the
   mutex and without any certainty of an active request, so the
   ->thread could theoretically disappear.
   So we need a spinlock to provide some protections.

So change md_unregister_thread to take a pointer to the thread
pointer, and ensure that it always does the required locking, and
clears the pointer properly.

Reported-by: "Moshe Melnikov" 
Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman

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

2011-10-03T18:40:14+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: Greg Kroah-Hartman

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

2011-10-03T18:40:03+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: Greg Kroah-Hartman