Received: by 2002:a05:7412:d1aa:b0:fc:a2b0:25d7 with SMTP id ba42csp830710rdb; Mon, 29 Jan 2024 22:37:37 -0800 (PST) X-Google-Smtp-Source: AGHT+IEF+/0pcN39ckpAahgwBAeZK1ifE2xFk3LGG6soZDnP2wdysncobWJhupWy0uEmH7Voqbrh X-Received: by 2002:a05:6102:128c:b0:46b:2335:88af with SMTP id jc12-20020a056102128c00b0046b233588afmr3673257vsb.41.1706596657243; Mon, 29 Jan 2024 22:37:37 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706596657; cv=pass; d=google.com; s=arc-20160816; b=sMHWKK8z5ERujXOKuj2FjRbHQevmD3S9s/DAvGjPhMgXbUxyXWuGkp0Zt5A04Sy+cN +71eA5s+DKXsiFyZBWYE4249/b79RZN0UPO5a7dtwLLsn3/UT/Rak8dZ1Vu4AMLt/OGQ l3RRKtIRJULg89invMlnPEGQCVDAYbspfdB87qmjoujGbD7l8d4yN24sxv13umkT1Xtv HxVXi5rgRvEZGQPMoxvhr0lDIWEIAu0aRnW9YHvOZfnN4tizTa6+MsWT+1oYO6v7z2oX He+zHfMnUeYY+KSz+pgD+AOMvP6B+Xsi/xQRXWvWWwE2Yw55f7oPMl/49IXzlSGCSy9+ CYEw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:list-unsubscribe:list-subscribe :list-id:precedence:dkim-signature; bh=BsYqvwl+WGhOaCxlM7Pqlb5nLah5CGyVbriRP5uBJOw=; fh=ytuQZdtv5IDLUSbkzIKjZmhDUN/utkCXCzJwGGNy1QY=; b=nqRR2srkuWVwU1HxMhDYLd1zLkk6o0YH7Ucow+qraQgXBuz3iJirrgNYeJ9YJ7Z1xm sWkbdJgchT7Tkjwmz9DRiPoKBYjmK8pDaYTLi2ECXelXmg0VpYd0Je4zUVrG1EJ7bZXT IYjib5rQRkoi7naEtm1pYK/mMHwLDWLQJ+JGkqn4j5N0lKIIy+vGNgSBHbgS/qp5xjce mQj6N95ZrEkWu9dHwsJPzkakwJgeIWvjRagbwXi+YRsjf23qU+xtmre9hTtfWtGk1gTs WSOe9Ugu8QzlGOaMV8dBxw6vtlvdgoITU8T4OoTp9ViB71TxGJtKNG0jiqtGxQgYu7Pb AfWA== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=INM8781O; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-43999-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-43999-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [2604:1380:40f1:3f00::1]) by mx.google.com with ESMTPS id b16-20020a656690000000b005cf02b42b29si6850196pgw.116.2024.01.29.22.37.36 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jan 2024 22:37:37 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-43999-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=INM8781O; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-43999-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-43999-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=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 sy.mirrors.kernel.org (Postfix) with ESMTPS id 1FBB6B22547 for ; Tue, 30 Jan 2024 06:37:35 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 7A97C3F9E3; Tue, 30 Jan 2024 06:37:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="INM8781O" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 9F8B539FC1; Tue, 30 Jan 2024 06:37:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706596635; cv=none; b=Ir9RGd+319rebbwkoq3QT0QmOaJecIgokIGPwldQrPbBL6MmGuSIRSTZwQqxgmT+BMzuEwLsj6+BwotXGkxxDQkT9DfjZkr/u5GbiUtH6qpwODJdOh77aQfv5EaHkI+B8xqZIr9KjDIa2p1Er2WQFu9eHtH2JI6K0TdmU2AbfWI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706596635; c=relaxed/simple; bh=ocd7CtyJUXOYKX8nrVVCi4rWZbk47Swv1h3/8sjcQWE=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=NnqmsPat8YfwL9llB4jYNdU3DLnG2tIxf+L7RCkJQzv1EiGQNI/eNVxLNQPoJkg66tZGdx0Vi8LmtiUMkAt5H1c1Ald3fvIE6yEStNRoqxCSHjR98DDTeiPyKkyVNTy/DvL1E2/TmgDITDYAVlUPebPCHstkridyAc5TQh8FNUk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=INM8781O; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 742B2C43390; Tue, 30 Jan 2024 06:37:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1706596635; bh=ocd7CtyJUXOYKX8nrVVCi4rWZbk47Swv1h3/8sjcQWE=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=INM8781OMSNPsB1j6nBqzZNn6KnUY8X8fVHLAXqjAuich3nvI2Et9oIypWnMcfIJB Q8t8MHPvFqGfo78UPnYkTVA2xITj9C30Q3M0+qe/YJAVnoweXAbsb7o5lGF2Fz/3zB BRyHefHvCeOgg1I1PDiKjrvWGj+l50QzBr/WgygEuf778ujcpjx3++4elxsdMAID/M V0a6jgzGsXqwl2FkytcCq7/v2AizXmVGD9uFSQXU+y6v7Qdo9SxYSMiL3XdR17fQRk wpoiTikH7tfNVtcvipdR/jZSPK0tRltd3A9u0fBaSabom7d99RxHLBI7n1MxkEGrQ+ zxWdx1LqXBzsw== Received: by mail-lf1-f48.google.com with SMTP id 2adb3069b0e04-5101f2dfdadso6200892e87.2; Mon, 29 Jan 2024 22:37:15 -0800 (PST) X-Gm-Message-State: AOJu0Yw7JZSFkb9gv1ivRblsZKKdMgwQQB8cokfMcgvSlMA6ed+SR1AQ nMnYg5KDlLt0NIomI5KrJ1ydFIS4csMKOr4UOcoJrBikjotXmBVFHntKt9ZrTT4RljFTSdk0UZa or+YQZmbvO04mUkQGeVQIuLQXOHs= X-Received: by 2002:ac2:4c34:0:b0:511:19b0:3f23 with SMTP id u20-20020ac24c34000000b0051119b03f23mr636305lfq.44.1706596633609; Mon, 29 Jan 2024 22:37:13 -0800 (PST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20231228125553.2697765-1-yukuai1@huaweicloud.com> <20231228125553.2697765-4-yukuai1@huaweicloud.com> In-Reply-To: <20231228125553.2697765-4-yukuai1@huaweicloud.com> From: Song Liu Date: Mon, 29 Jan 2024 22:37:01 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH -next 3/3] md: use interruptible apis in idle/frozen_sync_thread() To: Yu Kuai Cc: yukuai3@huawei.com, neilb@suse.de, linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org, yi.zhang@huawei.com, yangerkun@huawei.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Sorry for the late reply. The first two patches of the set look good, so I applied them to md-tmp-6.9 branch. However, this one needs a respin. On Thu, Dec 28, 2023 at 4:58=E2=80=AFAM Yu Kuai w= rote: > > From: Yu Kuai > > Before refactoring idle and frozen from action_store, interruptible apis > is used so that hungtask warning won't be triggered if it takes too long > to finish idle/frozen sync_thread. So change to use interruptible apis. This paragraph is confusing. Please rephrase it. > > In order not to make stop_sync_thread() more complicated, factor out a > helper prepare_to_stop_sync_thread() to replace stop_sync_thread(). > > Also return error to user if idle/frozen_sync_thread() failed, otherwise > user will be misleaded. s/misleaded/misled/ > > Fixes: 130443d60b1b ("md: refactor idle/frozen_sync_thread() to fix deadl= ock") > Fixes: 8e8e2518fcec ("md: Close race when setting 'action' to 'idle'.") Please add more information about what is being fixed here, so that we can make a clear decision on whether the fix needs to be back ported to stable kernels. > Signed-off-by: Yu Kuai > --- > drivers/md/md.c | 105 ++++++++++++++++++++++++++++++------------------ > 1 file changed, 67 insertions(+), 38 deletions(-) > > diff --git a/drivers/md/md.c b/drivers/md/md.c > index 60f99768a1a9..9ea05de79fe4 100644 > --- a/drivers/md/md.c > +++ b/drivers/md/md.c > @@ -4846,26 +4846,34 @@ action_show(struct mddev *mddev, char *page) > return sprintf(page, "%s\n", type); > } > > +static bool sync_thread_stopped(struct mddev *mddev, int *sync_seq) I think we need a comment for this. > +{ > + if (!test_bit(MD_RECOVERY_RUNNING, &mddev->recovery)) > + return true; > + > + if (sync_seq && *sync_seq !=3D atomic_read(&mddev->sync_seq)) > + return true; > + > + return false; > +} > + > /** > - * stop_sync_thread() - wait for sync_thread to stop if it's running. > + * prepare_to_stop_sync_thread() - prepare to stop sync_thread if it's r= unning. > * @mddev: the array. > - * @locked: if set, reconfig_mutex will still be held after this func= tion > - * return; if not set, reconfig_mutex will be released after= this > - * function return. > - * @check_seq: if set, only wait for curent running sync_thread to stop,= noted > - * that new sync_thread can still start. > + * @unlock: whether or not caller want to release reconfig_mutex if > + * sync_thread is not running. > + * > + * Return true if sync_thread is running, release reconfig_mutex and do > + * preparatory work to stop sync_thread, caller should wait for > + * sync_thread_stopped() to return true. Return false if sync_thread is = not > + * running, reconfig_mutex will be released if @unlock is set. > */ I found prepare_to_stop_sync_thread very hard to reason. Please try to rephrase the comment or refactor the code. Maybe it makes sense to put the following logic and its variations to a separate function: if (prepare_to_stop_sync_thread(mddev, false)) { wait_event(resync_wait, sync_thread_stopped(mddev, NULL)); mddev_lock_nointr(mddev); } Thanks, Song > -static void stop_sync_thread(struct mddev *mddev, bool locked, bool chec= k_seq) > +static bool prepare_to_stop_sync_thread(struct mddev *mddev, bool unlock= ) > { > - int sync_seq; [...]