From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 46572398C810; Fri, 2 Oct 2020 10:41:43 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 46572398C810 From: "danny.milo at gmail dot com" To: glibc-bugs@sourceware.org Subject: [Bug libc/23960] [2.28 Regression]: New getdents{64} implementation breaks qemu-user Date: Fri, 02 Oct 2020 10:41:42 +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: danny.milo at gmail 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: Fri, 02 Oct 2020 10:41:43 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D23960 --- Comment #61 from Danny Milosavljevic --- (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. T= he > kernel cannot do it due to the way the getdents64 system call works. glibc > can do it for telldir/seekdir (allocating table slots on demand), which a= re > the interfaces that are actually problematic. > LFS does not change the return type of telldir. >So it does not fix the issue.=20 I know what you mean. Given the seekdir and telldir interface as it is now, mandating LFS does not fix telldir and seekdir, because they use "long", not "off_t". The correct solution is to change the POSIX standard, too. Short term, that won't be done. But it still SHOULD be done. In the mean time, I agree, you could make a mapping table for the rare cases where telldir and seekdir are actually used. The question is where to store the latest (64 bit) d_off in the mean time (until telldir is called and you need it)... However, the current practical problem is much worse: 32 bit apps on 64 bits cannot reliably call *readdir* without using LFS. So far, Guix distribution has had to patch: gcc's libstdc++-v3, libidn2, fontconfig, libtasn1, openssl, libtool/libltdl, rhash, cmake-bootstrap, cma= ke, cyrus-sasl in order to even be able to *compile any end user program* as a distribution using cmake. That had broken the entire distribution on 32 bi= t, to the point I'm now asking to remove 32 bit support entirely from our homepage. Just to be clear, that is *without* using qemu. This problem affects even 32 bit distributions without LFS on 32 bit kernels (that is not a typo)! And if you enable LFS, it totally works fine in practice. I estimate that compared to that, seekdir users are few. And I agree that those users still have a problem even after enabling LFS. > We need to maintain a translation table for telldir and seekdir in > DIR. It can be filled on demand, so that applications that do not call > telldir are pretty much unaffected. The only thing that is a bit tricky is > that we have to pre-allocate the slot during readdir because telldir must > not fail. I argue the easiest fixing step to do is still to mandate LFS. Then glibc works in practice. Without, it *really* does not work--even in theory. But sure, also put workarounds into telldir and seekdir. If possible. Is = it possible? (readdir has been broken the last few glibc releases--I had thought it was = my imagination that the compilation of gcc would always be stuck in an endless loop on armhf--but now it all makes sense). --=20 You are receiving this mail because: You are on the CC list for the bug.=