summaryrefslogtreecommitdiff
path: root/scripts/basic
diff options
context:
space:
mode:
authorYufen Yu <yuyufen@huawei.com>2018-02-06 17:39:15 +0800
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2018-05-30 07:48:59 +0200
commit247e3b4dd0ccf6e703dfd9eb86af953849ed2999 (patch)
treeeb65e979a42c979c49f6f6e054aedc0f475d05a0 /scripts/basic
parent3e1e6e1c2d55b83aa3017dded40880838765fe2e (diff)
md raid10: fix NULL deference in handle_write_completed()
[ Upstream commit 01a69cab01c184d3786af09e9339311123d63d22 ] In the case of 'recover', an r10bio with R10BIO_WriteError & R10BIO_IsRecover will be progressed by handle_write_completed(). This function traverses all r10bio->devs[copies]. If devs[m].repl_bio != NULL, it thinks conf->mirrors[dev].replacement is also not NULL. However, this is not always true. When there is an rdev of raid10 has replacement, then each r10bio ->devs[m].repl_bio != NULL in conf->r10buf_pool. However, in 'recover', even if corresponded replacement is NULL, it doesn't clear r10bio ->devs[m].repl_bio, resulting in replacement NULL deference. This bug was introduced when replacement support for raid10 was added in Linux 3.3. As NeilBrown suggested: Elsewhere the determination of "is this device part of the resync/recovery" is made by resting bio->bi_end_io. If this is end_sync_write, then we tried to write here. If it is NULL, then we didn't try to write. Fixes: 9ad1aefc8ae8 ("md/raid10: Handle replacement devices during resync.") Cc: stable (V3.3+) Suggested-by: NeilBrown <neilb@suse.com> Signed-off-by: Yufen Yu <yuyufen@huawei.com> Signed-off-by: Shaohua Li <sh.li@alibaba-inc.com> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'scripts/basic')
0 files changed, 0 insertions, 0 deletions