From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id uPUmCMPybV8nZwAA0tVLHw (envelope-from ) for ; Fri, 25 Sep 2020 13:38:11 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id 2KDxA8PybV8cUQAAbx9fmQ (envelope-from ) for ; Fri, 25 Sep 2020 13:38:11 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id AF94E940876 for ; Fri, 25 Sep 2020 13:38:10 +0000 (UTC) Received: from localhost ([::1]:43154 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kLnvN-0001gv-9W for larch@yhetil.org; Fri, 25 Sep 2020 09:38:09 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59962) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kLnvG-0001eC-1t for guix-patches@gnu.org; Fri, 25 Sep 2020 09:38:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:59748) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kLnvF-0007Z9-Nq for guix-patches@gnu.org; Fri, 25 Sep 2020 09:38:01 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kLnvF-0000h4-Ly for guix-patches@gnu.org; Fri, 25 Sep 2020 09:38:01 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#43591] [PATCH core-updates] gnu: glibc-final: Catch all cases of a glibc user not requesting 64-bit offsets and then using readdir. Resent-From: Danny Milosavljevic Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Fri, 25 Sep 2020 13:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43591 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Marius Bakke Cc: 43591@debbugs.gnu.org Received: via spool by 43591-submit@debbugs.gnu.org id=B43591.16010410642641 (code B ref 43591); Fri, 25 Sep 2020 13:38:01 +0000 Received: (at 43591) by debbugs.gnu.org; 25 Sep 2020 13:37:44 +0000 Received: from localhost ([127.0.0.1]:43061 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kLnux-0000gX-Od for submit@debbugs.gnu.org; Fri, 25 Sep 2020 09:37:43 -0400 Received: from dd26836.kasserver.com ([85.13.145.193]:54482) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kLnuv-0000gO-R7 for 43591@debbugs.gnu.org; Fri, 25 Sep 2020 09:37:42 -0400 Received: from localhost (80-110-126-103.cgn.dynamic.surfer.at [80.110.126.103]) by dd26836.kasserver.com (Postfix) with ESMTPSA id 0A27433682F4; Fri, 25 Sep 2020 15:37:39 +0200 (CEST) Date: Fri, 25 Sep 2020 15:36:46 +0200 From: Danny Milosavljevic Message-ID: <20200925153646.6ef95908@scratchpost.org> In-Reply-To: <20200925122004.38275411@scratchpost.org> References: <20200924141211.21649-1-dannym@scratchpost.org> <87363759at.fsf@gnu.org> <20200924222711.2f22281a@scratchpost.org> <87tuvm4vop.fsf@gnu.org> <20200925122004.38275411@scratchpost.org> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-unknown-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/9ibAGn0cyY4gCY7.bZl8l_y"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-Spam-Score: -1.7 (-) X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-patches-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Spam-Score: -1.11 X-TUID: SN4jHt3jKdTo --Sig_/9ibAGn0cyY4gCY7.bZl8l_y Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable > >Why is this not an issue with i686 on x86_64 kernels? =20 >=20 > I'm not sure. I'll check. $ cat a00.c #include #if defined( __ILP32__ ) #warning ILP32 #endif int main() { return sizeof(off_t); } $ LC_ALL=3DC guix environment -s i686-linux gcc-toolchain -- gcc -o a00 a00= .c a00.c:3:2: warning: #warning ILP32 [-Wcpp] 3 | #warning ILP32 | ^~~~~~~ $ ./a00 $ echo $? 4 That means they are using the Linux kernel's X86_32 ABI. It has its own getdents64 system call that returns another value for d_off. $ LC_ALL=3DC guix environment -s i686-linux gcc-toolchain -- gcc -o a00 -D_= FILE_OFFSET_BITS=3D64 a00.c a00.c:3:2: warning: #warning ILP32 [-Wcpp] 3 | #warning ILP32 | ^~~~~~~ $ ./a00 $ echo $? 8 That is why __i686__ is not affected--at the cost of the kernel lying to us about the file system. Note that I also tried printing the actual d_off values[1]--on ILP32, even = with _FILE_OFFSET_BITS=3D64, the VALUES are still 32 bits, and the same values as without _FILE_OFFSET_BITS. The d_off SLOT gets bigger on _FILE_OFFSET_BITS= =3D64. (I also tried printing the actual d_off values[1] on x86_64 without any guix environment -s, I get entirely different d_off values!!) I also tried the former on native ARMHF--you get 32 bits d_off values. And= d_off is always the same size as off_t. off_t size changes depending on _FILE_OFFSET_BITS. I do not have access to a real aarch64 machine--so no idea how it is there. That would be the most interesting case, because those don't have X86_32, so ILP32 is either not present or implemented differently. ppc64 would also be interesting... Test result of [1]: system _FILE_OFFSET_BITS off_t d_off-sizeof d_off-values ------------------------------------------------------------- x86_64 - 8 Byte 8 Byte 8 Byte i686 - 4 Byte 4 Byte 4 Byte i686 64 8 Byte 8 Byte 4 Byte i686 32 4 Byte 4 Byte 4 Byte i686 7 4 Byte 4 Byte 4 Byte armhf - 4 Byte 4 Byte 4 Byte armhf 64 8 Byte 8 Byte 4 Byte armhf 32 4 Byte 4 Byte 4 Byte armhf 7 4 Byte 4 Byte 4 Byte This is all without qemu--in order to simplify the test case. So I take it ext4 has some special compilation mode for 32 bits... Could someone please test [1] on (real!) aarch64 and ppc64 and ppc32 machines? [1] $ cat a00.c=20 #include #include #include #include #if defined( __ILP32__ ) #warning ILP32 #endif int main() { DIR* d; struct dirent* ent; d =3D opendir("/tmp"); errno =3D 0; assert(sizeof(ent->d_off) =3D=3D sizeof(off_t)); while ((ent =3D readdir(d)) !=3D NULL) { printf("%llu\n", (unsigned long long) ent->d_off); } if (errno) perror("readdir"); return sizeof(off_t); --Sig_/9ibAGn0cyY4gCY7.bZl8l_y Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl9t8m4ACgkQ5xo1VCww uqWmVQf9Gy9Y5HXJyFlOOnywiaIBQuhAmEry1kSYKv0CEwwlZDsMmNyYbKZeMtMS AY5mw0zxZ215+47xTDqys5GOKKn6Iq6DgVw96Ts+sig945Crw52Aey/XIzrGrEaM 9sJ7xIIcLZuBUlOye9QtctB7tgDhCw9afjKfkB4nwnvPP3H6c+sOIcZiEH4OY3VQ 3xN40ErTBY+PovHojfvdiKy/7spTibocYxC5xWOaAXBIkaP6Xj1m7ySk96A4WF/8 WycJHuSsrVn/QEbens03akkCeME0ZDVZkQd0O12FZ3zL01aNB7EBZa3vjGxkcWSM H4oBddMV8VfQ2CzJeK4nsNz8FmFU2Q== =14ua -----END PGP SIGNATURE----- --Sig_/9ibAGn0cyY4gCY7.bZl8l_y--