lkml.org 
[lkml]   [2001]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: problems with reiserfs + nfs using 2.4.2-pre4
On Tuesday February 20, zippel@fh-brandenburg.de wrote:
> Hi,
>
> On Tue, 20 Feb 2001, Neil Brown wrote:
>
> > 2/ lookup("..").
>
> A small question:
> Why exactly is this needed?
>
> bye, Roman

Having read the subsequent posts, I now see what you are thinking and
know how to answer this.

The problem that I see is indeed related to rename, but not in the way
that Trond mentions. (Tronds issue is a real, though very different,
issue).

Suppose I have a directory path

/a/b/c/d/e/f/g

Where filehandle X refers to /a/b and filehande Y refers to
/a/b/c/d/e/f/g

Then an NFS request comes in saying

RENAME X/c to Y/h

If this was performed, then you would end up with a directory path

/a/b

and a disconnected loop:


d/e/f/g/h
^ v
+-------+

which is not good.
This possibility is protected against by the VFS layer. It serialises
all directory renames using s_vfs_rename_sem and then checks that the
source of the rename isn't an ancestor of the target.
For this check to be reliable, each dentry for a directory must be
properly connected to the root.

Now if you have a filesystem that:

- cannot do ".." lookups efficiently, or doesn't want to and
- can protect against this sort of loop (and any other issues that
the VFS usually protects against) itself

then it can (with my patch) simply define decode_fh and encode_fh and
do whatever it likes, such as create a dentry that isn't properly
connected.

get_parent is only called by nfsd_find_fh_dentry which is a helper
routine which is normally called by the decode_fh function (and is
called by the default decode_fh function).
If a filesystem provides it's own decode_fh which doesn't call
nfsd_find_fh_dentry, then get_parent won't be called and isn't needed.

NeilBrown

-
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:17    [W:0.099 / U:7.460 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site