This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/23960] [2.28 Regression]: New getdents{64} implementation breaks qemu-user
- From: "fweimer at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Tue, 30 Apr 2019 17:50:32 +0000
- Subject: [Bug libc/23960] [2.28 Regression]: New getdents{64} implementation breaks qemu-user
- Auto-submitted: auto-generated
- References: <bug-23960-131@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=23960
--- Comment #38 from Florian Weimer <fweimer at redhat dot com> ---
I feel we are running in circles here. Let me summarize what I think is going
on.
The core issue is that neither POSIX nor glibc have an LFS interface for
seekdir/telldir, and the d_off value is expected to be compatible with the
non-LFS seekdir, telldir functions.
The kernel implements an arbitrary truncation for both getdents and getdents64
(so both LFS and non-LFS interfaces) when running 32-bit compat mode. It is
not possible at all to get the same truncation in 64-bit mode. qemu-user fakes
a *different* truncation when emulating the getdents system call. Since hardly
anyone uses d_off/seekdir/telldir, this does not matter.
With the range checking for d_off in the current glibc implementation of
getdents, we suddenly insist on a 32-bit-compatible d_off value from a
getdents64 system call in 32-bit compat mode, like the actual kernel implements
this.
So I think without new kernel/userspace APIs, the only way to fix this is to
change the binaries running under qemu-user (and not qemu-user itself) to LFS
interfaces, and stop using telldir/seekdir, in favor of d_off from
readdir64/LFS-readdir with lseek64/LFS-lseek.
I hope this summary makes sense.
--
You are receiving this mail because:
You are on the CC list for the bug.