[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