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

[Mateusz Guzik <mjguzik@gmail.com>]

On 9/5/23, Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> wrote:
> 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.
>

I completely agree this is a problem going way past fstat.

One could be tempted to allow NULL with the flag, but that wont work
-- I know of code out there which checks for statx availability by
deliberately passing a NULL path. I would not be shocked if there was
more of the sort and passing the AT_EMPTY_PATH flag on top.

I am considering proposing a new flag which combined with NULL path
would indicate there is only a fd lookup to perform -- fuly backwards
compatible and avoiding the problem. Then syscalls could start
supporting it over time as people get around to it.

However, the fstab stub in glibc does not have to suffer it regardless
of what happens with the above.

-- 
Mateusz Guzik <mjguzik gmail.com>