From: "Theodore Ts'o" <tytso@mit.edu>
To: Arthur Marsh <arthur.marsh@internode.on.net>
Cc: Richard Weinberger <richard.weinberger@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
linux-ext4@vger.kernel.org
Subject: Re: ext3/ext4 filesystem corruption under post 5.1.0 kernels
Date: Wed, 15 May 2019 00:57:17 -0400 [thread overview]
Message-ID: <20190515045717.GB5394@mit.edu> (raw)
In-Reply-To: <17C30FA3-1AB3-4DAD-9B86-9FA9088F11C9@internode.on.net>
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 <tytso@mit.edu>
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 <arthur.marsh@internode.on.net>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
---
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
next prev parent reply other threads:[~2019-05-15 4:57 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-11 11:33 ext3/ext4 filesystem corruption under post 5.1.0 kernels Arthur Marsh
2019-05-11 12:43 ` Richard Weinberger
2019-05-11 22:06 ` Theodore Ts'o
2019-05-13 7:45 ` Arthur Marsh
2019-05-13 10:31 ` Arthur Marsh
2019-05-14 1:59 ` Arthur Marsh
2019-05-14 10:42 ` Ondrej Zary
2019-05-15 2:59 ` Arthur Marsh
2019-05-15 4:57 ` Theodore Ts'o [this message]
2019-05-15 12:12 ` Arthur Marsh
2019-05-16 2:56 ` Theodore Ts'o
2019-05-17 16:44 ` Geert Uytterhoeven
2019-07-01 12:43 ` Geert Uytterhoeven
2019-07-01 13:56 ` Theodore Ts'o
2019-07-01 14:08 ` Geert Uytterhoeven
2019-05-17 9:23 ` Geert Uytterhoeven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190515045717.GB5394@mit.edu \
--to=tytso@mit.edu \
--cc=arthur.marsh@internode.on.net \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=richard.weinberger@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox