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

Sure that’s fine (regarding copyright), just let me know what to fill out please. On Wed, Apr 15, 2020 at 6:55 PM Paul Eggert wrote: > On 4/15/20 7:11 AM, Gregg Leventhal wrote: > > > +xattr_size = flistxattr(src_fd, list, size); > > +if ( xattr_size || errno == ERANGE ) > > Surely this

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

On 4/15/20 7:11 AM, Gregg Leventhal wrote: +xattr_size = flistxattr(src_fd, list, size); +if ( xattr_size || errno == ERANGE ) Surely this should be 'if (flistxattr (src_fd, NULL, 0) < 0 && errno == ERANGE)'. If you agree with this direction, I can continue, addressing other

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

Paul, Your understanding is correct. The problem in cp is that it uses acl_get_fd or acl_get_file which will always return an ACL on EXT4, therefore contriving an ACL to set on the target when it doesn't exist on the source. This causes an extraneous fsetxattr, and hits several arguably

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

On 4/8/20 7:15 AM, Gregg Leventhal wrote: rsync doesn't make set/get xattr calls and purports to preserve ACLs with -A. I'm not quite following your bug report, but it appears that you're saying that cp could somehow discover that it needn't use fgetxattr and fsetxattr on files that lack

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

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