diff options
author | NeilBrown <neilb@suse.de> | 2012-11-22 14:42:49 +1100 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2012-12-03 11:38:15 -0800 |
commit | 8486cea66096dba0ba22bbfc49979aa13268bc43 (patch) | |
tree | 070ef11f4405acebecfc6714ca1bbd7f7c51d6c6 /Makefile | |
parent | 2087b40bec809ed98810ca80526ae092f58ac5d9 (diff) |
md/raid10: close race that lose writes lost when replacement completes.
commit e7c0c3fa29280d62aa5e11101a674bb3064bd791 upstream.
When a replacement operation completes there is a small window
when the original device is marked 'faulty' and the replacement
still looks like a replacement. The faulty should be removed and
the replacement moved in place very quickly, bit it isn't instant.
So the code write out to the array must handle the possibility that
the only working device for some slot in the replacement - but it
doesn't. If the primary device is faulty it just gives up. This
can lead to corruption.
So make the code more robust: if either the primary or the
replacement is present and working, write to them. Only when
neither are present do we give up.
This bug has been present since replacement was introduced in
3.3, so it is suitable for any -stable kernel since then.
Reported-by: "George Spelvin" <linux@horizon.com>
Cc: stable@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: George Spelvin <linux@horizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'Makefile')
0 files changed, 0 insertions, 0 deletions