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

[fweimer at redhat dot com]

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

--- Comment #25 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to joseph@codesourcery.com from comment #22)
> As d_off is an opaque value, can't __getdents just truncate without 
> producing an EOVERFLOW error?  As __getdents is a purely internal 
> function, its interface could be changed to return a truncation indication 
> or indeed to provide the full d_off value somehow - such truncation 
> indication only being relevant if telldir is used (which has a return type 
> of long int and no corresponding LFS version).

That pretty much breaks seekdir/telldir on top of getdents64 for 32-bit systems
unless the compat kludge described in comment 24 is active.  It's rather
annoying that LFS does not solve this.

If we want to get truly ambitious we could allocate our own file offsets in
telldir, so that they will fit into the 31 bits we have, keep the lookup tables
in the directory stream, and deallocate them on a call to closedir.  But that
would still be a waste on file systems which do the right thing internally
(such as XFS).  Maybe we could avoid doing this if the offsets in the result
buffer of getdents64 are monotonically increasing and sufficiently small, but
it's a lot of work for a fringe use case of a fringe feature.

It looks to me that qemu-user papers over this by truncating the values.  I'm
pretty sure that this will break seekdir on ext4, but apparently that's an
improvement over proper error checking.

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