From patchwork Mon Nov 20 11:13:45 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Zhihao Cheng X-Patchwork-Id: 166930 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:9910:0:b0:403:3b70:6f57 with SMTP id i16csp1956156vqn; Sun, 19 Nov 2023 19:20:33 -0800 (PST) X-Google-Smtp-Source: AGHT+IEZvXdwkERQIpLTGRZ9ULhrIfcdb5SG7y0L8bwTfGQaiNXZ1rLL8jObkzuA3rTeZpIOZxua X-Received: by 2002:a05:6a20:2446:b0:187:b7eb:944d with SMTP id t6-20020a056a20244600b00187b7eb944dmr8395742pzc.13.1700450433500; Sun, 19 Nov 2023 19:20:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1700450433; cv=none; d=google.com; s=arc-20160816; b=dq2Nyy5MSPF0bqFf0kkV2RBIWh1r42ZTJtW5l/D4b7t9LrGYQ8b4Vn5oS6yhIV4PXd YMRImF7qjKj2X75Crb2IFpBDzB0ddOYC/pIR0vHAsQBipAVmSEFJ50mjJb2sOywQVNbu 2Eoib6uU83Q8cGNPMkG03ufmWl5extH56iYHhzT7Cr7Lpc+AvM909cOZNW3Dfc9uof6G QTlHq7mZ3Q0zpTLUf3VAKoJ3iCzUSSfCLJNMz5nwS9sbeDAGoYm5JujNKKa/RCtFEBdJ 4b+Yfwnol86t1EpTW6x7eYR7PB2FPot0qgdScriLy0+9gKfWMWnHYTfg80CildvVpQbW sGuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=K0pTdeW9kn3t8ne+2EO0W06wp4y5vYhyjWGUYlA3Ldo=; fh=8iuAhxKZ4zRmu4yJ8kyLM0sJOjlCiDjhtzZdjPnU8ps=; b=0HqloszpmgiFhTyfGpUvqQrWIVghD4TyaxcVOsanNcn1qEMZZWxEjEithX/AY3gYsT Pfbm5zYE3rHBDVzOUw1xFotHi09h6iOR6PKe1iP6Bk0t2GrvvEdQbiU5iKhkSNptBmYe orIRJ2J7aHO56ZZUfqjusy/VOE5GRptwo/525AF37x+LGYccenBoaV6bUwwgpRpFM/Vv FHg+u0UbUoTu9Zcw9N90jsNzujtgwJpO6fS+Qt5ZE/kowjmOyFGTNQjqQ1XIo8jrUBHy IwJWxH8ZSy97trULnos857NuQR/de1pzUKew7OYO5Li9CyI944hnRgR9v9XaRkEzhfVd 1SFw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from fry.vger.email (fry.vger.email. [2620:137:e000::3:8]) by mx.google.com with ESMTPS id y188-20020a6364c5000000b005c203ad2343si6728699pgb.94.2023.11.19.19.20.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Nov 2023 19:20:33 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id 700AC809AFD7; Sun, 19 Nov 2023 19:20:25 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231882AbjKTDT5 (ORCPT + 28 others); Sun, 19 Nov 2023 22:19:57 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54718 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231814AbjKTDTy (ORCPT ); Sun, 19 Nov 2023 22:19:54 -0500 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BDBECD3 for ; Sun, 19 Nov 2023 19:19:49 -0800 (PST) Received: from kwepemm000013.china.huawei.com (unknown [172.30.72.55]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4SYXmQ11N8zWhYP; Mon, 20 Nov 2023 11:19:18 +0800 (CST) Received: from huawei.com (10.175.104.67) by kwepemm000013.china.huawei.com (7.193.23.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 20 Nov 2023 11:19:47 +0800 From: Zhihao Cheng To: , , , , CC: , Subject: [PATCH 1/3] ubifs: Check @c->dirty_[n|p]n_cnt and @c->nroot state under @c->lp_mutex Date: Mon, 20 Nov 2023 19:13:45 +0800 Message-ID: <20231120111347.2254153-2-chengzhihao1@huawei.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20231120111347.2254153-1-chengzhihao1@huawei.com> References: <20231120111347.2254153-1-chengzhihao1@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.175.104.67] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To kwepemm000013.china.huawei.com (7.193.23.81) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-0.8 required=5.0 tests=DATE_IN_FUTURE_06_12, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Sun, 19 Nov 2023 19:20:25 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1783051513604523625 X-GMAIL-MSGID: 1783051513604523625 The checking of @c->nroot->flags and @c->dirty_[n|p]n_cnt in function nothing_to_commit() is not atomic, which could be raced with modifying of lpt, for example: P1 P2 P3 run_gc ubifs_garbage_collect do_commit ubifs_return_leb ubifs_lpt_lookup_dirty dirty_cow_nnode do_commit nothing_to_commit if (test_bit(DIRTY_CNODE, &c->nroot->flags) // false test_and_set_bit(DIRTY_CNODE, &nnode->flags) c->dirty_nn_cnt += 1 ubifs_assert(c, c->dirty_nn_cnt == 0) // false ! Fetch a reproducer in Link: UBIFS error (ubi0:0 pid 2747): ubifs_assert_failed UBIFS assert failed: c->dirty_pn_cnt == 0, in fs/ubifs/commit.c Call Trace: ubifs_ro_mode+0x58/0x70 [ubifs] ubifs_assert_failed+0x6a/0x90 [ubifs] do_commit+0x5b7/0x930 [ubifs] ubifs_run_commit+0xc6/0x1a0 [ubifs] ubifs_sync_fs+0xd8/0x110 [ubifs] sync_filesystem+0xb4/0x120 do_syscall_64+0x6f/0x140 Fix it by checking @c->dirty_[n|p]n_cnt and @c->nroot state with @c->lp_mutex locked. Fixes: 944fdef52ca9 ("UBIFS: do not start the commit if there is nothing to commit") Link: https://bugzilla.kernel.org/show_bug.cgi?id=218162 Signed-off-by: Zhihao Cheng --- fs/ubifs/commit.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/fs/ubifs/commit.c b/fs/ubifs/commit.c index c4fc1047fc07..5b3a840098b0 100644 --- a/fs/ubifs/commit.c +++ b/fs/ubifs/commit.c @@ -69,6 +69,14 @@ static int nothing_to_commit(struct ubifs_info *c) if (c->zroot.znode && ubifs_zn_dirty(c->zroot.znode)) return 0; + /* + * Increasing @c->dirty_pn_cnt/@c->dirty_nn_cnt and marking + * nnodes/pnodes as dirty in run_gc() could race with following + * checking, which leads inconsistent states between @c->nroot + * and @c->dirty_pn_cnt/@c->dirty_nn_cnt, holding @c->lp_mutex + * to avoid that. + */ + mutex_lock(&c->lp_mutex); /* * Even though the TNC is clean, the LPT tree may have dirty nodes. For * example, this may happen if the budgeting subsystem invoked GC to @@ -76,12 +84,15 @@ static int nothing_to_commit(struct ubifs_info *c) * free space. In this case GC would just change the lprops of this * LEB (by turning all space into free space) and unmap it. */ - if (c->nroot && test_bit(DIRTY_CNODE, &c->nroot->flags)) + if (c->nroot && test_bit(DIRTY_CNODE, &c->nroot->flags)) { + mutex_unlock(&c->lp_mutex); return 0; + } ubifs_assert(c, atomic_long_read(&c->dirty_zn_cnt) == 0); ubifs_assert(c, c->dirty_pn_cnt == 0); ubifs_assert(c, c->dirty_nn_cnt == 0); + mutex_unlock(&c->lp_mutex); return 1; }