linux-kernel - Re: [PATCH] generic/365: Fix false failure when mapping ends with free space

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: <aLBvK4I7uhYI3bsZ@li-dc0c254c-257c-11b2-a85c-98b6c1322444.ibm.com>
Date: Thu, 28 Aug 2025 20:30:59 +0530
From: Ojaswin Mujoo <ojaswin@...ux.ibm.com>
To: Zorro Lang <zlang@...hat.com>
Cc: fstests@...r.kernel.org, Ritesh Harjani <ritesh.list@...il.com>,
        djwong@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] generic/365: Fix false failure when mapping ends with
 free space

On Mon, Aug 25, 2025 at 11:29:25PM +0800, Zorro Lang wrote:
> On Tue, Aug 05, 2025 at 02:55:56PM +0530, Ojaswin Mujoo wrote:
> > If we have a small FS where the first free space mapping is also the
> > last mapping of the FS, then the following sub-test fails:
> > 
> >   echo "test whatever came after freesp"
> >   $XFS_IO_PROG -c "fsmap -d $((freesp_end + 2)) $((freesp_end + 3))" $SCRATCH_MNT
> > 
> > since there is nothing after the freespace. Fix this by punching a 1M
> > hole in a 3M file to ensure that the first free space is always
> > surrounded by allocated blocks.
> > 
> > Signed-off-by: Ojaswin Mujoo <ojaswin@...ux.ibm.com>
> > ---
> >  tests/generic/365 | 4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/tests/generic/365 b/tests/generic/365
> > index 36cb2530..bbadae71 100755
> > --- a/tests/generic/365
> > +++ b/tests/generic/365
> > @@ -32,6 +32,10 @@ if ((blksz < 2048)); then
> >  	_notrun "test requires at least 4 bblocks per fsblock"
> >  fi
> >  
> > +# This makes sure there is free space surrounded by allocated blocks, which
> > +# is needed for some sub tests.
> > +$XFS_IO_PROG -fc 'falloc 0 3M' -c 'fpunch 1M 1M' -c 'fsync' $SCRATCH_MNT/f
> 
> If you add "falloc" and "fpunch" operations, you need to:
> 
> _require_xfs_io_command "falloc"
> _require_xfs_io_command "fpunch"

Hey Zorro thanks for the review and sorry I keep missing this helper :/ 
I'll fix it.

> 
> Due to not all fileystems support these two fs operations.
> 
> BTW, I'm wondering how small (and what kind of) the fs you use, cause there's only
> one unused region, even this's a clean fs, there're some still many different
> metadatas. I even tried a 100M ext2 fs (which doesn't has log space), there're
> many free space regions. So I'm curious, how can you hit this issue? And if the
> SCRATCH_DEV is too small (e.g. 10M), do we really need to test with that fs size:)

Right so actually we used the standard 5G SCRATCH_DEV however we were
testing for 64kb blocksize as well as ext4 bigalloc:

 $ mkfs.ext4 -b 65536 -O bigalloc $SCRATCH_DEV

which can actually format an ext4 FS that can hold 65528 * 64KB = ~40G
in a single block group, so we end up with 1 block group where metadata
is at the top and free space is in the end.

Adding a small file like above seems like a easy and universal way of
getting around this issue.

Regards,
ojaswin

> 
> Thanks,
> Zorro

> 
> > +
> >  $XFS_IO_PROG -c 'fsmap' $SCRATCH_MNT >> $seqres.full
> >  
> >  find_freesp() {
> > -- 
> > 2.49.0
> > 
>