summaryrefslogtreecommitdiffstats
path: root/include/linux/raid
diff options
context:
space:
mode:
authorNeilBrown <neilb@suse.de>2008-03-04 14:29:29 -0800
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2008-03-04 16:35:17 -0800
commita35e63efa1fb18c6f20f38e3ddf3f8ffbcf0f6e7 (patch)
tree8dddd54c45ebaad84a6178765d29d9536df944d1 /include/linux/raid
parent466634488e80968f12e73dd1fe6af5c37a1fbfe2 (diff)
downloadkernel-crypto-a35e63efa1fb18c6f20f38e3ddf3f8ffbcf0f6e7.tar.gz
kernel-crypto-a35e63efa1fb18c6f20f38e3ddf3f8ffbcf0f6e7.tar.xz
kernel-crypto-a35e63efa1fb18c6f20f38e3ddf3f8ffbcf0f6e7.zip
md: fix deadlock in md/raid1 and md/raid10 when handling a read error
When handling a read error, we freeze the array to stop any other IO while attempting to over-write with correct data. This is done in the raid1d(raid10d) thread and must wait for all submitted IO to complete (except for requests that failed and are sitting in the retry queue - these are counted in ->nr_queue and will stay there during a freeze). However write requests need attention from raid1d as bitmap updates might be required. This can cause a deadlock as raid1 is waiting for requests to finish that themselves need attention from raid1d. So we create a new function 'flush_pending_writes' to give that attention, and call it in freeze_array to be sure that we aren't waiting on raid1d. Thanks to "K.Tanaka" <k-tanaka@ce.jp.nec.com> for finding and reporting this problem. Cc: "K.Tanaka" <k-tanaka@ce.jp.nec.com> Signed-off-by: Neil Brown <neilb@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'include/linux/raid')
0 files changed, 0 insertions, 0 deletions