kernel/git/stable/linux-stable.git/drivers/md/raid1.c, branch linux-2.6.37.y

md: avoid spinlock problem in blk_throtl_exit

2011-03-07T23:05:11+00:00

commit da9cf5050a2e3dbc3cf26a8d908482eb4485ed49 upstream. blk_throtl_exit assumes that ->queue_lock still exists, so make sure that it does. To do this, we stop redirecting ->queue_lock to conf->device_lock and leave it pointing where it is initialised - __queue_lock. As the blk_plug functions check the ->queue_lock is held, we now take that spin_lock explicitly around the plug functions. We don't need the locking, just the warning removal. This is needed for any kernel with the blk_throtl code, which is which is 2.6.37 and later. Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman

md/raid1: really fix recovery looping when single good device fails.

2010-11-24T05:39:46+00:00

Commit 4044ba58dd15cb01797c4fd034f39ef4a75f7cc3 supposedly fixed a problem where if a raid1 with just one good device gets a read-error during recovery, the recovery would abort and immediately restart in an infinite loop. However it depended on raid1_remove_disk removing the spare device from the array. But that does not happen in this case. So add a test so that in the 'recovery_disabled' case, the device will be removed. This suitable for any kernel since 2.6.29 which is when recovery_disabled was introduced. Cc: stable@kernel.org Reported-by: Sebastian Färber Signed-off-by: NeilBrown

md: tidy up device searches in read_balance.

2010-10-29T05:40:33+00:00

The code for searching through the device list to read-balance in raid1 is rather clumsy and hard to follow. Try to simplify it a bit. No important functionality change here. Signed-off-by: NeilBrown

md/raid1: fix some typos in comments.

2010-10-29T05:40:33+00:00

Signed-off-by: NeilBrown

md/raid1: discard unused variable.

2010-10-29T05:40:33+00:00

This structure field (flushing_bio_list) is never used, so remove it. Signed-off-by: NeilBrown

md: use separate bio pool for each md device.

2010-10-28T06:36:15+00:00

bio_clone and bio_alloc allocate from a common bio pool. If an md device is stacked with other devices that use this pool, or under something like swap which uses the pool, then the multiple calls on the pool can cause deadlocks. So allocate a local bio pool for each md array and use that rather than the common pool. This pool is used both for regular IO and metadata updates. Signed-off-by: NeilBrown

md: change type of first arg to sync_page_io.

2010-10-28T06:36:11+00:00

Currently sync_page_io takes a 'bdev'. Every caller passes 'rdev->bdev'. We will soon want another field out of the rdev in sync_page_io, So just pass the rdev instead of the bdev out of it. Signed-off-by: NeilBrown

md/raid1: perform mem allocation before disabling writes during resync.

2010-10-28T06:36:09+00:00

Though this mem alloc is GFP_NOIO an so will not deadlock, it seems better to do the allocation before 'raise_barrier' which stops any IO requests while the resync proceeds. raid10 always uses this order, so it is at least consistent to do the same in raid1. Signed-off-by: NeilBrown

md: use bio_kmalloc rather than bio_alloc when failure is acceptable.

2010-10-28T06:36:06+00:00

bio_alloc can never fail (as it uses a mempool) but an block indefinitely, especially if the caller is holding a reference to a previously allocated bio. So these to places which both handle failure and hold multiple bios should not use bio_alloc, they should use bio_kmalloc. Signed-off-by: NeilBrown

md: Fix possible deadlock with multiple mempool allocations.

2010-10-28T06:34:07+00:00

It is not safe to allocate from a mempool while holding an item previously allocated from that mempool as that can deadlock when the mempool is close to exhaustion. So don't use a bio list to collect the bios to write to multiple devices in raid1 and raid10. Instead queue each bio as it becomes available so an unplug will activate all previously allocated bios and so a new bio has a chance of being allocated. This means we must set the 'remaining' count to '1' before submitting any requests, then when all are submitted, decrement 'remaining' and possible handle the write completion at that point. Reported-by: Torsten Kaiser Tested-by: Torsten Kaiser Signed-off-by: NeilBrown