Re: fstat(2) penalized by using newfstatat(6, "", buf, AT_EMPTY_PATH)

[Linus Torvalds <torvalds@linux-foundation.org>]

On Tue, 5 Sept 2023 at 10:28, Adhemerval Zanella Netto
<adhemerval.zanella@linaro.org> wrote:
>
> I think we can still make it in a generic way, stat family would use more
> syscall (which some filters might complain) but it should be ok:

Ugh. That patch of yours certainly seems to avoid the kernel overhead
(where that "fetch a byte from user space just to check it is '\0'" is
much more expensive than it is in user space), but why does glibc do
that whole "turn fstat() into fstatat(), and then turn it back again"?

It seems just stupid. If the user asked for 'fstat()', just give the
user 'fstat()'.

Your patch literally adds *complexity*, rather than take it away.

Is this all just because glibc did its own 'struct stat'
implementation way back when, and you want to have just one place
where the stat conversion is done?

Can't you just special case *that* case instead? It's long been
irrelevant. Afaik, on 32-bit x86, you just want to use the 'stat64'
system call family, and on 64-bit x86 you just use the regular 'stat'
family (yes, called 'newfstatat' for that one system call for internal
historial reasons), and there is no conversion needed.

IOW, all those wrappers just for 'struct stat' conversion are pure
overhead and silly garbage. Why do they exist? And if there is still
some other reason for them to exist, can't you make that be a
'sysdeps' file of its own, and not penalize all the sane cases with
'copy stat structures around'?

            Linus