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: <6afb4e1e2bad540dcb4790170c42f38a95d369bb.camel@xry111.site>
Date: Wed, 25 Sep 2024 22:30:18 +0800
From: Xi Ruoyao <xry111@...111.site>
To: Mateusz Guzik <mjguzik@...il.com>, brauner@...nel.org, Miao Wang
	 <shankerwangmiao@...il.com>
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>

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@...111.site>
School of Aerospace Science and Technology, Xidian University