Re: getdents64 problem

[Jakub Jelinek <jakub at redhat dot com>]

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