On Fri, 1 Sept 2023 at 08:20, Mateusz Guzik <mjguzik@xxxxxxxxx> wrote:
>
> I'm going to patch this, but first I want to address the bigger
> problem of glibc implementing fstat as newfstatat, demolishing perf of
> that op. In their defense currently they have no choice as this is the
> only exporter of the "new" struct stat. I'll be sending a long email
> to fsdevel soon(tm) with a proposed fix.
This ended up nagging me, and I looked it up.
You are correct that glibc seems to implement 'fstat()' as
'newfstatat(..AT_EMPTY_PATH)', which is a damn shame. We could
short-circuit that, but we really shouldn't need to.
Because you are incorrect when you claim that it's their only choice.
We have a native 'newfstat()' that glibc *should* be using.
We've had 'newfstat()' *forever*. It predates not just the git tree,
but the BK tree before it.
In fact, our 'newfstat()' system call goes back to Linux-0.97 (August
1, 1992), and yes, back then it really took a 'struct new_stat' as the
argument.
So I have no idea why you claim that "currently they have no choice".
glibc is simply being incredibly stupid, and using newfstatat() for no
good reason.
How very very annoying.
I guess we can - and now probably should - short-circuit the "empty
path with AT_EMPTY_PATH" case, but dammit, we shouldn't _need_ to.
Only because of excessive stupidity in user space does it look like we
should do it.
Why _is_ glibc doing that thing?
Linus
PS. On 32-bit x86, we also have 'stat64', but that has native
'fstat64()' support too, so that's no excuse. And it actually uses our
'unsafe_put_user()' infrastructure to avoid having to double copy,
mainly because it doesn't need to worry about the padding fields like
the generic 'cp_new_stat' does.
