public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Stefan Liebler <stli@linux.ibm.com>
To: libc-alpha@sourceware.org
Subject: Re: [PATCH 1/5] linux: Implement fstatat with __fstatat64_time64
Date: Fri, 26 Mar 2021 10:24:23 +0100	[thread overview]
Message-ID: <5970116c-2af3-2f02-d526-e89008d36f18@linux.ibm.com> (raw)
In-Reply-To: <20210319183121.2252064-2-adhemerval.zanella@linaro.org>

On 19/03/2021 19:31, Adhemerval Zanella via Libc-alpha wrote:
> It makes fstatat use __NR_statx, which fix the s390 issue with
> missing nanoxsecond support on compat stat syscalls (at least
> on recent kernels) and limits the statx call to only one function
> (which simplifies the __ASSUME_STATX support).
> 
> Checked on i686-linux-gnu and on powerpc-linux-gnu.
> ---
>  sysdeps/unix/sysv/linux/fstatat.c | 52 +++++++------------------------
>  1 file changed, 11 insertions(+), 41 deletions(-)
> 
> diff --git a/sysdeps/unix/sysv/linux/fstatat.c b/sysdeps/unix/sysv/linux/fstatat.c
> index 59efff615f..618c254d6f 100644
> --- a/sysdeps/unix/sysv/linux/fstatat.c
> +++ b/sysdeps/unix/sysv/linux/fstatat.c
> @@ -26,33 +26,19 @@
>  int
>  __fstatat (int fd, const char *file, struct stat *buf, int flag)
>  {
> -  int r;
> -
> -# if STAT_IS_KERNEL_STAT
> -  /* New kABIs which uses generic pre 64-bit time Linux ABI, e.g.
> -     csky, nios2  */
> -  r = INTERNAL_SYSCALL_CALL (fstatat64, fd, file, buf, flag);
> -  if (r == 0 && (buf->__st_ino_pad != 0
> -		 || buf->__st_size_pad != 0
> -		 || buf->__st_blocks_pad != 0))
> -    return INLINE_SYSCALL_ERROR_RETURN_VALUE (EOVERFLOW);
> -# else
> -#  ifdef __NR_fstatat64
> -  /* Old KABIs with old non-LFS support, e.g. arm, i386, hppa, m68k, mips32,
> -     microblaze, s390, sh, powerpc, and sparc.  */
> -  struct stat64 st64;
> -  r = INTERNAL_SYSCALL_CALL (fstatat64, fd, file, &st64, flag);
> +  struct __stat64_t64 st64;
> +  int r = __fstatat64_time64 (fd, file, &st64, flag);
>    if (r == 0)
>      {
>        if (! in_ino_t_range (st64.st_ino)
>  	  || ! in_off_t_range (st64.st_size)
> -	  || ! in_blkcnt_t_range (st64.st_blocks))
> +	  || ! in_blkcnt_t_range (st64.st_blocks)
> +	  || ! in_time_t_range (st64.st_atim.tv_sec)
> +	  || ! in_time_t_range (st64.st_mtim.tv_sec)
> +	  || ! in_time_t_range (st64.st_ctim.tv_sec))
>  	return INLINE_SYSCALL_ERROR_RETURN_VALUE (EOVERFLOW);
OK
> 
> -      /* Clear internal pad and reserved fields.  */
> -      memset (buf, 0, sizeof (*buf));
Do we have to clear the user provided struct as before?

> -
> -      buf->st_dev = st64.st_dev,
> +      buf->st_dev = st64.st_dev;
>        buf->st_ino = st64.st_ino;
>        buf->st_mode = st64.st_mode;
>        buf->st_nlink = st64.st_nlink;
> @@ -62,27 +48,11 @@ __fstatat (int fd, const char *file, struct stat *buf, int flag)
>        buf->st_size = st64.st_size;
>        buf->st_blksize = st64.st_blksize;
>        buf->st_blocks  = st64.st_blocks;
> -      buf->st_atim.tv_sec = st64.st_atim.tv_sec;
> -      buf->st_atim.tv_nsec = st64.st_atim.tv_nsec;
> -      buf->st_mtim.tv_sec = st64.st_mtim.tv_sec;
> -      buf->st_mtim.tv_nsec = st64.st_mtim.tv_nsec;
> -      buf->st_ctim.tv_sec = st64.st_ctim.tv_sec;
> -      buf->st_ctim.tv_nsec = st64.st_ctim.tv_nsec;
> -
> -      return 0;
> +      buf->st_atim = valid_timespec64_to_timespec (st64.st_atim);
> +      buf->st_mtim = valid_timespec64_to_timespec (st64.st_mtim);
> +      buf->st_ctim = valid_timespec64_to_timespec (st64.st_ctim);
>      }
> -#  else
> -  /* 64-bit kabi outlier, e.g. mips64 and mips64-n32.  */
> -  struct kernel_stat kst;
> -  r = INTERNAL_SYSCALL_CALL (newfstatat, fd, file, &kst, flag);
> -  if (r == 0)
> -    r = __cp_kstat_stat (&kst, buf);
> -#  endif /* __nr_fstatat64  */
> -# endif /* STAT_IS_KERNEL_STAT  */
> -
> -  return INTERNAL_SYSCALL_ERROR_P (r)
> -	 ? INLINE_SYSCALL_ERROR_RETURN_VALUE (-r)
> -	 : 0;
> +  return r;
>  }
> 
>  weak_alias (__fstatat, fstatat)
> 
OK

  parent reply	other threads:[~2021-03-26  9:24 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-19 18:31 [PATCH 0/5] More stat fixes Adhemerval Zanella
2021-03-19 18:31 ` [PATCH 1/5] linux: Implement fstatat with __fstatat64_time64 Adhemerval Zanella
2021-03-23 16:13   ` Stefan Liebler
2021-03-26  9:24   ` Stefan Liebler [this message]
2021-03-26 19:32     ` Adhemerval Zanella
2021-03-19 18:31 ` [PATCH 2/5] linux: Disable fstatat64 fallback if __ASSUME_STATX is defined Adhemerval Zanella
2021-03-26  9:24   ` Stefan Liebler
2021-03-26 19:38     ` Adhemerval Zanella
2021-03-19 18:31 ` [PATCH 3/5] linux: Use statx for MIPSn64 Adhemerval Zanella
2021-03-29 12:48   ` Adhemerval Zanella
2021-04-01  0:07   ` Maciej W. Rozycki
2021-04-01 12:45     ` Adhemerval Zanella
2021-04-01 18:00       ` Maciej W. Rozycki
2021-03-19 18:31 ` [PATCH 4/5] support: Add support_path_support_time64_value Adhemerval Zanella
2021-03-26  9:24   ` Stefan Liebler
2021-03-19 18:31 ` [PATCH 5/5] linux: Add y2106 support on utimensat tests Adhemerval Zanella
2021-03-26  9:24   ` Stefan Liebler
2021-03-26 19:40     ` Adhemerval Zanella

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5970116c-2af3-2f02-d526-e89008d36f18@linux.ibm.com \
    --to=stli@linux.ibm.com \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).