Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp3632424pxf; Mon, 29 Mar 2021 07:27:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzWRU9feVjRU5Sf2WjFRdMvaLB3VtIBtfbJby0xeKovzAYJPdRtxlAh6uWzzQCMwvMTLc9k X-Received: by 2002:a17:906:f12:: with SMTP id z18mr28904872eji.132.1617028072703; Mon, 29 Mar 2021 07:27:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617028072; cv=none; d=google.com; s=arc-20160816; b=cL2n9bYBjSXfM3v1YfhlpNTIGjmNxG/Q32MnYbBO3hU47O+lAkedlBPPRrdizWS0Qn R20T91S5S8wGweSWxZOMFuXei2rSoRsrXonu5gj75ylcGAwb+fR/MUk8SvhwyDVc+9s/ k6PQi1xUXa5NCHTCvahbhc3yx4ZJb0rKXJ9HzGvJRrkqQBbQv7GL8FF/AxxU2Om+q0RS LSviDQznE6x8+/tJtmpiCIDZdOBSBGhtW/wznOXg3Qn/hfw0vq6/WkeMeoa6YuuLmK3+ Bgg0VEPKDBG3HTumYs40/bGMqH7IjedUAkPHJ6LqN8xRqVq5uWhBKSadwdDT1g7nVaDU FtNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=f9rk8moDD8+cO50eE4RBFXvTVRQRJhuyNh3tWWAoIzk=; b=qFRxa6WVVuMjpCOh7WEvylyza5NKVUFxnWQQWXiEd/R1k+JtjNX3W72vVY1alL8Ovc jWr4oVCUHzWo1melM/4YhB4Nkq85w03x6YLsk+ne/v1qr9j2Om7Xd4q4rmDHjTClO6xW 03iv4qsYOP68gMitJ3ttJLU9Xga8AR7URd6HMmYzVGif/EMWzOQdbZ91s8KFS/7uJW54 Cf7VCUsqVTCWv6nh5W3IBqwe/nbzskUx0y1gtUEwlquy8DfDNRINJtgznM+KpECRjaiw HdMRrZ2o2Za9633hHA0IFRsGahx2h05QJ/ycEpeLxCrJiG7gh+Di7seGRcbNPOgwkLOr mqEg== 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 n15si12806265edv.534.2021.03.29.07.27.24; Mon, 29 Mar 2021 07:27:52 -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 S230306AbhC2O0w (ORCPT + 99 others); Mon, 29 Mar 2021 10:26:52 -0400 Received: from mx2.suse.de ([195.135.220.15]:55368 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229628AbhC2O0d (ORCPT ); Mon, 29 Mar 2021 10:26:33 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 99A5FAE56; Mon, 29 Mar 2021 14:26:32 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id E2A5A1E4353; Mon, 29 Mar 2021 16:26:31 +0200 (CEST) Date: Mon, 29 Mar 2021 16:26:31 +0200 From: Jan Kara To: Zhang Yi Cc: linux-ext4@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, jack@suse.cz Subject: Re: [PATCH] ext4: fix check to prevent false positive report of incorrect used inodes Message-ID: <20210329142631.GC4283@quack2.suse.cz> References: <20210329061955.2437573-1-yi.zhang@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210329061955.2437573-1-yi.zhang@huawei.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Mon 29-03-21 14:19:55, Zhang Yi wrote: > Commit <50122847007> ("ext4: fix check to prevent initializing reserved > inodes") check the block group zero and prevent initializing reserved > inodes. But in some special cases, the reserved inode may not all belong > to the group zero, it may exist into the second group if we format > filesystem below. > > mkfs.ext4 -b 4096 -g 8192 -N 1024 -I 4096 /dev/sda > > So, it will end up triggering a false positive report of a corrupted > file system. This patch fix it by avoid check reserved inodes if no free > inode blocks will be zeroed. > > Fixes: 50122847007 ("ext4: fix check to prevent initializing reserved inodes") > Signed-off-by: Zhang Yi Thanks! The patch looks correct but maybe the code can be made more comprehensible like I suggest below? > @@ -1543,22 +1544,25 @@ int ext4_init_inode_table(struct super_block *sb, ext4_group_t group, > * used inodes so we need to skip blocks with used inodes in > * inode table. > */ > - if (!(gdp->bg_flags & cpu_to_le16(EXT4_BG_INODE_UNINIT))) > - used_blks = DIV_ROUND_UP((EXT4_INODES_PER_GROUP(sb) - > - ext4_itable_unused_count(sb, gdp)), > - sbi->s_inodes_per_block); > - > - if ((used_blks < 0) || (used_blks > sbi->s_itb_per_group) || > - ((group == 0) && ((EXT4_INODES_PER_GROUP(sb) - > - ext4_itable_unused_count(sb, gdp)) < > - EXT4_FIRST_INO(sb)))) { > - ext4_error(sb, "Something is wrong with group %u: " > - "used itable blocks: %d; " > - "itable unused count: %u", > - group, used_blks, > - ext4_itable_unused_count(sb, gdp)); > - ret = 1; > - goto err_out; > + if (!(gdp->bg_flags & cpu_to_le16(EXT4_BG_INODE_UNINIT))) { > + used_inos = EXT4_INODES_PER_GROUP(sb) - > + ext4_itable_unused_count(sb, gdp); > + used_blks = DIV_ROUND_UP(used_inos, sbi->s_inodes_per_block); > + > + if (used_blks >= 0 && used_blks <= sbi->s_itb_per_group) > + used_inos += group * EXT4_INODES_PER_GROUP(sb); Maybe if would be more comprehensible like: /* Bogus inode unused count? */ if (used_blks < 0 || used_blks > sbi->s_itb_per_group) { ext4_error(...); ret = 1; goto err_out; } used_inos += EXT4_INODES_PER_GROUP(sb); /* * Are there some uninitialized inodes in the inode table * before the first normal inode? */ if (used_blks != sbi->s_itb_per_group && used_inos < EXT4_FIRST_INO(sb)) { ext4_error(...); ret = 1; goto err_out; } > + > + if ((used_blks < 0) || (used_blks > sbi->s_itb_per_group) || > + ((used_blks != sbi->s_itb_per_group) && > + (used_inos < EXT4_FIRST_INO(sb)))) { > + ext4_error(sb, "Something is wrong with group %u: " > + "used itable blocks: %d; " > + "itable unused count: %u", > + group, used_blks, > + ext4_itable_unused_count(sb, gdp)); > + ret = 1; > + goto err_out; > + } > } Honza -- Jan Kara SUSE Labs, CR