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

adhemerval.zanella at linaro dot org sourceware-bugzilla@sourceware.org
Tue Dec 11 20:54:00 GMT 2018


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

--- Comment #24 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(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).  Though if you want telldir 
> / seekdir to work in this case, maybe you do need to get the properly 
> truncated value from the kernel (and also to add LFS versions of telldir / 
> seekdir that work with directories too large for long on 32-bit systems).

One issue I can think of, if I am reading the ext4 code correctly, is the hash
is encoded on high bits of d_off:

fs/ext4/dir.c:

302 /*
303  * These functions convert from the major/minor hash to an f_pos
304  * value for dx directories
305  *
306  * Upper layer (for example NFS) should specify FMODE_32BITHASH or
307  * FMODE_64BITHASH explicitly. On the other hand, we allow ext4 to be
mounted
308  * directly on both 32-bit and 64-bit nodes, under such case, neither
309  * FMODE_32BITHASH nor FMODE_64BITHASH is specified.
310  */
311 static inline loff_t hash2pos(struct file *filp, __u32 major, __u32 minor)
312 {
313         if ((filp->f_mode & FMODE_32BITHASH) ||
314             (!(filp->f_mode & FMODE_64BITHASH) && is_32bit_api()))
315                 return major >> 1;
316         else
317                 return ((__u64)(major >> 1) << 32) | (__u64)minor;
318 }

It means that to mimic the FMODE_32BITHASH / 32 bits API we will need to return
the 32 high bits, which might not be correct for other filesystems.

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


More information about the Glibc-bugs mailing list