linux-toradex.git/drivers/md/raid10.c, branch v3.5.1

md/raid10: fix careless build error

2012-07-03T23:35:35+00:00

build error introduced by commit b357f04a67c2aeee8

That function doesn't get extra args until a later patch.  Bother.

Reported-by: Fengguang Wu  
Reported-by: Simon Kirby 
Reported-by: Tobias Klausmann 
Signed-off-by: NeilBrown

md: fix up plugging (again).

2012-07-03T07:45:31+00:00

The value returned by "mddev_check_plug" is only valid until the
next 'schedule' as that will unplug things.  This could happen at any
call to mempool_alloc.
So just calling mddev_check_plug at the start doesn't really make
sense.

So call it just before, or just after, queuing things for the thread.
As the action that happens at unplug is to wake the thread, this makes
lots of sense.
If we cannot add a plug (which requires a small GFP_ATOMIC alloc) we
wake thread immediately.

RAID5 is a bit different.  Requests are queued for the thread and the
thread is woken by release_stripe.  So we don't need to wake the
thread on failure.
However the thread doesn't perform certain actions when there is any
active plug, so it is important to install a plug before waking the
thread.  So for RAID5 we install the plug *before* queuing the request
and waking the thread.

Without this patch it is possible for raid1 or raid10 to queue a
request without then waking the thread, resulting in the array locking
up.

Also change raid10 to only flush_pending_write when there are not
active plugs, just like raid1.

This patch is suitable for 3.0 or later.  I plan to submit it to
-stable, but I'll like to let it spend a few weeks in mainline
first to be sure it is completely safe.

Signed-off-by: NeilBrown

md: make 'name' arg to md_register_thread non-optional.

2012-07-03T05:56:52+00:00

Having the 'name' arg optional and defaulting to the current
personality name is no necessary and leads to errors, as when
changing the level of an array we can end up using the
name of the old level instead of the new one.

So make it non-optional and always explicitly pass the name
of the level that the array will be.

Reported-by: majianpeng 
Signed-off-by: NeilBrown

md/raid10: fix failure when trying to repair a read error.

2012-07-03T05:55:33+00:00

commit 58c54fcca3bac5bf9290cfed31c76e4c4bfbabaf
     md/raid10: handle further errors during fix_read_error better.

in 3.1 added "r10_sync_page_io" which takes an IO size in sectors.
But we were passing the IO size in bytes!!!
This resulting in bio_add_page failing, and empty request being sent
down, and a consequent BUG_ON in scsi_lib.

[fix missing space in error message at same time]

This fix is suitable for 3.1.y and later.

Cc: stable@vger.kernel.org
Reported-by: Christian Balzer 
Signed-off-by: NeilBrown

md/raid10: Don't try to recovery unmatched (and unused) chunks.

2012-07-03T00:37:30+00:00

If a RAID10 has an odd number of chunks - as might happen when there
are an odd number of devices - the last chunk has no pair and so is
not mirrored.  We don't store data there, but when recovering the last
device in an array we retry to recover that last chunk from a
non-existent location.  This results in an error, and the recovery
aborts.

When we get to that last chunk we should just stop - there is nothing
more to do anyway.

This bug has been present since the introduction of RAID10, so the
patch is appropriate for any -stable kernel.

Cc: stable@vger.kernel.org
Reported-by: Christian Balzer 
Tested-by: Christian Balzer 
Signed-off-by: NeilBrown

md: raid1/raid10: fix problem with merge_bvec_fn

2012-05-31T05:56:30+00:00

The new merge_bvec_fn which calls the corresponding function
in subsidiary devices requires that mddev->merge_check_needed
be set if any child has a merge_bvec_fn.

However were were only setting that when a device was hot-added,
not when a device was present from the start.

This bug was introduced in 3.4 so patch is suitable for 3.4.y
kernels.  However that are conflicts in raid10.c so a separate
patch will be needed for 3.4.y.

Cc: stable@vger.kernel.org
Reported-by: Sebastian Riemer 
Signed-off-by: NeilBrown

md/raid10: Remove extras after reshape to smaller number of devices.

2012-05-22T03:55:33+00:00

When a reshape which reduced the number of devices finishes
we must remove the extra devices.

So ensure  that raid10_remove_disk won't try to keep them, and
have raid10_finish_reshape clear the 'in_sync' flag.  Then
remove_and_add_spares will be able to remove them.

Reported-by: Hannes Reinecke 
Signed-off-by: NeilBrown

md/raid10: resize bitmap when required during reshape.

2012-05-22T03:55:28+00:00

If a reshape changes the size of the array, then we can now
update the bitmap to suit - so do so.

Signed-off-by: NeilBrown

md: allow array to be resized while bitmap is present.

2012-05-22T03:55:27+00:00

Now that bitmaps can be resized, we can allow an array to be resized
while the bitmap is present.

This only covers resizing that involves changing the effective size
of member devices, not resizing that changes the number of devices.

Signed-off-by: NeilBrown

md/raid10: Fix memleak in r10buf_pool_alloc

2012-05-22T03:55:03+00:00

If the allocation of rep1_bio fails, we currently don't free the 'bio'
of the same dev.

Reported by kmemleak.

Signed-off-by: majianpeng 
Signed-off-by: NeilBrown