From patchwork Fri Mar 1 15:21:25 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Xiao Ni X-Patchwork-Id: 13578601 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CA59A3D0BE for ; Fri, 1 Mar 2024 15:21:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709306506; cv=none; b=Fho84x0xX2JCt8cabaJaRNavf+DqrK8ook47AMqBJYI7j3b/AOvIiRBfst9AZ0qEp/yAeCJkh9mvOAXSDgYfRtXmgif9hDkmH/lVf7bPlGwOhDmi7ArL/9tSPthIYHo0vjPw/2NK9MIqF0RcjeHQNvL07rZHxd3d3LMDFZbnWAM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709306506; c=relaxed/simple; bh=vEqcjpRsJ+ymHW0SAOe0HJPDbgpPW3ZgJYkU6M1pu/o=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=a/94TjuTZAut4ivKyc/koRGY8mCsY49hdQ+Oc4eVIcxlFvFyLJLwSnjchnCUTB2pndvgbbuo1Muh0/um4HHdF4ARa/2eD9zuxFQxYcqgr3WTra9N0kVGpD3QYeollxhpP+nYafHlv+gf1rRXBt9CVOROSFsEhYyxWUZ7WJvlwrY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=N9Gvvbwr; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="N9Gvvbwr" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1709306503; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8hY8wKrmrPYhSBN3Tuj0rq8VL+4sl5GthNYEjh9QoQY=; b=N9GvvbwrZ2K94pzmOoh0nHCUl0asn6aXG98jaubVSLGCqdTHDTpS7m9U0bVttkxX/TGvyT 3tE44BkshgJ9BX1LYylP1ZXWXZMsMk8LqdpnVFRecq8ita7h9adaaTow0kbRV92Ul8eWE7 JYnC2BvSrAUJZawsqyItI5cmLoWIrAU= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-503-KDdy2XpCPiWnl84NoVjaBg-1; Fri, 01 Mar 2024 10:21:38 -0500 X-MC-Unique: KDdy2XpCPiWnl84NoVjaBg-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 1B4F4381644B; Fri, 1 Mar 2024 15:21:38 +0000 (UTC) Received: from localhost.localdomain (unknown [10.72.120.8]) by smtp.corp.redhat.com (Postfix) with ESMTP id 904901121312; Fri, 1 Mar 2024 15:21:34 +0000 (UTC) From: Xiao Ni To: song@kernel.org Cc: yukuai1@huaweicloud.com, bmarzins@redhat.com, heinzm@redhat.com, snitzer@kernel.org, ncroxon@redhat.com, linux-raid@vger.kernel.org, dm-devel@lists.linux.dev Subject: [PATCH 1/4] md: Revert "md: Don't register sync_thread for reshape directly" Date: Fri, 1 Mar 2024 23:21:25 +0800 Message-Id: <20240301152128.13465-2-xni@redhat.com> In-Reply-To: <20240301152128.13465-1-xni@redhat.com> References: <20240301152128.13465-1-xni@redhat.com> Precedence: bulk X-Mailing-List: linux-raid@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.3 This reverts commit ad39c08186f8a0f221337985036ba86731d6aafe. The reverted patch says there is no way to guarantee that md_do_sync will be executed. Users should choose a sutiable chance to wake up sync thread after registering sync thread. And this patch set tries to use a minimal change to fix dmraid regressions. With patch03 and patch04 and commit 82ec0ae59d02 ("md: Make sure md_do_sync() will set MD_RECOVERY_DONE"), all deadlock problems can be fixed. So revert this one and we can rethink about this in future. Signed-off-by: Xiao Ni --- drivers/md/md.c | 5 +---- drivers/md/raid10.c | 16 ++++++++++++++-- drivers/md/raid5.c | 29 +++++++++++++++++++++++++++-- 3 files changed, 42 insertions(+), 8 deletions(-) diff --git a/drivers/md/md.c b/drivers/md/md.c index 9e41a9aaba8b..db4743ba7f6c 100644 --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -9376,7 +9376,6 @@ static void md_start_sync(struct work_struct *ws) struct mddev *mddev = container_of(ws, struct mddev, sync_work); int spares = 0; bool suspend = false; - char *name; /* * If reshape is still in progress, spares won't be added or removed @@ -9414,10 +9413,8 @@ static void md_start_sync(struct work_struct *ws) if (spares) md_bitmap_write_all(mddev->bitmap); - name = test_bit(MD_RECOVERY_RESHAPE, &mddev->recovery) ? - "reshape" : "resync"; rcu_assign_pointer(mddev->sync_thread, - md_register_thread(md_do_sync, mddev, name)); + md_register_thread(md_do_sync, mddev, "resync")); if (!mddev->sync_thread) { pr_warn("%s: could not start resync thread...\n", mdname(mddev)); diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c index a5f8419e2df1..7412066ea22c 100644 --- a/drivers/md/raid10.c +++ b/drivers/md/raid10.c @@ -4175,7 +4175,11 @@ static int raid10_run(struct mddev *mddev) clear_bit(MD_RECOVERY_SYNC, &mddev->recovery); clear_bit(MD_RECOVERY_CHECK, &mddev->recovery); set_bit(MD_RECOVERY_RESHAPE, &mddev->recovery); - set_bit(MD_RECOVERY_NEEDED, &mddev->recovery); + set_bit(MD_RECOVERY_RUNNING, &mddev->recovery); + rcu_assign_pointer(mddev->sync_thread, + md_register_thread(md_do_sync, mddev, "reshape")); + if (!mddev->sync_thread) + goto out_free_conf; } return 0; @@ -4569,8 +4573,16 @@ static int raid10_start_reshape(struct mddev *mddev) clear_bit(MD_RECOVERY_CHECK, &mddev->recovery); clear_bit(MD_RECOVERY_DONE, &mddev->recovery); set_bit(MD_RECOVERY_RESHAPE, &mddev->recovery); - set_bit(MD_RECOVERY_NEEDED, &mddev->recovery); + set_bit(MD_RECOVERY_RUNNING, &mddev->recovery); + + rcu_assign_pointer(mddev->sync_thread, + md_register_thread(md_do_sync, mddev, "reshape")); + if (!mddev->sync_thread) { + ret = -EAGAIN; + goto abort; + } conf->reshape_checkpoint = jiffies; + md_wakeup_thread(mddev->sync_thread); md_new_event(); return 0; diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c index 6a7a32f7fb91..4c1f572cc00f 100644 --- a/drivers/md/raid5.c +++ b/drivers/md/raid5.c @@ -7936,7 +7936,11 @@ static int raid5_run(struct mddev *mddev) clear_bit(MD_RECOVERY_SYNC, &mddev->recovery); clear_bit(MD_RECOVERY_CHECK, &mddev->recovery); set_bit(MD_RECOVERY_RESHAPE, &mddev->recovery); - set_bit(MD_RECOVERY_NEEDED, &mddev->recovery); + set_bit(MD_RECOVERY_RUNNING, &mddev->recovery); + rcu_assign_pointer(mddev->sync_thread, + md_register_thread(md_do_sync, mddev, "reshape")); + if (!mddev->sync_thread) + goto abort; } /* Ok, everything is just fine now */ @@ -8502,8 +8506,29 @@ static int raid5_start_reshape(struct mddev *mddev) clear_bit(MD_RECOVERY_CHECK, &mddev->recovery); clear_bit(MD_RECOVERY_DONE, &mddev->recovery); set_bit(MD_RECOVERY_RESHAPE, &mddev->recovery); - set_bit(MD_RECOVERY_NEEDED, &mddev->recovery); + set_bit(MD_RECOVERY_RUNNING, &mddev->recovery); + rcu_assign_pointer(mddev->sync_thread, + md_register_thread(md_do_sync, mddev, "reshape")); + if (!mddev->sync_thread) { + mddev->recovery = 0; + spin_lock_irq(&conf->device_lock); + write_seqcount_begin(&conf->gen_lock); + mddev->raid_disks = conf->raid_disks = conf->previous_raid_disks; + mddev->new_chunk_sectors = + conf->chunk_sectors = conf->prev_chunk_sectors; + mddev->new_layout = conf->algorithm = conf->prev_algo; + rdev_for_each(rdev, mddev) + rdev->new_data_offset = rdev->data_offset; + smp_wmb(); + conf->generation--; + conf->reshape_progress = MaxSector; + mddev->reshape_position = MaxSector; + write_seqcount_end(&conf->gen_lock); + spin_unlock_irq(&conf->device_lock); + return -EAGAIN; + } conf->reshape_checkpoint = jiffies; + md_wakeup_thread(mddev->sync_thread); md_new_event(); return 0; } From patchwork Fri Mar 1 15:21:26 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Xiao Ni X-Patchwork-Id: 13578602 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E22AB6F076 for ; Fri, 1 Mar 2024 15:21:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709306509; cv=none; b=St35PjY9uQnhl5FLA+XDb/1OLO5uSpIE1AR4Jwpppt16z3w6nbVGxkQy+QdyhBi9a5c25xyYZT+n/tKHDFVZeb9g6E6/JLmnK8yI3b9OTnqxjc45IPgn/8vp5VKfR11qBDqI/6wo7p64SaizoeKejYGUyisTDVPSOY9M8KBFjDQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709306509; c=relaxed/simple; bh=m+V8CUAm6L5FgD/lMv6u/nUWgVgY7CFIGYZOhIAc10Y=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=DrAOQaJslonNgo74FpFPgJiU56z3K1f0FVEv1uondU5oCA+POijgsfxwyNQxfM1N0Oaoz0J126ODRDgGn4CsWkGpGnQs+W+J2Yjw3XXCnKG+nmR64XNRufanXdcuuCrRTBAEk+g/2oiPpQp6g6XCxLA7IQnFH/ZMCc40nm7Z5Uc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=QxxANqKq; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="QxxANqKq" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1709306506; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WcNNQUkDZViYg7vPWVV3aHpQjklVij2EKy0H2bDFA5k=; b=QxxANqKqN1TbaZT3QAB2lS3TyWq1VvPlUIxs7tdNb9iULQK9OffY2eesP08fM5xsxsPkYD 0GHe2piYERYMcetc8qGuTqZiqZSFQ8BQ5ykFoE/cZDoczuQ6yyMyA8rcwy+usxcPNZzsTS ghpuGbCxeIxJiY/xPTQxmHGnF0y/FFA= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-568-QRoIEdzzN4OmGDn8T89klQ-1; Fri, 01 Mar 2024 10:21:42 -0500 X-MC-Unique: QRoIEdzzN4OmGDn8T89klQ-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 6D7EB1C05B05; Fri, 1 Mar 2024 15:21:42 +0000 (UTC) Received: from localhost.localdomain (unknown [10.72.120.8]) by smtp.corp.redhat.com (Postfix) with ESMTP id C45E21121312; Fri, 1 Mar 2024 15:21:38 +0000 (UTC) From: Xiao Ni To: song@kernel.org Cc: yukuai1@huaweicloud.com, bmarzins@redhat.com, heinzm@redhat.com, snitzer@kernel.org, ncroxon@redhat.com, linux-raid@vger.kernel.org, dm-devel@lists.linux.dev Subject: [PATCH 2/4] md: Revert "md: Don't ignore suspended array in md_check_recovery()" Date: Fri, 1 Mar 2024 23:21:26 +0800 Message-Id: <20240301152128.13465-3-xni@redhat.com> In-Reply-To: <20240301152128.13465-1-xni@redhat.com> References: <20240301152128.13465-1-xni@redhat.com> Precedence: bulk X-Mailing-List: linux-raid@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.3 This reverts commit 1baae052cccd08daf9a9d64c3f959d8cdb689757. For dmraid, it doesn't allow any io including sync io when array is suspended. Although it's a simple change in this patch, it still needs more work to support it. Now we're trying to fix regression problems. So let's keep as small changes as we can. We can rethink about this in future. Signed-off-by: Xiao Ni --- drivers/md/md.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/md/md.c b/drivers/md/md.c index db4743ba7f6c..c4624814d94c 100644 --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -9496,6 +9496,9 @@ static void unregister_sync_thread(struct mddev *mddev) */ void md_check_recovery(struct mddev *mddev) { + if (READ_ONCE(mddev->suspended)) + return; + if (mddev->bitmap) md_bitmap_daemon_work(mddev); From patchwork Fri Mar 1 15:21:27 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Xiao Ni X-Patchwork-Id: 13578603 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ACA2239AC4 for ; Fri, 1 Mar 2024 15:21:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709306512; cv=none; b=q4m7YfucW8Rob41iE9wOZzlOeq8IgnqxMDxuJzh3PrbuGE58mMYtscfxO1EsFPB7rRgP+EK+kQDYujQnw3RthXEZr5DB0oCjBu13V3O0WfDKp3BEDsCEXoqcCVxwSf6z70dQeh6cofs+K81SyeRdfRpB2i+V/XZn9PhNKq2bqRQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709306512; c=relaxed/simple; bh=twKyr/AQCXonyQJFYLl2e+MyrEq0SqDqPOri9QgRcZg=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=pw+lcMV4pwyKG9/vvg9GmKno88ua/eyYXlNIHkYyzXLwKbEnnw9jRN4QdGHdrjGlnZV7nIdfPY8Pn5GOfD+cmtG0/WScSjLiqGNa/D3of6mQ+7DGIBNQJiPuD8ldrIt+2gFc+bR7YeMN1lNC3eePQ2gW7gT0mDHrDmw+AVCQCYI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=UHOnPZTB; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="UHOnPZTB" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1709306509; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3TJ5epbe1waIGIp78Jg9/7z1apy7Rzqgqd/bd6euDGg=; b=UHOnPZTBhQHKEgQxZPk9siQ1t9DlpvgRNqVIwRaLGOKleFFdopsnUVEcCcN0XuXqTHxG1Z +l8lqgsSuslqwKGP4kP0ab3DLK3QAr7FuVbSa4ccTgD/af4Bq1YLOl5Vi4fcoawO50KSDw 8Rx8O17kcINHGG6/Wx+nFi8Mo1TPmw0= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-681-IPu4BHsoMYWHmc_VPCy4ew-1; Fri, 01 Mar 2024 10:21:48 -0500 X-MC-Unique: IPu4BHsoMYWHmc_VPCy4ew-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A0248282D3CE; Fri, 1 Mar 2024 15:21:46 +0000 (UTC) Received: from localhost.localdomain (unknown [10.72.120.8]) by smtp.corp.redhat.com (Postfix) with ESMTP id 26010112132A; Fri, 1 Mar 2024 15:21:42 +0000 (UTC) From: Xiao Ni To: song@kernel.org Cc: yukuai1@huaweicloud.com, bmarzins@redhat.com, heinzm@redhat.com, snitzer@kernel.org, ncroxon@redhat.com, linux-raid@vger.kernel.org, dm-devel@lists.linux.dev Subject: [PATCH 3/4] md: Set MD_RECOVERY_FROZEN before stop sync thread Date: Fri, 1 Mar 2024 23:21:27 +0800 Message-Id: <20240301152128.13465-4-xni@redhat.com> In-Reply-To: <20240301152128.13465-1-xni@redhat.com> References: <20240301152128.13465-1-xni@redhat.com> Precedence: bulk X-Mailing-List: linux-raid@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.3 After patch commit f52f5c71f3d4b ("md: fix stopping sync thread"), dmraid stops sync thread asynchronously. The calling process is: dev_remove->dm_destroy->__dm_destroy->raid_postsuspend->raid_dtr raid_postsuspend does two jobs. First, it stops sync thread. Then it suspend array. Now it can stop sync thread successfully. But it doesn't set MD_RECOVERY_FROZEN. It's introduced by patch f52f5c71f3d4b. So after raid_postsuspend, the sync thread starts again. raid_dtr can't stop the sync thread because the array is already suspended. This can be reproduced easily by those commands: while [ 1 ]; do vgcreate test_vg /dev/loop0 /dev/loop1 lvcreate --type raid1 -L 400M -m 1 -n test_lv test_vg lvchange -an test_vg vgremove test_vg -ff done Fixes: f52f5c71f3d4 ("md: fix stopping sync thread") Signed-off-by: Xiao Ni --- drivers/md/md.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/md/md.c b/drivers/md/md.c index c4624814d94c..c96a3bb073c4 100644 --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -6340,6 +6340,7 @@ static void __md_stop_writes(struct mddev *mddev) void md_stop_writes(struct mddev *mddev) { mddev_lock_nointr(mddev); + set_bit(MD_RECOVERY_FROZEN, &mddev->recovery); __md_stop_writes(mddev); mddev_unlock(mddev); } From patchwork Fri Mar 1 15:21:28 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Xiao Ni X-Patchwork-Id: 13578604 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 617186BFDE for ; Fri, 1 Mar 2024 15:21:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709306516; cv=none; b=RLZUegsqLSWhiBczmJfRRk0nN02Ae+7jqc6lDIb4136gUxQBVB2BB4Rt2BSLj7Lfd4d6Px+I/fw9Idj0MTD84lBeNX81ZAGuJ0TeZAR5B0PDkZfCubvoR7rTjtivHs6qWZObicHYwMJPr66zF1JiLghrDatxW+k7IhAw0YE1Etw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709306516; c=relaxed/simple; bh=6e+1jXXtCepzK8hrhCWjn2kM/sSuASqeVbE240TKykY=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=Rb5jTs+xLyWWbs3ODcnWkmAZRDG6c9zfWdWsjgQ2DV8nFfrhnVqSWP9IksEJ2GujpEG3SARZ/j0M8+HdJTfI7VFcduJfad8R7z4hyZUCUghtEkUU3vrHaS+iffRaU665Cq67oGamoiR1QBBryykSfEvt1PLxJa5XSlcX3DFMAMw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=AA+pijMB; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="AA+pijMB" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1709306514; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=69y1pCQHT5Ls9fEh8AKza2wRDYR+w4p2us5TEx1Nugk=; b=AA+pijMBL5JA+AR/NHXQUd1sb8TxJ8IGR7iP4NEVhlAdxYL05VRe3MnA6R2rmoZEx5g3Yl ZRj/GRaWDDCrHFijn4bKvUuNqkErFt+CTEGhi9GT8yyvFwPRx9MbPDnmGSfcg2LWBpnIrd ehmTN5Wj6DAY+k5SKCpsnYhZOtlVpbs= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-314-hYSBQMa6OL64K-R_5dIP5Q-1; Fri, 01 Mar 2024 10:21:52 -0500 X-MC-Unique: hYSBQMa6OL64K-R_5dIP5Q-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 142BC1C05EB7; Fri, 1 Mar 2024 15:21:51 +0000 (UTC) Received: from localhost.localdomain (unknown [10.72.120.8]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5AB051121312; Fri, 1 Mar 2024 15:21:47 +0000 (UTC) From: Xiao Ni To: song@kernel.org Cc: yukuai1@huaweicloud.com, bmarzins@redhat.com, heinzm@redhat.com, snitzer@kernel.org, ncroxon@redhat.com, linux-raid@vger.kernel.org, dm-devel@lists.linux.dev Subject: [PATCH 4/4] md/raid5: Don't check crossing reshape when reshape hasn't started Date: Fri, 1 Mar 2024 23:21:28 +0800 Message-Id: <20240301152128.13465-5-xni@redhat.com> In-Reply-To: <20240301152128.13465-1-xni@redhat.com> References: <20240301152128.13465-1-xni@redhat.com> Precedence: bulk X-Mailing-List: linux-raid@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.3 stripe_ahead_of_reshape is used to check if a stripe region cross the reshape position. So first, change the function name to stripe_across_reshape to describe the usage of this function. For reshape backwards, it starts reshape from the end of array and conf-> reshape_progress is init to raid5_size. During reshape, if previous is true (set in make_stripe_request) and max_sector >= conf->reshape_progress, ios should wait until reshape window moves forward. But ios don't need to wait if max_sector is raid5_size. And put the conditions into the function directly to make understand the codes easily. This can be reproduced easily by lvm2 test shell/lvconvert-raid-reshape.sh For dm raid reshape, before starting sync thread, it needs to reload table some times. In one time dm raid uses MD_RECOVERY_WAIT to delay reshape and it doesn't start sync thread this time. Then one io comes in and it waits because stripe_ahead_of_reshape returns true because it's a backward reshape and max_sectors > conf->reshape_progress. But the reshape hasn't started. So skip this check when reshape_progress is raid5_size Fixes: 486f60558607 ("md/raid5: Check all disks in a stripe_head for reshape progress") Signed-off-by: Xiao Ni --- drivers/md/raid5.c | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c index 4c1f572cc00f..8d562c1344f4 100644 --- a/drivers/md/raid5.c +++ b/drivers/md/raid5.c @@ -5832,17 +5832,12 @@ static bool ahead_of_reshape(struct mddev *mddev, sector_t sector, sector >= reshape_sector; } -static bool range_ahead_of_reshape(struct mddev *mddev, sector_t min, - sector_t max, sector_t reshape_sector) -{ - return mddev->reshape_backwards ? max < reshape_sector : - min >= reshape_sector; -} - -static bool stripe_ahead_of_reshape(struct mddev *mddev, struct r5conf *conf, +static sector_t raid5_size(struct mddev *mddev, sector_t sectors, int raid_disks); +static bool stripe_across_reshape(struct mddev *mddev, struct r5conf *conf, struct stripe_head *sh) { sector_t max_sector = 0, min_sector = MaxSector; + sector_t reshape_pos = 0; bool ret = false; int dd_idx; @@ -5856,9 +5851,12 @@ static bool stripe_ahead_of_reshape(struct mddev *mddev, struct r5conf *conf, spin_lock_irq(&conf->device_lock); - if (!range_ahead_of_reshape(mddev, min_sector, max_sector, - conf->reshape_progress)) - /* mismatch, need to try again */ + reshape_pos = conf->reshape_progress; + if (mddev->reshape_backwards) { + if (max_sector >= reshape_pos && + reshape_pos != raid5_size(mddev, 0, 0)) + ret = true; + } else if (min_sector < reshape_pos) ret = true; spin_unlock_irq(&conf->device_lock); @@ -5969,7 +5967,7 @@ static enum stripe_result make_stripe_request(struct mddev *mddev, } if (unlikely(previous) && - stripe_ahead_of_reshape(mddev, conf, sh)) { + stripe_across_reshape(mddev, conf, sh)) { /* * Expansion moved on while waiting for a stripe. * Expansion could still move past after this