e2fsprogs: Fix multiple xattr handling

There is an ordering issue when adding multiple xattr values to
an ext filesystem build using the -d option to mkfs. This patch
fixes that issue. Its been posted for discussion with the upstream
community.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

2 files changed, 67 insertions, 0 deletions

diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs/xattr_ordering.patch b/meta/recipes-devtools/e2fsprogs/e2fsprogs/xattr_ordering.patch
new file mode 100644
index 0000000000..a89b946450
--- /dev/null
+++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs/xattr_ordering.patch
@@ -0,0 +1,66 @@
+[Message sent to linux-ext4 on 2016/2/7]
+
+I'm using the -d option of mke2fs to construct a filesystem, I'm seeing
+that some xattrs are being corrupted. The filesystem builds with no
+errors but when mounted by the kernel, I see errors like "security.ima:
+No such attribute". The strace from such a failure is:
+
+mmap(NULL, 26258, PROT_READ, MAP_SHARED, 3, 0) = 0x7fdb36a8c000
+close(3)                    = 0
+getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=64*1024}) = 0
+lstat("mnt/foobar", {st_mode=S_IFREG|0755, st_size=1, ...}) = 0
+listxattr("mnt/foobar", NULL, 0) = 30
+listxattr("mnt/foobar", "security.SMACK64\0security.ima\0", 256) = 30
+getxattr("mnt/foobar", "security.SMACK64", 0x0, 0) = 1
+getxattr("mnt/foobar", "security.SMACK64", "_", 256) = 1
+fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 13), ...}) = 0
+mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fdb36a8b000
+write(1, "# file: mnt/foobar\n", 19# file: mnt/foobar) = 19
+write(1, "security.SMACK64=\"_\"\n", 21security.SMACK64="_") = 21
+getxattr("mnt/foobar", "security.ima", 0x0, 0) = -1 ENODATA (No data available)
+write(2, "mnt/foobar: ", 12mnt/foobar: ) = 12
+write(2, "security.ima: No such attribute\n", 32security.ima: No such attribute) = 32= 32
+
+so the attribute is there but the kernel gives ENODATA when trying
+to read it.
+
+http://www.nongnu.org/ext2-doc/ext2.html#CONTRIB-EXTENDED-ATTRIBUTES co
+ntains the small snippet that " The entry descriptors are sorted by
+attribute name, so that two extended attribute blocks can be compared
+efficiently. ". It doesn't specify what kind of sort.
+
+Looking at ext2fs, there is some sorting code through the qsort call
+using attr_compare() but it doesn't match what the kernel is doing in
+ext4_xattr_find_entry().
+
+This patch fixes the problem.
+
+Upstream-Status: Submitted
+RP
+2016/2/7
+
+Index: git/lib/ext2fs/ext_attr.c
+===================================================================
+--- git.orig/lib/ext2fs/ext_attr.c
++++ git/lib/ext2fs/ext_attr.c
+@@ -258,6 +258,7 @@ static struct ea_name_index ea_names[] =
+ static int attr_compare(const void *a, const void *b)
+ {
+ 	const struct ext2_xattr *xa = a, *xb = b;
++	size_t len;
+ 
+ 	if (xa->name == NULL)
+ 		return +1;
+@@ -267,7 +268,11 @@ static int attr_compare(const void *a, c
+ 		return -1;
+ 	else if (!strcmp(xb->name, "system.data"))
+ 		return +1;
+-	return 0;
++	len = strlen(xa->name) - strlen(xb->name);
++	if (len)
++		return len;
++
++	return strcmp(xa->name, xb->name);
+ }
+ 
+ static const char *find_ea_prefix(int index)
diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs_git.bb b/meta/recipes-devtools/e2fsprogs/e2fsprogs_git.bb
index 9ade1ff684..d4a19f9dde 100644
--- a/meta/recipes-devtools/e2fsprogs/e2fsprogs_git.bb
+++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs_git.bb
@@ -6,6 +6,7 @@ SRC_URI += "file://acinclude.m4 \
             file://run-ptest \
             file://ptest.patch \
             file://mkdir.patch \
+            file://xattr_ordering.patch \
 "
 
 SRCREV = "0f26747167cc9d82df849b0aad387bf824f04544"