Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp528891ybz; Wed, 29 Apr 2020 04:50:40 -0700 (PDT) X-Google-Smtp-Source: APiQypL/LcMDioYMZgKEPSmOrqpy6G5Mown/56eioeluE531mVFZxPmmH6BhSebcZQ3W/EaYydSu X-Received: by 2002:aa7:d78a:: with SMTP id s10mr2088893edq.319.1588161040797; Wed, 29 Apr 2020 04:50:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588161040; cv=none; d=google.com; s=arc-20160816; b=Ag/KulAk1UGpx2AgzXkMa7GBWG70fml+idBEArsooMLXVp9re3yhnsSmnEMBmDNoVf Vd1op2HgYjLmrfvJdgWJEGTDbx2AXjl4ZEaKyrfnEG0Vj845b6NoytyCdBeBzLzD1ZQa frXU0c5nxSLMi/CxIFbgioDTsNTNc8sZgd+sbySgoZBycobd0oV16cMMD7xLsW9haKHM qb05eLHp9d2AcLYPwaBgbDHPVB0UEKkjKIvTUCJ4DmlpWDL78Om6HGIaFf4DLJgixw1X L+EhS6v2PrT2Pf6awRC+0TrcqcyHYV1AR5GlxFeWqivT2wC1GnM2j/DdLdppMZcqR4Jq R3Hw== 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=LDOMVUtegZ5dAzvpmXED1AVxB43U+rIqV2d+wvmpucQ=; b=E3eOF23EAeq4dchxyot64ib+ao8xCIEg5/eHp+TzJLypaZSPo3BxEn+VUBlNOx4ptt Up7S6VYR+cgLYdlzg+B+iKmxe3CD7bHUmv4S5Wsc+InpfiazkoYPZpEY4uqTtsdUkNdG EgU7yjTcCGvrfqpopOdhpUEcI06ijNah3yi5WBCuMEp3tSW+e0UjnqSJQosQUU3vJ7fq o89d59Irg4HRl0UhOhbgsl8vUuySOx3NcmlkvF9ty+UXbiq7R6UU1zEYiJgtjNTE3C9Z TUeYQJZ5DXatLLsriRfesbv4wGNh7v3ZtbIDWK3FTs4k1iuNmDrU82pJiv9bsdK0zXJB gJ0w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-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 g7si3445770ejf.410.2020.04.29.04.50.17; Wed, 29 Apr 2020 04:50:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-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-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-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 S1726942AbgD2LsQ (ORCPT + 99 others); Wed, 29 Apr 2020 07:48:16 -0400 Received: from ex13-edg-ou-002.vmware.com ([208.91.0.190]:20551 "EHLO EX13-EDG-OU-002.vmware.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726913AbgD2LsO (ORCPT ); Wed, 29 Apr 2020 07:48:14 -0400 Received: from sc9-mailhost2.vmware.com (10.113.161.72) by EX13-EDG-OU-002.vmware.com (10.113.208.156) with Microsoft SMTP Server id 15.0.1156.6; Wed, 29 Apr 2020 04:33:07 -0700 Received: from localhost.localdomain (ashwinh-vm-1.vmware.com [10.110.19.225]) by sc9-mailhost2.vmware.com (Postfix) with ESMTP id 64B38B2643; Wed, 29 Apr 2020 07:33:07 -0400 (EDT) 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 00:51:37 +0530 Message-ID: <1884f659f99a03cf5a0751ac1d848eae662892e2.1587713792.git.ashwinh@vmware.com> 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-002.vmware.com: ashwinh@vmware.com does not designate permitted sender hosts) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@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 71c68bd..76a8a03 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -530,10 +530,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