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: <cd2201c9-ff7f-4cfd-acfc-2bba265b3a29@huawei.com>
Date: Wed, 12 Nov 2025 10:49:19 +0800
From: Baokun Li <libaokun1@...wei.com>
To: Theodore Ts'o <tytso@....edu>
CC: <linux-ext4@...r.kernel.org>, <adilger.kernel@...ger.ca>, <jack@...e.cz>,
	<linux-kernel@...r.kernel.org>, <kernel@...kajraghav.com>,
	<mcgrof@...nel.org>, <ebiggers@...nel.org>, <willy@...radead.org>,
	<yi.zhang@...wei.com>, <yangerkun@...wei.com>, <chengzhihao1@...wei.com>,
	<libaokun@...weicloud.com>, Baokun Li <libaokun1@...wei.com>
Subject: Re: [PATCH v2 00/24] ext4: enable block size larger than page size

On 2025-11-12 07:54, Theodore Ts'o wrote:
> On Fri, Nov 07, 2025 at 10:42:25PM +0800, libaokun@...weicloud.com wrote:
>> `kvm-xfstests -c ext4/all -g auto` has been executed with no new failures.
>> `kvm-xfstests -c ext4/64k -g auto` has been executed and no Oops was
>> observed, but allocation failures for large folios may trigger warn_alloc()
>> warnings.
> I'm seeing some new failures.  ext4/4k -g auto is running without any
> failures, but when I tried to run ext4/64, I got:
>
> ext4/64k: 607 tests, 16 failures, 101 skipped, 7277 seconds
>   Failures: ext4/033 generic/472 generic/493 generic/494 generic/495
>     generic/496 generic/497 generic/554 generic/569 generic/620
>     generic/636 generic/641 generic/643 generic/759 generic/760
>   Flaky: generic/251: 80% (4/5)
> Totals: 671 tests, 101 skipped, 79 failures, 0 errors, 6782s
>
> Some of the test failures may be because I was only using a 5G test
> and scratch device, and with a 64k block sze, that might be too small.
> But I tried using a 20G test device, and ext3/033 is still failing but
> with a different error signature:
>
>     --- tests/ext4/033.out      2025-11-06 22:04:13.000000000 -0500
>     +++ /results/ext4/results-64k/ext4/033.out.bad      2025-11-11 17:57:31.149710364 -0500
>     @@ -1,6 +1,8 @@
>      QA output created by 033
>      Figure out block size
>      Format huge device
>     +mount: /vdf: fsconfig() failed: Structure needs cleaning.
>     +       dmesg(1) may have more information after failed mount system call.
>
>
> I took a look at the generc/472 and that appears to be a swap on file failure:
>
> root@...-xfstests:~# /vtmp/mke2fs.static -t ext4 -b 65536 -Fq /dev/vdc
> Warning: blocksize 65536 not usable on most systems.
> /dev/vdc contains a ext4 file system
>         created on Tue Nov 11 18:02:13 2025
> root@...-xfstests:~# mount /dev/vdc /vdc
> root@...-xfstests:~# fallocate -l 1G /vdc/swap
> root@...-xfstests:~# mkswap /vdc/swap
> mkswap: /vdc/swap: insecure permissions 0644, fix with: chmod 0600 /vdc/swap
> Setting up swapspace version 1, size = 1024 MiB (1073737728 bytes)
> no label, UUID=a6298248-abf1-42a1-b124-2f6b3be7f597
> root@...-xfstests:~# swapon /vdc/swap
> swapon: /vdc/swap: insecure permissions 0644, 0600 suggested.
> swapon: /vdc/swap: swapon failed: Invalid argument
> root@...-xfstests:~# 

I checked the code of the swapon syscall in mm/swapfile.c, and currently
the swapfile does not support LBS. Therefore, some failing test cases can
be filtered out based on this.

         /*
          * The swap subsystem needs a major overhaul to support this.
          * It doesn't work yet so just disable it for now.
          */
         if (mapping_min_folio_order(mapping) > 0) {
                 error = -EINVAL;
                 goto bad_swap_unlock_inode;
         }

Regards,
Baokun

> A number of the other tests (generic/493, generic/494, generic/495,
> generic/496, generic/497, generic/554) are all swapfile tests.
>
> I'm not sure why you're not seeing these issues; what version of
> xfstests are you using?  I recently uploaded a new test appliance[1]
> can you try rerunning your tests with the latest test appliance for
> kvm-xfstests?
>
> [1] https://www.kernel.org/pub/linux/kernel/people/tytso/kvm-xfstests;
>
> 					- Ted
>


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ