This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/23960] [2.28 Regression]: New getdents{64} implementation breaks qemu-user


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]