[PATCHSET] fstests: more random fixes for v2025.04.27

[PATCHSET] fstests: more random fixes for v2025.04.27

[Darrick J. Wong]

Hi all,

Here's the usual odd fixes for fstests.

If you're going to start using this code, I strongly recommend pulling
from my git trees, which are linked below.

With a bit of luck, this should all go splendidly.
Comments and questions are, as always, welcome.

--D

kernel git tree:
https://git.kernel.org/cgit/linux/kernel/git/djwong/xfs-linux.git/log/?h=random-fixes

xfsprogs git tree:
https://git.kernel.org/cgit/linux/kernel/git/djwong/xfsprogs-dev.git/log/?h=random-fixes

fstests git tree:
https://git.kernel.org/cgit/linux/kernel/git/djwong/xfstests-dev.git/log/?h=random-fixes
---
Commits in this patchset:
 * fsstress: fix attr_set naming
 * xfs/349: don't run on kernels that don't support scrub
---
 ltp/fsstress.c |    4 ++--
 tests/xfs/349  |    2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

[PATCH 1/2] fsstress: fix attr_set naming

[Darrick J. Wong]

From: Darrick J. Wong <djwong@kernel.org>

Back in 2020 I converted attr_set to lsetxattr, but neglected to notice
that the attr name now has to have the prefix "user." which attr_set
used to append for us.  Unfortunately nobody runs fsstress in verbose
mode so I didn't notice until now, and even then only because fuse2fs
stupidly accepts any name, even if that corrupts the filesystem.

Found by running generic/642 on fuse2fs.

Cc: <fstests@vger.kernel.org> # v2022.05.01
Fixes: 808f39a416c962 ("fsstress: stop using attr_set")
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
---
 ltp/fsstress.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)


diff --git a/ltp/fsstress.c b/ltp/fsstress.c
index 14c29921e8b0f8..ed9d5fa1efc3d9 100644
--- a/ltp/fsstress.c
+++ b/ltp/fsstress.c
@@ -2481,7 +2481,7 @@ attr_remove_f(opnum_t opno, long r)
 void
 attr_set_f(opnum_t opno, long r)
 {
-	char		aname[10];
+	char		aname[32];
 	char		*aval;
 	int		e;
 	pathname_t	f;
@@ -2493,7 +2493,7 @@ attr_set_f(opnum_t opno, long r)
 	init_pathname(&f);
 	if (!get_fname(FT_ANYm, r, &f, NULL, NULL, &v))
 		append_pathname(&f, ".");
-	sprintf(aname, "a%x", nameseq++);
+	sprintf(aname, "user.a%x", nameseq++);
 	li = (int)(random() % (sizeof(lengths) / sizeof(lengths[0])));
 	len = (int)(random() % lengths[li]);
 	if (len == 0)

Re: [PATCH 1/2] fsstress: fix attr_set naming

[Christoph Hellwig]

On Wed, May 07, 2025 at 02:54:07PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> Back in 2020 I converted attr_set to lsetxattr, but neglected to notice
> that the attr name now has to have the prefix "user." which attr_set
> used to append for us.  Unfortunately nobody runs fsstress in verbose
> mode so I didn't notice until now, and even then only because fuse2fs
> stupidly accepts any name, even if that corrupts the filesystem.

Looks good

Reviewed-by: Christoph Hellwig <hch@lst.de>

I wonde if this creates a fallout somewhere else now that we actually
do xattr ops that don't fail..

Re: [PATCH 1/2] fsstress: fix attr_set naming

[Darrick J. Wong]

On Wed, May 07, 2025 at 09:19:22PM -0700, Christoph Hellwig wrote:
> On Wed, May 07, 2025 at 02:54:07PM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> > 
> > Back in 2020 I converted attr_set to lsetxattr, but neglected to notice
> > that the attr name now has to have the prefix "user." which attr_set
> > used to append for us.  Unfortunately nobody runs fsstress in verbose
> > mode so I didn't notice until now, and even then only because fuse2fs
> > stupidly accepts any name, even if that corrupts the filesystem.
> 
> Looks good
> 
> Reviewed-by: Christoph Hellwig <hch@lst.de>
> 
> I wonde if this creates a fallout somewhere else now that we actually
> do xattr ops that don't fail..

Yes, generic/753 now fails when xfs_repair complains about INCOMPLETE
xattrs and blows out the entire attr fork.  I tried the stupid fix of
downgrading the warning to leave the incomplete attr behind, but then
incomplete remote attr entries have a valueblk==0 and later I saw
corruption of block 0 of the attr fork with the remote block magic so
clearly something else is wrong there too.

--D

[PATCH 2/2] xfs/349: don't run on kernels that don't support scrub

[Darrick J. Wong]

From: Darrick J. Wong <djwong@kernel.org>

Don't run this scrub test if the kernel doesn't support scrub.

Fixes: f5f0c11a67a8f5 ("xfs: fuzz every field of every structure")
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
---
 tests/xfs/349 |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


diff --git a/tests/xfs/349 b/tests/xfs/349
index a68bfee579ac41..a03ab812dc9ec6 100755
--- a/tests/xfs/349
+++ b/tests/xfs/349
@@ -16,9 +16,9 @@ _register_cleanup "_cleanup" BUS
 . ./common/populate
 . ./common/fuzzy
 
-
 _require_scratch
 _require_scrub
+_require_xfs_stress_scrub
 _require_populate_commands
 
 echo "Format and populate"

Re: [PATCH 2/2] xfs/349: don't run on kernels that don't support scrub

[Christoph Hellwig]

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>