Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp318713pxb; Wed, 18 Aug 2021 23:47:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwmiVc4e3ObGFCBiGIUNCRfM7YpqzbK86RjOPioOTsvoHMxnIXSjC8CRFeYUVXCTLgLxLaM X-Received: by 2002:a02:c61a:: with SMTP id i26mr12012448jan.108.1629355620022; Wed, 18 Aug 2021 23:47:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629355620; cv=none; d=google.com; s=arc-20160816; b=uUQ2ePiPeKNjXtwsCdv/EkOdSMVtEp8nC44WkDny9HJlfVHMARKqlljyfmmmbN8sio olWsrFl039OrlzlSjsQ7MwrA6VxxQTpJk+PvAJGuqiVHbk7I+WJOIoE6pkP0d5YecWZ/ 3VsHRux/LLxG4G2TGgpxm5Cm1jYe9VKaY2gfT6Us+5oFcqmp8NAXCE3gwKKZWQ9cjrb4 w3ltEmA3TCv57huuPeRD3CJvfUjG+pAqDPYYMMoY2e/hsjKahi1W17Gz13WVI8xx46A3 kxuNsjkFGAXGouCbF5/B+uwilb65B6bQQSaHAHbCyCelKtbDl8V3VDgp9cubc9B0x53W otTw== 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=9kQMnmIVCOwqvPsxWkcacaO9NB9dBYlJcFX3vOrjlJs=; b=XYnlNepdXGthgVM27fwfLp8H8itHH3obo0t5cBAZnF/JzQtaPfr+676F5Kjt0gjFkO 5OWiUsMRipGux0DDI2wHtBcB274+umW4enC6dt6MEl+3hUpxv64rNtG4mU3s99Zgvx0Y O7CNIzKP22q93gglwFKW/JVevEJdUlsCqmD7STN97YF9xKlY4RVGxXlVipzqXwC3u/XQ CU+TnbK6UNmcLPBF5WD2ZxGv7BOChSUn/g/bueobpO7CXzAXabwR4NLisiFJQmxXrXMz U/ODOFg8s+1S2iUoA76iDRK6kzhm3YqilTKP3Xr/RC1g2T3+hQ6XsW5RvtBadkDpktf+ Nx1Q== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r17si2805532iov.104.2021.08.18.23.46.47; Wed, 18 Aug 2021 23:47:00 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231426AbhHSGrP (ORCPT + 99 others); Thu, 19 Aug 2021 02:47:15 -0400 Received: from szxga01-in.huawei.com ([45.249.212.187]:17048 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231347AbhHSGrN (ORCPT ); Thu, 19 Aug 2021 02:47:13 -0400 Received: from dggeme752-chm.china.huawei.com (unknown [172.30.72.56]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4GqwF66vCdzbfMl; Thu, 19 Aug 2021 14:42:50 +0800 (CST) Received: from huawei.com (10.175.127.227) by dggeme752-chm.china.huawei.com (10.3.19.98) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Thu, 19 Aug 2021 14:46:35 +0800 From: Zhang Yi To: CC: , , , , Subject: [PATCH v2 4/4] ext4: prevent getting empty inode buffer Date: Thu, 19 Aug 2021 14:57:04 +0800 Message-ID: <20210819065704.1248402-5-yi.zhang@huawei.com> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210819065704.1248402-1-yi.zhang@huawei.com> References: <20210819065704.1248402-1-yi.zhang@huawei.com> 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 dggeme752-chm.china.huawei.com (10.3.19.98) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org In ext4_get_inode_loc(), we may skip IO and get an zero && uptodate inode buffer when the inode monopolize an inode block for performance reason. For most cases, ext4_mark_iloc_dirty() will fill the inode buffer to make it fine, but we could miss this call if something bad happened. Finally, __ext4_get_inode_loc_noinmem() may probably get an empty inode buffer and trigger ext4 error. For example, if we remove a nonexistent xattr on inode A, ext4_xattr_set_handle() will return ENODATA before invoking ext4_mark_iloc_dirty(), it will left an uptodate but zero buffer. We will get checksum error message in ext4_iget() when getting inode again. EXT4-fs error (device sda): ext4_lookup:1784: inode #131074: comm cat: iget: checksum invalid Even worse, if we allocate another inode B at the same inode block, it will corrupt the inode A on disk when write back inode B. So this patch postpone the init and mark buffer uptodate logic until before filling correct inode data in ext4_do_update_inode() if skip read I/O, ensure the buffer is real uptodate. Signed-off-by: Zhang Yi --- fs/ext4/inode.c | 26 +++++++++++++++++++++++--- 1 file changed, 23 insertions(+), 3 deletions(-) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index d0d7a5295bf9..02d910c9d8f1 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -4367,9 +4367,11 @@ static int __ext4_get_inode_loc(struct super_block *sb, unsigned long ino, } brelse(bitmap_bh); if (i == start + inodes_per_block) { - /* all other inodes are free, so skip I/O */ - memset(bh->b_data, 0, bh->b_size); - set_buffer_uptodate(bh); + /* + * All other inodes are free, skip I/O. Return + * un-inited buffer (which is postponed until + * before filling inode data) immediately. + */ unlock_buffer(bh); goto has_buffer; } @@ -5026,6 +5028,24 @@ static int ext4_do_update_inode(handle_t *handle, gid_t i_gid; projid_t i_projid; + /* + * If the buffer is not uptodate, it means all information of inode + * in memory and we got this buffer without reading the block. We + * must be cautious that once we mark the buffer as uptodate, we + * rely on filling in the correct inode data later in this function. + * Otherwise if we getting the left falsepositive buffer when + * creating other inode on the same block, it could corrupt the + * inode data on disk. + */ + if (!buffer_uptodate(bh)) { + lock_buffer(bh); + if (!buffer_uptodate(bh)) { + memset(bh->b_data, 0, bh->b_size); + set_buffer_uptodate(bh); + } + unlock_buffer(bh); + } + spin_lock(&ei->i_raw_lock); /* For fields not tracked in the in-memory inode, -- 2.31.1