kernel/linux.git/drivers/md/raid1.c, branch v3.18.62

md/raid1: avoid reusing a resync bio after error handling.

2017-05-20T12:18:42+00:00

commit 0c9d5b127f695818c2c5a3868c1f28ca2969e905 upstream. fix_sync_read_error() modifies a bio on a newly faulty device by setting bi_end_io to end_sync_write. This ensure that put_buf() will still call rdev_dec_pending() as required, but makes sure that subsequent code in fix_sync_read_error() doesn't try to read from the device. Unfortunately this interacts badly with sync_request_write() which assumes that any bio with bi_end_io set to non-NULL other than end_sync_read is safe to write to. As the device is now faulty it doesn't make sense to write. As the bio was recently used for a read, it is "dirty" and not suitable for immediate submission. In particular, ->bi_next might be non-NULL, which will cause generic_make_request() to complain. Break this interaction by refusing to write to devices which are marked as Faulty. Reported-and-tested-by: Michael Wang Fixes: 2e52d449bcec ("md/raid1: add failfast handling for reads.") Signed-off-by: NeilBrown Signed-off-by: Shaohua Li Signed-off-by: Greg Kroah-Hartman

md:raid1: fix a dead loop when read from a WriteMostly disk

2017-05-08T05:44:07+00:00

commit 816b0acf3deb6d6be5d0519b286fdd4bafade905 upstream. If first_bad == this_sector when we get the WriteMostly disk in read_balance(), valid disk will be returned with zero max_sectors. It'll lead to a dead loop in make_request(), and OOM will happen because of endless allocation of struct bio. Since we can't get data from this disk in this case, so continue for another disk. Signed-off-by: Wei Fang Signed-off-by: Shaohua Li Cc: Julia Lawall Signed-off-by: Greg Kroah-Hartman

md/raid1: submit_bio_wait() returns 0 on success

2015-11-15T17:51:52+00:00

[ Upstream commit 203d27b0226a05202438ddb39ef0ef1acb14a759 ] This was introduced with 9e882242c6193ae6f416f2d8d8db0d9126bd996b which changed the return value of submit_bio_wait() to return != 0 on error, but didn't update the caller accordingly. Fixes: 9e882242c6 ("block: Add submit_bio_wait(), remove from md") Cc: stable@vger.kernel.org (v3.10) Reported-by: Bill Kuzeja Signed-off-by: Jes Sorensen Signed-off-by: NeilBrown Signed-off-by: Sasha Levin

md/raid1: fix test for 'was read error from last working device'.

2015-08-27T17:25:44+00:00

[ Upstream commit 34cab6f42003cb06f48f86a86652984dec338ae9 ] When we get a read error from the last working device, we don't try to repair it, and don't fail the device. We simple report a read error to the caller. However the current test for 'is this the last working device' is wrong. When there is only one fully working device, it assumes that a non-faulty device is that device. However a spare which is rebuilding would be non-faulty but so not the only working device. So change the test from "!Faulty" to "In_sync". If ->degraded says there is only one fully working device and this device is in_sync, this must be the one. This bug has existed since we allowed read_balance to read from a recovering spare in v3.0 Reported-and-tested-by: Alexander Lyakas Fixes: 76073054c95b ("md/raid1: clean up read_balance.") Cc: stable@vger.kernel.org (v3.0+) Signed-off-by: NeilBrown Signed-off-by: Sasha Levin

md/raid1: extend spinlock to protect raid1_end_read_request against inconsistencies

2015-08-27T17:25:33+00:00

[ Upstream commit 423f04d63cf421ea436bcc5be02543d549ce4b28 ] raid1_end_read_request() assumes that the In_sync bits are consistent with the ->degaded count. raid1_spare_active updates the In_sync bit before the ->degraded count and so exposes an inconsistency, as does error() So extend the spinlock in raid1_spare_active() and error() to hide those inconsistencies. This should probably be part of Commit: 34cab6f42003 ("md/raid1: fix test for 'was read error from last working device'.") as it addresses the same issue. It fixes the same bug and should go to -stable for same reasons. Fixes: 76073054c95b ("md/raid1: clean up read_balance.") Cc: stable@vger.kernel.org (v3.0+) Signed-off-by: NeilBrown Signed-off-by: Sasha Levin

md/raid1: fix read balance when a drive is write-mostly.

2015-03-06T22:53:05+00:00

commit d1901ef099c38afd11add4cfb3312c02ef21ec4a upstream. When a drive is marked write-mostly it should only be the target of reads if there is no other option. This behaviour was broken by commit 9dedf60313fa4dddfd5b9b226a0ef12a512bf9dc md/raid1: read balance chooses idlest disk for SSD which causes a write-mostly device to be *preferred* is some cases. Restore correct behaviour by checking and setting best_dist_disk and best_pending_disk rather than best_disk. We only need to test one of these as they are both changed from -1 or >=0 at the same time. As we leave min_pending and best_dist unchanged, any non-write-mostly device will appear better than the write-mostly device. Reported-by: Tomáš Hodek Reported-by: Dark Penguin Signed-off-by: NeilBrown Link: http://marc.info/?l=linux-raid&m=135982797322422 Fixes: 9dedf60313fa4dddfd5b9b226a0ef12a512bf9dc Signed-off-by: Greg Kroah-Hartman

md: remove unwanted white space from md.c

2014-10-14T02:08:29+00:00

My editor shows much of this is RED. Signed-off-by: NeilBrown

md/raid1: process_checks doesn't use its return value.

2014-10-14T02:08:28+00:00

process_checks() always returns '0', so change it to 'void'. Signed-off-by: NeilBrown

md: use set_bit/clear_bit instead of shift/mask for bi_flags changes.

2014-10-08T23:07:04+00:00

Using {set,clear}_bit is more consistent than shifting and masking. No functional change. Signed-off-by: NeilBrown

md/raid1: minor typos and reformatting.

2014-10-08T23:07:04+00:00

Signed-off-by: NeilBrown