[Ocfs2-devel] a patch for ocfs2_link

Mark Fasheh mark.fasheh at oracle.com
Thu Aug 31 20:26:02 PDT 2006


On Thu, Aug 31, 2006 at 08:06:33PM -0700, Joel Becker wrote:
> > -       if (inode->i_nlink >= OCFS2_LINK_MAX) {
> > -               err = -EMLINK;
> > -               goto bail;
> > -       }
> > -
> 
> 	Why is this redundant?  Is someone doing it for us?  I see we
> check the fe->i_links_count below, but that's after the expense of a
> cluster lock.  Don't we save some effort here?
It's wrong because the i_nlink might be stale. We might actually be able to
insert, but we don't know until we have the cluster lock.


> > @@ -661,6 +656,11 @@ static int ocfs2_link(struct dentry *old
> >                goto bail;
> >        }
> > 
> > +       if (!dir->i_nlink) {
> > +               err = -ENOENT;
> > +               goto bail;
> > +       }
> > +
> 
> 	And what does this do?  If a directory...oh, wait, is this to
> check for a directory that's going away?  Can this actually happen?  I'd
> think that the VFS would protect it.
Again, the link count might be stale, so we have to double check after
getting the lock. The way I imagine this could happen is if the dir inode is
orphaned and a process attempts to do a create (imagine if it was unlinked
while someone still had a shell open there)

There are similar checks in ocfs2_symlink() and ocfs2_mknod() which Tiger is
basing that one on.


Granted, neither of these conditions are particularly likely, but we should
protect against them nonetheless.
	--Mark

--
Mark Fasheh
Senior Software Developer, Oracle
mark.fasheh at oracle.com



More information about the Ocfs2-devel mailing list