Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp1033597ybz; Wed, 29 Apr 2020 13:47:41 -0700 (PDT) X-Google-Smtp-Source: APiQypJANy5Mt+AAE36AKVi3kBhmKnDR+CTWliYhoeRxRdcKo3gcUnBp2g5qeClzTNgxHtO5E2Es X-Received: by 2002:a17:906:c113:: with SMTP id do19mr4514736ejc.286.1588193261539; Wed, 29 Apr 2020 13:47:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588193261; cv=none; d=google.com; s=arc-20160816; b=pa0oa1136F0uNlsSqMwo/6dLz0BbCOp5+K55PCGuG3IjYUOMSlgh3Zwb152wK9hCZL Gk1K2kcfhNEqE0RQQpT9Sk+lVKFOP+swouwHT3gKcGoTn9OrzaJ5VhTNqk18KovI8MwX 87OpoaNZn23guVlRtokZQObe5cPSUFQLQ6Hh+rsGz1Mc5hISz3yyMr3bBFcSzdUmbWvV S97JivC8YcqF4Jk8YI0hggVBIbHqDSUF5fbrKQjgxkYhUhHoTAVq9xoHznelPrZpYlFg aywr+KtO04B0aVhoQZ7lGBzutsK+Xqn7T/bxsaj68rVSI7K+zhM+W+udUiinbz0bY7qp BCMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from; bh=eKQ84sWYN0vDEq4waA562uP98RnFzug2aZvcgqYRfqc=; b=BzqVZQHqApFz22fKuuu8QoenaalweUWPkaVc4ctZ26bVVv4C6cmUuOUVUGuSfLmQ4l 9mEBTqlW9xz/AilfBEZgoGXu5a4kO5A1GM/R8mUXE1agrDcJAZflovN2jciXyFGwhEjL 0mInfzKJS19w/psvG9EX4Q97il9pW5KEcXYlIticYTP8f6Wd3uUxjYfGqL7NrFR/X9X4 AbbV3YIeHkSWIhq9RIutAj4nw3nvpNeC64FucJg5KiGb6TEXt/7GD3n4XhYgWBc6WwWu urxYIFjVVoS1VuF1w8eEITFFnOcGgkFhRQZykjx3MpXLFoFmSvNH2GC9NRcpyHLsdG5L Ly7g== 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=vmware.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u22si5015442edd.207.2020.04.29.13.47.18; Wed, 29 Apr 2020 13:47:41 -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=vmware.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727778AbgD2Uqy (ORCPT + 99 others); Wed, 29 Apr 2020 16:46:54 -0400 Received: from ex13-edg-ou-001.vmware.com ([208.91.0.189]:26946 "EHLO EX13-EDG-OU-001.vmware.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726554AbgD2Uqx (ORCPT ); Wed, 29 Apr 2020 16:46:53 -0400 Received: from sc9-mailhost3.vmware.com (10.113.161.73) by EX13-EDG-OU-001.vmware.com (10.113.208.155) with Microsoft SMTP Server id 15.0.1156.6; Wed, 29 Apr 2020 13:46:50 -0700 Received: from localhost.localdomain (ashwinh-vm-1.vmware.com [10.110.19.225]) by sc9-mailhost3.vmware.com (Postfix) with ESMTP id 8D5F840A68; Wed, 29 Apr 2020 13:46:50 -0700 (PDT) From: ashwin-h To: , CC: , , , , , , , , , Ashwin H Subject: [PATCH 3/5] ext4: don't perform block validity checks on the journal inode Date: Thu, 30 Apr 2020 10:05:19 +0530 Message-ID: X-Mailer: git-send-email 2.7.4 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain Received-SPF: None (EX13-EDG-OU-001.vmware.com: ashwinh@vmware.com does not designate permitted sender hosts) Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org From: Theodore Ts'o commit 0a944e8a6c66ca04c7afbaa17e22bf208a8b37f0 upstream. Since the journal inode is already checked when we added it to the block validity's system zone, if we check it again, we'll just trigger a failure. This was causing failures like this: [ 53.897001] EXT4-fs error (device sda): ext4_find_extent:909: inode #8: comm jbd2/sda-8: pblk 121667583 bad header/extent: invalid extent entries - magic f30a, entries 8, max 340(340), depth 0(0) [ 53.931430] jbd2_journal_bmap: journal block not found at offset 49 on sda-8 [ 53.938480] Aborting journal on device sda-8. ... but only if the system was under enough memory pressure that logical->physical mapping for the journal inode gets pushed out of the extent cache. (This is why it wasn't noticed earlier.) Fixes: 345c0dbf3a30 ("ext4: protect journal inode's blocks using block_validity") Reported-by: Dan Rue Signed-off-by: Theodore Ts'o Tested-by: Naresh Kamboju Signed-off-by: Ashwin H --- fs/ext4/extents.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index 8d98c9a..71492bf 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -525,10 +525,14 @@ __read_extent_tree_block(const char *function, unsigned int line, } if (buffer_verified(bh) && !(flags & EXT4_EX_FORCE_CACHE)) return bh; - err = __ext4_ext_check(function, line, inode, - ext_block_hdr(bh), depth, pblk); - if (err) - goto errout; + if (!ext4_has_feature_journal(inode->i_sb) || + (inode->i_ino != + le32_to_cpu(EXT4_SB(inode->i_sb)->s_es->s_journal_inum))) { + err = __ext4_ext_check(function, line, inode, + ext_block_hdr(bh), depth, pblk); + if (err) + goto errout; + } set_buffer_verified(bh); /* * If this is a leaf block, cache all of its entries -- 2.7.4