lkml.org 
[lkml]   [2001]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Subtle NFS/VFS/GLIBC interaction bug
From
Date
>>>>> " " == 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/

\
 
 \ /
  Last update: 2005-03-22 13:29    [W:0.044 / U:0.644 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site