public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
To: Theodore Ts'o <tytso@mit.edu>,
	"Unterwurzacher,
	Jakob" <jakob.unterwurzacher@theobroma-systems.com>
Cc: "linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: ext4 online resize -> EXT4-fs error (device loop0) in ext4_update_backup_sb:174: Filesystem failed CRC
Date: Thu, 3 Nov 2022 12:54:20 +0100	[thread overview]
Message-ID: <e7c7d42c-bfb9-b015-fcd2-bfb5e6334e06@theobroma-systems.com> (raw)
In-Reply-To: <Y1tTk5ILKICjJL82@mit.edu>

Hi Theodore,

On 10/28/22 05:59, Theodore Ts'o wrote:
> On Wed, Oct 26, 2022 at 07:49:56PM +0000, Unterwurzacher, Jakob wrote:
>>
>> it looks like I am hitting a similar issue as reported by Borislav Petkov
>> in April 2022 ( https://urldefense.com/v3/__https://lore.kernel.org/lkml/YmqOqGKajOOx90ZY@zn.tnic/__;!!OOPJP91ZZw!kg_tsVkw00-Mf-bC3nyz9aOxZvEowuWZ19B4d-Vzx22Kd8RwNeAb7lEReLYF4ulwcE_OE0im6sdv3zVWHiLXp8Tafu1i$  ).
>>
>> I'm on kernel 6.0.5 and see this on arm64 as well as x86_64.
>> I have a 100% reproducer using a loop mount, here it is:
>>
>> 	truncate -s 16g ext4.img
>> 	mkfs.ext4 ext4.img 500m
>> 	mkdir ext4.mnt
>> 	mount ext4.img ext4.mnt
>> 	resize2fs ext4.img
> 
> Thanks for the reproducer!  The following patch should fix things.
> 
>         	       		      		- Ted
> 
>  From 9a8c5b0d061554fedd7dbe894e63aa34d0bac7c4 Mon Sep 17 00:00:00 2001
> From: Theodore Ts'o <tytso@mit.edu>
> Date: Thu, 27 Oct 2022 16:04:36 -0400
> Subject: [PATCH] ext4: update the backup superblock's at the end of the online
>   resize
> 
> When expanding a file system using online resize, various fields in
> the superblock (e.g., s_blocks_count, s_inodes_count, etc.) change.
> To update the backup superblocks, the online resize uses the function
> update_backups() in fs/ext4/resize.c.  This function was not updating
> the checksum field in the backup superblocks.  This wasn't a big deal
> previously, because e2fsck didn't care about the checksum field in the
> backup superblock.  (And indeed, update_backups() goes all the way
> back to the ext3 days, well before we had support for metadata
> checksums.)
> 
> However, there is an alternate, more general way of updating
> superblock fields, ext4_update_primary_sb() in fs/ext4/ioctl.c.  This
> function does check the checksum of the backup superblock, and if it
> doesn't match will mark the file system as corrupted.  That was
> clearly not the intent, so avoid to aborting the resize when a bad
> superblock is found.
> 
> In addition, teach update_backups() to properly update the checksum in
> the backup superblocks.  We will eventually want to unify
> updapte_backups() with the infrasture in ext4_update_primary_sb(), but
> that's for another day.
> 
> Note: The problem has been around for a while; it just didn't really
> matter until ext4_update_primary_sb() was added by commit bbc605cdb1e1
> ("ext4: implement support for get/set fs label").  And it became
> trivially easy to reproduce after commit 827891a38acc ("ext4: update
> the s_overhead_clusters in the backup sb's when resizing") in v6.0.
> 
> Cc: stable@kernel.org # 5.17+
> Fixes: bbc605cdb1e1 ("ext4: implement support for get/set fs label")
> Signed-off-by: Theodore Ts'o <tytso@mit.edu>

I don't see a formal patch on the linux-ext4 mailing list yet though 
your previous mail was sent to the ML. Is there any plan to send a 
formal patch or is your mail enough? I also don't see it on 
https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git yet.

Basically asking because we enforce that backporting is only allowed for 
patches that are sent to mailing lists so it's easier to follow progress 
were there any update to the patch warranted by reviews/feedback after 
we backported the patch. (In short, anything that can be fetched with b4 
shazam can be backported).

Let us know if there's anything we can do to help.

Thanks,
Quentin

      parent reply	other threads:[~2022-11-03 11:54 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-26 19:49 ext4 online resize -> EXT4-fs error (device loop0) in ext4_update_backup_sb:174: Filesystem failed CRC Unterwurzacher, Jakob
2022-10-28  3:59 ` Theodore Ts'o
2022-10-28 11:49   ` Jakob Unterwurzacher
2022-11-03 11:54   ` Quentin Schulz [this message]

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=e7c7d42c-bfb9-b015-fcd2-bfb5e6334e06@theobroma-systems.com \
    --to=quentin.schulz@theobroma-systems.com \
    --cc=jakob.unterwurzacher@theobroma-systems.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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