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

["adhemerval.zanella at linaro dot org" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=23960

--- Comment #39 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Florian Weimer from comment #38)
> 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.

Ok, so this my understanding as well. To make it clear the truncation and thus
the issue only happens when a binary runs with a qemu-system built without LFS,
so the question is which build step in debian buildd infrastructure is not
being built with LFS support. The idea is once binaries are not using non-LFS
getdents anymore this issue won't happen.

> 
> I hope this summary makes sense.

-- 
You are receiving this mail because:
You are on the CC list for the bug.