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] [day] [month] [year] [list]
Message-ID: <20260216131308.atxnkqehyke4conu@dell-per750-06-vm-08.rhts.eng.pek2.redhat.com>
Date: Mon, 16 Feb 2026 21:13:08 +0800
From: Zorro Lang <zlang@...hat.com>
To: Jan Kara <jack@...e.cz>
Cc: Zorro Lang <zlang@...nel.org>, fstests@...r.kernel.org,
	linux-ext4@...r.kernel.org, linux-xfs@...r.kernel.org
Subject: Re: [PATCH 0/4] Avoid failing shutdown tests without a journal

On Mon, Feb 16, 2026 at 09:56:07AM +0100, Jan Kara wrote:
> On Fri 13-02-26 00:44:02, Zorro Lang wrote:
> > On Thu, Feb 12, 2026 at 11:41:59AM +0100, Jan Kara wrote:
> > > > I initially considered calling _require_metadata_journaling directly inside
> > > > _require_scratch_shutdown. However, I decided against it because some cases might
> > > > only need the shutdown ioctl and don't strictly require a journal.
> > > 
> > > Absolutely. I think they should stay separate.
> > > 
> > > So to summarize I think we should still add _require_metadata_journaling to:
> > > 
> > > overlay/087
> > > g/536
> > > g/622
> > > g/722
> > 
> > Agree :)
> 
> Should I send patches or will you do this modification?

As you brought this issue up, so I'd like to leave the finish line to you :)
I saw your 4 patches nearly use same subject and commit log too. If you fix more 4 cases,
we'll have 8 seperated patches :-D So how about squashing all changes into one single
patch? Does that make sense to you?

Thanks,
Zorro

> 
> > > and we might add fsync of parent directory before shutdown to g/737 and
> > > overlay/078. Does this sound good?
> > 
> > I'm concerned that adding broader sync or fsync operations might interfere with the
> > test's original intent. We should probably evaluate the impact further. Alternatively,
> > we could simply use _require_metadata_journaling to ensure we at least keep the
> > coverage for the original bug :)
> 
> I agree with the approach to just leave the test as is for now and invest time
> into deciding what's the proper solution once someone complains :)
> 
> 								Honza
> -- 
> Jan Kara <jack@...e.com>
> SUSE Labs, CR
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ