Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp376779pxk; Thu, 24 Sep 2020 07:46:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwpdEJuYw9NQSwfPZgjM5ZHB6quweih6Y+zdzZS0dRdXQqtVvCMJfm/WJcgLAe91gJN/m9T X-Received: by 2002:a17:906:1c03:: with SMTP id k3mr225164ejg.259.1600958761820; Thu, 24 Sep 2020 07:46:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600958761; cv=none; d=google.com; s=arc-20160816; b=Onbx9f4YYBhedaPL0xSiEdV0SyHxlzWemHGunORyrz+icfzkdfaeO+OUiVhoNtMZf2 KVlQYR44G4Mm6ewgstJ2+35OxXZifhqBWSsP1d+PfG1GvgTIRn13F43jQV3/D+RbOQYD tjWoGSTmr4AcygHiMrozxjO5Gv0/Kas6R2R5ok9aYLt2EDc+WhrRW1pF0u+/m817ycaD fW8THJL9xtrKq5qmsieCUUGhCaTv2+62SWss3hj13X5JFE2LnXz80pDVYo2uZBdL3WwI 65wIxdKK2D1jETKFoXe/hzJ94qZ3eFtaVw7R1agqisXq9EXfPnSmGCE3KhyH6A5G/a4M fM0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=4GlEtj2yzdEWLcfvaBSuV8DaGwNGoG5bUES0qVh+dsw=; b=zl+maHdJxxBKbGkI0soXCuMB52J+0lvhfsdrmyzswFAuBNyru+NZk4EZebx96uAM3x Y/78MiRz/gLAOPHMZ8sHMbdO1zJx4ViePnPhcSve5YJnBzrR6yLU94hU1uMpybsI1RX+ UozAgOnffyKPcRWso9epCNHflLEBP9gOjzyw/zlYEzQEeWbGP6Yx7s4Wkn/PPSlJBEsy tC/z5DisotSw2AYQvnKDmHb68kSj/fZdh7AHSwl53V/COzQdPw816PyCr3fUuS6DbaX5 +cQEVl+K+5oofaAJ02xHnNKBoZYBazvwMkYYJe3kmyVb6YWoVvT4RocAEaq1cfFwgtwU tirw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i12si2147289ejk.740.2020.09.24.07.45.33; Thu, 24 Sep 2020 07:46:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728192AbgIXOmk (ORCPT + 99 others); Thu, 24 Sep 2020 10:42:40 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:46646 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727889AbgIXOmk (ORCPT ); Thu, 24 Sep 2020 10:42:40 -0400 Received: from DGGEMS401-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 8F4506427D0E2EF3E382; Thu, 24 Sep 2020 22:42:37 +0800 (CST) Received: from [10.174.179.224] (10.174.179.224) by DGGEMS401-HUB.china.huawei.com (10.3.19.201) with Microsoft SMTP Server id 14.3.487.0; Thu, 24 Sep 2020 22:42:30 +0800 Subject: Re: [PATCH] ext4: Fix bdev write error check failed when mount fs with ro To: Jan Kara CC: , , , References: <20200924011149.1624846-1-zhangxiaoxu5@huawei.com> <20200924080613.GC27019@quack2.suse.cz> From: "zhangxiaoxu (A)" Message-ID: Date: Thu, 24 Sep 2020 22:42:30 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.2.1 MIME-Version: 1.0 In-Reply-To: <20200924080613.GC27019@quack2.suse.cz> Content-Type: text/plain; charset="gbk"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.179.224] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org ?? 2020/9/24 16:06, Jan Kara ะด??: > On Wed 23-09-20 21:11:49, Zhang Xiaoxu wrote: >> If some errors has occurred on the device, and the orphan list not empty, >> then mount the device with 'ro', the bdev write error check will failed: >> ext4_check_bdev_write_error:193: comm mount: Error while async write back metadata >> >> Since the sbi->s_bdev_wb_err wouldn't be initialized when mount file system >> with 'ro', when clean up the orphan list and access the iloc buffer, bdev >> write error check will failed. >> >> So we should always initialize the sbi->s_bdev_wb_err even if mount the >> file system with 'ro'. >> >> Fixes: bc71726c7257 ("ext4: abort the filesystem if failed to async write metadata buffer") >> Signed-off-by: Zhang Xiaoxu > > Thanks for the patch! Good catch! I just think you should now remove the > errseq_check_and_advance() call in ext4_remount() because it isn't needed > anymore. Thanks for your suggesstion. I will send the v2 to remove the errseq_check_and_advance in ext4_remount. Xiaoxu. > > >> diff --git a/fs/ext4/super.c b/fs/ext4/super.c >> index ea425b49b345..086439889869 100644 >> --- a/fs/ext4/super.c >> +++ b/fs/ext4/super.c >> @@ -4814,9 +4814,8 @@ static int ext4_fill_super(struct super_block *sb, void *data, int silent) >> * used to detect the metadata async write error. >> */ >> spin_lock_init(&sbi->s_bdev_wb_lock); >> - if (!sb_rdonly(sb)) >> - errseq_check_and_advance(&sb->s_bdev->bd_inode->i_mapping->wb_err, >> - &sbi->s_bdev_wb_err); >> + errseq_check_and_advance(&sb->s_bdev->bd_inode->i_mapping->wb_err, >> + &sbi->s_bdev_wb_err); >> sb->s_bdev->bd_super = sb; >> EXT4_SB(sb)->s_mount_state |= EXT4_ORPHAN_FS; >> ext4_orphan_cleanup(sb, es); >> -- >> 2.25.4 >>