bug#73418: ls (GNU coreutils) 9.4 is extremely slower than ls (GNU coreutils) 8.32 listing files on a cifs mounted share

[Pádraig Brady]

On 03/10/2024 07:39, Paul Eggert wrote:
> On 2024-10-02 15:14, Pádraig Brady wrote:
> > I notice that tests/ls/getxattr-speedup.sh is failing now,
> > which I've not looked into yet.
>
> I'm not seeing that after the changes I committed this evening. If you
> can still reproduce it please let us know the details.

I can still repro.
I'm on BTRFS though I don't think that matters for this test.
I suspect the caching is being bypassed as we don't return ENOTSUP
in all cases where the underlying lgetxattr() returns ENOTSUP.
Actually in cases where the caching in file_has_aclinfo_cache()
is effective, and file_has_aclinfo() is bypassed, we get UMR
due to the uninitialized aclinfo struct.
So the whole interaction with file_has_aclinfo_cache() needs looking at.

If I remove the caching I also see issues with symlink handling,
where security contexts aren't read for symlinks.
Comparing system ls, with latest:
  $ ls -lZ INSTALL
  lrwxrwxrwx. 1 padraig padraig unconfined_u:object_r:user_home_t:s0 ...

  $ src/ls -lZ INSTALL
  lrwxrwxrwx 1 padraig padraig ? ...

I pushed two other fixes:

1. Since tests/ls/no-cap.sh is now always skipped.
I adjusted the test to avoid that.

2. ls -Z always output an error, so fixed up the
condition around the error() call in that case.

cheers,
Pádraig