Re: Possible NFS client 2.2.9 kernel bug and fix

Trond Myklebust (trond.myklebust@fys.uio.no)
Tue, 25 May 1999 11:23:37 +0200 (CEST)


>>>>> " " == Tom Shield <shield@aem.umn.edu> writes:

> Trond, I agree my patch is wrong that it cuts off long
> directories, I should have noticed this sooner.

> However, I don't think it is a glibc 2.1 issue, I first noticed
> this problem using the stock RH5.2 glibc, I upgraded to 2.1 to
> see it that was the problem and it did not go away.

> I don't know the source of this problem, there definitely is a
> short (93 entries) directory that does not get the EOF bit set
> correctly, any hints of where to look would be appreciated. I
> do believe my analysis of the possible infinite loop if the EOF
> bit does not get set is correct.

> I'll take another look and let you know if I figure anything
> out, maybe even correctly this time.

I suggest you start by checking whether the server is indeed sending
you an eof. This is the only way NFS allows us to tell whether we've
reached the end of the directory or not (using the inode 'size' or
other such tricks are usually quite meaningless). Try using the
following printk:

Cheers,
Trond

--- fs/nfs/nfs2xdr.c-orig Sat Mar 6 23:21:13 1999
+++ fs/nfs/nfs2xdr.c Tue May 25 11:11:18 1999
@@ -481,6 +481,7 @@
*entry++ = fileid;
*entry++ = cookie;
*entry++ = ((string - start) << 16) | status | (len & 0x7FFF);
+ if (status) printk ("Readdirres found eof!\n");
}
#ifdef NFS_PARANOIA
printk("nfs_xdr_readdirres: %d entries, ent sp=%d, str sp=%d\n",

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