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: <20241122160430.GZ9425@frogsfrogsfrogs>
Date: Fri, 22 Nov 2024 08:04:30 -0800
From: "Darrick J. Wong" <djwong@...nel.org>
To: Ritesh Harjani <ritesh.list@...il.com>
Cc: Nirjhar Roy <nirjhar@...ux.ibm.com>, fstests@...r.kernel.org,
	linux-ext4@...r.kernel.org, linux-xfs@...r.kernel.org,
	ojaswin@...ux.ibm.com, zlang@...nel.org
Subject: Re: [PATCH v3 2/3] common/rc: Add a new _require_scratch_extsize
 helper function

On Fri, Nov 22, 2024 at 12:22:41AM +0530, Ritesh Harjani wrote:
> Nirjhar Roy <nirjhar@...ux.ibm.com> writes:
> 
> > On 11/21/24 13:23, Ritesh Harjani (IBM) wrote:
> >> Nirjhar Roy <nirjhar@...ux.ibm.com> writes:
> >>
> >>> _require_scratch_extsize helper function will be used in the
> >>> the next patch to make the test run only on filesystems with
> >>> extsize support.
> >>>
> >>> Reviewed-by: Ojaswin Mujoo <ojaswin@...ux.ibm.com>
> >>> Signed-off-by: Nirjhar Roy <nirjhar@...ux.ibm.com>
> >>> ---
> >>>   common/rc | 17 +++++++++++++++++
> >>>   1 file changed, 17 insertions(+)
> >>>
> >>> diff --git a/common/rc b/common/rc
> >>> index cccc98f5..995979e9 100644
> >>> --- a/common/rc
> >>> +++ b/common/rc
> >>> @@ -48,6 +48,23 @@ _test_fsxattr_xflag()
> >>>   	grep -q "fsxattr.xflags.*\[.*$2.*\]" <($XFS_IO_PROG -c "stat -v" "$1")
> >>>   }
> >>>   
> >>> +# This test requires extsize support on the  filesystem
> >>> +_require_scratch_extsize()
> >>> +{
> >>> +	_require_scratch
> >> _require_xfs_io_command "extsize"
> >>
> >> ^^^ Don't we need this too?
> > Yes, good point. I will add this in the next revision.
> >>
> >>> +	_scratch_mkfs > /dev/null
> >>> +	_scratch_mount
> >>> +	local filename=$SCRATCH_MNT/$RANDOM
> >>> +	local blksz=$(_get_block_size $SCRATCH_MNT)
> >>> +	local extsz=$(( blksz*2 ))
> >>> +	local res=$($XFS_IO_PROG -c "open -f $filename" -c "extsize $extsz" \
> >>> +		-c "extsize")
> >>> +	_scratch_unmount
> >>> +	grep -q "\[$extsz\] $filename" <(echo $res) || \
> >>> +		_notrun "this test requires extsize support on the filesystem"
> >> Why grep when we can simply just check the return value of previous xfs_io command?
> > No, I don't think we can rely on the return value of xfs_io. For ex, 
> > let's look at the following set of commands which are ran on an ext4 system:
> >
> > root@...RPC: /mnt1/test$ xfs_io -V
> > xfs_io version 5.13.0
> > root@...RPC: /mnt1/test$ touch new
> > root@...RPC: /mnt1/test$ xfs_io -c "extsize 8k"  new
> > foreign file active, extsize command is for XFS filesystems only
> > root@...RPC: /mnt1/test$ echo "$?"
> > 0
> > This incorrect return value might have been fixed in some later versions 
> > of xfs_io but there are still versions where we can't solely rely on the 
> > return value.
> 
> Ok. That's bad, we then have to rely on grep.
> Sure, thanks for checking and confirming that.

You all should add CMD_FOREIGN_OK to the extsize command in xfs_io,
assuming that you've not already done that in your dev workspace.

--D

> -ritesh
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ