linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Zorro Lang <zlang@redhat.com>
Cc: fstests@vger.kernel.org, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 5/8] generic/772: actually check for file_getattr special file support
Date: Mon, 20 Oct 2025 09:26:14 -0700	[thread overview]
Message-ID: <20251020162614.GK6178@frogsfrogsfrogs> (raw)
In-Reply-To: <20251018075708.t7agddy5ceisek2e@dell-per750-06-vm-08.rhts.eng.pek2.redhat.com>

On Sat, Oct 18, 2025 at 03:57:08PM +0800, Zorro Lang wrote:
> On Fri, Oct 17, 2025 at 03:54:48PM -0700, Darrick J. Wong wrote:
> > On Sat, Oct 18, 2025 at 01:46:33AM +0800, Zorro Lang wrote:
> > > On Wed, Oct 15, 2025 at 09:38:01AM -0700, Darrick J. Wong wrote:
> > > > From: Darrick J. Wong <djwong@kernel.org>
> > > > 
> > > > On XFS in 6.17, this test fails with:
> > > > 
> > > >  --- /run/fstests/bin/tests/generic/772.out	2025-10-06 08:27:10.834318149 -0700
> > > >  +++ /var/tmp/fstests/generic/772.out.bad	2025-10-08 18:00:34.713388178 -0700
> > > >  @@ -9,29 +9,34 @@ Can not get fsxattr on ./foo: Invalid ar
> > > >   Can not set fsxattr on ./foo: Invalid argument
> > > >   Initial attributes state
> > > >   ----------------- SCRATCH_MNT/prj
> > > >  ------------------ ./fifo
> > > >  ------------------ ./chardev
> > > >  ------------------ ./blockdev
> > > >  ------------------ ./socket
> > > >  ------------------ ./foo
> > > >  ------------------ ./symlink
> > > >  +Can not get fsxattr on ./fifo: Inappropriate ioctl for device
> > > >  +Can not get fsxattr on ./chardev: Inappropriate ioctl for device
> > > >  +Can not get fsxattr on ./blockdev: Inappropriate ioctl for device
> > > >  +Can not get fsxattr on ./socket: Inappropriate ioctl for device
> > > > 
> > > > This is a result of XFS' file_getattr implementation rejecting special
> > > > files prior to 6.18.  Therefore, skip this new test on old kernels.
> > > > 
> > > > Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
> > > > ---
> > > >  tests/generic/772 |    3 +++
> > > >  tests/xfs/648     |    3 +++
> > > >  2 files changed, 6 insertions(+)
> > > > 
> > > > 
> > > > diff --git a/tests/generic/772 b/tests/generic/772
> > > > index cc1a1bb5bf655c..e68a6724654450 100755
> > > > --- a/tests/generic/772
> > > > +++ b/tests/generic/772
> > > > @@ -43,6 +43,9 @@ touch $projectdir/bar
> > > >  ln -s $projectdir/bar $projectdir/broken-symlink
> > > >  rm -f $projectdir/bar
> > > >  
> > > > +file_attr --get $projectdir ./fifo &>/dev/null || \
> > > > +	_notrun "file_getattr not supported on $FSTYP"
> > > 
> > > I'm wondering if a _require_file_attr() is better?
> > 
> > It's checking specifically that the new getattr syscall works on special
> > files.  I suppose you could wrap that in a helper, but I think this is a
> > lot more direct about what it's looking for.
> 
> Please correct me if I'm wrong. The new syscall is created for setting extended
> attributes on special files, therefore I suppose if there's file_setattr syscall
> and it can work on regular file, then it can work on any other files the fs supports.
> If this's correct, _require_file_attr can use file_attr to try to set and get
> attr on a regular file in $TEST_DIR, to make sure the whole file_set/getattr
> feature is supported. Is that right?

No.  The new new syscall allows programs to specify a {dir fd, path}
input that points to a special file, but it uses the existing per-fs
get/setattr implementations.  All of those implementations have to
remove their copy-pasta'd code:

	if (d_is_special(dentry))
		return -ENOTTY;

before the new syscall will return non-error for special files.  This
wasn't done for all of the filesystems before 6.18, which means that
6.17 has the syscall but none of the filesystems support accessing
special files.  As of 6.18-rc2, gfs, jfs, and ubifs still have that
code.

TLDR: You can't assume that the new syscall works with special files.

--D

> Thanks,
> Zorro
> 
> > 
> > --D
> > 
> > > Thanks,
> > > Zorro
> > > 
> > > > +
> > > >  echo "Error codes"
> > > >  # wrong AT_ flags
> > > >  file_attr --get --invalid-at $projectdir ./foo
> > > > diff --git a/tests/xfs/648 b/tests/xfs/648
> > > > index 215c809887b609..e3c2fbe00b666a 100755
> > > > --- a/tests/xfs/648
> > > > +++ b/tests/xfs/648
> > > > @@ -47,6 +47,9 @@ touch $projectdir/bar
> > > >  ln -s $projectdir/bar $projectdir/broken-symlink
> > > >  rm -f $projectdir/bar
> > > >  
> > > > +$here/src/file_attr --get $projectdir ./fifo &>/dev/null || \
> > > > +	_notrun "file_getattr not supported on $FSTYP"
> > > > +
> > > >  $XFS_QUOTA_PROG -D $tmp.projects -P $tmp.projid -x \
> > > >  	-c "project -sp $projectdir $id" $SCRATCH_DEV | filter_quota
> > > >  $XFS_QUOTA_PROG -D $tmp.projects -P $tmp.projid -x \
> > > > 
> > > 
> > > 
> > 
> 
> 

  reply	other threads:[~2025-10-20 16:26 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-15 16:36 [PATCHSET] fstests: more random fixes for v2025.10.05 Darrick J. Wong
2025-10-15 16:36 ` [PATCH 1/8] generic/427: try to ensure there's some free space before we do the aio test Darrick J. Wong
2025-10-17  4:18   ` Christoph Hellwig
2025-10-20 14:16   ` Zorro Lang
2025-10-20 18:35     ` Darrick J. Wong
2025-10-15 16:37 ` [PATCH 2/8] common/rc: fix _require_xfs_io_shutdown Darrick J. Wong
2025-10-17  4:18   ` Christoph Hellwig
2025-10-24  7:31   ` Nirjhar Roy (IBM)
2025-10-24 22:08     ` Darrick J. Wong
2025-10-30  6:31       ` Nirjhar Roy (IBM)
2025-10-15 16:37 ` [PATCH 3/8] generic/742: avoid infinite loop if no fiemap results Darrick J. Wong
2025-10-17  4:19   ` Christoph Hellwig
2025-10-15 16:37 ` [PATCH 4/8] generic/{482,757}: skip test if there are no FUA writes Darrick J. Wong
2025-10-17  4:22   ` Christoph Hellwig
2025-10-17 16:24     ` Darrick J. Wong
2025-10-20  6:59       ` Christoph Hellwig
2025-10-15 16:38 ` [PATCH 5/8] generic/772: actually check for file_getattr special file support Darrick J. Wong
2025-10-17  4:23   ` Christoph Hellwig
2025-10-17 17:46   ` Zorro Lang
2025-10-17 22:54     ` Darrick J. Wong
2025-10-18  7:57       ` Zorro Lang
2025-10-20 16:26         ` Darrick J. Wong [this message]
2025-10-24  7:44   ` Nirjhar Roy (IBM)
2025-10-24 22:10     ` Darrick J. Wong
2025-10-30  6:05       ` Nirjhar Roy (IBM)
2025-10-30 16:33         ` Darrick J. Wong
2025-10-15 16:38 ` [PATCH 6/8] common/filter: fix _filter_file_attributes to handle xfs file flags Darrick J. Wong
2025-10-17  4:23   ` Christoph Hellwig
2025-10-17 16:22     ` Darrick J. Wong
2025-10-20  7:01       ` Christoph Hellwig
2025-10-20 16:37         ` Darrick J. Wong
2025-10-21  5:30           ` Christoph Hellwig
2025-10-21 14:47             ` Darrick J. Wong
2025-10-15 16:38 ` [PATCH 7/8] common/attr: fix _require_noattr2 Darrick J. Wong
2025-10-17  4:24   ` Christoph Hellwig
2025-10-17 17:13   ` Zorro Lang
2025-10-17 22:55     ` Darrick J. Wong
2025-10-18 14:43       ` Zorro Lang
2025-10-20 16:27         ` Darrick J. Wong
2025-10-24  9:01   ` Nirjhar Roy (IBM)
2025-10-24 22:15     ` Darrick J. Wong
2025-10-30  6:02       ` Nirjhar Roy (IBM)
2025-10-15 16:38 ` [PATCH 8/8] common: fix _require_xfs_io_command pwrite -A for various blocksizes Darrick J. Wong
2025-10-17  4:24   ` Christoph Hellwig
2025-10-24  9:18   ` Nirjhar Roy (IBM)
2025-10-24 22:16     ` Darrick J. Wong
2025-10-30  6:03       ` Nirjhar Roy (IBM)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251020162614.GK6178@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=zlang@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).