bug#40509: Use of fsetxattr() in cp tickles an EXT leak (possibly unnecessarily so)

[Gregg Leventhal]

This bug <https://patchwork.criu.org/patch/7413/> in EXT4 leaks posix_acl
allocations causing unreclaimable slab allocations to grow unbounded in the
kmalloc-64 cache.

It turns out that most of the problems we are having due to that leak is
due to programs making heavy use of "cp -a" or any of the cp --preserve
arguments that call fsetxattr.




*$ echo example1 > file$ strace -e fgetxattr,fsetxattr -f cp -a file
file2fgetxattr(3, "system.posix_acl_access", 0x7ffef5a38ce0, 132) = -1
ENODATA (No data available)fsetxattr(4, "system.posix_acl_access",
"\2\0\0\0\1\0\6\0\377\377\377\377\4\0\6\0\377\377\377\377
\0\4\0\377\377\377\377", 28, 0) = 0*

Mainly, I am concerned about this behavior because there are no ACLs, we
don't use them, so what is it setting?
















* $ getfacl file2# file: file2# owner: gleventhal# group:
techuser::rw-group::rw-other::r--$ touch new$ getfacl new# file: new#
owner: gleventhal# group: techuser::rw-group::rw-other::r--*

This is an ext4 file system with kernel 3.10.0-1062.18.1.el7 - CentOS Linux
release 7.7.1908 (Core)

rsync doesn't make set/get xattr calls and purports to preserve ACLs with
-A.

Thanks for listening, please let me know if I can provide more
information.  I hope all of you are doing well during this trying time in
our civilization.