linux-ext4 - Re: [PATCH v2 1/8] migrate: fix skipping metadata buffer heads on migration

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aAlN4-pMHoc-PZ1G@bombadil.infradead.org>
Date: Wed, 23 Apr 2025 13:30:27 -0700
From: Luis Chamberlain <mcgrof@...nel.org>
To: Jan Kara <jack@...e.cz>
Cc: dave@...olabs.net, brauner@...nel.org, tytso@....edu,
	adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org,
	riel@...riel.com, willy@...radead.org, hannes@...xchg.org,
	oliver.sang@...el.com, david@...hat.com, axboe@...nel.dk,
	hare@...e.de, david@...morbit.com, djwong@...nel.org,
	ritesh.list@...il.com, linux-fsdevel@...r.kernel.org,
	linux-block@...r.kernel.org, linux-mm@...ck.org,
	gost.dev@...sung.com, p.raghav@...sung.com, da.gomez@...sung.com,
	syzbot+f3c6fda1297c748a7076@...kaller.appspotmail.com
Subject: Re: [PATCH v2 1/8] migrate: fix skipping metadata buffer heads on
 migration

On Wed, Apr 23, 2025 at 07:09:28PM +0200, Jan Kara wrote:
> On Wed 16-04-25 09:58:30, Luis Chamberlain wrote:
> > On Tue, Apr 15, 2025 at 06:28:55PM +0200, Jan Kara wrote:
> > > > So I tried:
> > > > 
> > > > root@...ext4-2k /var/lib/xfstests # fsck /dev/loop5 -y 2>&1 > log
> > > > e2fsck 1.47.2 (1-Jan-2025)
> > > > root@...ext4-2k /var/lib/xfstests # wc -l log
> > > > 16411 log
> > > 
> > > Can you share the log please?
> > 
> > Sure, here you go:
> > 
> > https://github.com/linux-kdevops/20250416-ext4-jbd2-bh-migrate-corruption
> > 
> > The last trace-0004.txt is a fresh one with Davidlohr's patches
> > applied. It has trace-0004-fsck.txt.
> 
> Thanks for the data! I was staring at them for some time and at this point
> I'm leaning towards a conclusion that this is actually not a case of
> metadata corruption but rather a bug in ext4 transaction credit computation
> that is completely independent of page migration.
> 
> Based on the e2fsck log you've provided the only damage in the filesystem
> is from the aborted transaction handle in the middle of extent tree growth.
> So nothing points to a lost metadata write or anything like that. And the
> credit reservation for page writeback is indeed somewhat racy - we reserve
> number of transaction credits based on current tree depth. However by the
> time we get to ext4_ext_map_blocks() another process could have modified
> the extent tree so we may need to modify more blocks than we originally
> expected and reserved credits for.
> 
> Can you give attached patch a try please?
> 
> 								Honza
> -- 
> Jan Kara <jack@...e.com>
> SUSE Labs, CR

> From 4c53fb9f4b9b3eb4a579f69b7adcb6524d55629c Mon Sep 17 00:00:00 2001
> From: Jan Kara <jack@...e.cz>
> Date: Wed, 23 Apr 2025 18:10:54 +0200
> Subject: [PATCH] ext4: Fix calculation of credits for extent tree modification
> 
> Luis and David are reporting that after running generic/750 test for 90+
> hours on 2k ext4 filesystem, they are able to trigger a warning in
> jbd2_journal_dirty_metadata() complaining that there are not enough
> credits in the running transaction started in ext4_do_writepages().
> 
> Indeed the code in ext4_do_writepages() is racy and the extent tree can
> change between the time we compute credits necessary for extent tree
> computation and the time we actually modify the extent tree. Thus it may
> happen that the number of credits actually needed is higher. Modify
> ext4_ext_index_trans_blocks() to count with the worst case of maximum
> tree depth.
> 
> Link: https://lore.kernel.org/all/20250415013641.f2ppw6wov4kn4wq2@offworld
> Reported-by: Davidlohr Bueso <dave@...olabs.net>
> Reported-by: Luis Chamberlain <mcgrof@...nel.org>
> Signed-off-by: Jan Kara <jack@...e.cz>

I kicked off tests! Let's see after ~ 90 hours!

  Luis