This bug 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 file2
fgetxattr(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: tech
user::rw-
group::rw-
other::r--

$ touch new
$ getfacl new
# file: new
# owner: gleventhal
# group: tech
user::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.