linux-ext4 - Re: ext4 v6.15-rc2 baseline

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: <20250419183641.GD210438@mit.edu>
Date: Sat, 19 Apr 2025 13:36:41 -0500
From: "Theodore Ts'o" <tytso@....edu>
To: Luis Chamberlain <mcgrof@...nel.org>
Cc: adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org,
        kdevops@...ts.linux.dev, dave@...olabs.net, jack@...e.cz
Subject: Re: ext4 v6.15-rc2 baseline

On Fri, Apr 18, 2025 at 12:08:17PM -0700, Luis Chamberlain wrote:
> > [1] https://github.com/tytso/xfstests-bld/blob/master/test-appliance/files/root/fs/ext4/exclude
> 
> Why not just add a hook to the test to skip it upstream?

Quite a few years ago, the upstream xfstests-bld maintainer at the
time was very much against adding these sorts of exceptions.

Instead of trying to pursuade upstream about these sorts of changes,
it was just simpler for me to exclude them in my test runner.  It's
for similar reasons why I still have some out of tree patches.  The
standards of patch review of patches from some folks such as myself
are *substantially* higher than say, those of parallel check patches,
where xfstests for-next was broken for three months.

If upstream was more willing to take patches that I find useful, I'd
certainly send them upstream.  But it's been painful.

> > Hmm, some of these are because there ar a bunch of tests that don't
> > work well the allocation cluster size != the file system block size.
> 
> We experienced a lot of test bugs for LBS but we addressed them.

If I recall correctly, upstream was hostile to the bigalloc changes a
while back, but that was many years ago. 

> 
> > See [2] for the tests that I exclude.  These are fundamentally test
> > bugs that just don't work for bigalloc's clustered allocation.
> 
> Absolutely all of these are test bugs? And they can't be fixed to
> test bigalloc?

The ones in [2] are test bugs, and *why* they are test bugs are
clearly documented in the exclude file.  If I had confidence that
upstream would accept them, I could work on it in my copious spare
time.  But it's *way* simpler for me to exclude them in my test
runner, as opposed to trying to get changes upstream in xfstests.

If other people want to try to get changes upstream, please be my
guest.  :-)

						- Ted