From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-3.7 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 84C461F4B4 for ; Tue, 13 Oct 2020 21:21:26 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B08D43941C1D; Tue, 13 Oct 2020 21:21:25 +0000 (GMT) Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.10]) by sourceware.org (Postfix) with ESMTPS id B62A8386F455 for ; Tue, 13 Oct 2020 21:21:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B62A8386F455 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=denx.de Authentication-Results: sourceware.org; spf=none smtp.mailfrom=lukma@denx.de Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 4C9pPs36r9z1rtZg; Tue, 13 Oct 2020 23:21:21 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 4C9pPs2WNkz1qrFH; Tue, 13 Oct 2020 23:21:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new, port 10024) with ESMTP id VYsR0j6x-a0g; Tue, 13 Oct 2020 23:21:20 +0200 (CEST) X-Auth-Info: 3t/PneT+NS3q8PazpMKYkUNveK3U4E/iIEdWl5vqI3g= Received: from jawa (85-222-111-42.dynamic.chello.pl [85.222.111.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Tue, 13 Oct 2020 23:21:19 +0200 (CEST) Date: Tue, 13 Oct 2020 23:20:55 +0200 From: Lukasz Majewski To: Adhemerval Zanella Subject: Re: [PATCH 15/16] linux: Add {f}stat{at} y2038 support Message-ID: <20201013232055.5790b3ec@jawa> In-Reply-To: References: <20200723194641.1949404-1-adhemerval.zanella@linaro.org> <20200723194641.1949404-16-adhemerval.zanella@linaro.org> <20201006114802.1450d29b@jawa> <99a35800-d0ed-5561-b36b-4416f041ab5d@linaro.org> <331ab260-ef82-8e94-7148-5522fdb6e195@linaro.org> <20201013155838.0e61252b@jawa> <250a2b16-f06a-7215-bb8a-445511a4976f@linaro.org> Organization: denx.de X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/.TwCr7e.NeMg1t08x3NGLcL"; protocol="application/pgp-signature" X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Alistair Francis , libc-alpha@sourceware.org Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" --Sig_/.TwCr7e.NeMg1t08x3NGLcL Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Adhemerval, > On 13/10/2020 11:18, Adhemerval Zanella wrote: > >=20 > >=20 > > On 13/10/2020 10:58, Lukasz Majewski wrote: =20 > >> Hi Adhemerval, > >> =20 > >>> On 07/10/2020 09:52, Adhemerval Zanella wrote: =20 > >>>> > >>>> > >>>> On 06/10/2020 06:48, Lukasz Majewski wrote: =20 > >>>>> Hi Adhemerval, > >>>>> =20 > >>>>>> 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. =20 > >>>>> > >>>>> 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. =20 > >>>> > >>>> Hi Lukasz, thanks to remind me. I will rebase against master and > >>>> run some regressions tests against some platforms and push it. > >>>> =20 > >>> > >>> 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}). > >>> =20 > >> > >> 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. =20 > >=20 > > 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? =20 > >=20 > > 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. > >=20 > > I will check on a different kernel/system with a 32-bit kernel. =20 >=20 > 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. >=20 > The issue is at: >=20 > elf/dl-load.c >=20 > 1982 if (here_any && (err =3D errno) !=3D ENOENT && err !=3D EACCES) > 1983 /* The file exists and is readable, but something went > wrong. */ 1984 return -1; >=20 > 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. >=20 > 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=20 > currently implement the y2038 support with INLINE_SYSCALL_CALL=20 > (a function that succeeds is allowed to change errno and it > simplifies the resulting y2038 support a bit). >=20 > 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). =20 >=20 > 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): >=20 > 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 =3D 0; > - int err; > =20 > /* 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 =3D errno) !=3D ENOENT && err !=3D EACCES) > - /* The file exists and is readable, but something went wrong. > */ > - return -1; > =20 > /* Remember whether we found anything. */ > any |=3D here_any; >=20 >=20 I've tested this patch and it doesn't fix my issue. >=20 >=20 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 --Sig_/.TwCr7e.NeMg1t08x3NGLcL Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEgAyFJ+N6uu6+XupJAR8vZIA0zr0FAl+GGjcACgkQAR8vZIA0 zr2e8Af6AxtRXIhnN2fCXDu1e/NU6qD2ImRYvc8+TsPgmUCNQNn0mihi0fQ2S2jT uM44nzOIxKYABdZiGBrY+7u3jle2R6WkGSXRa4/5FqwMxFgvLX2S1+7eC1dEBcCS 72EYd3ifSeSu0Agz6+94I+in8bgT5gJCfOY4VeFd4YEcM92agNtDUSThJJ9bd2/d OQT9PCYEk9yak7k3KOGq4vMgF0es2NF+Ypwjk3rkZ15vO6iTwu2DY5n86WTtIc+R Hksr5FiWHnGzYd+drR88PR2bq2gofKWbxCX1AJyhvEosRnp7z+WUPNfdcd81GiPS 1Ic4dYq+gkgHTYAv/qwM4iO/MXHmzw== =0e3r -----END PGP SIGNATURE----- --Sig_/.TwCr7e.NeMg1t08x3NGLcL--