[PATCH] for glibc-2.2 getdents code

[Trond Myklebust]

>>>>> " " == Jakub Jelinek <jakub@redhat.com> writes:

     > But d_type should be completely orthogonal to LFS. It is not
     > present in sys_getdents simply because sys_getdents was there
     > before d_type was introduced and as userland getdents can call
     > sys_getdents64 to get d_type, I have not added sys_newgetdents.
     > IMHO the fix is really simple, if kernel nfs client will cast
     > the offset for NFSv2 properly (it goes as 32bit value over the
     > network AFAIC), then the problem will go away. And if people
     > are using NFSv3 and the server passes d_off's which don't fit
     > into 32bit off_t, then IMNSHO kernel sys_getdents should fail
     > on it the same way as glibc getdents does, because it is better
     > to give user error than incorrect information (= silently
     > discarded bits from d_off).

No! No! No! How on earth is NFS supposed to know where a cookie came
from and whether or not a sign extension has been performed on it?
Is the cookie 0xFFFFFFFF80000001 on an NFSv3 system a sign extended
32-bit cookie 0x80000001, is it a full 64-bit cookie or what???

I agree that sys_getdents could return EOVERFLOW if we have 64-bit
cookies, however that is not an excuse for glibc to be playing around
with valid 32-bit cookies.

A cookie is an opaque value and cannot be processed.

Cheers,
  Trond