summaryrefslogtreecommitdiff
path: root/arch/m68k/include/uapi/asm/sembuf.h
diff options
context:
space:
mode:
authorNeilBrown <neilb@suse.de>2012-11-22 14:42:49 +1100
committerNeilBrown <neilb@suse.de>2012-11-22 15:12:36 +1100
commite7c0c3fa29280d62aa5e11101a674bb3064bd791 (patch)
treeeb897529fb562a99e56fe29934f141f68c906af3 /arch/m68k/include/uapi/asm/sembuf.h
parentca64cae96037de16e4af92678814f5d4bf0c1c65 (diff)
md/raid10: close race that lose writes lost when replacement completes.
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>
Diffstat (limited to 'arch/m68k/include/uapi/asm/sembuf.h')
0 files changed, 0 insertions, 0 deletions