Re: [PATCH] ext4: do not WARN when starting a journal on a frozen filesystem

On Fri, Jul 24, 2026 at 02:16:59PM -0500, Luyao Bai wrote:
> > Luyao, I'm curious what (if any) testing you performed before
> > submitting this patch?
> 
> I ran the syzbot C reproducer under QEMU on a clean mainline build to
> confirm the WARNING fires, and again with the patch applied to confirm
> it no longer does, plus a build of fs/ext4/ and checkpatch. I did not
> exercise fsync-during-freeze or the freeze/thaw transition (e.g. the
> fstests freeze tests), which is why the problems above escaped me.

In general I ask people who submit patches, especially if they are
relatively new to ext4 development to run at least the fstests smoke
tests, using (for example) "kvm-xfstests smoke" using this test
appliance.

[1] https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-quickstart.md

Unfortunately, this wouldn't be sufficient since the smoke tests don't
exercise the freeze/thaw transition, since the focus is on keeping
smoke tests to 15-20 minutes.  I'm *fairly* certain the problem with
this patch would have been detected by the auto group (e.g.,
"kvm-xfstests -c ext4/default -g auto") but that takes 2 to 2.5 hours
to run, and it wasn't clear we could get people to run that much
testing.

An interesting approach if we are using LLM-based tooling is to create
some kind of prompt that examines the patch, and the generates a list
of tests that exercises the code paths modified by patch.

Personally, because I have access to Cloud VM's, I'll just run
"gce-xfstests ltm -c ext4/all,ext4/64k -g auto", which takes 24 hours
of VM time (sharded across multiple VM's, so it only takes about 2.5
hours worth of wall clock time).  And since that's only about $2 of
cloud VM time, it hasn't been worth it for me to try to optimize set
of tests to run.  But if you only have access to using something like
kvm-xfstets, maybe it would be worthwhile to optimize the wall clock
time of running the tests.

Cheers,

						- Ted