From: Lukasz Majewski <lukma@denx.de>
To: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Cc: Alistair Francis <alistair.francis@wdc.com>, libc-alpha@sourceware.org
Subject: Re: [PATCH 15/16] linux: Add {f}stat{at} y2038 support
Date: Tue, 13 Oct 2020 23:20:55 +0200 [thread overview]
Message-ID: <20201013232055.5790b3ec@jawa> (raw)
In-Reply-To: <bb0ff901-219b-7b39-1d2e-08400acc7ab4@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 5669 bytes --]
Hi Adhemerval,
> On 13/10/2020 11:18, Adhemerval Zanella wrote:
> >
> >
> > On 13/10/2020 10:58, Lukasz Majewski wrote:
> >> Hi Adhemerval,
> >>
> >>> On 07/10/2020 09:52, Adhemerval Zanella wrote:
> >>>>
> >>>>
> >>>> On 06/10/2020 06:48, Lukasz Majewski wrote:
> >>>>> Hi Adhemerval,
> >>>>>
> >>>>>> A new struct __stat{64}_t64 type is added with the required
> >>>>>> __timespec64 time definition. Both non-LFS and LFS support
> >>>>>> were done with an extra __NR_statx call plus a conversion to
> >>>>>> the new __stat{64}_t64 type. The statx call is done only for
> >>>>>> architectures with support for 32-bit time_t ABI.
> >>>>>>
> >>>>>> Internally some extra routines to copy from/to struct stat{64}
> >>>>>> to struct __stat{64} used on multiple implementations (stat,
> >>>>>> fstat, lstat, and fstatat) are added on a extra file
> >>>>>> (stat_t64_cp.c). Aslo some extra routines to copy from statx
> >>>>>> to __stat{64} is added on statx_cp.c.
> >>>>>>
> >>>>>> Checked with a build for all affected ABIs. I also checked on
> >>>>>> x86_64, i686, powerpc, powerpc64le, sparcv9, sparc64, s390, and
> >>>>>> s390x.
> >>>>>
> >>>>> When do you plan to pull this patch set to -master?
> >>>>> Those patches have been available for review on the mailing list
> >>>>> for more than two months now.
> >>>>
> >>>> Hi Lukasz, thanks to remind me. I will rebase against master and
> >>>> run some regressions tests against some platforms and push it.
> >>>>
> >>>
> >>> One required change with the rebase is adapt the riscv32 ABI to
> >>> exclude the __{f,l}xstat{at} symbol and replace with proper
> >>> {f,l}stat ones. It is possible because the new ABI was added on
> >>> current development branch, however one minor inconvenient is the
> >>> toolchain need to be rebuild with a updated glibc branch to avoid
> >>> linking failures with libstd++ (which uses __{f,l}xstat{at}).
> >>>
> >>
> >> I'm not sure if this is related, but on my ARMv7 (32 bit) sandbox
> >> there is an issue with fstat accesses to files.
> >>
> >> When I try to run a program build against newest glibc (installed
> >> in /opt/lib) I do see issues with {f}stat on other libraries (e.g.
> >> /opt/lib/librt.so). To be more specific I do experience the
> >> EOVERFLOW error:
> >>
> >> error while loading shared libraries: librt.so.1: cannot stat
> >> shared object: Error 75
> >>
> >> The "base" glibc is 2.28 (installed in /lib). The glibc under test
> >> is the newest master installed in /opt/lib.
> >>
> >> I'm now investigating this issue.
> >
> > I am not sure what it might be based on these information, could you
> > provide a strace so we can pinpoint what might the issue?
> >
> > The arm-linux-gnueabihf testing I did was on a aarch64 kernel
> > (4.12.13). Besides the make check without regression, I could run
> > system binaries with ./testrun.sh.
> >
> > I will check on a different kernel/system with a 32-bit kernel.
>
> Ok, this change in fact triggered a very subtle issue at dl-load.c
> that I saw in both arm-linux-gnueabihf system with a 32-bit kernel
> and on mips-linux-gnu.
>
> The issue is at:
>
> elf/dl-load.c
>
> 1982 if (here_any && (err = errno) != ENOENT && err != EACCES)
> 1983 /* The file exists and is readable, but something went
> wrong. */ 1984 return -1;
>
> And it is just triggered on system where {f,l}stat{at}{64} issues
> __NR_statx and it fails with ENOSYS but later success with the system
> stat* syscall.
>
> This code here checks the errno value without checking whether the
> previous function call that might change err actually has failed
> (in this specific case the stat64 at line 1931). And this due how we
> currently implement the y2038 support with INLINE_SYSCALL_CALL
> (a function that succeeds is allowed to change errno and it
> simplifies the resulting y2038 support a bit).
>
> In fact this check does not really make sense, since either 'fd' will
> be different than '0' (meaning it has being opened) or the 'stat64'
> at line 1931 failed and 'here_any' won't be set (the stat64 at line
> 1951 already explicit sets errno in failure case).
>
> Also, git history does not give much information on why it was added
> at fist place. So I think we just need to remove this extra check,
> you can check if the following patch helps (I am running some
> regression tests before sensing it upstream):
>
> diff --git a/elf/dl-load.c b/elf/dl-load.c
> index f3201e7c14..39ae43c6ce 100644
> --- a/elf/dl-load.c
> +++ b/elf/dl-load.c
> @@ -1878,7 +1878,6 @@ open_path (const char *name, size_t namelen,
> int mode, size_t cnt;
> char *edp;
> int here_any = 0;
> - int err;
>
> /* If we are debugging the search for libraries print the path
> now if it hasn't happened now. */
> @@ -1979,9 +1978,6 @@ open_path (const char *name, size_t namelen,
> int mode, return -1;
> }
> }
> - if (here_any && (err = errno) != ENOENT && err != EACCES)
> - /* The file exists and is readable, but something went wrong.
> */
> - return -1;
>
> /* Remember whether we found anything. */
> any |= here_any;
>
>
I've tested this patch and it doesn't fix my issue.
>
>
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-10-13 21:21 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-23 19:46 [PATCH 00/16] Add y2038 support for stat functions Adhemerval Zanella via Libc-alpha
2020-07-23 19:46 ` [PATCH 01/16] linux: Always define STAT_IS_KERNEL_STAT Adhemerval Zanella via Libc-alpha
2020-07-24 8:17 ` Lukasz Majewski
2020-07-23 19:46 ` [PATCH 02/16] linux: Define STAT64_IS_KERNEL_STAT64 Adhemerval Zanella via Libc-alpha
2020-07-24 8:20 ` Lukasz Majewski
2020-07-23 19:46 ` [PATCH 03/16] linux: Consolidate xstat{64} Adhemerval Zanella via Libc-alpha
2020-07-23 20:51 ` Joseph Myers
2020-07-24 8:34 ` Lukasz Majewski
2020-09-09 14:46 ` Lukasz Majewski
2020-09-09 18:05 ` Adhemerval Zanella via Libc-alpha
2020-09-10 7:10 ` Lukasz Majewski
2020-07-23 19:46 ` [PATCH 04/16] linux: Consolidate lxstat{64} Adhemerval Zanella via Libc-alpha
2020-07-24 8:43 ` Lukasz Majewski
2020-07-23 19:46 ` [PATCH 05/16] linux: Consolidate fxstat{64} Adhemerval Zanella via Libc-alpha
2020-07-24 9:04 ` Lukasz Majewski
2020-07-23 19:46 ` [PATCH 06/16] linux: Consolidate fxstatat{64} Adhemerval Zanella via Libc-alpha
2020-07-24 9:14 ` Lukasz Majewski
2020-07-23 19:46 ` [PATCH 07/16] Linux: Consolidate xmknod Adhemerval Zanella via Libc-alpha
2020-07-24 9:14 ` Lukasz Majewski
2020-07-23 19:46 ` [PATCH 08/16] Remove internal usage of extensible stat functions Adhemerval Zanella via Libc-alpha
2020-07-24 9:16 ` Lukasz Majewski
2020-07-23 19:46 ` [PATCH 09/16] Remove stat wrapper functions, move them to exported symbols Adhemerval Zanella via Libc-alpha
2020-07-24 9:23 ` Lukasz Majewski
2020-07-23 19:46 ` [PATCH 10/16] Remove mknod wrapper functions, move them to symbols Adhemerval Zanella via Libc-alpha
2020-07-23 20:53 ` Joseph Myers
2020-07-23 20:58 ` Adhemerval Zanella via Libc-alpha
2020-07-23 21:01 ` Joseph Myers
2020-07-24 9:25 ` Lukasz Majewski
2020-10-12 22:27 ` Joseph Myers
2020-10-13 0:58 ` Adhemerval Zanella via Libc-alpha
2020-07-23 19:46 ` [PATCH 11/16] linux: Move the struct stat{64} to struct_stat.h Adhemerval Zanella via Libc-alpha
2020-07-24 9:27 ` Lukasz Majewski
2020-07-23 19:46 ` [PATCH 12/16] linux: Implement {l}fstat{at} in terms of fstatat Adhemerval Zanella via Libc-alpha
2020-07-24 9:29 ` Lukasz Majewski
2020-07-23 19:46 ` [PATCH 13/16] linux: Disentangle fstatat from fxstatat Adhemerval Zanella via Libc-alpha
2020-07-24 9:39 ` Lukasz Majewski
2020-07-24 10:25 ` Florian Weimer via Libc-alpha
2020-07-24 14:39 ` Adhemerval Zanella via Libc-alpha
2020-07-23 19:46 ` [PATCH 14/16] linux: Move {f}xstat{at} to compat symbols Adhemerval Zanella via Libc-alpha
2020-07-24 9:40 ` Lukasz Majewski
2020-10-21 5:21 ` __xstat et al. as compat symbols (was: Re: [PATCH 14/16] linux: Move {f}xstat{at} to compat symbols) Florian Weimer via Libc-alpha
2020-10-21 11:59 ` Adhemerval Zanella via Libc-alpha
2020-10-21 12:57 ` __xstat et al. as compat symbols Florian Weimer via Libc-alpha
2020-10-21 13:09 ` Adhemerval Zanella via Libc-alpha
2020-10-22 10:08 ` Florian Weimer via Libc-alpha
2020-10-22 12:43 ` Adhemerval Zanella via Libc-alpha
2020-10-22 15:37 ` Florian Weimer via Libc-alpha
2020-10-22 16:40 ` Adhemerval Zanella via Libc-alpha
2020-10-22 18:04 ` Adhemerval Zanella via Libc-alpha
2020-07-23 19:46 ` [PATCH 15/16] linux: Add {f}stat{at} y2038 support Adhemerval Zanella via Libc-alpha
2020-07-23 20:55 ` Joseph Myers
2020-07-23 21:00 ` Adhemerval Zanella via Libc-alpha
2020-07-24 10:53 ` Lukasz Majewski
2020-07-30 12:42 ` Adhemerval Zanella via Libc-alpha
2020-08-02 19:46 ` Maciej W. Rozycki via Libc-alpha
2020-10-06 9:48 ` Lukasz Majewski
2020-10-07 12:52 ` Adhemerval Zanella via Libc-alpha
2020-10-07 14:25 ` Adhemerval Zanella via Libc-alpha
2020-10-07 20:20 ` Lukasz Majewski
2020-10-07 21:01 ` Adhemerval Zanella via Libc-alpha
2020-10-07 21:07 ` Adhemerval Zanella via Libc-alpha
2020-10-08 7:57 ` Lukasz Majewski
2020-10-09 14:05 ` Adhemerval Zanella via Libc-alpha
2020-10-09 15:39 ` Lukasz Majewski
2020-10-09 20:06 ` Adhemerval Zanella via Libc-alpha
2020-10-13 13:58 ` Lukasz Majewski
2020-10-13 14:18 ` Adhemerval Zanella via Libc-alpha
2020-10-13 14:23 ` H.J. Lu via Libc-alpha
2020-10-13 14:27 ` Adhemerval Zanella via Libc-alpha
2020-10-13 18:14 ` Adhemerval Zanella via Libc-alpha
2020-10-13 21:20 ` Lukasz Majewski [this message]
2020-10-13 21:40 ` Lukasz Majewski
2020-10-14 13:15 ` Lukasz Majewski
2020-10-14 13:39 ` Adhemerval Zanella via Libc-alpha
2020-07-23 19:46 ` [PATCH 16/16] linux: Move xmknoda{at} to compat symbols Adhemerval Zanella via Libc-alpha
2020-07-24 10:30 ` Florian Weimer via Libc-alpha
2020-07-24 12:34 ` Adhemerval Zanella via Libc-alpha
2020-07-24 12:43 ` Florian Weimer via Libc-alpha
2020-07-24 12:49 ` Adhemerval Zanella via Libc-alpha
2020-07-24 10:43 ` Lukasz Majewski
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
List information: https://www.gnu.org/software/libc/involved.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201013232055.5790b3ec@jawa \
--to=lukma@denx.de \
--cc=adhemerval.zanella@linaro.org \
--cc=alistair.francis@wdc.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).