aboutsummaryrefslogtreecommitdiff
path: root/Makefile
diff options
context:
space:
mode:
authorNeilBrown <neilb@suse.de>2012-11-22 14:42:49 +1100
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2012-12-03 11:38:15 -0800
commit8486cea66096dba0ba22bbfc49979aa13268bc43 (patch)
tree070ef11f4405acebecfc6714ca1bbd7f7c51d6c6 /Makefile
parent2087b40bec809ed98810ca80526ae092f58ac5d9 (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