[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 #20 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to James Clarke from comment #19)
> (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?

>From a kernel standpoint, I think it is the case: new ports will only provide
the LFS variants (I think the idea is essentially the same for 64 time_t). The
issue is glibc only sets off_t being off64_t for LP64 architectures. I am not
sure how hard would be for newer 32-bit ports to not provide non-LFS variants,
although I think it is doable (it would require a arch-specific typesizes.h
plus some adjustments I think).

Unfortunately, we have nios2 which still provides non-LFS variants through
glibc.

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