All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Pitt <martin@amutable.com>
To: linux-erofs@lists.ozlabs.org
Cc: Gao Xiang <xiang@kernel.org>, Yifan Zhao <zhaoyifan28@huawei.com>,
	Martin Pitt <martin@amutable.com>
Subject: [PATCH 3/3] erofs-utils: tests: check that the xattr layout is order-independent
Date: Tue,  4 Aug 2026 05:32:14 +0200	[thread overview]
Message-ID: <20260804033214.211267-4-martin@amutable.com> (raw)
In-Reply-To: <20260804033214.211267-1-martin@amutable.com>

b260119b8edb ("erofs-utils: mkfs: emit an inode's xattrs in a canonical
order") made the layout independent of the order listxattr(2) reports an
inode's attributes in. Cover it: stage the same tree twice with the same
attributes set in opposite order, and compare the two images. The names
differ in length and share prefixes, so a subtly wrong comparison cannot
order them correctly by accident.

Signed-off-by: Martin Pitt <martin@amutable.com>
---
 tests/Makefile.am   |  3 ++
 tests/erofs/032     | 77 +++++++++++++++++++++++++++++++++++++++++++++
 tests/erofs/032.out |  2 ++
 3 files changed, 82 insertions(+)
 create mode 100755 tests/erofs/032
 create mode 100644 tests/erofs/032.out

diff --git a/tests/Makefile.am b/tests/Makefile.am
index c0291ac..363b93d 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -132,6 +132,9 @@ TESTS += erofs/030
 # 031 - test chunk-based mapping with shared chunks across inodes
 TESTS += erofs/031
 
+# 032 - check that the xattr layout does not depend on listxattr(2) order
+TESTS += erofs/032
+
 # NEW TEST CASE HERE
 # TESTS += erofs/999
 
diff --git a/tests/erofs/032 b/tests/erofs/032
new file mode 100755
index 0000000..063ed2c
--- /dev/null
+++ b/tests/erofs/032
@@ -0,0 +1,77 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Check that the xattr layout does not depend on listxattr(2) order
+#
+# listxattr(2) makes no promise about the order it reports, and filesystems
+# disagree: tmpfs reports the order the attributes were set in, while ext4 and
+# btrfs report their own on-disk order. The same set of attributes must end up
+# in the same layout however mkfs.erofs is handed them, otherwise images are
+# not reproducible. The names also differ in length and share prefixes, which
+# exercises the length tiebreak.
+#
+# On a filesystem that reports its own order rather than the insertion order
+# this check cannot fail, so it needs $tmp on a filesystem that keeps insertion
+# order or randomizes it, like tmpfs, which /tmp normally is.
+#
+seq=`basename $0`
+seqres=$RESULT_DIR/$(echo $0 | awk '{print $((NF-1))"/"$NF}' FS="/")
+
+# get standard environment, filters and checks
+. "${srcdir}/common/rc"
+
+cleanup()
+{
+	cd /
+	rm -rf $tmp.*
+}
+
+_require_xattr
+
+# remove previous $seqres.full before test
+rm -f $seqres.full
+
+# real QA test starts here
+echo "QA output created by $seq"
+
+attrs="user.aa=1 user.mm=22 user.mm_long=333 user.zz=4444
+user.a_long_attribute_name=55555 user.growfs=666666 user.roothash=7777777
+user.verity=88888888 user.gpt_label=999999999 user.gpt_type_uuid=aaaaaaaaaa"
+
+localdir=$tmp/$seq
+rm -rf $localdir
+
+# same tree and same attributes twice, set in opposite order
+for pass in forward reverse; do
+	tree=$localdir/$pass
+	mkdir -p $tree/dir
+	echo payload > $tree/dir/file
+
+	list=$attrs
+	if [ $pass = reverse ]; then
+		list=
+		for attr in $attrs; do
+			list="$attr $list"
+		done
+	fi
+	for attr in $list; do
+		setfattr -n "${attr%%=*}" -v "${attr#*=}" $tree ||
+			_fail "failed to set ${attr%%=*}"
+	done
+
+	# pin the timestamps and the filesystem UUID, so the attribute order
+	# is the only thing that can differ
+	$MKFS_EROFS_PROG -T1739577600 -U 5230d7cf-f2ce-43ed-9ae2-39e7e2fe48ca \
+		$localdir/$pass.img $tree >> $seqres.full 2>&1 ||
+		_fail "failed to mkfs"
+done
+
+$FSCK_EROFS_PROG --extract $localdir/forward.img >> $seqres.full 2>&1 ||
+	_fail "fsck failed"
+
+cmp -s $localdir/forward.img $localdir/reverse.img ||
+	_fail "the image depends on the order listxattr(2) reported"
+
+echo Silence is golden
+status=0
+exit 0
diff --git a/tests/erofs/032.out b/tests/erofs/032.out
new file mode 100644
index 0000000..34e059f
--- /dev/null
+++ b/tests/erofs/032.out
@@ -0,0 +1,2 @@
+QA output created by 032
+Silence is golden
-- 
2.55.0



      parent reply	other threads:[~2026-08-04  3:32 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-04  3:32 [PATCH 0/3] erofs-utils: tests: cover the canonical xattr order Martin Pitt
2026-08-04  3:32 ` [PATCH 1/3] erofs-utils: tests: fix broken loop in POSIX shells Martin Pitt
2026-08-04  3:32 ` [PATCH 2/3] erofs-utils: tests: look up programs with command -v Martin Pitt
2026-08-04  3:32 ` Martin Pitt [this message]

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=20260804033214.211267-4-martin@amutable.com \
    --to=martin@amutable.com \
    --cc=linux-erofs@lists.ozlabs.org \
    --cc=xiang@kernel.org \
    --cc=zhaoyifan28@huawei.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.