diff options
author | NeilBrown <neilb@suse.de> | 2008-03-04 14:29:29 -0800 |
---|---|---|
committer | Linus Torvalds <torvalds@woody.linux-foundation.org> | 2008-03-04 16:35:17 -0800 |
commit | a35e63efa1fb18c6f20f38e3ddf3f8ffbcf0f6e7 (patch) | |
tree | 8dddd54c45ebaad84a6178765d29d9536df944d1 /include/linux/raid | |
parent | 466634488e80968f12e73dd1fe6af5c37a1fbfe2 (diff) | |
download | kernel-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