Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp1895524rwd; Fri, 2 Jun 2023 01:31:30 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5ipeASmv4p7/lGmp5GLIEcdr1Qkhw7xjojaVZAdEt/yD/EaDLE61W1qSAq6RMYIXDC0rUO X-Received: by 2002:a05:6a21:6d96:b0:10b:7b64:706 with SMTP id wl22-20020a056a216d9600b0010b7b640706mr14758540pzb.13.1685694689960; Fri, 02 Jun 2023 01:31:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685694689; cv=none; d=google.com; s=arc-20160816; b=utB2Jg2wWTaCVJaWEwgBSZ401xkqn/sdkXnHGtXLBvnpbpNKIpedNoWCRza2pwoOPI +hk3qCMuwIWXxm9nWXUWedlQW/Epj4XH5bYtpZ+nBd2EFNbFSsG5WFwUhRoSQrpmSxES haqiD+iQcFyiYvd0ZmDxEyYrRlYQF72tH8AzGg6EdWqsj8D8x9SecuZTUuIoBhsVFQPu /iOHuKEDCzAOaVTgr5ksabyb7PmO6/FKcYk7VhaogHCYZ9ST3ELVX3h8FSnlBc2+aPmg 7xsY1PRmxXKzGezathBmMmhpaby9ullswrSVhnedtvI3MMUKhSIE0v2TTGViKvFyurwJ lAqA== 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 :message-id:date:subject:cc:to:from; bh=BR8X9cS02g86kYLjMC4BmQuVkbZhn9Ni65VSg515IEE=; b=BbR/Her6zLJuzeJ9UjfxSDuDCZZRQeAmpTrNKz70Ezsph+JA2qnJSpGMbchoFh00o8 Xco2ehOdqpMdA7sFuUVdtbWogXObF9J1GfY7KNPznu2QTZ6Q3yx9FQYEyDDUClni+e+n C0jdEsH1lUBJkYtL6sgXdoi9g0G+xUrUgcbaX8GXcXstr7LC/x0braXsmbD67pT8fMpG c2rs9149I1cAuvEOTZ7ePPZiYrm4owHNWFRB40+dpMMFxwsREA7xlxZb1DahSzI3iKup oYkEa9nDS8CiVO42G45yc212BDpBMRDJwrzFnQw2oOCflV1vNfNnZeOa5b63gy2wLgXQ PfYQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l21-20020a637015000000b0053fb768afc8si629852pgc.748.2023.06.02.01.31.09; Fri, 02 Jun 2023 01:31:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234468AbjFBIat (ORCPT + 99 others); Fri, 2 Jun 2023 04:30:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37504 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233991AbjFBIaZ (ORCPT ); Fri, 2 Jun 2023 04:30:25 -0400 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 848801A7 for ; Fri, 2 Jun 2023 01:30:02 -0700 (PDT) Received: from dggpeml500016.china.huawei.com (unknown [172.30.72.55]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4QXbhN0Lw2zLncT; Fri, 2 Jun 2023 16:27:00 +0800 (CST) Received: from huawei.com (10.175.127.227) by dggpeml500016.china.huawei.com (7.185.36.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Fri, 2 Jun 2023 16:29:59 +0800 From: zhanchengbin To: CC: , , , zhanchengbin Subject: [PATCH] e2fsck: restore sb->s_state before journal recover Date: Fri, 2 Jun 2023 16:27:59 +0800 Message-ID: <20230602082759.4062633-1-zhanchengbin1@huawei.com> X-Mailer: git-send-email 2.31.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.175.127.227] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To dggpeml500016.china.huawei.com (7.185.36.70) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org ext4_handle_error EXT4_SB(sb)->s_mount_state |= EXT4_ERROR_FS; if remount-ro ext4_commit_super(sb); As you can see, when the filesystem error in the kernel, the last sb commit not record the journal, So sb->s_state will be overwritten by journal recover. In some cases , modifying metadata and superblock data are placed in two transactions, if the previous transaction is already in the journal, and ext4_handle_error occurs when updating sb, the filesystem is still error even if the journal is recovered(I know that this situation should not occur in theory, but I encountered this error when testing quota. Therefore, I think we cannot fully rely on the kernel). So when the filesystem is error before the journal recover, keep the error state and perform deep check later. Signed-off-by: zhanchengbin --- e2fsck/journal.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/e2fsck/journal.c b/e2fsck/journal.c index c7868d89..6f49321d 100644 --- a/e2fsck/journal.c +++ b/e2fsck/journal.c @@ -1683,6 +1683,7 @@ errcode_t e2fsck_run_ext3_journal(e2fsck_t ctx) errcode_t retval, recover_retval; io_stats stats = 0; unsigned long long kbytes_written = 0; + __u16 state = ctx->fs->super->s_state; printf(_("%s: recovering journal\n"), ctx->device_name); if (ctx->options & E2F_OPT_READONLY) { @@ -1722,6 +1723,9 @@ errcode_t e2fsck_run_ext3_journal(e2fsck_t ctx) ctx->fs->flags |= EXT2_FLAG_MASTER_SB_ONLY; ctx->fs->super->s_kbytes_written += kbytes_written; + if (EXT2_ERROR_FS | state) + ctx->fs->super->s_state = state | EXT2_ERROR_FS; + /* Set the superblock flags */ e2fsck_clear_recover(ctx, recover_retval != 0); -- 2.31.1