On Tue, 2024-06-25 at 17:18 +0200, Mateusz Guzik wrote:
> The newly used helper also checks for empty ("") paths.
>
> NULL paths with any flag value other than AT_EMPTY_PATH go the usual
> route and end up with -EFAULT to retain compatibility (Rust is abusing
> calls of the sort to detect availability of statx).
>
> This avoids path lookup code, lockref management, memory allocation
> and
> in case of NULL path userspace memory access (which can be quite
> expensive with SMAP on x86_64).
>
> Benchmarked with statx(..., AT_EMPTY_PATH, ...) running on Sapphire
> Rapids, with the "" path for the first two cases and NULL for the last
> one.
>
> Results in ops/s:
> stock: 4231237
> pre-check: 5944063 (+40%)
> NULL path: 6601619 (+11%/+56%)
>
> Signed-off-by: Mateusz Guzik <mjguzik@xxxxxxxxx>
Hi Mateusz and Christian,
There's a special case, AT_FDCWD + NULL + AT_EMPTY_PATH, still resulting
EFAULT, while AT_FDCWD + "" + AT_EMPTY_PATH is OK (returning the stat of
current directory).
I know allowing NULL with AT_FDCWD won't produce any performance gain,
but it seems the difference would make the document of the API more
nasty.
So is it acceptable to make the kernel "hide" this difference, i.e.
accept AT_FDCWD + NULL + AT_EMPTY_PATH as-is AT_FDCWD + "" +
AT_EMPTY_PATH?
--
Xi Ruoyao <xry111@xxxxxxxxxxx>
School of Aerospace Science and Technology, Xidian University
