[PATCH v3 07/12] md: suspend i/o during runtime blk_integrity_unregister
NeilBrown
neilb at suse.com
Tue Jan 12 18:14:39 PST 2016
On Thu, Oct 22 2015, Dan Williams wrote:
> Synchronize pending i/o against a change in the integrity profile to
> avoid the possibility of spurious integrity errors. Given linear_add()
> is suspending the mddev before manipulating the mddev, do the same for
> the other personalities.
>
> Acked-by: NeilBrown <neilb at suse.com>
> Signed-off-by: Dan Williams <dan.j.williams at intel.com>
> ---
> drivers/md/md.c | 1 +
> drivers/md/multipath.c | 2 ++
> drivers/md/raid1.c | 2 ++
> drivers/md/raid10.c | 2 ++
> 4 files changed, 7 insertions(+)
>
> diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
> index 7c99a4037715..6f0ec107996a 100644
> --- a/drivers/md/raid10.c
> +++ b/drivers/md/raid10.c
> @@ -1736,7 +1736,9 @@ static int raid10_add_disk(struct mddev *mddev, struct md_rdev *rdev)
> rcu_assign_pointer(p->rdev, rdev);
> break;
> }
> + mddev_suspend(mddev);
> md_integrity_add_rdev(rdev, mddev);
> + mddev_resume(mddev);
> if (mddev->queue && blk_queue_discard(bdev_get_queue(rdev->bdev)))
> queue_flag_set_unlocked(QUEUE_FLAG_DISCARD, mddev->queue);
>
Hi Dan,
Somewhat belatedly I am testing this code, and it deadlocks. Which is
obvious once I think about it.
raid10_add_disk() is called from
raid10d -> md_check_recovery -> remove_and_add_spares
so this call to mddev_suspend() will block raid10d until all pending IO
completes. But raid10d might be needed to complete some IO -
particularly in the case of errors. I don't know exactly what is
deadlocking in my test, but it doesn't surprise me that something does.
Can you explain in more detail what needs to be synchronised here? If
the synchronisation doesn't happen, what can do wrong?
Because I cannot imagine what this might actually be protecting against.
Thanks,
NeilBrown
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-nvme/attachments/20160113/219e785c/attachment-0001.sig>
More information about the Linux-nvme
mailing list