Re: Subtle NFS/VFS/GLIBC interaction bug

From: Trond Myklebust (trond.myklebust@fys.uio.no)
Date: Mon Mar 12 2001 - 09:45:27 EST


>>>>> " " == Leon Bottou <leonb@research.att.com> writes:

> Note the strange numbers in the d_off fields. These are in
> fact cookies used internally by nfs. Under nfs2, these are 32
> bit unsigned number, sign extended to 64 bits.

> The last cookie has not been properly sign extended. The
> glibc-2.2.2 source code for readdir uses __NR_getdents64 and
> converts the result into 32 bit dirents. But it sees that the
> last d_ino cannot fit in an off_t and it simply bails out.

> There is already a problem in the making since nfs3 cookies are
> 64 bits long. But things should work with nfs2.

This is why I wish glibc would drop the whole idea of relying on
seekdir/telldir existing. The LFS does in fact not specify any
equivalent seekdir64/telldir64, and most implementations of *NIX don't
support them.
Currently, the VFS only allows us to support the minimum
implementation which is required to support the 32-bit interface.

> I can fix the problem using the following hack:

I've got a more complete one. See the 'IRIX' patch on

  http://www.fys.uio.no/~trondmy/src/2.4.2/linux-2.4.2-dir.dif

That patch also sign-extends 32-bit cookies at the NFS level, so that
we can
  a) convert cookies back so that the server accepts them
  b) match sign-extended 32-bit cookies in the page cache

> That is acceptable as long as filldir_t does not handle 64bits
> offsets anyway.

> But it won't last.

Yes and no. All NFSv3 implementations are supposed to support 32-bit
client implementations. All you lose here is the ability to handle
multi-Gigabyte directories.

Cheers,
  Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Thu Mar 15 2001 - 21:00:13 EST