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: <20250829170945.dhxvuxeesyop375v@dell-per750-06-vm-08.rhts.eng.pek2.redhat.com>
Date: Sat, 30 Aug 2025 01:09:45 +0800
From: Zorro Lang <zlang@...hat.com>
To: Ojaswin Mujoo <ojaswin@...ux.ibm.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 Thu, Aug 28, 2025 at 08:30:59PM +0530, Ojaswin Mujoo wrote:
> 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.

Thanks Ojaswin, if so I think we can accept this change :)

Reviewed-by: Zorro Lang <zlang@...hat.com>

> 
> Regards,
> ojaswin
> 
> > 
> > Thanks,
> > Zorro
> 
> > 
> > > +
> > >  $XFS_IO_PROG -c 'fsmap' $SCRATCH_MNT >> $seqres.full
> > >  
> > >  find_freesp() {
> > > -- 
> > > 2.49.0
> > > 
> > 
>