diff options
author | Nate Dailey <nate.dailey@stratus.com> | 2016-02-29 15:43:58 (GMT) |
---|---|---|
committer | Shaohua Li <shli@fb.com> | 2016-03-17 21:24:51 (GMT) |
commit | ccfc7bf1f09d6190ef86693ddc761d5fe3fa47cb (patch) | |
tree | ac865debfb6c95c6daf0092fe248b7960131835c /kernel/cgroup_pids.c | |
parent | d85326cf86d7f52d1ac23c38f745470066acc76f (diff) | |
download | linux-ccfc7bf1f09d6190ef86693ddc761d5fe3fa47cb.tar.xz |
raid1: include bio_end_io_list in nr_queued to prevent freeze_array hang
If raid1d is handling a mix of read and write errors, handle_read_error's
call to freeze_array can get stuck.
This can happen because, though the bio_end_io_list is initially drained,
writes can be added to it via handle_write_finished as the retry_list
is processed. These writes contribute to nr_pending but are not included
in nr_queued.
If a later entry on the retry_list triggers a call to handle_read_error,
freeze array hangs waiting for nr_pending == nr_queued+extra. The writes
on the bio_end_io_list aren't included in nr_queued so the condition will
never be satisfied.
To prevent the hang, include bio_end_io_list writes in nr_queued.
There's probably a better way to handle decrementing nr_queued, but this
seemed like the safest way to avoid breaking surrounding code.
I'm happy to supply the script I used to repro this hang.
Fixes: 55ce74d4bfe1b(md/raid1: ensure device failure recorded before write request returns.)
Cc: stable@vger.kernel.org (v4.3+)
Signed-off-by: Nate Dailey <nate.dailey@stratus.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Diffstat (limited to 'kernel/cgroup_pids.c')
0 files changed, 0 insertions, 0 deletions