The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: "Theodore Tso" <tytso@mit.edu>
To: Luyao Bai <bailuyao1997@gmail.com>
Cc: Christian Brauner <brauner@kernel.org>,
	linux-ext4@vger.kernel.org,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	Jan Kara <jack@suse.cz>, Baokun Li <libaokun@linux.alibaba.com>,
	Ojaswin Mujoo <ojaswin@linux.ibm.com>,
	Ritesh Harjani <ritesh.list@gmail.com>,
	Zhang Yi <yi.zhang@huawei.com>,
	"Darrick J . Wong" <djwong@kernel.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ext4: do not WARN when starting a journal on a frozen filesystem
Date: Fri, 24 Jul 2026 10:32:28 -0400	[thread overview]
Message-ID: <amN037A4dXtbyREt@mit.edu> (raw)
In-Reply-To: <20260724141659.669079-1-bailuyao1997@gmail.com>

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

      reply	other threads:[~2026-07-24 14:34 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-23 20:50 [PATCH] ext4: do not WARN when starting a journal on a frozen filesystem Luyao Bai
2026-07-24  8:11 ` Christian Brauner
2026-07-24 13:31   ` Theodore Tso
2026-07-24 14:16     ` Luyao Bai
2026-07-24 14:32       ` Theodore Tso [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=amN037A4dXtbyREt@mit.edu \
    --to=tytso@mit.edu \
    --cc=adilger.kernel@dilger.ca \
    --cc=bailuyao1997@gmail.com \
    --cc=brauner@kernel.org \
    --cc=djwong@kernel.org \
    --cc=jack@suse.cz \
    --cc=libaokun@linux.alibaba.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ojaswin@linux.ibm.com \
    --cc=ritesh.list@gmail.com \
    --cc=yi.zhang@huawei.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