Re: Urgent help needed on an NFS question, please help!!!

From: Xin Zhao
Date: Thu Aug 10 2006 - 02:13:59 EST


I found where the server checks the generation number. It's in fh_verify(). :)

Many thanks for your help, Neil!

-x

On 8/10/06, Xin Zhao <uszhaoxin@xxxxxxxxx> wrote:
I think nfs_compare_fh() might do the file handle verification task.
However, it is still possible that AFTER C1 gets a valid file handle,
BUT BEFORE C1 sends out the getattr() request, C2 deletes file X and
creates a different file X1 which has the same inode number. Looks
like the server side must verify the generation number carried in the
file handle. Unfortunately, I didn't find this code at the server
side. Any further insight on this?

Thanks,
Xin

On 8/10/06, Neil Brown <neilb@xxxxxxx> wrote:
> On Thursday August 10, uszhaoxin@xxxxxxxxx wrote:
> > I just ran into a problem about NFS. It might be a fundmental problem
> > of my current work. So please help!
> >
> > I am wondering how NFS guarantees a client didn't get wrong file
> > attributes. Consider the following scenario:
> >
> > Suppose we have an NFS server S and two clients C1 and C2.
> >
> > Now C1 needs to access the file attributes of file X, it first does
> > lookup() to get the file handle of file X.
> >
> > After C1 gets X's file handle and before C1 issues the getattr()
> > request, C2 cuts in. Now C2 deletes file X and creates a new file X1,
> > which has different name but the same inode number and device ID as
> > the nonexistent file X.
> >
> > When C1 issues getattr() with the old file handle, it may get file
> > attribute on wrong file X1. Is this true?
> >
> > If not, how NFS avoid this problem? Please direct me to the code that
> > verifies this.
>
> Generation numbers.
>
> When the filesystem creates a new file it assigns a random number
> as the 'generation' number and stores that in the inode.
> This gets included in the filehandle, and checked when the filehandle
> lookup is done.
>
> Look for references to 'i_generation' in fs/ext3/*
>
> Other files systems may approach this slightly differently, but the
> filesystem is responsible for providing a unique-over-time filehandle,
> and 'generation number' is the 'standard' way of doing this.
>
> NeilBrown
>

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