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

[Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>]

On 04/09/23 07:11, Mateusz Guzik via Libc-alpha wrote:
> On 9/4/23, Andreas Schwab <schwab@suse.de> wrote:
>> On Sep 04 2023, Mateusz Guzik via Libc-alpha wrote:
>>
>>> Commit 4d97cc8cf3da ("io: Remove xstat implementations") reimplemented
>>> fstat entry point on top of newfstatat (as opposed to newfstat).
>>
>> You are looking at the wrong commit.  See 30f1c74394 instead.
>>
> 
> I still got the right person and the question stands. ;)
> 

The glibc has started to implement some symbols over more generic syscalls
because it simplifies *a lot* the required code (just check how messy was the
stat family implementation back then).  So I would really like to avoid the
need to get back on arch-specific syscall to fix very specific corner cases.

If I understand correctly, the issue seems to be the usage of a empty string 
sentinel ("") to indicate the argument it not really used (which trigger all
the SMAP issues since kernel will always try to copy the argument from
userland).  This also means on x86_64 you will also have this performance
penalty on syscalls that use AT_EMPTY_PATH (i.e, execveat, name_to_handle_at,
open_tree, faccessat, etc.).  I really think it would better fixed in the
kernel instead of adding extra constraints for the userland.

CCing Rich, from musl, which seems to be also affected it and to have another
view from a libc implementation.