Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 7 Oct 2023 17:09:27 -0400
From: Rich Felker <>
Subject: Re: [PATCH v2] pass AT_NO_AUTOMOUNT when emulating fstatat
 via statx

On Sat, Oct 07, 2023 at 09:02:18PM +0300, Alexey Izbyshev wrote:
> AT_NO_AUTOMOUNT is implied for stat/lstat/fstatat syscalls since Linux
> 3.1 [1]. However, this is not the case for statx syscall, which defaults
> to automounting, so this flag must be passed explicitly when statx is
> used to implement stat-like functions.
> This change affects only arches which use 32-bit seconds in struct kstat,
> as well as out-of-tree/future ports to arches which lack SYS_fstatat.
> [1]
> ---
> Fixed the wrong statement about affected arches in the commit message.

Indeed, statx is always used on 32-bit archs. 32-bit archs with no
legacy 32-bit kernel timespec struct (i.e. rv32) don't have the legacy
stat syscalls either.

> ---
>  src/stat/fstatat.c | 1 +
>  1 file changed, 1 insertion(+)
> diff --git a/src/stat/fstatat.c b/src/stat/fstatat.c
> index 04506375d897..9eed063b26bc 100644
> --- a/src/stat/fstatat.c
> +++ b/src/stat/fstatat.c
> @@ -36,6 +36,7 @@ static int fstatat_statx(int fd, const char *restrict path, struct stat *restric
>  {
>  	struct statx stx;
> +	flag |= AT_NO_AUTOMOUNT;
>  	int ret = __syscall(SYS_statx, fd, path, flag, 0x7ff, &stx);
>  	if (ret) return ret;
> -- 
> 2.39.2

I think this is ok. I recall noticing something about this when
initially adding it but not being sure what behavior the legacy stat
syscall would give or whether it's "right". But short of a very good
reason to differ from the kernel default (which would then require
changing other archs to match), I think we just need to make it
consistent with what happens on other archs.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.