GNU bug report logs -
#40509
Use of fsetxattr() in cp tickles an EXT leak (possibly unnecessarily so)
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
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.
[Message part 2 (text/html, inline)]
This bug report was last modified 5 years and 150 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.