<handwaving> There is no problem here </handwaving>
invalidate_list, prune_icache, generic_delete_inode, and
generic_forget_inode all move the inode off of the inode hash before
setting the I_FREEING flag. So inodes in I_FREEING state can not be
found by find_inode.
Clear inode bugs when the inode is not I_FREEING, it then clears out the
inode and sets I_CLEAR. As a result, inodes in I_CLEAR state can not be
found by find_inode either.
So you can safely remove that test in ilookup.
> > > 4) If anything, as Christoph Hellwig suggested to me on #kernel,
> > > iget{,5}_locked() should be reimplemented in terms of my ilookup()
> > > implementation and not vice versa. (-:
> >
> > Well, considering that this function (modulo the I_FREEING|I_CLEAR test
> > is identical to the first 10 lines in iget5_locked, this could call that
> > function. Ofcourse iget_locked is using the 'fast' version of find_inode.
>
> Yes, indeed, and yes. I recall that Al wanted the _fast() versions to
> remain separate. This can be done easily enough here, too. For example
> ilookup() and ilookup5() (to remain consistent with iget5() or if you
> have a better idea for a name...).
I have no problem with the name. And coda_fid_to_inode could use
ilookup5 as well, as currently uses iget with the 'set_fail' trick.
Jan
-
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/