From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED, USER_AGENT_MUTT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8D985C04AA7 for ; Wed, 15 May 2019 04:57:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 631FB20881 for ; Wed, 15 May 2019 04:57:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725974AbfEOE52 (ORCPT ); Wed, 15 May 2019 00:57:28 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:52534 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725876AbfEOE52 (ORCPT ); Wed, 15 May 2019 00:57:28 -0400 Received: from callcc.thunk.org (168-215-239-3.static.ctl.one [168.215.239.3] (may be forged)) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x4F4vI6M029686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 15 May 2019 00:57:20 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id 6872D420024; Wed, 15 May 2019 00:57:17 -0400 (EDT) Date: Wed, 15 May 2019 00:57:17 -0400 From: "Theodore Ts'o" To: Arthur Marsh Cc: Richard Weinberger , LKML , linux-ext4@vger.kernel.org Subject: Re: ext3/ext4 filesystem corruption under post 5.1.0 kernels Message-ID: <20190515045717.GB5394@mit.edu> Mail-Followup-To: Theodore Ts'o , Arthur Marsh , Richard Weinberger , LKML , linux-ext4@vger.kernel.org References: <48BA4A6E-5E2A-478E-A96E-A31FA959964C@internode.on.net> <20190511220659.GB8507@mit.edu> <09D87554-6795-4AEA-B8D0-FEBCB45673A9@internode.on.net> <850EDDE2-5B82-4354-AF1C-A2D0B8571093@internode.on.net> <17C30FA3-1AB3-4DAD-9B86-9FA9088F11C9@internode.on.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17C30FA3-1AB3-4DAD-9B86-9FA9088F11C9@internode.on.net> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Ah, I think I see the problem. Sorry, this one was my fault. Does this fix things for you? - Ted >From 0c72924ef346d54e8627440e6d71257aa5b56105 Mon Sep 17 00:00:00 2001 From: Theodore Ts'o Date: Wed, 15 May 2019 00:51:19 -0400 Subject: [PATCH] ext4: fix block validity checks for journal inodes using indirect blocks Commit 345c0dbf3a30 ("ext4: protect journal inode's blocks using block_validity") failed to add an exception for the journal inode in ext4_check_blockref(), which is the function used by ext4_get_branch() for indirect blocks. This caused attempts to read from the ext3-style journals to fail with: [ 848.968550] EXT4-fs error (device sdb7): ext4_get_branch:171: inode #8: block 30343695: comm jbd2/sdb7-8: invalid block Fix this by adding the missing exception check. Fixes: 345c0dbf3a30 ("ext4: protect journal inode's blocks using block_validity") Reported-by: Arthur Marsh Signed-off-by: Theodore Ts'o --- fs/ext4/block_validity.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/fs/ext4/block_validity.c b/fs/ext4/block_validity.c index 8d03550aaae3..8e83741b02e0 100644 --- a/fs/ext4/block_validity.c +++ b/fs/ext4/block_validity.c @@ -277,6 +277,11 @@ int ext4_check_blockref(const char *function, unsigned int line, __le32 *bref = p; unsigned int blk; + if (ext4_has_feature_journal(inode->i_sb) && + (inode->i_ino == + le32_to_cpu(EXT4_SB(inode->i_sb)->s_es->s_journal_inum))) + return 0; + while (bref < p+max) { blk = le32_to_cpu(*bref++); if (blk && -- 2.19.1