linux-kernel - Re: [PATCH v3] vfs: support statx(..., NULL, AT_EMPTY

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6ba5b3a01715326d2a0aee11db5cbc7cb7bce59d.camel@xry111.site>
Date: Wed, 26 Jun 2024 11:15:47 +0800
From: Xi Ruoyao <xry111@...111.site>
To: Mateusz Guzik <mjguzik@...il.com>, brauner@...nel.org
Cc: viro@...iv.linux.org.uk, jack@...e.cz, linux-kernel@...r.kernel.org, 
	linux-fsdevel@...r.kernel.org, io-uring@...r.kernel.org, axboe@...nel.dk, 
	torvalds@...ux-foundation.org, loongarch@...ts.linux.dev
Subject: Re: [PATCH v3] vfs: support statx(..., NULL, AT_EMPTY_PATH, ...)

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@...il.com>
> ---
> 
> Diffed against fs-next and assumes c050122bdbb4 ("fs: new helper
> vfs_empty_path()") from vfs.empty.path is already applied.
> 
> WARNING: io_uring remains untested (modulo compilation). I presume
> Jens has a handy way of making sure things still work. 

For non-io_uring part:

On LoongArch the time usage of 10000000 calls:

baseline
Glibc fstat: ./a.out  0.44s user 3.56s system 99% cpu 4.013 total
bare statx:  ./a.out  0.39s user 3.54s system 99% cpu 3.927 total

patched
Glibc fstat: ./a.out  0.49s user 1.34s system 99% cpu 1.841 total
bare statx:  ./a.out  0.42s user 1.32s system 99% cpu 1.748 total
statx NULL:  ./a.out  0.44s user 1.29s system 99% cpu 1.734 total

Tested-by: Xi Ruoyao <xry111@...111.site>

-- 
Xi Ruoyao <xry111@...111.site>
School of Aerospace Science and Technology, Xidian University