Message ID | 20240201092559.910982-6-yukuai1@huaweicloud.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-47868-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:2719:b0:106:209c:c626 with SMTP id hl25csp30078dyb; Thu, 1 Feb 2024 01:32:39 -0800 (PST) X-Google-Smtp-Source: AGHT+IEjSaUNKq0u56lIUWo679qIi0yIF27QevH30TIz4HHFrs6Ke6VmOaMCPJn5ogf8rjmWPntT X-Received: by 2002:a17:906:9c88:b0:a36:3152:f55f with SMTP id fj8-20020a1709069c8800b00a363152f55fmr6754967ejc.33.1706779959325; Thu, 01 Feb 2024 01:32:39 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706779959; cv=pass; d=google.com; s=arc-20160816; b=QVNWgKwEEWHImuB2qzngVzvbPYN0Nto0cPCrzb+4HwWUXlXXLlo9wHFYHjFI2I4bDL FJ5z9otgRafkkRxsXBwDlivCaRP72V++epb+3L0D/YLUGwqO8altVXgq3OJHWmsQ1QRX 49ttqJwtWWVfKWQS8CHx5n3Q1QB1ZnBFN1FZF8kZ/JhRM1Dp/PTEe3VvxFNnLTkefRVI 4Mj6dRkrO3TTQ1DknvPgEwS34kpz/ltpAmIQdz9dUr0zcjKLE4wM/ntN+nsWzoJqyINp 2P4NxM4cpcCzg10dm6ylqUBm9LjzK0wffiyl2u5/Mz8mZI0TiMwCTqMReH9QanEi46mX 05RQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from; bh=y959pjDZ7J8BFqaQCMjqyW0JW84A6rEyA3lltCKk3rY=; fh=yxU3U1G5P4WRHGJR2/fbLH54JYb4sc6LVMAk7ls2i5k=; b=dD2hRQSYTvbNyPjupdrP2zPX2NhlCo1YdatAMxgdrSyyr3eOnJPIP/+tOBSN6voTRt JHAlGoJkxg7aRixpzowtIVgHb2XrOHdT9V2L+NKr16EmTztWZbUmvZlXJUuOtzT8IXMn TlPezAuv5L+rPxyGdfydXL/o7P29cjQTl3h+lyo4RHA0zwgBF6AkrH8KtrhfC4TO/OmL Kj0mKmGEei4p9aRNfz139QNhmi305J/RFtDMkYnRF5Q27qJQYtaMzdqCV3l0cXOSXFtb In4diXDx1WQd6If+jkMXj2Q58aU3BLTzTVBq6uD6l+wzZYXQQV3AOMB/g1FijKhUJE1Q 6dOw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=huaweicloud.com); spf=pass (google.com: domain of linux-kernel+bounces-47868-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-47868-ouuuleilei=gmail.com@vger.kernel.org" X-Forwarded-Encrypted: i=1; AJvYcCWCLctzvIWIakXNNavPiiabhBFEhJ8k2f0CrtmW9Z1dUQp0to9+xQvLQMbDNzJ6ovLVQRd7EZRvTJh+lTpONbEF1SE6Dw== Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id w24-20020a1709067c9800b00a349fd53d0bsi6313894ejo.66.2024.02.01.01.32.39 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Feb 2024 01:32:39 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-47868-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=huaweicloud.com); spf=pass (google.com: domain of linux-kernel+bounces-47868-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-47868-ouuuleilei=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id E85AC1F229E4 for <ouuuleilei@gmail.com>; Thu, 1 Feb 2024 09:32:38 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 2821815F31A; Thu, 1 Feb 2024 09:30:36 +0000 (UTC) Received: from dggsgout12.his.huawei.com (unknown [45.249.212.56]) (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 B27A215B975; Thu, 1 Feb 2024 09:30:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.56 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706779833; cv=none; b=HaVF47Yr/yGFfsyddbtBrP+ICCTmu+ZymH4hmgxlPLBf1AjHiJuClyb3OtuyjskWPkex+gUZps/PcrKvmiVNKGEZxSMtd61Cq+HQgb91IM7XStMbWRxIEguydEEhmYZKzWctpTYegx2hGFn8z/2mz3iyn2VDySvqewEteGs0gd8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706779833; c=relaxed/simple; bh=W6rufQZZ+hnLEGX0/LnkFyb5yoGyGO/17y5HhbzHXQ8=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=c5JEHjW3OyqPkLvxLRFnJFCl4I71n/NwsadaZeZjUwqnapD4uN41gQkEe+5Tcj74doe3tXZVnoIzmmizwLWNBZIDXrvGH6icTI1PlbIAHrTSPFyPHesOoWocGsPvoTHDr4oGsAjZ+AhA2Dp1Ap9FFrbkm5/ghQ3GkP8fK1wbXpo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.163.216]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTP id 4TQYXw3LNSz4f3l6h; Thu, 1 Feb 2024 17:30:24 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.112]) by mail.maildlp.com (Postfix) with ESMTP id A6FFF1A0199; Thu, 1 Feb 2024 17:30:28 +0800 (CST) Received: from huaweicloud.com (unknown [10.175.104.67]) by APP1 (Coremail) with SMTP id cCh0CgCXaBGtZLtl8V6KCg--.33515S9; Thu, 01 Feb 2024 17:30:28 +0800 (CST) From: Yu Kuai <yukuai1@huaweicloud.com> To: mpatocka@redhat.com, heinzm@redhat.com, xni@redhat.com, blazej.kucman@linux.intel.com, agk@redhat.com, snitzer@kernel.org, dm-devel@lists.linux.dev, song@kernel.org, yukuai3@huawei.com, jbrassow@f14.redhat.com, neilb@suse.de, shli@fb.com, akpm@osdl.org Cc: linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org, yukuai1@huaweicloud.com, yi.zhang@huawei.com, yangerkun@huawei.com Subject: [PATCH v5 05/14] md: don't suspend the array for interrupted reshape Date: Thu, 1 Feb 2024 17:25:50 +0800 Message-Id: <20240201092559.910982-6-yukuai1@huaweicloud.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240201092559.910982-1-yukuai1@huaweicloud.com> References: <20240201092559.910982-1-yukuai1@huaweicloud.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID: cCh0CgCXaBGtZLtl8V6KCg--.33515S9 X-Coremail-Antispam: 1UD129KBjvJXoW7uF1fuFy3ZFWkArykCr17Jrb_yoW8ur13p3 y3tF1ayrs8X39ava1UG3s2gFyYk3s5trWYy3srJ34UAw13Gr1fGr43Gr4qvFyY9ry3trs0 qr1Yq34rGF1qkaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUP214x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Cr1j6r xdM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl6s0D M2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xIIjx v20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1l F7xvr2IYc2Ij64vIr41lF7I21c0EjII2zVCS5cI20VAGYxC7M4IIrI8v6xkF7I0E8cxan2 IY04v7MxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAF wI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVW8ZVWrXwCIc4 0Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1I6r4UMIIF0xvE2Ix0cI8IcVCY1x0267AK xVW8Jr0_Cr1UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVWUJV W8JwCI42IY6I8E87Iv6xkF7I0E14v26r4UJVWxJrUvcSsGvfC2KfnxnUUI43ZEXa7VUbmZ X7UUUUU== X-CM-SenderInfo: 51xn3trlr6x35dzhxuhorxvhhfrp/ X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1789688502603835195 X-GMAIL-MSGID: 1789688502603835195 |
Series |
[v5,01/14] md: don't ignore suspended array in md_check_recovery()
|
|
Commit Message
Yu Kuai
Feb. 1, 2024, 9:25 a.m. UTC
From: Yu Kuai <yukuai3@huawei.com> md_start_sync() will suspend the array if there are spares that can be added or removed from conf, however, if reshape is still in progress, this won't happen at all or data will be corrupted(remove_and_add_spares won't be called from md_choose_sync_action for reshape), hence there is no need to suspend the array if reshape is not done yet. Meanwhile, there is a potential deadlock for raid456: 1) reshape is interrupted; 2) set one of the disk WantReplacement, and add a new disk to the array, however, recovery won't start until the reshape is finished; 3) then issue an IO across reshpae position, this IO will wait for reshape to make progress; 4) continue to reshape, then md_start_sync() found there is a spare disk that can be added to conf, mddev_suspend() is called; Step 4 and step 3 is waiting for each other, deadlock triggered. Noted this problem is found by code review, and it's not reporduced yet. Fix this porblem by don't suspend the array for interrupted reshape, this is safe because conf won't be changed until reshape is done. Fixes: bc08041b32ab ("md: suspend array in md_start_sync() if array need reconfiguration") Signed-off-by: Yu Kuai <yukuai3@huawei.com> --- drivers/md/md.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-)
Comments
在 2024/2/1 下午5:25, Yu Kuai 写道: > From: Yu Kuai <yukuai3@huawei.com> > > md_start_sync() will suspend the array if there are spares that can be > added or removed from conf, however, if reshape is still in progress, Hi Kuai Why md_start_sync can run when reshape is still in progress? md_check_recovery should return without queue sync_work, right? > this won't happen at all or data will be corrupted(remove_and_add_spares > won't be called from md_choose_sync_action for reshape), hence there is > no need to suspend the array if reshape is not done yet. > > Meanwhile, there is a potential deadlock for raid456: > > 1) reshape is interrupted; > > 2) set one of the disk WantReplacement, and add a new disk to the array, > however, recovery won't start until the reshape is finished; > > 3) then issue an IO across reshpae position, this IO will wait for > reshape to make progress; > > 4) continue to reshape, then md_start_sync() found there is a spare disk > that can be added to conf, mddev_suspend() is called; I c. The answer for my above question is reshape is interrupted and then it continues the reshape, right? Best Regards Xiao > > Step 4 and step 3 is waiting for each other, deadlock triggered. Noted > this problem is found by code review, and it's not reporduced yet. > > Fix this porblem by don't suspend the array for interrupted reshape, > this is safe because conf won't be changed until reshape is done. > > Fixes: bc08041b32ab ("md: suspend array in md_start_sync() if array need reconfiguration") > Signed-off-by: Yu Kuai <yukuai3@huawei.com> > --- > drivers/md/md.c | 13 +++++++++---- > 1 file changed, 9 insertions(+), 4 deletions(-) > > diff --git a/drivers/md/md.c b/drivers/md/md.c > index 6c5d0a372927..85fde05c37dd 100644 > --- a/drivers/md/md.c > +++ b/drivers/md/md.c > @@ -9374,12 +9374,17 @@ static void md_start_sync(struct work_struct *ws) > bool suspend = false; > char *name; > > - if (md_spares_need_change(mddev)) > + /* > + * If reshape is still in progress, spares won't be added or removed > + * from conf until reshape is done. > + */ > + if (mddev->reshape_position == MaxSector && > + md_spares_need_change(mddev)) { > suspend = true; > + mddev_suspend(mddev, false); > + } > > - suspend ? mddev_suspend_and_lock_nointr(mddev) : > - mddev_lock_nointr(mddev); > - > + mddev_lock_nointr(mddev); > if (!md_is_rdwr(mddev)) { > /* > * On a read-only array we can:
Hi, 在 2024/02/29 10:10, Xiao Ni 写道: > > 在 2024/2/1 下午5:25, Yu Kuai 写道: >> From: Yu Kuai <yukuai3@huawei.com> >> >> md_start_sync() will suspend the array if there are spares that can be >> added or removed from conf, however, if reshape is still in progress, > > > Hi Kuai > > Why md_start_sync can run when reshape is still in progress? > md_check_recovery should return without queue sync_work, right? > >> this won't happen at all or data will be corrupted(remove_and_add_spares >> won't be called from md_choose_sync_action for reshape), hence there is >> no need to suspend the array if reshape is not done yet. >> >> Meanwhile, there is a potential deadlock for raid456: >> >> 1) reshape is interrupted; >> >> 2) set one of the disk WantReplacement, and add a new disk to the array, >> however, recovery won't start until the reshape is finished; >> >> 3) then issue an IO across reshpae position, this IO will wait for >> reshape to make progress; >> >> 4) continue to reshape, then md_start_sync() found there is a spare disk >> that can be added to conf, mddev_suspend() is called; > > > I c. The answer for my above question is reshape is interrupted and then > it continues the reshape, right? > Yes, reshape is interrupted and sync_thread is unregister, then sync_thread can be registered again to continue reshape. Thanks, Kuai > > Best Regards > > Xiao > >> >> Step 4 and step 3 is waiting for each other, deadlock triggered. Noted >> this problem is found by code review, and it's not reporduced yet. >> >> Fix this porblem by don't suspend the array for interrupted reshape, >> this is safe because conf won't be changed until reshape is done. >> >> Fixes: bc08041b32ab ("md: suspend array in md_start_sync() if array >> need reconfiguration") >> Signed-off-by: Yu Kuai <yukuai3@huawei.com> >> --- >> drivers/md/md.c | 13 +++++++++---- >> 1 file changed, 9 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/md/md.c b/drivers/md/md.c >> index 6c5d0a372927..85fde05c37dd 100644 >> --- a/drivers/md/md.c >> +++ b/drivers/md/md.c >> @@ -9374,12 +9374,17 @@ static void md_start_sync(struct work_struct *ws) >> bool suspend = false; >> char *name; >> - if (md_spares_need_change(mddev)) >> + /* >> + * If reshape is still in progress, spares won't be added or removed >> + * from conf until reshape is done. >> + */ >> + if (mddev->reshape_position == MaxSector && >> + md_spares_need_change(mddev)) { >> suspend = true; >> + mddev_suspend(mddev, false); >> + } >> - suspend ? mddev_suspend_and_lock_nointr(mddev) : >> - mddev_lock_nointr(mddev); >> - >> + mddev_lock_nointr(mddev); >> if (!md_is_rdwr(mddev)) { >> /* >> * On a read-only array we can: > > . >
diff --git a/drivers/md/md.c b/drivers/md/md.c index 6c5d0a372927..85fde05c37dd 100644 --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -9374,12 +9374,17 @@ static void md_start_sync(struct work_struct *ws) bool suspend = false; char *name; - if (md_spares_need_change(mddev)) + /* + * If reshape is still in progress, spares won't be added or removed + * from conf until reshape is done. + */ + if (mddev->reshape_position == MaxSector && + md_spares_need_change(mddev)) { suspend = true; + mddev_suspend(mddev, false); + } - suspend ? mddev_suspend_and_lock_nointr(mddev) : - mddev_lock_nointr(mddev); - + mddev_lock_nointr(mddev); if (!md_is_rdwr(mddev)) { /* * On a read-only array we can: