Re: ext3/ext4 filesystem corruption under post 5.1.0 kernels

[Arthur Marsh]

On 15 May 2019 2:27:17 pm ACST, Theodore Ts'o <tytso@xxxxxxx> wrote:
>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@xxxxxxx>
>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@xxxxxxxxxxxxxxxx>
>Signed-off-by: Theodore Ts'o <tytso@xxxxxxx>
>---
> 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 &&

I have built kernels with the attached patch applied and run git gc on the patched kernels (both the 32 bit kernel on the Pentium-D and the 64 bit kernel on the Athlon II X4 640). 

There were a couple of warnings from other processes being blocked while the git gc was taking place but no filesystem corruption detected. (I ran forced fsck checks on the root filesystems after the git gc runs to check for corruption). 

Thanks for the patch! 

Arthur. 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Attachment: ext4.tmp
Description: Binary data

Attachment: 20190515iucode_tool.log
Description: Binary data