Re: [PATCH 3/3] NFS: Detect loops in a readdir due to bad cookies

[NeilBrown <neilb@suse.de>]

On Wed, 23 Mar 2011 14:48:35 -0400 Trond Myklebust
<Trond.Myklebust@netapp.com> wrote:

> On Wed, 2011-03-23 at 14:42 -0400, peter.staubach@emc.com wrote:
> > Although I think that it is a good thing to protect the client against broken servers, it does seem like the right solution is to get the server fixed...
> 
> Don't get me wrong: I fully agree with that!

Ack.

As I understand it, ext4 (and ext3) use the hash of the basename as the
cookie.  This hash has a per-directory random seed which is hidden so it is
not possible to deliberately create files with the same hash, but thanks to
the birthday paradox it isn't too hard to get collisions in a suitably large
directory.

For 'readdir' ext4 keeps extra state in the 'struct file' so that it knows
where it was up to in a list of names with the same hash and so won't return
duplicates.  However if you telldir/seekdir you will restart at the start of
the sequence (I think).

Assuming that the fs always delivers names-with-the-same-cookie in a
contiguous set (which seems likely), NFSD could mitigate this problem by
treating them as a unit.
i.e. to a given READDIR request, it either returns all names with a
particular cookie, or none of them.
This could only work if the set of names with the one cookie fits inside a
single reply, but that should be likely unless the rsize is tiny.

nfsd should also, after lseeking to the given address, skip over any
subsequent entries that have the same address.
This would ensure no looping happened, and the first step would make it
unlikely that names were missed.

It would be nice if filesystems would get this right, but I think it is
reasonable for NFSD to take steps like this to guard against unfortunate
filesystem design.

NeilBrown