From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 79A113944424; Sat, 3 Oct 2020 13:54:38 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 79A113944424 From: "fweimer at redhat dot com" To: glibc-bugs@sourceware.org Subject: [Bug libc/23960] [2.28 Regression]: New getdents{64} implementation breaks qemu-user Date: Sat, 03 Oct 2020 13:54:37 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: 2.28 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: fweimer at redhat dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2020 13:54:38 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D23960 --- Comment #66 from Florian Weimer --- (In reply to Danny Milosavljevic from comment #62) > (In reply to Florian Weimer from comment #60) > > (In reply to Danny Milosavljevic from comment #59) > > > It's impossible to store a 64 bit result into a 32 bit slot. > >=20 > > You can do something like that if you can maintain a translation table. >=20 > Mathematically speaking, no, you can't. There cannot be a 1:1 mapping > between all 64 bit values and all 32 bit values. >=20 > I know what you mean--in practice it could be good enough, if the directo= ry > doesn't have too many entries (or, depending on implementation, telldir > isn't called too often--though first that implementation with only telldir > doing the counting has to be possible. Is it?). >=20 > But that's just kicking the can down the road--eventually, someone somewh= ere > will have that many entries. And then, the mapping will fail. Most Linux file systems use some hash-based approach, so that they do not h= ave to maintain a separate lookup table for seeking in directories. A simple of= fset does not work because there are POSIX (and quality-of-implementation) requirements that after seekdir, the same sequence of entries is produced e= ven if unrelated directory entries are created and removed. Because of the hash= ing involved, directories with tens of millions of entries may run into problems even with a 64-bit hash. If a file system uses a separate data structure for directory seeking, it w= on't have a problem to generate 30-bit offsets, in which case glibc could avoid translation completely (if it reserves the offsets in the range INT_MAX/2 += 1 =E2=80=A6 INT_MAX for translation, which should be large enough). --=20 You are receiving this mail because: You are on the CC list for the bug.=