getdents64 problem
Jakub Jelinek
jakub@redhat.com
Tue Jan 23 01:18:00 GMT 2001
On Tue, Jan 23, 2001 at 10:07:25AM +0100, Trond Myklebust wrote:
> >>>>> " " == Jakub Jelinek <jakub@redhat.com> writes:
>
> > Actually, are you talking NFSv2 or NFSv3 to the SGI server? If
> > you're talking NFSv2 which passes around 32bit cookies as far
> > as I can see, then this is definitely a kernel bug (at least in
> > my 2.4-testsomething tree nfs_decode_dirent does
> > entry-> cookie = ntohl(*p++);
> > which is wrong (dunno if that changed since then), because
> > ntohl gives unsigned result).
>
> The NFSv2 cookie is a u32 value. It's being stored in a u64. Where's
> the kernel bug?
You're passing that unmodified u64 value to filldir which is off_t (ie.
signed 32 or 64bit), so IMHO you basically have 2 options, either
sign-extend it at cookie assignment time, or find out if cookie comes from
NFSv2 protocol (inherently 32bit) and sign-extend cookies before passing
them to filldir (in both cases do nothing about NFSv3 cookies).
>
> I agree we need some translation of cookies if we're to support 'seek'
> operations correctly, however at the kernel level, it's working fine.
>
> BTW: why does glibc need that lseek?
glibc uses seek if getdents{,64} fails to seek to the first unprocessed
dirent. Anyway, this issue is not related to lseek at all,
the issue comes when glibc tries to convert the last entry's dirent64
d_off (0x00000000ffffffffULL in this case) to 32bit d_off, which is not
possible because 4GB-1 does not fit into signed 32bit range, thus glibc
fails to convert the last entry.
Jakub
More information about the Libc-alpha
mailing list