[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#40509: Use of fsetxattr() in cp tickles an EXT leak (possibly unnece
From: |
Gregg Leventhal |
Subject: |
bug#40509: Use of fsetxattr() in cp tickles an EXT leak (possibly unnecessarily so) |
Date: |
Wed, 8 Apr 2020 10:15:51 -0400 |
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.
- bug#40509: Use of fsetxattr() in cp tickles an EXT leak (possibly unnecessarily so),
Gregg Leventhal <=