From patchwork Thu Feb 29 15:49:36 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Xiao Ni X-Patchwork-Id: 13577295 X-Patchwork-Delegate: snitzer@redhat.com 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 32FFD7829A for ; Thu, 29 Feb 2024 15:49:56 +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=1709221797; cv=none; b=OR4YdFK2S7a/J6XqCyYYhettjBoir/qXCHpSnc4E/dSXYt+MP6wN6Ex0suFLjyNagZucAqsnDbFYssQDcrqTlOibQNU1CrWb9D2BOFn+03KlFovkLuHbZQ+XQo4CsYWVEKCmHL5+HZdLj7DkBqXc0GhmkFqrLtv0amlOtOAPpfI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709221797; c=relaxed/simple; bh=ZmC35RCrPhUTQl8+M8nLnEQvNoqf6oq53QOhvyHP3PM=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=OC1S3WiFIWto/emeJh9ZuCXgz9UBA83BaljOUe8riUijAn9nhuJzPWIdLTZPIUFjDMndDhjXXKZF0+GCUQM/ykPCCroH19XLmF/AJh8gmi8jSGyLUFRlbvgEuZEtwZBbDgdQTJKsxbOBUX23vsDPShQUe+yY+YdR1VPerqeJDYs= 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=gQ+q4UOu; 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="gQ+q4UOu" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1709221795; 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=z9c1/ubZy0Xa4EcWrsRRt62KfmBqmKDvkzP1wK/kFfs=; b=gQ+q4UOuso3u3FMHCZTJ+ZHzXUZjYqE9MIwaac5Wb6Nox/ImTzj80AFZ1f0a3KRyR0G5qJ pGNWatppijrL47Gg/xQVLPu2OJll+5O2oO4Ki6opnAYI+SjYXt7H5K0PYAgojJZcjwJcit +6T/9rmn8hZeq9xZY6BSJBPNC5SZRHU= 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-587-4y5TiYQmPdWWCQ4S0E4x1g-1; Thu, 29 Feb 2024 10:49:51 -0500 X-MC-Unique: 4y5TiYQmPdWWCQ4S0E4x1g-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (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 7560C3C2B608; Thu, 29 Feb 2024 15:49:51 +0000 (UTC) Received: from localhost.localdomain (unknown [10.72.120.8]) by smtp.corp.redhat.com (Postfix) with ESMTP id ECA93C0348B; Thu, 29 Feb 2024 15:49: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 1/6] md: Revert "md: Don't register sync_thread for reshape directly" Date: Thu, 29 Feb 2024 23:49:36 +0800 Message-Id: <20240229154941.99557-2-xni@redhat.com> In-Reply-To: <20240229154941.99557-1-xni@redhat.com> References: <20240229154941.99557-1-xni@redhat.com> Precedence: bulk X-Mailing-List: dm-devel@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.8 This reverts commit ad39c08186f8a0f221337985036ba86731d6aafe. Function stop_sync_thread only wakes up sync task. It also needs to wake up sync thread. This problem will be fixed in the following patch. 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..8497880135ee 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 Thu Feb 29 15:49:37 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Xiao Ni X-Patchwork-Id: 13577296 X-Patchwork-Delegate: snitzer@redhat.com 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 B12C5151CE8 for ; Thu, 29 Feb 2024 15:50:01 +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=1709221803; cv=none; b=DqkOp/ZvORGB8HxU7fTz+xuu0i96FEKywhq17fMlp9Ba9StnbIKBBNjunIh9ZleuxE7W1cEAH25FPRAnagAEJXxEkOqhESaWeNwhcOxuQAJ/iINBgRn+hDON2kFcwQ5iBwBGv81O3OcDjgN9UodUP+kpufewJWuCKPVEv77CHN0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709221803; c=relaxed/simple; bh=6KCzEtTF5WUnU+nH49pMCEZH3yxkZWWwXlBTM3MMiHw=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=kTLIaYQyrUGZJN3QafOl8Q/JsBwLvPZr0Zx5GMVeDFOADVoFE6VeBJGaCL1yRjH18XRT6KOubUp7tC6K4SdJrkPUFR8kYqX0Yi+E237Pi3nO8DYTUCTu+k/NVxPqQnEjKUp5R/xyTDXDBIhVQObDYkXFu7k2zLUtbl2nFYZqSp0= 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=bS662fnm; 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="bS662fnm" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1709221800; 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=da+5u9B4hhHOxuNEUVTs2cHeQnZWLj/nJmX2jJGb57A=; b=bS662fnmZMHiPegxjNRHCd4T4Pb6r4d3FT+phcp7o1ycBCUxehPZ4qGIuu4nfA2HPew4vr y45ur9Q3L8Lz7jP8oBM8vY4n0EsAB3QhW8v/oCunId8BSN3K7Jmz93hmHuguflIC9n+JEs jYh7mf9+nysBwszT/Upr54y6wen54Os= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-447-pOhqcrI_NX25mUPXwc5HbQ-1; Thu, 29 Feb 2024 10:49:56 -0500 X-MC-Unique: pOhqcrI_NX25mUPXwc5HbQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (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 C8A3688D284; Thu, 29 Feb 2024 15:49:55 +0000 (UTC) Received: from localhost.localdomain (unknown [10.72.120.8]) by smtp.corp.redhat.com (Postfix) with ESMTP id 294B1C1D36C; Thu, 29 Feb 2024 15:49:51 +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/6] md: Revert "md: Make sure md_do_sync() will set MD_RECOVERY_DONE" Date: Thu, 29 Feb 2024 23:49:37 +0800 Message-Id: <20240229154941.99557-3-xni@redhat.com> In-Reply-To: <20240229154941.99557-1-xni@redhat.com> References: <20240229154941.99557-1-xni@redhat.com> Precedence: bulk X-Mailing-List: dm-devel@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.8 This reverts commit 82ec0ae59d02e89164b24c0cc8e4e50de78b5fd6. The root cause is that MD_RECOVERY_WAIT isn't cleared when stopping raid. The following patch 'Clear MD_RECOVERY_WAIT when stopping dmraid' fixes this problem. Signed-off-by: Xiao Ni --- drivers/md/md.c | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/drivers/md/md.c b/drivers/md/md.c index db4743ba7f6c..6376b1aad4d9 100644 --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -8792,16 +8792,12 @@ void md_do_sync(struct md_thread *thread) int ret; /* just incase thread restarts... */ - if (test_bit(MD_RECOVERY_DONE, &mddev->recovery)) + if (test_bit(MD_RECOVERY_DONE, &mddev->recovery) || + test_bit(MD_RECOVERY_WAIT, &mddev->recovery)) return; - - if (test_bit(MD_RECOVERY_INTR, &mddev->recovery)) - goto skip; - - if (test_bit(MD_RECOVERY_WAIT, &mddev->recovery) || - !md_is_rdwr(mddev)) {/* never try to sync a read-only array */ + if (!md_is_rdwr(mddev)) {/* never try to sync a read-only array */ set_bit(MD_RECOVERY_INTR, &mddev->recovery); - goto skip; + return; } if (mddev_is_clustered(mddev)) { From patchwork Thu Feb 29 15:49:38 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Xiao Ni X-Patchwork-Id: 13577297 X-Patchwork-Delegate: snitzer@redhat.com 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 CE6D3151CF4 for ; Thu, 29 Feb 2024 15:50:04 +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=1709221806; cv=none; b=SED8AJy5Maq+CyazBVxrnwX8dz3vdpmamOiD9NmfAHrBuIKKoZ46PIBb1La75L5opqFBUPncky271nWBZOWkrvXfHZQ7iEYI1ZDY4iLBlWuDAMHBkVSm7QNwwnq7bfseBhAVj691sUawlLfvWVBq2LK2wRBTVwMNE37NDLV4qWU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709221806; c=relaxed/simple; bh=OWBoe6+fAMVojgfAunr4vaW3PFA8dgvLQ6SANTycfXw=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=fepw/8MWmRNreYTya6vVMxyUczKMWINxs99Xv7bx874Fn4jgu5MbjWRksoSlLc/dEtM9pWL4yACY0VITAdpKZc8zyvnehMG6CyZKwiVMbl93rYe8I9/wie5G2BXaVS0//WQRQQQ35/cmCF4C1Dj3DePqSz+EJrJBHeAoFYbLMj8= 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=JdgVKy4I; 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="JdgVKy4I" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1709221803; 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=DNK4gvQ+bHqZYAYDjbVNjLmYadcAzhvUX3KDcuzvuv0=; b=JdgVKy4IrD4SP2O3raNwfRHpAPHYb0Hm1pj7XXiaNj28DUkXIVuw8AnopHFBqwIj3H7KZG TvAtllt36doGIPwB6wVkV3Vq9zfYwHr6v3X2QjkqwsdzqNkqw+Bk4zxfVqzfTXW3fvPGuX +oDlIgDTvAWDxrssxGc1PCNsMWIpaZQ= 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-511-oui4lvW4PXmEwBrv0QoLkA-1; Thu, 29 Feb 2024 10:50:00 -0500 X-MC-Unique: oui4lvW4PXmEwBrv0QoLkA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (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 0C23829AA3BB; Thu, 29 Feb 2024 15:50:00 +0000 (UTC) Received: from localhost.localdomain (unknown [10.72.120.8]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7E094C1D36C; Thu, 29 Feb 2024 15:49:56 +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/6] md: Revert "md: Don't ignore suspended array in md_check_recovery()" Date: Thu, 29 Feb 2024 23:49:38 +0800 Message-Id: <20240229154941.99557-4-xni@redhat.com> In-Reply-To: <20240229154941.99557-1-xni@redhat.com> References: <20240229154941.99557-1-xni@redhat.com> Precedence: bulk X-Mailing-List: dm-devel@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.8 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 6376b1aad4d9..79dfc015c322 100644 --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -9492,6 +9492,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 Thu Feb 29 15:49:39 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Xiao Ni X-Patchwork-Id: 13577298 X-Patchwork-Delegate: snitzer@redhat.com 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 03D0F13C9F4 for ; Thu, 29 Feb 2024 15:50:06 +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=1709221808; cv=none; b=LdUrUUR5OErzwJlHWenqwzFj1NfLg5RA66GkJwhHJtrLHrfFv7mF9ypBjvX77pFI7wmKS0w3Kc4+bUQpWmVq4vxBwB02FAlEPE+3Q/xWhz3w0dPwkq4UQR/a2xEDhCeXKNiXm+hxaZbd4AoJ8bSlc+z0dGrBiPyqB1KBieIlr9c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709221808; c=relaxed/simple; bh=pAvQfBq5JEbKKzt67taGpxkFXHje80f2n/ZZC6yHfq4=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=HJLzP/vMWJR54fQkR7vnLxuaUJkJBl4wL9tFfd02eGk9bJMRNNHBLd+PlitV4sbHTtShpABkDyWK3GcJxRUbE0XVnIUFYrPaoGhe4CVTLWmviHOg46yG+GYRpydy3x8/wFqEdBS3JUp2Olq8g7JE3iIOKIht2t1uM5GagSxwq1A= 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=QuTExpUl; 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="QuTExpUl" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1709221805; 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=ZlVfP7NvFLEr+ZESpyoIezolwSzXWil2f/AjEcRQ9TE=; b=QuTExpUlcLlWVaW3vhIvaN6eJYFZSdVEdkD1gYyA8H4iQi7AyJciMHZqmUiamPGdh78PR7 FnMhOOXME9kRa6Wk3agsbl7x7ZV09odqO478LDbkGFiynxBXQP0KV9BkSD+UTzm/Z1HC8e PNcpFbsv1yAh5T2XyzegONQePER307o= 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-115-wHv-TnnmMFaWWhymVuHBtw-1; Thu, 29 Feb 2024 10:50:04 -0500 X-MC-Unique: wHv-TnnmMFaWWhymVuHBtw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (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 3CE532812FF0; Thu, 29 Feb 2024 15:50:04 +0000 (UTC) Received: from localhost.localdomain (unknown [10.72.120.8]) by smtp.corp.redhat.com (Postfix) with ESMTP id BB497C185C0; Thu, 29 Feb 2024 15:50:00 +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/6] dm-raid/md: Clear MD_RECOVERY_WAIT when stopping dmraid Date: Thu, 29 Feb 2024 23:49:39 +0800 Message-Id: <20240229154941.99557-5-xni@redhat.com> In-Reply-To: <20240229154941.99557-1-xni@redhat.com> References: <20240229154941.99557-1-xni@redhat.com> Precedence: bulk X-Mailing-List: dm-devel@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.8 MD_RECOVERY_WAIT is used by dmraid to delay reshape process by patch commit 644e2537fdc7 ("dm raid: fix stripe adding reshape deadlock"). Before patch commit f52f5c71f3d4b ("md: fix stopping sync thread") dmraid stopped sync thread directy by calling md_reap_sync_thread. After this patch dmraid stops sync thread asynchronously as md does. This is right. Now the dmraid stop process is like this: 1. raid_postsuspend->md_stop_writes->__md_stop_writes->stop_sync_thread. stop_sync_thread sets MD_RECOVERY_INTR and wait until MD_RECOVERY_RUNNING is cleared 2. md_do_sync finds MD_RECOVERY_WAIT is set and return. (This is the root cause for this deadlock. We hope md_do_sync can set MD_RECOVERY_DONE) 3. md thread calls md_check_recovery (This is the place to reap sync thread. Because MD_RECOVERY_DONE is not set. md thread can't reap sync thread) 4. raid_dtr stops/free struct mddev and release dmraid related resources dmraid only sets MD_RECOVERY_WAIT but doesn't clear it. It needs to clear this bit when stopping the dmraid before stopping sync thread. But the deadlock still can happen sometimes even MD_RECOVERY_WAIT is cleared before stopping sync thread. It's the reason stop_sync_thread only wakes up task. If the task isn't running, it still needs to wake up sync thread too. This deadlock can be reproduced 100% by these commands: modprobe brd rd_size=34816 rd_nr=5 while [ 1 ]; do vgcreate test_vg /dev/ram* lvcreate --type raid5 -L 16M -n test_lv test_vg lvconvert -y --stripes 4 /dev/test_vg/test_lv vgremove test_vg -ff sleep 1 done Fixes: 644e2537fdc7 ("dm raid: fix stripe adding reshape deadlock") Fixes: f52f5c71f3d4 ("md: fix stopping sync thread") Signed-off-by: Xiao Ni --- drivers/md/dm-raid.c | 2 ++ drivers/md/md.c | 1 + 2 files changed, 3 insertions(+) diff --git a/drivers/md/dm-raid.c b/drivers/md/dm-raid.c index eb009d6bb03a..325767c1140f 100644 --- a/drivers/md/dm-raid.c +++ b/drivers/md/dm-raid.c @@ -3796,6 +3796,8 @@ static void raid_postsuspend(struct dm_target *ti) struct raid_set *rs = ti->private; if (!test_and_set_bit(RT_FLAG_RS_SUSPENDED, &rs->runtime_flags)) { + if (test_bit(MD_RECOVERY_WAIT, &rs->md.recovery)) + clear_bit(MD_RECOVERY_WAIT, &rs->md.recovery); /* Writes have to be stopped before suspending to avoid deadlocks. */ if (!test_bit(MD_RECOVERY_FROZEN, &rs->md.recovery)) md_stop_writes(&rs->md); diff --git a/drivers/md/md.c b/drivers/md/md.c index 79dfc015c322..f264749be28b 100644 --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -4908,6 +4908,7 @@ static void stop_sync_thread(struct mddev *mddev, bool locked, bool check_seq) * never happen */ md_wakeup_thread_directly(mddev->sync_thread); + md_wakeup_thread(mddev->sync_thread); if (work_pending(&mddev->sync_work)) flush_work(&mddev->sync_work); From patchwork Thu Feb 29 15:49:40 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Xiao Ni X-Patchwork-Id: 13577299 X-Patchwork-Delegate: snitzer@redhat.com 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 44BD8141279 for ; Thu, 29 Feb 2024 15:50:13 +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=1709221815; cv=none; b=Pw8mYvSoXQh5waQwV5KTWF9/zrEO/snhUDvyDD1r+s30X1+WLM9u5HhzP8L5mgPcrpDDwlKl4SwquZMLorO+6slG68j0EGPWXfYDPgl8HmZM+XGAzzeK/U2Jt/q4HQgQ/scCBYCuXK65TXt20rH4APfCAlVfiF0oEJRqF6jRdDQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709221815; c=relaxed/simple; bh=0rnQyoyTlg3NbFP2xDGLMqFSdLbaPSQzUA+5qj2XTgA=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=sxvNhlxtrkbVxwMQWLBgxbHRAiOlnDnuongAu1SehKin3Oirf1uoLYc3ad2HXX7iedMknRYEIp1NV4YlQJ5tPmD8hVY3N3OVUtyX2z/RdGE8GV5KIA+oyq4feD9QWBbGdFnfNFnE+xksToRelx6+50qcqxGKD1fEKFC5L/NrhkQ= 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=PgZbfTRs; 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="PgZbfTRs" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1709221812; 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=Dt9GfymT1kyhV1QstwRrdfFuwoG4I2AsFDk18HlPQIc=; b=PgZbfTRssmlKEEbf817xKluA5H+InArQGElvpo4YNdm0JULvGxoxwjDdQppBbXT6/9HzhU n5JW3KZKQz4WJ4SKt5HlyiIfodGFgJFj89V7rxPdcUb2NDJc7l5/xIpA20mjSLQbcSj6Ot adzq0dacs959jIyyYMqQXYF4DkzhJ3g= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-561-QaiRIttkPSOf714xg3SBMQ-1; Thu, 29 Feb 2024 10:50:08 -0500 X-MC-Unique: QaiRIttkPSOf714xg3SBMQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (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 69AF088D28B; Thu, 29 Feb 2024 15:50:08 +0000 (UTC) Received: from localhost.localdomain (unknown [10.72.120.8]) by smtp.corp.redhat.com (Postfix) with ESMTP id E0FBDC185C4; Thu, 29 Feb 2024 15:50:04 +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 5/6] md: Set MD_RECOVERY_FROZEN before stop sync thread Date: Thu, 29 Feb 2024 23:49:40 +0800 Message-Id: <20240229154941.99557-6-xni@redhat.com> In-Reply-To: <20240229154941.99557-1-xni@redhat.com> References: <20240229154941.99557-1-xni@redhat.com> Precedence: bulk X-Mailing-List: dm-devel@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.8 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 f264749be28b..cf15ccf0e27b 100644 --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -6341,6 +6341,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 Thu Feb 29 15:49:41 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Xiao Ni X-Patchwork-Id: 13577300 X-Patchwork-Delegate: snitzer@redhat.com 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 574DE142918 for ; Thu, 29 Feb 2024 15:50:16 +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=1709221818; cv=none; b=G0E/T1GuX22uY/TC2LijwQI/VxZLElZpN4jfgscbbLdLsDDAPPaiSvnI1mfZu2gdiHFRM6DgQl6GhU5IeGzIzMiREktPvJP3i5JiWL+WQ0/1L03TUtQH4hEU5tHQ5LEWaPjcFNQnAMhKyB2bGfAeFUPxcXU1AVBQDwKU+ztQVfU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709221818; c=relaxed/simple; bh=LTEfMG/Orgek9/+KffFIHJIsvwmTWlrcesY7nf5S5BA=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=MB7KFbOhGw8zbN0M6AqjdHYm4p072m1IYZ9uTliMvGIq6mLovyGA0OD0cJPhNT+OWT/pnQwOba0S0V6icx+Z+OaNrHpOutAHN9H3pLmblzgciYW8xH16HH3uBChn1/T/t5d/Exjqd7cHsVH8ZcJZd2CCYHET7g89yQCHzwklKcE= 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=GcBJHrpW; 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="GcBJHrpW" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1709221815; 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=bJTPXuN6gXL91A4tWiu0yacncmf8eEQurT0X3u/rYoI=; b=GcBJHrpWRGCse41FwlAUGIITHwMYr7/SoBxmC3CYIyRUajJ258NZZ8GUgJBlvFesp9yb2R 75E2qrdf8onG4lwizgxkrpcHBZ2NOyxKoEsPzWcCM7Nsr0+ae0RiAbsynPCftSMWtxeqmM UkOyMjBAxkP8641Oh9F/d/LemGifsz8= 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-324-MmeF2vMhNeWvQ-uoaQ7iJQ-1; Thu, 29 Feb 2024 10:50:13 -0500 X-MC-Unique: MmeF2vMhNeWvQ-uoaQ7iJQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (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 AB66029AA3BB; Thu, 29 Feb 2024 15:50:12 +0000 (UTC) Received: from localhost.localdomain (unknown [10.72.120.8]) by smtp.corp.redhat.com (Postfix) with ESMTP id 17EE4C185C0; Thu, 29 Feb 2024 15:50:08 +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 6/6] md/raid5: Don't check crossing reshape when reshape hasn't started Date: Thu, 29 Feb 2024 23:49:41 +0800 Message-Id: <20240229154941.99557-7-xni@redhat.com> In-Reply-To: <20240229154941.99557-1-xni@redhat.com> References: <20240229154941.99557-1-xni@redhat.com> Precedence: bulk X-Mailing-List: dm-devel@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.8 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 8497880135ee..965991a3104f 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