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

[jrtc27 at jrtc27 dot com]

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

--- Comment #19 from James Clarke <jrtc27 at jrtc27 dot com> ---
(In reply to Adhemerval Zanella from comment #18)
> (In reply to James Clarke from comment #17)
> > (In reply to Florian Weimer from comment #16)
> > > (In reply to James Clarke from comment #15)
> > > > You're right that this isn't a proper fix; QEMU currently just truncates
> > > > d_off for __NR_getdents on 32-bit targets, but that's what it's always (FSVO
> > > > always) done. At least with __NR_getdents on 32-bit targets it knows that
> > > > userspace wants a 32-bit d_off, though. With __NR_getdents64, what should
> > > > QEMU do?
> > > 
> > > Check if the emulated userspace runs in long mode.  If it does, use the
> > > kernel-supplied 64-bit value.  If it does not, do whatever the kernel does
> > > to produce the d_off value.
> > > 
> > > There must be many system calls where something like this is necessary.
> > 
> > Except this behaviour is filesystem-specific and *only* occurs on ext4. If
> > you have a big enough directory in BTRFS you will get back a value bigger
> > than 2^32 even on i386. For ext4 we'd need to convert it, but for BTRFS we'd
> > need to report EOVERFLOW. We can't support both simultaneously without
> > horrendous probing and hard-coding the encoding of d_off for ext4 which I
> > would assume is meant to be an implementation detail that could change.
> 
> Sigh, alright I would really like to avoid this workaround on glibc but it
> looks like it seems the most straightforward issue.  
> 
> However, new 32-bits ABI which only provides getdents64 such as nios2 and
> possible newer one as sky, arc, and riscv32; will continue to be broken:
> glibc will still provide non-LFS interfaces for such cases (since off_t will
> defined as long int regardless). It will be fixed only when we really phase
> out non-LFS support for good, especially for newer ports.

Sounds to me like any port without a getdents system call should have only LFS
(much like how new ports should have a 64-bit time_t forced upon them), using
the kernel's lack of support as motivation. Are there any current 32-bit ports
that only have getdents64?

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