All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: "Nirjhar Roy (IBM)" <nirjhar.roy.lists@gmail.com>
Cc: zlang@redhat.com, fstests@vger.kernel.org, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 7/8] common/attr: fix _require_noattr2
Date: Fri, 24 Oct 2025 15:15:03 -0700	[thread overview]
Message-ID: <20251024221503.GV6178@frogsfrogsfrogs> (raw)
In-Reply-To: <95366976c8fee19ab2901c4b11fe5925042fdc95.camel@gmail.com>

On Fri, Oct 24, 2025 at 02:31:16PM +0530, Nirjhar Roy (IBM) wrote:
> On Wed, 2025-10-15 at 09:38 -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> > 
> > attr2/noattr2 doesn't do anything anymore and aren't reported in
> > /proc/mounts, so we need to check /proc/mounts and _notrun as a result.
> > 
> > Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
> > ---
> >  common/attr |    4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > 
> > diff --git a/common/attr b/common/attr
> > index 1c1de63e9d5465..35e0bee4e3aa53 100644
> > --- a/common/attr
> > +++ b/common/attr
> > @@ -241,7 +241,11 @@ _require_noattr2()
> >  		|| _fail "_try_scratch_mkfs_xfs failed on $SCRATCH_DEV"
> >  	_try_scratch_mount -o noattr2 > /dev/null 2>&1 \
> >  		|| _notrun "noattr2 mount option not supported on $SCRATCH_DEV"
> > +	grep -w "$SCRATCH_MNT" /proc/mounts | awk '{print $4}' | grep -q -w noattr2
> If noatrr2 doesn't do anything, then in that case _try_scratch_mount will ignore noattr2 and mount
> will succeed. With the above change, we are just checking if noattr2 appears in /proc/mounts(after
> the mount), if yes then the preconditions returns true, else the test using this precondition is
> notrun. Right?

Right.

On a pre-6.18 kernel where noattr2 did something, the following will
happen:

a) V4 filesystem, noattr2 actually matters for the mount, and it should
show up in /proc/mounts.  If it doesn't, then the test should not run.

b) V5 filesystem, noattr2 is impossible so the mount fails.  Test will
not run.

With 6.18 the behavior changes:

a) V4 filesystem, noattr2 doesn't do anything, the mount succeeds, but
noattr2 does not show up in /proc/mounts.  The test should not run.

b) V5 filesystem, noattr2 now no longer fails the mount but it doesn't
show up in /proc/mounts either.  The test still should not run.

> This looks okay to me.
> Reviewed-by: Nirjhar Roy (IBM) <nirjhar.roy.lists@gmail.com>

Thanks!

--D

> --NR
> > +	local res=${PIPESTATUS[2]}
> >  	_scratch_unmount
> > +	test $res -eq 0 \
> > +		|| _notrun "noattr2 mount option no longer functional"
> >  }
> >  
> >  # getfattr -R returns info in readdir order which varies from fs to fs.
> > 
> 
> 

  reply	other threads:[~2025-10-24 22:15 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
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 [this message]
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=20251024221503.GV6178@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=nirjhar.roy.lists@gmail.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.